Java program to decode DMR

[dtscho]

That's a good idea. Build 53 can now be downloaded from the usual place ..

https://github.com/IanWraith/DMRDecode/downloads

In the "Main" menu you will find a new item "Save Settings" which when clicked saves the programs current settings to a file DMRDecode_settings.xml. Then on start up the program reads in this file and sets its settings from it as required.

The only feature I can't add is the default location for the "Save to File". I tried this before on one of my other decoder problems and ran into some odd problems related either to Java or different versions of operating systems. Sorry about that.

Anyway give build 53 a try and if anyone finds any problems please let me know. Also feature suggestions are always welcome.

Regards

Ian

Thank you!

Dave

 

[IanWraith]

Hello All

As was mentioned earlier it all seems to depend on how well the processor handles threading. DMRDecode uses threads (thing of these as separate programs running at the same time) with one thread gathering data from the soundcard and running it through a root raised filter then sending that data through a pipeline to another thread that decodes and displays the information. This is fine on a PC with 2 or more cores but it appears some single core processors really struggle. A friend of fine with a 3 GHz single core AMD CPU can only run DMRDecode if he shuts everything else down. Yet other single core PCs appear to run it just fine , so I'm afraid it is a mystery why this is.

Regards

Ian

 

[DaveH]

Maybe those CPU's support hyper threading? Ian had reported in the past that DMR Decode won't run on older, single threaded CPU's. I've tried it on a few P4 desktop machines and they all choked.

