I have put together a C++ based decoder P25 CAI audio (https://github.com/robotastic/smartnet-recorder/blob/master/logging_receiver... https://github.com/robotastic/smartnet-recorder/blob/master/logging_receiver...) based off the usrp_rx.py file and using the C blocks in /blocks http://groups.yahoo.com/trac/wiki.png/browser/trunk/blocks?order=name/src http://groups.yahoo.com/trac/wiki.png/browser/trunk/blocks/src?order=name/li... http://groups.yahoo.com/trac/wiki.png/browser/trunk/blocks/src/lib?order=nam.... It using a lot of CPU though. Are the C code blocks for the Repeater any diferent? Should I try building off of those instead?
My basic app is recording a SmartNet system. It follows the trunking control channel and the creates loggers to capture the audio from a talkgroup and saves it to WAV file. Right now it is using DSD which has been shoehorned into a GR Block, but I would much rather use OP25. Unfortunately the DSD implementation allows for about 7 concurrent recordings, and I am only able to get about 2-3 using OP25 on a quad core machine. I am sure the fault is on my end, I just want to make sure I am using the best code to base my stuff off of, before I begin trying to track down my problems.
- Luke
very interesting question - if I were you I wouldn't necessarily be so quick to blame all faults and problems on your end. We haven't done specific benchmarks/comparisions/CPU-usage studies, at least that I'm aware of. We do know that the decoder logic used in DSD has some shortcuts and simplifications specifically to make it run using less CPU; whereas the focus in OP25 has been on correctness and adherence to the standard(s). In tracing performance problems such as this it would be good to know specifically where the problem area(s) are before necessarily making wholesale changes. It might turn out the problem is in a totally different area than first thought. The GNU Radio 3.7 release contains new performance tracking features which should enable pinpointing which block(s) are hogging the CPU.
As far as the repeater, there are many differences. Two receiver chains available in the repeater - a cqpsk demod is available in addition to Frank's c4fm demodulator; the repeater does FEC error correction; also, it allows user choce of two IMBE voice decoders (Pavel's as well as the original software IMBE decoder)... For these reasons it's very difficult to say (without actually trying) whether you'd see a benefit to switching, other than that there are more options to choose from when running performance comparison tests...
Best
Max
---In op25-dev@yahoogroups.com, op25-dev@yahoogroups.com wrote:
I have put together a C++ based decoder P25 CAI audio (https://github.com/robotastic/smartnet-recorder/blob/master/logging_receiver... https://github.com/robotastic/smartnet-recorder/blob/master/logging_receiver...) based off the usrp_rx.py file and using the C blocks in /blocks http://groups.yahoo.com/trac/wiki.png/browser/trunk/blocks?order=name/src http://groups.yahoo.com/trac/wiki.png/browser/trunk/blocks/src?order=name/li... http://groups.yahoo.com/trac/wiki.png/browser/trunk/blocks/src/lib?order=nam.... It using a lot of CPU though. Are the C code blocks for the Repeater any diferent? Should I try building off of those instead?
My basic app is recording a SmartNet system. It follows the trunking control channel and the creates loggers to capture the audio from a talkgroup and saves it to WAV file. Right now it is using DSD which has been shoehorned into a GR Block, but I would much rather use OP25. Unfortunately the DSD implementation allows for about 7 concurrent recordings, and I am only able to get about 2-3 using OP25 on a quad core machine. I am sure the fault is on my end, I just want to make sure I am using the best code to base my stuff off of, before I begin trying to track down my problems.
- Luke
Thanks Max! This is really helpful and gives me a plan of attack. I am going to get my code up to GR3.7 so I can use the latest OP25 build and try out the performance tracking feature. I will also switch my code around to the Repeater C blocks. It sounds like there are more knobs, which should allow for some performance tweaking.
- Luke
---In op25-dev@yahoogroups.com, op25-dev@yahoogroups.com wrote:
very interesting question - if I were you I wouldn't necessarily be so quick to blame all faults and problems on your end. We haven't done specific benchmarks/comparisions/CPU-usage studies, at least that I'm aware of. We do know that the decoder logic used in DSD has some shortcuts and simplifications specifically to make it run using less CPU; whereas the focus in OP25 has been on correctness and adherence to the standard(s). In tracing performance problems such as this it would be good to know specifically where the problem area(s) are before necessarily making wholesale changes. It might turn out the problem is in a totally different area than first thought. The GNU Radio 3.7 release contains new performance tracking features which should enable pinpointing which block(s) are hogging the CPU.
As far as the repeater, there are many differences. Two receiver chains available in the repeater - a cqpsk demod is available in addition to Frank's c4fm demodulator; the repeater does FEC error correction; also, it allows user choce of two IMBE voice decoders (Pavel's as well as the original software IMBE decoder)... For these reasons it's very difficult to say (without actually trying) whether you'd see a benefit to switching, other than that there are more options to choose from when running performance comparison tests...
Best
Max
---In op25-dev@yahoogroups.com, op25-dev@yahoogroups.com wrote:
I have put together a C++ based decoder P25 CAI audio (https://github.com/robotastic/smartnet-recorder/blob/master/logging_receiver... https://github.com/robotastic/smartnet-recorder/blob/master/logging_receiver...) based off the usrp_rx.py file and using the C blocks in /blocks http://groups.yahoo.com/trac/wiki.png/browser/trunk/blocks?order=name/src http://groups.yahoo.com/trac/wiki.png/browser/trunk/blocks/src?order=name/li... http://groups.yahoo.com/trac/wiki.png/browser/trunk/blocks/src/lib?order=nam.... It using a lot of CPU though. Are the C code blocks for the Repeater any diferent? Should I try building off of those instead?
My basic app is recording a SmartNet system. It follows the trunking control channel and the creates loggers to capture the audio from a talkgroup and saves it to WAV file. Right now it is using DSD which has been shoehorned into a GR Block, but I would much rather use OP25. Unfortunately the DSD implementation allows for about 7 concurrent recordings, and I am only able to get about 2-3 using OP25 on a quad core machine. I am sure the fault is on my end, I just want to make sure I am using the best code to base my stuff off of, before I begin trying to track down my problems.
- Luke
-
ikj1234i＠yahoo.com -
lukekb＠gmail.com