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 <kpr...@switchb.org> wrote: > >> On Thu, Sep 14, 2017 at 12:08 AM, James Wanga <jwa...@gmail.com> 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.
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
