SDRTrunk - p25 decoder test release

[cpetraglia]

Oddly enough, the CPU stays around 55% when following one control channel. However, the memory will climb by roughly 1MB/sec until it maxes out and crashes. I've tried setting aside more memory with the -Xms512 -Xmx768 flags, but that doesn't really address what's causing the garbage collector routine to lag behind. It would be a beautiful thing if SDRTrunk could run reliably on a Pi...

I am not sure about the PI 2 or 3, but my Win 10 Pro 64 bit wont run long with out 4 G of memory reserved. I also noticed the more reserve memory you have the lower the Proc load. Mine is down to 13% while decoding 2 talk groups at once.

 

[rjdj2000]

Also, I caved and ordered the ODROID C2 and a case, so in about a week, we'll see how that little $42 monster does. Stay tuned!
If everything works, I'm going to need to buy/build some kind of larger case or something that will accommodate the ODROID and 1/2 SDR dongles. I really wish it had battery/charging support. A home made portable would be badass!

I will be looking forward to see how you make out with it. If you are running it on that other little box, as I took a look at the specs for it, then the C2 should work out. I just want to downsize myself to get rid of 1 pc running 24/7 (already have a total of 5 doing this) and then I could put a battery on it so it will run 24/7 even if power goes out.

RJ

 

[chudgoo]

I will be looking forward to see how you make out with it. If you are running it on that other little box, as I took a look at the specs for it, then the C2 should work out. I just want to downsize myself to get rid of 1 pc running 24/7 (already have a total of 5 doing this) and then I could put a battery on it so it will run 24/7 even if power goes out.

RJ

Funny you should mention that. They make a UPS add on board. The price though makes a traditional standalone UPS a better option IMO...

ODROID | Hardkernel

 

[rjdj2000]

Funny you should mention that. They make a UPS add on board. The price though makes a traditional standalone UPS a better option IMO...

ODROID | Hardkernel

Interesting little gizmo... I am using a 2.3 amp hour 12V battery with a charging circuit on my 536HP scanner and I have one that is powering my home weather station. So I will probably put a splitter onto the output and use a USB charger for phone (have tons of those cords laying around) so it has the 5v to run it.

 

[chudgoo]

Ok, so far so good with the ODROID C2. The hardware is awesome and runs like a normal-ish desktop.
They provide an image of Ubunu Mate 14.04.

Now here's where it gets interesting... I installed all the Pulse Audio packages for java, OpenJDK 8 and everything I could find relating to libusb, but when I try to run sdrtrunk I get the following:


odroid@odroid64:~/sdrtrunk$ bash ./run_sdrtrunk_linux.sh
18:37:01.784 INFO gui.SDRTrunk -
18:37:01.799 INFO gui.SDRTrunk -
18:37:01.799 INFO gui.SDRTrunk - *******************************************************************
18:37:01.800 INFO gui.SDRTrunk - **** sdrtrunk: a trunked radio and digital decoding application ***
18:37:01.801 INFO gui.SDRTrunk - **** website: https://github.com/dsheirer/sdrtrunk ***
18:37:01.802 INFO gui.SDRTrunk - *******************************************************************
18:37:01.802 INFO gui.SDRTrunk -
18:37:01.803 INFO gui.SDRTrunk -
18:37:01.818 INFO gui.SDRTrunk - Home path: /home/odroid/SDRTrunk
18:37:01.823 INFO p.SystemProperties - loaded [/home/odroid/SDRTrunk/SDRTrunk.properties]
18:37:01.824 INFO p.SystemProperties - application properties loaded [/home/odroid/SDRTrunk/SDRTrunk.properties]
18:37:01.871 INFO settings.SettingsManager - loading settings file [/home/odroid/SDRTrunk/settings/settings.xml]
18:37:03.542 INFO playlist.PlaylistManager - playlist does not exist [/home/odroid/SDRTrunk/playlist/playlist.xml]
18:37:04.966 INFO source.mixer.MixerManager - loading system mixer devices
[LOADED] Input: PulseAudio Mixer CHANNELS: [LEFT, RIGHT, MONO]
[LOADED] Output: PulseAudio Mixer CHANNELS: [MONO, STEREO]
[LOADED] Input: default [default] CHANNELS: [LEFT, RIGHT, MONO]
[LOADED] Output: default [default] CHANNELS: [MONO, STEREO]
[LOADED] Input: ODROIDHDMI [plughw:0,0] CHANNELS: [LEFT, RIGHT, MONO]
[LOADED] Output: ODROIDHDMI [plughw:0,0] CHANNELS: [MONO, STEREO]

18:37:05.198 WARN audio.output.AudioOutput - Couldn't obtain MASTER GAIN control for stereo line [PulseAudio Mixer | M]
18:37:05.202 WARN audio.output.AudioOutput - Couldn't obtain MUTE control for stereo line [PulseAudio Mixer | M]
18:37:05.316 INFO s.r.RecordingSourceManager - discovered [0] recording configurations
Exception in thread "main" java.lang.ExceptionInInitializerError
at source.tuner.TunerManager.initTuners(Unknown Source)
at source.tuner.TunerManager.<init>(Unknown Source)
at controller.ResourceManager.<init>(Unknown Source)
at controller.ResourceManager.<init>(Unknown Source)
at gui.SDRTrunk.<init>(Unknown Source)
at gui.SDRTrunk.main(Unknown Source)
Caused by: org.usb4java.LoaderException: Native library not found in classpath: /org/usb4java/linux-aarch64/libusb4java.so
at org.usb4java.Loader.extractLibrary(Loader.java:281)
at org.usb4java.Loader.load(Loader.java:358)
at org.usb4java.LibUsb.<clinit>(LibUsb.java:640)
... 6 more



So libusb4java doesn't seem to have a ARM 64 bit version and nothing else I've tried can get around this...
When I try to install libusb4java via the 'linux.sh' install script I just get the error "Unknown Platform: aarch64"
Any ideas? Has anyone run sdrtrunk on ARM 64 before? If so, how?

 

[whelgeson]

...snip...
So libusb4java doesn't seem to have a ARM 64 bit version and nothing else I've tried can get around this...
When I try to install libusb4java via the 'linux.sh' install script I just get the error "Unknown Platform: aarch64"
Any ideas? Has anyone run sdrtrunk on ARM 64 before? If so, how?

You're most likely going to have to compile usb4java from source for the ARM platform: usb4java - Native libraries (See subsection: Unsupported platforms)

 

[DSheirer]

You're most likely going to have to compile usb4java from source for the ARM platform: usb4java - Native libraries (See subsection: Unsupported platforms)

That's correct. Another user compiled the libraries for PPC and sent them to me and now they're part of the application.

If you can compile the native library and then add the resulting jar file to the sdrtrunk /imports folder and then build the sdrtrunk application, you should have a version that will run on your OS. Or, simply drop the native library in the /libs folder of the version 0.2.0 application and it should also recognize it.

If you're successful in building the native library, please send me a copy and I'll add it permanently to the repo.

cheers,
Denny

 

[Chewmeister]

Denny,

First off, I would like to thank you for developing and sharing this excellent program. Although SDRTrunk is still being developed, it is by far a better option for me than consumer scanners.

I moved about a year ago and now live in a very challenging area for our 800 MHz statewide P25 simulcast system. I can now enjoy listening to the system once again thanks to SDRTrunk. In addition to the simulcast site interference, the large amount of dense trees, shrubs, and housing in the area adds major multipath issues to the situation. This is especially true for the 800 MHz band. While yagi antennas help with the multiple site interference, they do not overcome the multipath problem. The best antenna to use in my area seems to be the Radio Shack 800 MHz omni whip although that whip can become frustrating at times as I have to constantly relocate the scanner due to wind and rain changing the multipath patterns. When a storm moves through the area, this can be every couple of minutes.

My monitoring gear includes a GRE PSR500, GRE PSR600, and two Uniden BCD996T scanners. I have borrowed and tested a Uniden BCD536HP scanner with little, if any, improvement. The audio still comes through garbled and distorted more than I care to listen to. Due to Uniden and Whistler still not including a proper CQPSK demodulator for LSM broadcasts in their latest models, I have given up on the idea of purchasing a new scanner for now. This is where SDRTrunk comes into the picture.

As an alternative to scanners, I purchased an Airspy R2 SDR. After researching software options, I came across SDRTrunk and OP25. SDRTrunk appealed to me as it is a complete integrated package running on a Java platform which allows me to use it with Windows or Linux. OP25 runs reliably only in Linux as I do not care to run it in a VM enviroment. In addition to the Airspy, I am using a Lenovo laptop with an i7 and 16 GB of memory with SDRTrunk.

My experience with SDRTrunk has been very good except for a few issues noted below. The CC and audio decode error rate has greatly improved versus consumer scanners. Even with the few occasional times the error rate is above normal, the decoded audio is still intelligible. That is a big plus for utilizing a proper demodulator. I started off with version 0.2.0 and downloaded/compiled version 0.3.0 (July 12) to see if that would take care of issues I have. The LSM decoded audio seems a little better with 0.3.0.

[Major Issue] - SDRTrunk ignores patched talkgroups
One of the agencies I track uses north and south dispatch talkgroups when busy. When not busy, they patch the two talkgroups together. The dispatch TGs make up over 75% of the traffic for that agency. SDRTrunk does decode the patch message:

20160727 085651,PASSED,NAC:404 TSBK3 MOTOROLA ADD PATCH GROUP PATCH GROUP:12D8 GRP1:12D8 GRP2:12DA GRP3:12D8

When not patched, SDRTrunk tracks and outputs audio from both trunkgroups just fine. When patched, SDRTrunk does not acknowledge patched trunkgroups even exist in the events window, channel display, or output audio from either trunkgroup. I have noticed this behavior in other simulcast sites within the system using patched trunkgroups as well.

[Minor Issue] - Delay in displaying TGID and RID in version 0.3.0 channel pop-up
When I updated to version 0.3.0, I noticed that there is couple of seconds delay in displaying the TGID and RID on the channel pop-up (lower left side) as compared to version 0.2.0. With short transmissions the TGID and RID may not display at all. Version 0.2.0. displayed both IDs almost instantly.

[Minor Issue] - Talkgroup entry is cumbersome and no bulk method to enter them
I am aware this horse has been kicked around in this forum way too many times. One of the systems I monitor has over 900 talkgroups in regular use with many more (statewide system) that can affiliate. This site also has over 20 frequencies in use, including CC, SSCs, and VCs spanning around 8.75 MHz. This was my reasoning for choosing the Airspy over the other SDRs. I do make a lot of use of the wildcard option, but even then, I can have over 80 wildcard entries per site depending how spread out the talkgroups are that I want to monitor. This does not count the talkgroups I want to monitor. It would be nice to copy and paste the talkgroups from a spreadsheet. It might be worthwhile to have all the talkgroups disabled by default and only have to enter the talkgroups one is interested in like scanners do.

Thanks for all the hard work,
Craig

 

[DSheirer]

[Major Issue] - SDRTrunk ignores patched talkgroups
One of the agencies I track uses north and south dispatch talkgroups when busy. When not busy, they patch the two talkgroups together. The dispatch TGs make up over 75% of the traffic for that agency. SDRTrunk does decode the patch message:

20160727 085651,PASSED,NAC:404 TSBK3 MOTOROLA ADD PATCH GROUP PATCH GROUP:12D8 GRP1:12D8 GRP2:12DA GRP3:12D8

When not patched, SDRTrunk tracks and outputs audio from both trunkgroups just fine. When patched, SDRTrunk does not acknowledge patched trunkgroups even exist in the events window, channel display, or output audio from either trunkgroup. I have noticed this behavior in other simulcast sites within the system using patched trunkgroups as well.

I'm currently not doing anything with patched talkgroups and I don't have any info on how they're handled in other programs. When the patch is created, do you expect each of the patched talkgroups to be aliased with the common patch talkgroup? If you can help me to understand the desired effect, I can probably implement it in sdrtrunk.

