|Subject:||Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7|
|Date:||Fri, 17 Oct 2014 07:37:25 -0700|
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]-JohnOn 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.pyIt 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.- LukeOn 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
|[Prev in Thread]||Current Thread||[Next in Thread]|