Java program to decode DMR

[IanWraith]

Hello

the error protection code is known and is decoding right and the logical link data position is known. are the header and data block formats unknown? is there no way to know where in the block the user data octets are?

Oh yes we know where the data is but we need to be able to recognise the packets and understand them. So we need to know if a packet (actually a packet within a packet within a PDU) is a text message , a GPS position fix (and there are many types of those) etc so we can intelligently decode it. To make things worse the Text messaging isn't in the DMR standard so is left to the manufacturers to do in their own proprietary way. So you can be sure a Hytera text message is sent differently to a Moto text message etc etc.

Regards

Ian

 

[nycap]

Oh yes we know where the data is but we need to be able to recognise the packets and understand them. So we need to know if a packet (actually a packet within a packet within a PDU) is a text message , a GPS position fix (and there are many types of those) etc so we can intelligently decode it. To make things worse the Text messaging isn't in the DMR standard so is left to the manufacturers to do in their own proprietary way. So you can be sure a Hytera text message is sent differently to a Moto text message etc etc.
Ian

is there not some sort of link control format that idenifies what is going to be where within the pdu ? where is the standard documented? is there a pdf i can look at or something?
Thanks!

 

[IanWraith]

Hello

is there not some sort of link control format that idenifies what is going to be where within the pdu ? where is the standard documented? is there a pdf i can look at or something?
Thanks!

Oh yes see ..

ETSI TS 102 361-1
ETSI TS 102 361-2
ETSI TS 102 361-3

and more besides which can be downloaded for free from the ETSI website.

However the spec allows manufacturers a lot of latitude to customise it with propitiatory features hence the Capacity Plus commands but also text messaging and GPS position fixes.

Regards

Ian

 

[molay]

long been speculated that these functions are adaptations of previous protocols motorola. enhanced privacy -> P25 ADP , Mototorbo Positioning -> LRRP.

http://cwh050.blogspot.com.es/2012/10/mototrbo-gps-in-nutshell.html

 

[rr60]

Thank-you Ian

A big thank-you to Ian Wraith for this slick piece. I know others have contributed to the effort as well with feedback or adding code as I needed to read most of the threads to sort my issues out. The reason I find this program to be helpful is so that I can see what others see and stay a step ahead. My Dell E510 runs about 30% load with stock sigma tel card. I am using a BC796D with a straight tap and no cap.

Here were the issues that came up for me that had nothing to do with Ian's work but have been repeated many times in the threads.

Java obstructions: Ultimately I found many old versions on my machine. I had to remove all of them and re-install the latest version.

Radio: I started with a .01 cap, that was a mistake as eloquently pointed out by Mike G_D. I am now using raw disc with no problem. This is clearly very important.

The program: I was using old links in the beginning threads instead of the newest latest links.

In closing the information is all here.Just needed some effort. Thank's again Ian.

I put the ? marks in.
8:41:45 AM DMR Data Frame
Target Address : 6???4 Source Address : 6???1
Service Options : Non-emergency/No priority
Unit to Unit Voice Channel User LC
Slot Type : Colour Code ?? Terminator with LC
CACH : TACT Ch 2 First fragment of CSBK

8:44:03 AM DMR Data Frame
Slot Type : Colour Code ?? Idle
CACH : TACT AT=1 Ch 2 First fragment of CSBK
8:44:03 AM DMR Data Frame
Slot Type : Colour Code ?? Idle
CACH : TACT AT=1 Ch 2 First fragment of CSBK
8:44:03 AM DMR Data Frame
Group Address : 4???6 Source Address : 6???1
Service Options : Non-emergency/No priority
Group Voice Channel User LC
Slot Type : Colour Code ?? Terminator with LC
CACH : TACT Ch 1 First fragment of CSBK
8:44:04 AM DMR Data Frame

 

[IanWraith]

Hello r60

Many thanks for your thank you , it's always good to hear from users and I'm glad everything is working now.

Ian

 

[cg]

Minor suggestion:
I was recently monitoring the Mohegan Sun Casino (CT) Motorola Connect Plus 900MHz system using release 70 of DMRDecode for the system information and DSDPlus for the audio.
When the were two conversations, one in each slot, and one ended, the information stayed in both slots. It would be helpful for the inactive slot to have gone back to being greyed out (even if the info stayed there). Even though the DSDPlus sends slot 1 audio to the left and slot 2 to the right speaker, it would have been much easier to follow if it could grey out as soon as each mike was unkeyed.

