Figured I'd chime in since I wrote the code in question. The band edge FLL is probably the wrong thing to use, but it did work surprisingly well for my local setup (at very high SNR), so I left it in. The square-and-FFT block works great for MSK, but Smartnet isn't MSK, it's FSK, and its lack of phase coherence (and variable deviation) mean you won't see those nice 1/2-bitrate FFT spikes.
As Andy points out, the "right" answer is to correlate against the modulated preamble and develop phase, frequency, and timing estimates from the known preamble.
--n
On Oct 18, 2014 6:41 AM, "Andy Walls" <
address@hidden> wrote:
On Fri, 2014-10-17 at 12:00 -0400, address@hidden
wrote:
> Message: 33
> Date: Fri, 17 Oct 2014 07:37:25 -0700
> From: John Malsbury <address@hidden>
> To: Luke Berndt <address@hidden>
> Cc: "address@hidden List" <address@hidden>
> Subject: Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7
> Message-ID:
> <CAK+fQffv_gbGbq7DimJM0DiD=address@hidden>
> Content-Type: text/plain; charset="utf-8"
>
> Also, my understanding for the PLL blocks were that they were ideal for
> "strong carrier" signals like AM. When I say strong carrier i mean a
> signal that has an obvious carrier which isn't "hidden" under modulation..
John and Luke,
Yup. GMSK doesn't have any narrow and strong spectral feature on which
one can lock a PLL. (And the band-edge FLL is the wrong thing to use
too.)
You can however get a spectral feature from the square of the GMSK
signal. *Assuming* you have an approximately random bit stream,
squaring the GMSK signal gives you spectral peaks at f_c +/- f_b/2,
where f_c is the center frequency and f_b is your bit rate. See the
attached "GMSK_squared_spectrum.png" which shows the spectra from a
random bit stream.
So you can get a non-data-aided coarse frequency correction doing
essentially what older versions of gr-ais did. See the attached
"square_and_fft_freq_sync.grc.png". The gr-ais "freqest" block is the
only non-stock gnuradio block and it just walks the FFT looking for the
spectral peaks at +/- f_b/2 and outputs a frequency correction values
based on how many FFT bins the peaks are offset from the expected center
frequency.
The major tradeoff is the length of the FFT:
1. More FFT points gives you finer resolution bins and a finer
correction.
2. More FFT points protects against pathological data sequences (e.g. a
long run of 0's) that give different spectral peaks which screw up the
correction.
3. Fewer FFT points ensures the start and end of bursts get the proper
correction as the correction reacts faster to the transition from
dead-air to modulated signal.
4. Fewer FFT points ensures faster reaction to changes in frequency
offset.
Although, if you have a known preamble to inspect, data-aided carrier
frequency offset correction is way better than the above non-data-aided
stuff.
Regards,
Andy
> Anyway, the GMSK block might be a good place to start.
>
> -John
>
> On Fri, Oct 17, 2014 at 7:35 AM, John Malsbury <address@hidden
> > wrote:
>
> > It doesn't have frequency correction - I can probably follow up with some
> > ideas on how to implement that part. But the GMSK demod might do OK for
> > you initially. It doesn't do anything intelligent to deal with the data
> > shaping - its just a non-coherent slicer.
> >
> > If you want to design in GRC but keep your top-level application as is,
> > you can use a hier block. You can also use a command line parameter or
> > other mechanism to select your demodulator at start-time for easy
> > comparisons.
> >
> > [typed one handed.. my daughter has my other and]
> >
> > -John
> >
> > On Fri, Oct 17, 2014 at 7:08 AM, Luke Berndt <address@hidden> wrote:
> >
> >> Thanks for looking into it! To be honest, I am not really good at RF. I
> >> based my code off the python code in gr-smartnet. The fsk-demod python file
> >> is here:
> >> https://github.com/bistromath/gr-smartnet/blob/master/src/python/fsk_demod.py
> >>
> >> It is quite possible that it just happened to work because of an error
> >> that got patched in Gr 3.7.
> >>
> >> Are there some good examples for GMSK/FSK demodulation that I could
> >> borrow from instead?
> >>
> >> Recreating this in GRC sounds like a great idea so I can scope along the
> >> way. I will give that a try next.
> >>
> >> Thanks again for the pointers, fresh eyes are really helpful when you
> >> have been staring at it for so long.
> >>
> >> - Luke
> >>
> >> On Fri, Oct 17, 2014 at 8:18 AM, Martin Braun <address@hidden>
> >> wrote:
> >>
> >>> On 10/17/2014 08:28 AM, John Malsbury wrote:
> >>> > Also also, is the Band-Edge FLL ideal for GMSK? My possibly, incorrect
> >>> > understanding of that block is that it was more ideal for PAM with
> >>> > common RRC.
> >>>
> >>> For the record: It might work coincidentally because of the rolloff-y
> >>> shape of GMSK, but it's derived for and designed for common PAM/RRC, as
> >>> John says and I wouldn't recommend it for anything else.
> >>> To look up the math, I suggest Harris' works.
> >>>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> Discuss-gnuradio mailing list
> >> address@hidden
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio