Java program to decode DMR

[IanWraith]

Hello

Problem solved.
I've reinstalled Java on all computers. Now it is 7u51 version and everything seems to work ok.

Nice one ! I suspect some other program you had installed had disturbed Java.

Have fun with DMRDecode.

Regards

Ian

 

[SignalPatcher]

How use DMRDecode is build 73 in Windows 8.1?

System want open this aplication in WinRAR and I can't choose others options.

 

[br0adband]

How use DMRDecode is build 73 in Windows 8.1?

System want open this aplication in WinRAR and I can't choose others options.

Go to Java.com and install Java - then execute the DMRDecode .jar file by double-clicking on it - it's a Java program so it won't work if you don't have Java installed (latest version basically).

 

[cg]

you may need to assign the .jar extension to JAVA. I don't use Windows 8 but I suspect it cannot be too different.

Find and right click the .jar file
Click "Open With..."
Find JAVA or, if you don't see it on the list, choose "Browse" and find it.
If the small box toward the bottom of the program list, "always use this program..." is not checked, check it.
Click OK
Try the JAVA program again. You should be running it with JAVA.

chris

 

[dtscho]

The problem here is that there is no specific DMR command that says "call over" (as there was with say MPT1327). Unless there is a SLCO Act_Updt to say the channel is no longer in use (or if that is missed or contains errors) then the program has no way of knowing a call is over. Unless there is another voice/data call on that channel or the carrier is lost then program assumes the call is continuing.

Its hard to know how to fix this one.

Ian

Ian,

Many thanks for the program and all the work you put into it. Sorry to bring up an old topic, but maybe the information in the first slot could be cleared when DMRDecode decodes the same group using the second slot. This method gets around the problem of DMR not having a "call over" message.

Dave

 

[Forts]

... and on a conventional system if only one slot is used? The only time a group would jump to the other slot would be on a trunked system.

Well.. I suppose different users could use the same talkgroup ID on separate slots on a conventional system but that would be a little odd I'd think.

 

[IanWraith]

Hello Dave

Ian,

Many thanks for the program and all the work you put into it. Sorry to bring up an old topic, but maybe the information in the first slot could be cleared when DMRDecode decodes the same group using the second slot. This method gets around the problem of DMR not having a "call over" message.

Dave

It's a nice idea but I'm not sure that would happen often enough for this to be useful.

I will look into it though as it may help.

Regards

Ian

 

[dtscho]

Another idea for the program, when you get a chance...

When applicable, DMRDecode could denote the type of Privacy being used, such as "Basic Privacy Enabled" or "Enhanced Privacy Enabled" instead of simply "Privacy Enabled."

Thanks.

Dave

 

[Forts]

That's not as easy as it seems unfortunately....

 

[dtscho]

I don't know if this Batboard thread helps - there is a reply from someone who claims that the basic privacy key is in a string of numbers read from the Airtracer program (a program included with the MOTOTRBO CPS). If some of these numbers indicate basic privacy, then I assume there is a different string to indicate the presence of enhanced privacy.

Batboard • Login

Dave

 

[WayneH]

Ian,

Have you given thought on expanding the message filtering ability? With the limited scrollback history when you're forced to see the Connect Plus messages it makes trying to watch for traffic, and grab the info, difficult.

Perhaps adding an LCN table that shows what's currently being announced too similar to the common CC decoding software.

 

[TampaTyron]

I know we have talked about text messages before. Could we revisit decoding text messages, specifically MOTOTRBO ones? I install/test/maintain a lot of Hotel and Theme Park TRBO systems where there are Job Ticket (sent and received via the Text Message function) messages being sent over the radio. I know that different manufacturers handle text messaging differently, but in my experience, most messaging solutions will be Motorola based. TT

 

[SCPD]

I know we have talked about text messages before. Could we revisit decoding text messages, specifically MOTOTRBO ones? I install/test/maintain a lot of Hotel and Theme Park TRBO systems where there are Job Ticket (sent and received via the Text Message function) messages being sent over the radio. I know that different manufacturers handle text messaging differently, but in my experience, most messaging solutions will be Motorola based. TT