chris

 

[inigo88]

Minor suggestion:
I was recently monitoring the Mohegan Sun Casino (CT) Motorola Connect Plus 900MHz system using release 70 of DMRDecode for the system information and DSDPlus for the audio.
When the were two conversations, one in each slot, and one ended, the information stayed in both slots. It would be helpful for the inactive slot to have gone back to being greyed out (even if the info stayed there). Even though the DSDPlus sends slot 1 audio to the left and slot 2 to the right speaker, it would have been much easier to follow if it could grey out as soon as each mike was unkeyed.

chris

I have noticed this too, for what it's worth. Sometimes the group and source activity on each timeslot will persist in the bottom right well after the users have unkeyed. Restarting the program or switching to a new frequency seems to clear it up.

 

[IanWraith]

I have noticed this too, for what it's worth. Sometimes the group and source activity on each timeslot will persist in the bottom right well after the users have unkeyed. Restarting the program or switching to a new frequency seems to clear it up.

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

 

[cg]

That would explain why replies stay on the same slot, thanks.

chris

 

[krokus]

Wirelessly posted (Opera/9.80 (Android 2.3.4; Linux; Opera Mobi/ADR-1309251116) Presto/2.11.355 Version/12.10)

...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

Does the data stream continue? Loss of the stream should be a good indicator, I would think.

 

[IanWraith]

Wirelessly posted (Opera/9.80 (Android 2.3.4; Linux; Opera Mobi/ADR-1309251116) Presto/2.11.355 Version/12.10)



Does the data stream continue? Loss of the stream should be a good indicator, I would think.

Its not that easy. The transmission will cease if this is the only transmission on the frequency but if the other channel is in use then this has to continue. If it isn't in use the system sends Idle PDUs but you can't use these to sense a conversion is over since the system also transmits Idle PDUs when there is a brief pause in a voice over.

Regards

Ian

 

[Jay911]

Hey Ian (and others),

I'm trying to figure out another local TRBO DMR system and I'm thinking I could use some help.

5 frequencies owned by the same radio leasing company were switched from a Type II system to TRBO modulation - I am pretty sure 4 of the 5 are all one system, but I'm not sure which 4, and/or if the fifth frequency is part of the same system or a separate entity of its own.

I'm using SDR# and VAC 4.13 (full), with DMR Decode 70, and DSDplus for voice. Anyway, all five frequencies report color code 1.

Is there anything in the DMR Decode logs that will identify a frequency's purpose within a system, other than the color code? I'm seeing "activity on LCN 5" and "rest channel on LCN 6" as well as "rest on LCN 7" and "rest on LCN 8" in the same log (for one frequency) so I presume the LCNs pertain to the entire system, not just the one frequency being monitored.

I only see LCNs 1 thru 8 in use in my logs, never 9 or 10. I thought with 5 freqs I'd see 9 and 10 at some point. I'm pretty sure I've had voice traffic on all 5 frequencies. Or should I be looking for one that is only ever sending data (even if I have no constant control channel) and the other 4 are the voice channels?

 

[Forts]

It's possible that they are using all 5 channels, but only 4 of them are trunked. I have a couple universities like that near me... the lower priority groups are Capacity Plus, where as groups like campus police and an emergency channel are on a dedicated channel (each using one timeslot).

You say you are seeing the different 'LCN xx is the rest channel' messages while sitting on one frequency? From what I've seen if you are seeing that message, then you are on that LCN. ie if I'm sitting on 460.1000 and it's saying 'LCN 4 is the rest channel' then I know that frequency is LCN 3/4 (and the rest channel is the one that is 'pulsing')... However that's the only message I see on there... No references to other channels being the rest frequency.

I can confirm this tomorrow as I will be onsite with a Capacity Plus system.

 

[Jay911]

One frequency is decidedly weaker than the other four, so I'm wondering if that's the one.

I'll try to get closer to the signal and have the antenna on a good ground plane (my truck) over the next couple days.

It also didn't occur to me to look at the status bar on the bottom of DMR Decode and compare that to what is scrolling up the screen.....

 

[IanWraith]

Hello Jay

Are you seeing the same talk groups and identities on the mystery channels that you see on the definitely trunked channels ? If the same groups and identities are present then the system is linked. My suspicion though is that Forts is right and these channels are for specific users (perhaps security) on the system.

Regards

Ian

 

[Jay911]

