[Top][All Lists]

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

Re: [Discuss-gnuradio] Recording Moto II Digital Voice Talk Groups

From: Nick Foster
Subject: Re: [Discuss-gnuradio] Recording Moto II Digital Voice Talk Groups
Date: Tue, 13 Aug 2013 18:56:56 -0700

On Tue, Aug 13, 2013 at 6:52 PM, Luke B <address@hidden> wrote:
In DC the fire dept uses a Motorola SmartZone II trunking system and most of the talk groups use digital voice. I have gotten Nick Foster's GR-Smartnet code up and running and I am able to decode the trunking channel and record the NBFM version of the the Digital Voice in the talk groups. It manages to do this while hitting about 125% CPU utilization on an Intel I5.

Separately I have also gotten the OP25 code up and running and I am able to decode and listen to the digital voice if I just tune in one of the channels. I have also done this using the gr-DSD code, which packages up the DSD program into a gnu-radio block.

Here is where things get messy. I have tried taking the OP25 python code and also the gr-DSD python code that gets generated with the GRC files get parsed and tried integrating it into the gr-smartnet code. I have done this by replacing the orig sections in the logging_receiver.py that handled doing the NBFM demod with the code for decoding the digital voice. It actually works, and I can receive audio... the problem is that after program tunes in a talkgroup and starts playing or recording the audio, the other blocks that follow the trunking channel seem to stop listening.  The only real change is in the section that handles the audio, and there it is only the core section that does the decoding. If I switch it back to using the NBFM decoding, it runs fine and can both capture the audio and decode the trunking channel. Both the trunking channel decode and audio capture are taps off of the same source block.

I think it could be an issue with Python Threading. The audio thread just gets greedy and doesn't give back control. Or maybe the CPU utilization gets to high, it get up to 260% (of 400) or so.

So... am I foolish for trying to get this to work in Python? I am not good at Python, and I am not sure if it can handle something like this and if so what I would need to do to tune it. If so, are there good examples of programs that have multiple decoders running off of one RF source?

I am not horrible at C++. I am better off trying to write a C++ program that uses the GNURadio parts, but would let me come up with a better approach for threading.

Is there a better design approach to this that I am missing. I am trying to loosely model my system after the Super Trunking system that "RachelByTheBay" designed.

Thanks for any pointers! 

 - Luke

Well, the better approach would be for me to refactor gr-smartnet completely, but I haven't gotten around to that yet and gr-smartnet is suffering some pretty major bitrot.

Email me off-list and I'll work with you to get OP25/DSD working with gr-smartnet, it's something I need to do eventually anyway.


Discuss-gnuradio mailing list

reply via email to

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