On Sat, 2014-10-18 at 08:00 -0700, Nick Foster wrote: > 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,
Oops, I thought the thread was about GMSK. I guess I didn't read far enough back. :P Thanks Nick. -Andy > 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" <a...@silverblocksystems.net> > wrote: > On Fri, 2014-10-17 at 12:00 -0400, > discuss-gnuradio-requ...@gnu.org > wrote: > > > Message: 33 > > Date: Fri, 17 Oct 2014 07:37:25 -0700 > > From: John Malsbury <jmalsbury.perso...@gmail.com> > > To: Luke Berndt <l...@robotastic.com> > > Cc: "Discuss-gnuradio@gnu.org List" > <discuss-gnuradio@gnu.org> > > Subject: Re: [Discuss-gnuradio] Works with GR 3.6, breaks > with 3.7 > > Message-ID: > > <CAK+fQffv_gbGbq7DimJM0DiD=aGFz1RXekc7NaV > +xzimzqv...@mail.gmail.com> > > 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 > <jmalsbury.perso...@gmail.com > > > 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 > <l...@robotastic.com> 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 > <martin.br...@ettus.com> > > >> 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 > > >> Discuss-gnuradio@gnu.org > > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >> > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
