Re: FSK and Timing Recovery Questions

[Andy Walls]

> Message: 3
> Date: Wed, 8 Jan 2020 13:57:09 -0600
> From: Alex Roberts
> To: GNURadio Discussion List
> Subject: FSK and Timing Recovery Questions
> 
> Hello Mailing List,
> 
> Happy New Year!
> 
> I've been playing around with this (
> http://aaronscher.com/GNU_Radio_Companion_Collection/Audio_Modem_loop_back_test_FSK.html)
> FSK audio modem and have a few issues/questions.
> 
> 1) Is the PFB block the way to go for FSK timing recovery?

I recommend the new Symbol Synchronizer block.  It is a superset of all
the other GNURadio PLL timing recovery blocks, and it address a lot of
bugs that the old blocks have.  (To be fair the PFB clock-sync block is
the least buggy/best block of the old bunch.)

Please take a few minutes to read:
https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf

Slide 21 is where the theory ends and the practical begins.

>  I have issues
> where if I start the receiver before the transmitter, the system
> doesn't
> work. And if I start the transmitter before the receiver, it will
> eventually lose sync and never recover. I added a message strobe to
> send
> dummy data once a second (like a keep alive/heartbeat) and this helps
> it
> from losing sync in between time of when I send meaningful data.

Yeah, tracking loops can wander way off when there is no signal and it
trying to just track on noise.

With all fixed-gain PLL tracking loops (aka feedback tracking loop),
there is a trade off between long term tracking stability (low jitter)
and rapid acquisition.

The clock sync block's processing of the "time_est" tag or "clock_est"
tag is meant to be used in a data-aided timing acquisition scheme to
jump start packet symbol timing acquisition.  Some block ahead of the
symbol timing sync block needs to detect the preamble and then open-
loop, feedforward estimate where the center of one symbol is, and then
tag that symbol center.

> 1a) Reading docs on both PFB and M&M blocks, do I need a moving avg.
> filter
> after quad demod to round out the square pulses to allow PFB and M&M
> to
> better find peaks or is the moving avg filter implemented within the
> block?

The M&M block certainly needs a peaking filter, usually a matched
filter, out front.

The PFB clock sync block implements that filter for you.  However, it
crashes on filter designs for square pulses, because internally the PFB
clock-sync block builds a derivative matched filter.  That derivative
doesn't work out so well numerically with a square pulse filter as an
input parameter.


> 2) Is the pre-amble being muxed doing anything more than just padding
> my
> data to help the PFB lock in before actual data arrives?

Well that's part of the point of a preamble, to aid in symbol timing
acquisition.

Not that the PFB clock synch block does any of the following, but:

Preambles can also be used to estimate and correct carrier frequency
offset.

Preambles can also be used for adaptive channel equalization (e.g. RLS
or LMS adaptive filter).


> 3) Would the Correlation Estimator help since it can send "time_est"
> tags
> downstream to the PFB and if so, where would be the ideal place to
> put it?

Yes.  But that block tries to use an adaptive thresholding algorithm
that doesn't work well with preambles with poor auto-correlation
properties.

Regards,
Andy

> Cheers,
> Alex