[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7

From: Luke Berndt
Subject: Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7
Date: Mon, 3 Nov 2014 07:09:51 -0500

On the off chance that someone has some free time to look into this, I have built the Smartnet trunk control channel in GRC. I have also made a capture of the signal. Everything is working the way it does on my C++ program. It is able find a lot of frames where the preamble matches, but barely any of them bas the CRC test. The expected behavior is that there would be 2-3 frames that pass the CRC test every second, and that is how it works under 3.6.5.

The SmartNet stuff is rolled into 3.7 blocks. Git clone, cmake . , make, sudo make install

If anyone sees some obvious mistakes let me know. I know this not the ideal way to decode an FSK signal, but it works perfectly in 3.6.

Thanks for any pointers people have!

Capture of the signal:

GRC Blocks for Smartnet

GRC to decode Smartnet Tunking channel

Attachment: smartnet.grc
Description: Binary data

PNG image

On Oct 20, 2014, at 3:19 AM, Martin Braun <address@hidden> wrote:

On 10/18/2014 05:57 PM, Luke Berndt wrote:
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?

None of the DSP was changed, if it worked before it should(TM) still
work. The reason we say it's a bad choice is that it was derived for
PSK/PAM signals. The reason it still might work is that the
implementation runs 2 filters at the band-edges and compares the energy
content of those, and that difference might be sufficient to correct
your frequency offset if you have sufficient averaging (i.e. low enough
loop bandwidth).


Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]