I'm going to have to look at my logs again (and do some more logging today) but all 5 frequencies are showing talkgroups, and several of them for sure have the same TG across multiple frequencies. I'll let it run for a while today and see how things turn out.

 

[SCPD]

Thanks for all your work on writing this program Ian, its a fantastic program, I use it all the time.

One thing that could be added to the program is the decoding of call alerts. When I send a call alert to another radio, it only shows the binary data in DMRdecode.

I'll show you a log:
Preamble CSBK : CSBK content 13 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:38 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 12 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:38 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 11 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:38 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 10 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:38 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 9 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:38 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 8 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:38 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 7 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:38 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 6 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:38 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 5 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:38 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 4 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:38 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 3 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:38 DMR Data Frame
Unknown CSBK : CSBKO=31 + FID=16 0000000000000000000000000001011101110010000000000001011101110001
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:39 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 16 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:42 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 15 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:42 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 14 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:42 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 13 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:42 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 12 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:42 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 11 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:43 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 10 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:43 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 9 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:43 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 8 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:43 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 7 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:43 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 6 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:43 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 5 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:43 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 4 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:43 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 3 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:43 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 2 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:43 DMR Data Frame
Target Address : 6002 Source Address : 6001
Preamble CSBK : CSBK content 1 Blocks to follow
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:43 DMR Data Frame
Unknown CSBK : CSBKO=31 + FID=16 0000000000000000000000000001011101110010000000000001011101110001
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:43 DMR Data Frame
Unknown CSBK : CSBKO=31 + FID=16 0000000000000000000000000001011101110010000000000001011101110001
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:43 DMR Data Frame
Unknown CSBK : CSBKO=32 + FID=16 1001111100000000000000000001011101110001000000000001011101110010
Slot Type : Colour Code 10 CSBK
CACH : TACT Ch 2 First fragment of CSBK
22:10:43 DMR Data Frame

The top bit of data is radio ID 6001 sending a call alert to 6002.
At this time I have 6002 on a different channel. I switch it over before the second try of 6001 to call alert 6002. The second try succeeds and 6002 sends an acknowledge call alert which is the last data message with the CSBKO of 32.

Looking at the call alert's binary:
Unknown CSBK : CSBKO=31 + FID=16
0000000000000000 000000000001011101110010 000000000001011101110001
I've split it up, so that the first section is separate from the 24 bit IDs of the radios.

and then looking at the acknowledge:
Unknown CSBK : CSBKO=32 + FID=16 1001111100000000 000000000001011101110001 000000000001011101110010
again, split up. The first part I don't know, maybe someone else knows what that does? The second part is the radio the ack is directed to. The third part is the sending radio of the ack. This message allows the radio sending the call alert to stop trying, because otherwise it tries a few times and then alerts the user with a beep if there was no acknowledge received.

It would be good to have this implemented in the program so it says something like
Call alert from 6001 to 6002

And then
Call alert from 6001 to 6002: acknowledged

I would do it myself but I don't have any idea how to code java (or any language really for that matter)

Thanks,
Ben

 

[M0DQO]

Hi All,

New to the forum but a great fan of the DMRdecode program and all the work that has gone into it! Thanks Ian....

I just wanted to add my findings into the mixing pot and wondered if you guys agree! This is thanks to DSDplus that this back my findings up.

Just up the postings a little, it was mentioned that you see Group Call on Channel 1 & 2 at the same time.. I have a 6 channel capacity plus system quite local to me here in the UK that does exactly that. I missed the logging but i can see a group call on channel 1 and the reply from the mobile unit is heard on channel 2 which seems to correspond to the rest channel changing to another trunk group LCN 3 but the group call continues to bounce around LCN1 & 2 until it ends.

I will try and get a copy of the logs for next time, but with the help of DSDplus and DMRdecode, this was witnessed a number of times on this system.

Hope it helps someone..

Thanks,
Chris - M0DQO (Portsmouth, UK)

 

[inigo88]

Hey Forts, for what its worth I've definitely seen "LCN xx is the rest channel" on other LCN frequencies on capacity plus. Once I know the announced LCN I quickly search for the one that's "bursting" so I can match LCN to frequency. At the next voice call the rest channel hops again, so you can map out capacity plus systems pretty well by searching for the system frequency with the data bursts while the others are announcing the rest channel LCN with no burst.

Bben95 thanks for the call alert log! Any chance you could do something similar for text messaging?