[Minor Issue] - Delay in displaying TGID and RID in version 0.3.0 channel pop-up
When I updated to version 0.3.0, I noticed that there is couple of seconds delay in displaying the TGID and RID on the channel pop-up (lower left side) as compared to version 0.2.0. With short transmissions the TGID and RID may not display at all. Version 0.2.0. displayed both IDs almost instantly.

I think this may be related to Java 8. I'm seeing other GUI responsiveness issues like the spectral display not updating. I'll work on these issues more as version 0.3.0 nears feature-complete.

[Minor Issue] - Talkgroup entry is cumbersome and no bulk method to enter them
I am aware this horse has been kicked around in this forum way too many times. One of the systems I monitor has over 900 talkgroups in regular use with many more (statewide system) that can affiliate. This site also has over 20 frequencies in use, including CC, SSCs, and VCs spanning around 8.75 MHz. This was my reasoning for choosing the Airspy over the other SDRs. I do make a lot of use of the wildcard option, but even then, I can have over 80 wildcard entries per site depending how spread out the talkgroups are that I want to monitor. This does not count the talkgroups I want to monitor. It would be nice to copy and paste the talkgroups from a spreadsheet. It might be worthwhile to have all the talkgroups disabled by default and only have to enter the talkgroups one is interested in like scanners do.

I have an interface to RR's web services planned that will allow you to bulk import systems and talkgroups. This should alleviate some of the data entry pain. Pasting of talkgroups and aliases from a spreadsheet could be tricky. I'll add a feature for the RR interface to designate all talkgroups as disabled/enabled on import. In the current version 0.3.0, you can select a block of aliases and disable/enable them all at once.

This has been a busy summer and I haven't had any opportunities to code much. But, summer's coming to an end soon and I'll be able to spend more time on it.

v/r,
Denny

 

[Chewmeister]

I'm currently not doing anything with patched talkgroups and I don't have any info on how they're handled in other programs. When the patch is created, do you expect each of the patched talkgroups to be aliased with the common patch talkgroup? If you can help me to understand the desired effect, I can probably implement it in sdrtrunk.

I may have an idea on how to answer the what to expect for each of the talkgroups issue. A simple test I did was to run this site with both uniden and GRE scanners and various software. The current patch is set up in this configuration:
Talkgroup 1: DEC=4824 HEX=12D8
Talkgroup 2: DEC=4826 HEX=12DA
Patch: 4826 (Source) -----> 4826 (Target or common)

The results:
The Uniden and GRE scanners were configured to only monitor both 4824 and 4826 TGIDs. Both always locked on to the 4826 (12DA) talkgroup. Neither scanner had traffic on 4824 (12D8). I even set both to manual and on the 4824 TG with zero traffic heard.

Next I broke out the SDRs and several variations of software to analyze the control channel.

SDRTrunk - Listed the following patch messages:
20160728 222358,PASSED,NAC:404 TSBK3 MOTOROLA PATCH VOICE CHANNEL GRANT PATCH GROUP:12DA FROM:0226B6 PRI:0 CHAN:19-0 DN:0 UP:0
20160728 222358,PASSED,NAC:404 TSBK1 MOTOROLA ADD PATCH GROUP PATCH GROUP:12DA GRP1:12DA GRP2:12D8 GRP3:12DA
20160728 222358,PASSED,NAC:404 TSBK2 MOTOROLA PATCH VOICE CHANNEL UPDATE PATCH GRP1:12DA GRP2:12DA CHAN 1:19-0 DN:0 CHAN 2:19-0 DN:0

As we both know there was no channel assigned for the voice grant therefore no decoded audio.


DSDPlus - Listed the following patch messages and a group call:
2016/07/28 22:10:27 NAC=404 Patch Supergroup: TG=4826
2016/07/28 22:10:27 NAC=404 Patch Subgroup: TG=4824

2016/07/28 22:12:47 NAC=404 P-Group call; TG=4826 RID=140982 Ch=852.8000 Pri0 4s

There were many more group calls, but I noticed all were for TG 4826 and none for 4824. There was also a (P) in front of the talkgroup to indicate a patched TG.


Pro96Com - The site activity screen only showed hits for TG 4826.


