Re: [Discuss-gnuradio] Time sinks out of sync after adding and removing noise in simple FSK simulation

[James Wanga]

That's really helps me understand what's happening, thank you. I'm curious if this can be solved by sending packets instead of raw bytes. Is it correct to assume that sequence detection is one of the responsibilities of a packet decoder? I'm also curious if I there is any advantage to using a clock recovery block and binary slicer instead of the monolithic GFSK demod block? Stated another way. Is the GFSK demod block just a quadrature demod, clock recovery, and binary slicer rolled into one? 

Another thought is, once you loose symbol timing, do I need to then dynamically tweak the clock recovery settings (like mu) in order to realign?

James Wanga

On Sep 14, 2017, at 7:20 AM, Kevin Reid <address@hidden> wrote:

On Thu, Sep 14, 2017 at 12:08 AM, James Wanga <address@hidden> wrote:

I recently decided to simulate an FSK modulation scheme with a constant source, a noice source and 2 time sinks. The first time sink is pre-modulation and the second is post-modulation. When I first start the simulation, both time sinks display the same waveform as expected. When I add a strong noise signal in real time via a GUI entry the post-modulation time sink displays a randomly changing waveform again, as expected. However, when I reduce the noise source to 0, the post-modulated sink stabilizes to match the pre-modulated sink except that it is translated arbitrarily to the left or right. this causes an arbitrary byte to be spit out when the bits are repacked.

This is not an effect of your simulation but an actual problem in digital communication.

When you introduce noise, the GFSK Demod loses track of the actual symbol timing and so its estimate drifts freely. When you remove the noise, it locks on again starting at who-knows-what symbol out of your 8-symbol groups. The same problem would occur in a real receiver which does not share a clock with the transmitter, because you start in the no-information state.

If you want to recover properly aligned bytes (or packets, even) you need a way to detect where one begins. This is usually done with a known sequence of symbols at the beginning of a transmission. Unfortunately, I don't have experience with the digital blocks available in GNU Radio so I cannot tell you how to construct a working example.