I was mistaken about the desktop...it uses AMD Athlon 64 3000+ (1.8GHz)
and chokes on DMRDecode (CPU pegs at 99%). The laptop (Intel M (745 I think)
and netbook (Intel Atom N270) both do OK although I notice CPU utilization
bounces around and sometimes peaks at >90%.

Dave

 

[thundercookies]

Hey Ian,

I don't have anything to test it on, but the problem probably is the AudioInThread outrunning the reader on the other side of your pipe. That thread is running wide open in an infinite for loop and will consume 100% of a single core. That's why dual cores show CPU utilization at 50% - the audio reading thread got assigned to one of the cores and just about everything else is running on the other one. I've modified the code to use a fixed length BlockingQueue backed by an array to put a cap on it and cause it to block once the buffer fills. I also took some liberties with the project structure in a fork on git hub and mavenized it to help me build and run the junit tests.

If you want to play with it and twiddle the buffer sizes, take a look at the changes to DMRDecode.java and AudioInThread.java on the master branch of https://github.com/csams/DMRDecode.git and see if helps.

Cheers,
Chris

 

[thundercookies]

Actually, I was just taking a look at the source for the PipedInputStream and PipedOutputStream, and the PipedInputStream controls the data buffer sizes with the POS just directly telling the PIS to receive data. OpenJDK 6 has the default pipe size at 1024, but you can construct it with less. Something else to consider is perhaps making the units transferred across the pipe much larger instead of an int at a time.

 

[thundercookies]

Ian,

I changed the communication back to a pipe, increased the default buffer size substantially, moved the socket and audio threads into executor services, and moved the main loop out of the main function and into an executor service of its own. I also had the socket thread pause for 1 second if its not yet in a ready state each time through its main loop so that it's not just hammering. CPU usage decreased from ~100% to ~7% on my machine.

I have changes checked into the master branch of my fork of your repo on github if you want to take a look.

Cheers,
Chris

 

[IanWraith]

My thanks to Chris for his brilliant code. I have now merged it with mine using Github. I need to test it when I get home but will then release it as build 54 as soon as possible.

Regards

Ian

 

[IanWraith]

Hello All
I have just uploaded build 54 to the usual place ..

https://github.com/IanWraith/DMRDecode/downloads

This new build incorporates Chris's code which he sent to me via Github. In the brief tests I have run I am seeing both lower CPU usage and nearly 10% fewer errors monitoring some signals compared to the previous build.

So please try it and report the results. I would be very interested in hearing what happens when you run it on a lower powered machine which wouldn't run previous versions.

Regards

Ian

 

[Forts]

Wow! Seeing a biiig difference here. I just tried Build 52 on a P4 3.2ghz with 2 gigs of ram. CPU pegs at 100% and program struggles to launch. Build 54 pops open right away with CPU load bouncing from 30-50% (and that's with me logged in remotely via TeamViewer which is adding some overhead). Great work guys!

 

[ilgrant]

Build 54

This build will run on my 1.4 Ghz Intel Mobile Processor based laptop where the previous builds did not. Thanks for the great work to have it work on these old school systems!

 

[DaveH]

Happy to report, Build 54 now runs on the 1.8GHz Athlon 64 desktop,
typically using 20-30% CPU sometimes peaking at ~50%, with up to
95% decoding. Of course it runs on the laptop/desktop, which ran on
previous builds. Should run on just about anything out there, except
maybe that old K6/500M machine running Windows 98...

Dave

 

[blantonl]

Quick question - if I put DMRDecode on a MotoTRBO control channel - does it decode control channel messages? I get good decode on voice channels but nothing on the control channels.

 

[Forts]

It should, yes. Do you see any activity at all? On a Connect Plus control channel you should see Colour Code, the Network ID and Site #, in addition to any call activity.

 

[mtindor]

Quick question - if I put DMRDecode on a MotoTRBO control channel - does it decode control channel messages? I get good decode on voice channels but nothing on the control channels.

For any TRBO signal (except for maybe simplex, if there is such a thing as simplex TRBO), if you are hearing the data stream you should be seeing something in DMRDecode.

I see things come across the screen in DMRDecode if I monitor a ConnectPlus CC or VC, CapacityPlus or any standard TRBO repeater in TRBO mode.

I have run across instances where I could hear what I can tell is a TRBO repeater but I can't pick anything up. In those cases though I had found out it was a new repeater being "burned in" -- maybe it was doing some 0s/1s BER testing of some sort. It was TRBO but it sounded off freq (and often was). Then a few days or a week later the signal disappeared and re-appeared, copyable with DSD, on the licensed freq.

Mike

 

[blantonl]

It should, yes. Do you see any activity at all? On a Connect Plus control channel you should see Colour Code, the Network ID and Site #, in addition to any call activity.

Strange, I'm not seeing anything at all on a control channel. The voice channels show up as Capacity Plus channels and I get full decode.

 

[mtindor]

Strange, I'm not seeing anything at all on a control channel. The voice channels show up as Capacity Plus channels and I get full decode.

How do you know it's a CC then? The only way to tell if something is a CC or VC is to run DMRDecode on it and see what it announces itself as.

One freq is going to have two slots. A CC can have both data and voice traffic on it, as can a VC. The CC just has some extra messages that come across to indicate that it's a CC, just as a VC has some messages coming across to indicate they are a VC.

On the ConnectPlus systems around here, there is a CC active 24/7. DMRDecode will show its a CC. There will be voice / data on it and I'll hear the voice in DSD and see that there is data / GPS stuff being transmitted according to DMRDecode / DSD. The VCs won't always be transmitting, but often are [at least around here] because so many users have GPS-enabled radios and many are doing text messaging.

So I'm not sure I understand how you are considering one to be a CC vs a VC, unless you're assuming that one is a CC by virtue of it transmitting 24/7 continuous.

You definitely should be seeing something if it's TRBO though. In DSD are you seeing anything on that same frequency [when you aren't seeing anything in DMRDecode] ?

Mike

 

[blantonl]

You know what - I think these control channels that I am attempting to decode are actually NEXEDGE control channels. It looks like the MotoTRBO systems here are actually Capacity Plus channels - NOT Connect Plus... I'll try to get a recording of the control channel shortly so you can hear what it sounds like.

 

[mtindor]

You know what - I think these control channels that I am attempting to decode are actually NEXEDGE control channels. It looks like the MotoTRBO systems here are actually Capacity Plus channels - NOT Connect Plus... I'll try to get a recording of the control channel shortly so you can hear what it sounds like.

Alrighty. That very well could be. Incidentally, the NEXEDGE systems [at least around here] always sound quite a bit "softer". That may just be because the maintainers of the transmitters don't have audio levels as high. But typically that's the first clue to me that something might be NEXEDGE vs TRBO.

Use DSD on it -- but you have to specify custom switches if you want to monitor NEXEDGE

-fi (for 4800 baud NXDN)
-fn (for 9600 baud NXDN)

If I'm not mistaken, it won't autodetect which one so you would want to specify it. So if you think it's NEXEDGE, run dsd -fi and dsd -fn on it and see if you pick up anything in DSD. You may or may not hear audio (depending on whether its voice traffic or some kind of data), but DSD would show information scrolling down the screen if you set the right switch and its NXDN.

Mike

 

[IanWraith]

Lindsay - The only control channel I can't decode that well around here is a Capacity Plus system belonging to a local government. When it isn't doing anything it transmits a couple of frames then shuts down for a second then transmits a couple of frames and so on. The symbol timing code in DMRDecode (and DSD because its the same) can't establish symbol timing quick enough before the system goes quiet. When there is activity though the channel transmits as normal and DMRDecode is fine with it.

 

[blantonl]

Mike, I thought I read that DSD doesn't decode any NEXEDGE trunking ?