Certainly.
Have you got any more technical info that can be added to the program to allow it to decode messages?

 

[TampaTyron]

I have several items available to me:
-1 Aeroflex 3920
-dozens of active IP Site Connect systems consisting of hundreds of repeaters
-Access to multiple Job Ticketing solutions
-ability to join to many of these IP Site Connect systems via VPN
-dozens of radios to test with (XPR and Hytera)

What do you need? TT

Certainly.
Have you got any more technical info that can be added to the program to allow it to decode messages?

 

[Forts]

I think the easiest way to start would be to send a message between two radios and capture the data that DMR Decode displays. Then do it again and see if the data changes at all. Then try a different message and log what changes etc etc...

 

[SCPD]

I've manged to decode the text msg on Mototrbo and Hytera using the below method.

You will need DMRDecode and this web site ASCII, Hex, Unicode, Base64, Binary, Octal Converter

Start by capturing the data through DMRDecode into a log file. you will need a good capture of 3/4 Data binary for a clean msg!

Once you have your Binary 3/4 Data you will need to remove the first 8 bits and the last 8 bits of the binary data. open up the web site as above, copy and paste the remaining Binary bits into the "Decode Binary into ASCII" window, check the "Binary" check dot at the top, uncheck the "Space between bytes" box then click on the Decode Binary into ASCII button. job done :biggrin:

 

[Alandmr]

Great work by Ian and others on here! I wonder if anyone can help with DMRDecode? I am running SDR# with free virtual cable into DSD+ and all works fine on trbo seeing what frames DSD shows and recovering audio fine. When I start up DMRdecode, (Build 73) that also is getting the stream and decoding frames and with about 7% errors on the stat. But it is not showing any information at all about colour code, talkgroups and IDs. This is from a conventional trbo repeater. Also when selecting quick file, a csv is laid down but is zero filled. Also options called "capture" and "debug mode" are greyed out.

Any idea why no talk group etc information?

Many thanks

Alan

 

[ducttape]

Mototrbo, as far as I have observed, uses Motorola Text Messaging Service protocol. The TMS is encapsulated in UDP/IP packets using port 4007. Messages are usually sent in standard DMR confirmed rate 3/4 data blocks.

The source and destination IP addresses are encoded radio IDs, where the first 8 bits of the address is the type of device (12d = radio, 13 = USB, 14 = bluetooth, ...), the remaining 24 bits is the actual ID of the radio.

The contents of the UDP packet have the TMS header, which appears to always be 6 bytes long, so in a pinch you can just skip those bytes and display the rest.

In my observation it seems that the TMS header is something along the lines of:
-Bytes 0+1: length of the message in bytes, excluding the first two length bytes
-Byte 2: unknown, 0xC0 or 0XE0. E0 usually gets a response packet, so it could be that C0 is for unacknowledged, and E0 for ack'ed... just a guess.
-Byte 3: 0x00
-Byte 4: probably a sequence number, increments with every new message. Can probably be used to merge messages split in multiple UDP packets.
-Byte 5: 0x04

Mind you, I have described the headers for the TMS packets actually carrying text, the other headers, which are probably used for signalization (ACK, resend), are different, usually 3 (+2) bytes long without content.

Regards.

 

[IanWraith]

Hello Alan

Great work by Ian and others on here! I wonder if anyone can help with DMRDecode? I am running SDR# with free virtual cable into DSD+ and all works fine on trbo seeing what frames DSD shows and recovering audio fine. When I start up DMRdecode, (Build 73) that also is getting the stream and decoding frames and with about 7% errors on the stat. But it is not showing any information at all about colour code, talkgroups and IDs. This is from a conventional trbo repeater. Also when selecting quick file, a csv is laid down but is zero filled. Also options called "capture" and "debug mode" are greyed out.

Any idea why no talk group etc information?

Sorry for the late reply. 7% is a good error rate (about the best you will get) what PDUs are you seeing ? If you are seeing nothing but voice frames then try changing the setting of the "Invert" option in the main menu.

Ian

 

[Alandmr]

Ian

Many thanks and yes a newbie error and I found that by inverting all works beautifully! Great piece of software

Regards