Unitrunker - Same as the others. There were plenty of hits for 4826 and none for 4824.

In the past, during pursuits between two or more agencies, a dispatcher may set up a "soft patch" so that if any of the talkgroups transmitted, all the patched talkgroups would hear it.

I suspect this may be a different type of patch. Perhaps this type of patch sets the mobile to TX/RX on 4826 even though his/her radio is set for 4824. I will test this theory by monitoring the control channel over night and see if 4824 hits at all. That will at least tell us which direction to pursue in dealing with the patch.

Craig

 

[slicerwizard]

DSDPlus - Listed the following patch messages and a group call:
2016/07/28 22:10:27 NAC=404 Patch Supergroup: TG=4826
2016/07/28 22:10:27 NAC=404 Patch Subgroup: TG=4824

2016/07/28 22:12:47 NAC=404 P-Group call; TG=4826 RID=140982 Ch=852.8000 Pri0 4s

There were many more group calls, but I noticed all were for TG 4826 and none for 4824.

There will never be a group call on a subgroup.

 

[Chewmeister]

There will never be a group call on a subgroup.

Thanks for confirming my observations. Until SDRTrunk, I always ignored patches as the hardware and/or software always worked with or without them. Curiosity has the best of me now. I have been searching the internet for detailed information on trunkgroup patching. The only items I found are marketing one line sentences.

I would appreciate it if you or anyone else could answer these questions.

1. A subcriber radio receives a TSBK add patch group message that Trunkgroup B is patched into Trunkgroup A, TGID B ----> TGID A. Does this radio use Trunkgroup A for TX/RX calls if the radio is switched to Talkgroup B?

2. In order to monitor the above patched group, one would only need to monitor Trunkgroup A until the patch is removed, or is there more to this?

Thanks,
Craig

 

[slicerwizard]

1. A subcriber radio receives a TSBK add patch group message that Trunkgroup B is patched into Trunkgroup A, TGID B ----> TGID A. Does this radio use Trunkgroup A for TX/RX calls if the radio is switched to Talkgroup B?

If a subscriber is set to group B, it will affiliate to group B, and should also TX on group B. The trunking system will convert that to the supergroup (group A) and broadcast it as a call on group A.

On RX, subscribers merely keep track of the fact that a call on group A is also a call on group B, so since the radio is dialed to group B, it follows calls on group A exactly as if they were calls on group B.

2. In order to monitor the above patched group, one would only need to monitor Trunkgroup A until the patch is removed, or is there more to this?

That's it - just monitor the supergroup.

Edit: Sorry, just noticed that these are SDRTrunk related questions - I can't advise re SDRTrunk operating procedures.

 

[Chewmeister]

If a subscriber is set to group B, it will affiliate to group B, and should also TX on group B. The trunking system will convert that to the supergroup (group A) and broadcast it as a call on group A.

On RX, subscribers merely keep track of the fact that a call on group A is also a call on group B, so since the radio is dialed to group B, it follows calls on group A exactly as if they were calls on group B.


That's it - just monitor the supergroup.

Thanks slicerwizard. That does make sense. Unfortunately, I am located too far away from the mobiles to monitor the input channels to see what talkgroup they transmit on.

Craig

 

[Chewmeister]

Edit: Sorry, just noticed that these are SDRTrunk related questions - I can't advise re SDRTrunk operating procedures.

That is fine as you answered my question on how these patches work.

Thanks

 

[DSheirer]

SDRTrunk - Listed the following patch messages:
20160728 222358,PASSED,NAC:404 TSBK3 MOTOROLA PATCH VOICE CHANNEL GRANT PATCH GROUP:12DA FROM:0226B6 PRI:0 CHAN:19-0 DN:0 UP:0
20160728 222358,PASSED,NAC:404 TSBK1 MOTOROLA ADD PATCH GROUP PATCH GROUP:12DA GRP1:12DA GRP2:12D8 GRP3:12DA
20160728 222358,PASSED,NAC:404 TSBK2 MOTOROLA PATCH VOICE CHANNEL UPDATE PATCH GRP1:12DA GRP2:12DA CHAN 1:19-0 DN:0 CHAN 2:19-0 DN:0

