Tom changed it to use the fir_filter_with_buffer vs. the standard fir_filter internally, but as the taps remain the same I'd imagine it to be more or less numerically identical.
First step I think is to verify that the FLL is actually the problem -- get a scope on the output of the FLL and see that your FSK signal is more or less at baseband. --n On Sat, Oct 18, 2014 at 8:57 AM, Luke Berndt <l...@robotastic.com> wrote: > Thanks! I clearly have a lot of RF theory to read up on. > > The Band Edge FLL works great for me too, on 3.6. Does anyone know if > there were changes to it or surrounding blocks in 3.7 that would make it > stop working? > > I have a pretty strong, clean signal. > > Sent from my iPhone > > On Oct 18, 2014, at 11:00 AM, Nick Foster <bistrom...@gmail.com> 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, 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
