> 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