Craig,

I just added code to the version 0.3.0 master branch to process Motorola vendor-specific Patch messages.

You should see the patch events listed in the EVENTS tab as:

Patch Group Add
Patch Group Delete
Patch Group Call

The patch information (talkgroups, session routing mode, etc.) will be in the DETAILS column.

You'll have to do a GIT FETCH to pull down the code updates and then recompile the software. If you have an opportunity to test the code, I'd appreciate any feedback if it's working or not.

Denny

 

[Chewmeister]

Craig,

I just added code to the version 0.3.0 master branch to process Motorola vendor-specific Patch messages.

You should see the patch events listed in the EVENTS tab as:

Patch Group Add
Patch Group Delete
Patch Group Call

The patch information (talkgroups, session routing mode, etc.) will be in the DETAILS column.

You'll have to do a GIT FETCH to pull down the code updates and then recompile the software. If you have an opportunity to test the code, I'd appreciate any feedback if it's working or not.

Denny

Denny,

Thanks for looking into this as losing dispatch talkgroups creates a large listening void. I will download the update and give it a run. The trunkgroups have been pach for over a week straight so I have a great source for the test. I'll definitely let you know the results.

Craig

 

[Chewmeister]

Denny,

The Patch Voice Channel Grant trunk tracking and audio decoding are working great. The first time I ran the new update I was overcome by all the channels poping up as the wildcard alias group I made no longer works. I read on the issues tab a while ago that you are going to redo the wildcards, so I figured it is disabled. I quickly created a new do not monitor alias group to silence the worst chatter talkgroups.

The first run of this update showed no TGID or RID in the pop-up frequency box in the channel section for patched talkgroups. After a second start up, the TGID now appears, but still no RID. Group Calls still display both. A temporary fix is to disable everything in the messages tab except for Motorola Patch Voice Channel Grant, and see the RIDs there, as that is working as it should.

A suggestion is to have a filter option for the events tab like the messages tab has. All the Add Patch Group messages drown out all the other events. Register, Query, Deregister, Response messages are useful at times for troubleshooting. However, I like to just filter out everything but Group Calls and Patch Group Calls during normal use.

Some of the slowdowns I experienced from another post improved some with the wildcard aliases disabled. There is still some lag and latency in the TGIDs and RIDs in the channel window from the Java 8 issue you mentioned before, but it seem faster now even with all the do not monitor talkgroups I added. I suspect creating a table for all the wildcards creates a heavy computer load.

Anyways, thanks for looking into this as fast as you did. I will monitor the system and report any other issues that may come up. This update really has been a big improvement for the patch issue.

Thanks,
Craig

 

[Chewmeister]

An additional comment to post. During dispatcher shift changes, they sometimes redo the patch and flip the sub group and supergroup around. Talkgroup B ---> talkgroup A becomes talkgroup A ---> talkgroup B. This situation just happened a bit ago. SDRTrunk transitioned instantly and flawlessly to the new supergroup TG and started decoding voice calls. It appears you have nailed the patched talkgroup issue down.

 

[DSheirer]

A suggestion is to have a filter option for the events tab like the messages tab has. All the Add Patch Group messages drown out all the other events. Register, Query, Deregister, Response messages are useful at times for troubleshooting. However, I like to just filter out everything but Group Calls and Patch Group Calls during normal use.

I'll add an enhancement ticket for this.

Some of the slowdowns I experienced from another post improved some with the wildcard aliases disabled. There is still some lag and latency in the TGIDs and RIDs in the channel window from the Java 8 issue you mentioned before, but it seem faster now even with all the do not monitor talkgroups I added. I suspect creating a table for all the wildcards creates a heavy computer load.

I just changed the alias list handling. I load a hash map of all of the talkgroup IDs and corresponding aliases. I also check each talkgroup ID for wildcard characters (*) and load them into a separate list.

When I lookup an alias from a talkgroup, I first look in the map and if it's not found, I check each of the wildcarded talkgroups in the list to see if any of them match and then return the matching alias.