Last edited:
SDRTrunk - p25 decoder test release
- Thread starter DSheirer
- Start date
- Status
Sorry about the confusion, the JMBE auto-builder requires you to have the (Java Development Kit) version installed and the JAVA_HOME environment variable setup. I have to update the instructions on the wiki.
I'll be working on the traffic/voice channel following this upcoming weekend. I only had a few free hours this past weekend and was experimenting with an equalizer and new LSM symbol timing error detector to replace the Gardner detector.
Denny
I'll be working on the traffic/voice channel following this upcoming weekend. I only had a few free hours this past weekend and was experimenting with an equalizer and new LSM symbol timing error detector to replace the Gardner detector.
Denny
- Joined
- Jun 16, 2015
- Messages
- 2
hi DSheirer,
I found your project after some frustration with developing on gnuradio and then op25. the only radio I own is a USRP b100 but as a java dev I really wanted to try sdrtrunk so I decided to try and implement b100 (and general USRP) support.
I used JavaCPP to wrap the official UHD shared object library from Ettus, I feel like this was the correct way to go because:
1. no need to worry about writing a UHD implementation
2. conformity with the official UHD programming API
3. installation instructions for UHD are readily available for all modern operating systems
check out my uhd-java library here: https://github.com/bananaguard/uhd-java
check out my SDRTrunk patches here: https://github.com/bananaguard/SDRTrunk/commit/6f42861b5d2bb4b16e5afbee29d99c01e2198dd6
the library and patches are still definitely a work in progress but I'm considerably happy with the state of both of them. last night I was using this to monitor 12 p25 channels simultaneously at a sample rate of 3500000, things start to get kinda hairy there and even more so beyond that.
I intend to host the uhd-java library on github, the SDRTrunk repo I only put there as a way to get the diff to you. btw: do you intend to move SDRTrunk from google anytime soon? I'd definitely appreciate it
also, github is alerting me that my account has been flagged and may not be viewable publicly at this moment, I sent an email asking for this to be resolved so hopefully the links above don't 404 for you.
awesome project looking forward to patching more things and very much looking forward to p25 call following and audio recording.
I found your project after some frustration with developing on gnuradio and then op25. the only radio I own is a USRP b100 but as a java dev I really wanted to try sdrtrunk so I decided to try and implement b100 (and general USRP) support.
I used JavaCPP to wrap the official UHD shared object library from Ettus, I feel like this was the correct way to go because:
1. no need to worry about writing a UHD implementation
2. conformity with the official UHD programming API
3. installation instructions for UHD are readily available for all modern operating systems
check out my uhd-java library here: https://github.com/bananaguard/uhd-java
check out my SDRTrunk patches here: https://github.com/bananaguard/SDRTrunk/commit/6f42861b5d2bb4b16e5afbee29d99c01e2198dd6
the library and patches are still definitely a work in progress but I'm considerably happy with the state of both of them. last night I was using this to monitor 12 p25 channels simultaneously at a sample rate of 3500000, things start to get kinda hairy there and even more so beyond that.
I intend to host the uhd-java library on github, the SDRTrunk repo I only put there as a way to get the diff to you. btw: do you intend to move SDRTrunk from google anytime soon? I'd definitely appreciate it
also, github is alerting me that my account has been flagged and may not be viewable publicly at this moment, I sent an email asking for this to be resolved so hopefully the links above don't 404 for you.awesome project
looking forward to patching more things and very much looking forward to p25 call following and audio recording.Awesome. I have a B100 sitting on the shelf, new and unused. I'll have to give it a try this weekend and see about merging your code.
I intend to host the uhd-java library on github, the SDRTrunk repo I only put there as a way to get the diff to you. btw: do you intend to move SDRTrunk from google anytime soon? I'd definitely appreciate it
awesome project
Extra coding help will be greatly appreciated!
Google code told everyone to get out by August. I've got a placeholder on github where I'm planning to rehost the project. I hope to push it over in the next couple weeks.
Denny
Denny,
not sure what you and bananaguard are doing, but i have a ETTUS B200. Are you going to include this receiver to SDRTrunk?
vince48
The UHD software is a universal interface to all of the Ettus radios, so it makes adding the B200 a possibility. No promises yet, but once the B100 and UHD are fully integrated, we can look to add the B200.
Denny
Thanks Denny, looking forward.
vince48
vince48
- Joined
- Jun 16, 2015
- Messages
- 2
cool, a friend of mine has a USRP1 that I'm hoping to borrow sometime soon, with that and my B100 I should be able to abstract the B100 code I put up into something that works reliably for all UHD devices-- I feel that it's already pretty close
other than that I don't expect to need to update that code again really.as far as merging this into sdrtrunk, I think the uhd-java library I wrote will likely be the main difficulty. the thing is that it links against the UHD shared object library installed on the host system, I'm not really worried about versioning issues because of the excellent standardized API, but there might need to be a different build for linux vs windows, etc, idk. idk how all that works really but guess we'll see.
anyways, the uhd-java build process is extremely straightforward if you have maven installed, also all the integration tests I wrote can be skipped using some fancy maven flags, so it should be possible to script the build much like you did for JMBE.
sdtrunk update ...
I wanted to post an update on the P25 traffic channel following feature and merging in the new B100 code.
In order to create a cleaner architecture for handling traffic channels, I had to completely redesign the channel and decoder processing framework. This part of the code is also the root of a critical memory management issue that's been impacting users with higher data rate receivers (hackrf), so I'm addressing that issue at the same time. I'm also redesigning the audio management sub-system so that I can more easily add audio streaming features.
There's lots of needed redesign and code change ongoing and subsequent testing, so it will be a little while until I can push a new test release.
Denny
I wanted to post an update on the P25 traffic channel following feature and merging in the new B100 code.
In order to create a cleaner architecture for handling traffic channels, I had to completely redesign the channel and decoder processing framework. This part of the code is also the root of a critical memory management issue that's been impacting users with higher data rate receivers (hackrf), so I'm addressing that issue at the same time. I'm also redesigning the audio management sub-system so that I can more easily add audio streaming features.
There's lots of needed redesign and code change ongoing and subsequent testing, so it will be a little while until I can push a new test release.
Denny
Denny
please don't forget the B200
please don't forget the B200
Still finishing the coding of the architecture redesign. This change affected all of the sample processing and decoder pieces in the program.
I've finished the redesign/coding of the sample processing and filtering subsystem and the application is producing demodulated audio once again.
I'm testing/validating the signal flows right now. I updated each of the decoders. Next, I have to cleanup and test each of the decoder state machines.
I've coded part of the new Audio management subsystem, enough to handle mono audio. I still have to add multi-channel audio and streaming with metadata tag support.
The new architecture allows me to setup and (more importantly) reuse multiple traffic channel processing streams to support traffic channel following.
Denny
I'm close to posting an alpha release for version 0.2.0. Here's a screen grab running a P25 LSM control channel with up to 3 traffic channel following:
https://drive.google.com/open?id=0B7BHsssXUq8eWTdsZzdOcXJfVms
Version 0.2.0 Features:
-P25 and MPT1327 traffic channel following with max traffic channel and channel timeout settings
-Audio priority by talkgroup alias with auto routing to 1 or 2 channel sound card (mono/stereo) and a new 'No Monitor' alias action
-Per call recording (.wav) and a new 'No Record' alias action
-Airspy tuner support
-Spectral and waterfall display zooming/panning
internet audio streaming, DMR decoder and Ettus tuner support are planned for build 0.3.x
I'll probably announce the alpha/beta releases in the google support group and once I get some testing feedback, I'll announce a release on RR.
cheers,
Denny
Looking forward to it. Just this morning I installed whatever the latest stuff was on Github.
Monitoring a P25 LSM system. For the life of me, can't get the CC to decode. But the 6 other voice channels all display the system info/talkgroup and events when there is traffic on those.
The CC and all VCs are set for P25 Phase 1 - > LSM.
Can you think of any reason why it wouldn't decode the CC information of this LSM system but will decode the VC information?
I have an airspy -- and its detected. I can't tell if it's being used or if only the RTL is being used.
Mike
PS: And yes, I understand that what I'm using is not what you were using in that screenshot. Screenshot looks great, and the additional features sound awesome!
Disregard my question about CC not decoding. I did something while fiddling around and it's working now, after hours of trying to figure out why it wasn't. No idea what I did that made it work, but it works now
Mike
Denny,
When I run the Airspy at 10 msps, it bails out within a minute or so when monitoring a 7-channel system (channels from 851.1625 to 858.4625, which is why I ran 10 msps).
Always comes up with an OOM / Java Heap error. It doesn't seem to using up all my physical memory ( have 12 GB). Is this some known leakage problem? Is this something I could attempt to curtail by changing some values somewhere?
Or it is simply that I have 7 channels enabled all at once? Rarely has there been traffic on more than two channel simultaneously.
Also, looks like my i5-4570 (quad core, no HT) isn't quite up to handling this configuration long term -- 66% CPU idle, increases when there is audio to be handled of course. I notice "skipping" of audio at 10 msps. At 2.5 msps everything sounds perfect. Oddly, the "skipping" i hear was the skipping I noticed when the system couldn't communicate full speed with the airspy in the past. Although I think in this case it's the stuttering/skipping is likely simple processor exhaustion.
Mike
When I run the Airspy at 10 msps, it bails out within a minute or so when monitoring a 7-channel system (channels from 851.1625 to 858.4625, which is why I ran 10 msps).
Always comes up with an OOM / Java Heap error. It doesn't seem to using up all my physical memory ( have 12 GB). Is this some known leakage problem? Is this something I could attempt to curtail by changing some values somewhere?
Or it is simply that I have 7 channels enabled all at once? Rarely has there been traffic on more than two channel simultaneously.
Also, looks like my i5-4570 (quad core, no HT) isn't quite up to handling this configuration long term -- 66% CPU idle, increases when there is audio to be handled of course. I notice "skipping" of audio at 10 msps. At 2.5 msps everything sounds perfect. Oddly, the "skipping" i hear was the skipping I noticed when the system couldn't communicate full speed with the airspy in the past. Although I think in this case it's the stuttering/skipping is likely simple processor exhaustion.
Mike
Mike,
Are these 7 channels all control channels, or are they a mix of control and traffic? If they are a mix, do the control channels manage all of the traffic channels that you're listening to?
I only have 1 computer to test against (i7/16 GB/linux) and I'm averaging 26% CPU with 500 MB of heap (memory used) running airspy at 10msps with 1 control channel and 3 traffic channels P25/LSM.
10 msps is quite a bit to process. Each channel has to be mixed/downsampled to baseband at the full rate, and then decimated to 48 ksps for decoding. Airspy's no center DC spike also comes at a small cost ... 20 msps real running through a hilbert transform filter to get 10 msps complex.
Denny
Sweetness! Looking forward to trying it!
- Status
Similar threads
- Locked
BCD325P2/BCD996P2:
996P2 Won't Decode Conventional P25 - Tried Everything - HELP
