Java program to decode DMR

[mtindor]

Hello All

There are a couple of improvements which I would like to make to DMRDecode that I think would dramatically improve the programs performance ..

1) At the moment the program only detects when there is an error in a frame but doesn't try to fix it as the error correction in the standard allows. So if there is a single bad bit the frame is marked as bad. Really the program needs to error correct as well.

Makes sense to me - so I'll agree with you. Then again, I'm not the one devoting the time and effort. I can certainly understand why some things are left for the future.

2) Improve the symbol timing (jitter) and FSK level calculation code. The program takes way to long to "lock" onto a DMR transmission. I have tried to improve this but have never bettered the DSD authors formulas which the program still uses.

Wonder if woodpecker would be willing to provide you with the source code mods that he made to DSD in order to implement the filtering that he did. I'm not sure he is around on the forums anymore to even ask, or is busy like the rest of you software developers

Regards

Ian

 

[IanWraith]

Hello

Wonder if woodpecker would be willing to provide you with the source code mods that he made to DSD in order to implement the filtering that he did. I'm not sure he is around on the forums anymore to even ask, or is busy like the rest of you software developers

No need for the source code but many thanks. I generate the filter coefficients using this website ..

Raised Cosine Filters

If you enter a filter with these parameters ..

// Filter details ..
// filtertype = Raised Cosine
// samplerate = 48000
// corner = 2400
// beta = 0.2
// impulselen = 81
// racos = sqrt

You will see the coefficients in the DMRDecode source ..

https://github.com/IanWraith/DMRDecode/blob/master/src/com/dmr/AudioInThread.java

You can increase the impulse length to improve the filter performance but the price is you increase the number of calculations the PC running the program needs to do. In my filters case the PC needs to 81x48000 = 3888000 floating point calculations a second.

Regards

Ian

 

[mrpurrfect69]

hi all i downloaded the updated version & run it but nothing do i have to change the sum of the settings within the software or should it just start displaying information when it hears sum DMR transmissions but at the moe its not displaying nothing..............Looking for sum advice if anyone can help, Thanks in advance

 

[IanWraith]

Hi Folks

I have just uploaded a new build (46) to Github at the usual location ..

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

This new build has the following features ..

1) It decodes Unconfirmed Data packets

2) It partially decodes Proprietary Data Packets

3) It partially decodes Rate ½ Data Continuation Packets to binary.

My thanks to a certain member of this group who has been assisting me with decoding text messages. This build is to aid the investigation into decoding these.

As usual bug reports and feature requests to this forum please.

Regards

Ian

 

[Forts]

Nice work! Can't wait to give it a try tonight!!

 

[Forts]

You'd likely be further ahead asking in a DSD discussion, or starting a new thread. This thread revolves around DMRDecode, not DSD.

 

[IanWraith]

Hi All
Build 48 is now on Github ..

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

New features include ..

Convert the Connect Plus site ID field in SLCO 10 packets from 3 bits to 8 bits
Display the manufacturers name in Proprietary Data Headers.

Regards

Ian

 

[Forts]

Thanks Ian!

 

[dtscho]

Thanks!

I know you're really busy, and maybe you don't even have a test system near you, but any progress/update on decoding information for simplex transmissions?

Dave

 

[IanWraith]

Hello Dave & all

Thanks!

I know you're really busy, and maybe you don't even have a test system near you, but any progress/update on decoding information for simplex transmissions?

Dave

Yes simplex decoding is something I really would like to add. However the major problems are time (or lack of it) but also the signal acquisition and symbol timing code in the program really needs to be improved before it is ready for simplex decoding. The problem is that the program takes far to long to "lock on" to a new DMR signal and with brief and bursty simplex transmissions this will be a real problem.

Regards

Ian

 

[IanWraith]

Hello All
DMRDecode build 49 is now available from the usual place ..

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

This new build displays the payload in half rate data PDUs both as binary and ASCII. It is an experimental build to be used for investigating text messages.

Regards

Ian

 

[mtindor]

Ian,

Is there any chance that whatever fix you made for the incorrect site number issue in build 48 may not apply across the board? On CC's, it seems to produce the right result. But I was monitoring a VC of a site 8 and it was showing as site 0.

See below.

10:22:47 AM DMR Data Frame
Slot Type : Colour Code 12 Idle
CACH : TACT  AT=1 Ch 1 Continuation fragment of LC 
10:22:47 AM DMR Data Frame
10:22:47 AM Short LC : Connect Plus Voice Channel SLCO=9 Network: 145 Site: 0
Group Address : 36 Source Address : 20654
Service Options : Non-emergency/No priority
Group Voice Channel User LC
Slot Type : Colour Code 12 Terminator with LC
CACH : TACT  Ch 2 Last fragment of LC 
10:22:47 AM DMR Data Frame
Slot Type : Colour Code 12 Idle
CACH : TACT  AT=1 Ch 1 First fragment of LC 
10:22:47 AM DMR Data Frame
Group Address : 36 Source Address : 20654
Service Options : Non-emergency/No priority
Group Voice Channel User LC
Slot Type : Colour Code 12 Terminator with LC
CACH : TACT  Ch 2 Continuation fragment of LC 
10:22:47 AM DMR Data Frame
Slot Type : Colour Code 12 Idle
CACH : TACT  AT=1 Ch 1 Continuation fragment of LC 
10:22:47 AM DMR Data Frame
10:22:47 AM Short LC : Connect Plus Voice Channel SLCO=9 Network: 145 Site: 0
Group Address : 36 Source Address : 20654
Service Options : Non-emergency/No priority
Group Voice Channel User LC
Slot Type : Colour Code 12 Terminator with LC
CACH : TACT  Ch 2 Last fragment of LC 
10:22:47 AM DMR Data Frame
Slot Type : Colour Code 12 Idle
CACH : TACT  AT=1 Ch 1 First fragment of LC 
10:22:47 AM DMR Data Frame
Group Address : 36 Source Address : 20654
Service Options : Non-emergency/No priority
Group Voice Channel User LC
Slot Type : Colour Code 12 Terminator with LC
CACH : TACT  Ch 2 Continuation fragment of LC 
10:22:47 AM DMR Data Frame
Slot Type : Colour Code 12 Idle
CACH : TACT  AT=1 Ch 1 Continuation fragment of LC 
10:22:47 AM DMR Data Frame
10:22:47 AM Short LC : Connect Plus Voice Channel SLCO=9 Network: 145 Site: 0
Group Address : 36 Source Address : 20654
Service Options : Non-emergency/No priority
Group Voice Channel User LC
Slot Type : Colour Code 12 Terminator with LC
CACH : TACT  Ch 2 Last fragment of LC 
10:22:47 AM DMR Data Frame
Slot Type : Colour Code 12 Idle
CACH : TACT  AT=1 Ch 1 First fragment of LC 
10:22:47 AM DMR Data Frame
Group Address : 36 Source Address : 20654
Service Options : Non-emergency/No priority
Group Voice Channel User LC
Slot Type : Colour Code 12 Terminator with LC
CACH : TACT  Ch 2 Continuation fragment of LC 
10:22:47 AM DMR Data Frame
Slot Type : Colour Code 12 Idle
CACH : TACT  AT=1 Ch 1 Continuation fragment of LC 
10:22:47 AM DMR Data Frame
10:22:47 AM Short LC : Connect Plus Voice Channel SLCO=9 Network: 145 Site: 0
Group Address : 36 Source Address : 20654
Service Options : Non-emergency/No priority
Group Voice Channel User LC
Slot Type : Colour Code 12 Terminator with LC
CACH : TACT  Ch 2 Last fragment of LC 
10:22:47 AM DMR Data Frame
Slot Type : Colour Code 12 Idle
CACH : TACT  AT=1 Ch 1 First fragment of LC 
10:22:47 AM DMR Data Frame
Group Address : 36 Source Address : 20654
Service Options : Non-emergency/No priority
Group Voice Channel User LC
Slot Type : Colour Code 12 Terminator with LC
CACH : TACT  Ch 2 Continuation fragment of LC 
10:22:47 AM DMR Data Frame
Slot Type : Colour Code 12 Idle
CACH : TACT  AT=1 Ch 1 Continuation fragment of LC 
10:22:47 AM DMR Data Frame
10:22:47 AM Short LC : Connect Plus Voice Channel SLCO=9 Network: 145 Site: 0
Group Address : 36 Source Address : 20654
Service Options : Non-emergency/No priority
Group Voice Channel User LC
Slot Type : Colour Code 12 Terminator with LC
CACH : TACT  Ch 2 Last fragment of LC 
10:22:47 AM DMR Data Frame
Slot Type : Colour Code 12 Idle
CACH : TACT  AT=1 Ch 1 First fragment of LC 
10:22:47 AM DMR Data Frame
CACH : TACT  Ch 2 Continuation fragment of LC

Mike

 

[IanWraith]

Hello Mike & all

Ian,

Is there any chance that whatever fix you made for the incorrect site number issue in build 48 may not apply across the board? On CC's, it seems to produce the right result. But I was monitoring a VC of a site 8 and it was showing as site 0.

I can see the bug and will fix it in the next build.

Sorry about that its annoying when I miss one.

Regards

Ian

 

[Forts]

Nice catch Mike... I never even thought about the SLCO=9 packets for voice channels.

 

[mtindor]

Nice catch Mike... I never even thought about the SLCO=9 packets for voice channels.

Thanks. I didn't either. The initial problem with CCs had me baffled for a few months, and while I tried to figure out where sites were located I really never bothered to monitor VCs. Now that the CCs are reporting correct site ID, I just started monitoring on the VCs.

Mike

PS: To Ian: Thanks for adding that to the fixlist.

 

[IanWraith]

Hello All
I have just uploaded build 50 to Github which fixes the bug found by Mike ..

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

Regards

Ian

 

[mtindor]

Ian,

Is there something that needs to be done to display the new info from Built 49 (the half-rate data) ? When might one expect to see something on the screen reflecting that new information?

I see there are data frames, but I'm guessing they must have to do with GPS info or something rather than this "half-rate" stuff you're referring to? I'm monitoring a ConnectPlus system.

Mike

 

[IanWraith]

Hi Mike & All

Yes there are two types of data on a DMR system half rate (which I currently display as binary and ASCII) and three quarter rate which is convolution coded and which I haven't even looked at yet.

I see a lot of half rate data on a local system which I suspect is GPS fixes from cars and I know one US based listener has found a DMR user that sends text messages as half rate data. I see an awful lot of three quarter rate data on a local Capacity Plus system which I'm not sure of the purpose of.

Regards

Ian

 

[mtindor]

Hi Mike & All

Yes there are two types of data on a DMR system half rate (which I currently display as binary and ASCII) and three quarter rate which is convolution coded and which I haven't even looked at yet.

I see a lot of half rate data on a local system which I suspect is GPS fixes from cars and I know one US based listener has found a DMR user that sends text messages as half rate data. I see an awful lot of three quarter rate data on a local Capacity Plus system which I'm not sure of the purpose of.

Regards

Ian

Ok thanks. Looks like I'll need to monitor a standalone repeater that I remember there being a ton o 1/2 rate stuff on.

Mike

 

[mtindor]

Hi Mike & All

Yes there are two types of data on a DMR system half rate (which I currently display as binary and ASCII) and three quarter rate which is convolution coded and which I haven't even looked at yet.

I see a lot of half rate data on a local system which I suspect is GPS fixes from cars and I know one US based listener has found a DMR user that sends text messages as half rate data. I see an awful lot of three quarter rate data on a local Capacity Plus system which I'm not sure of the purpose of.

Regards

Ian

I vaguely remember seeing 3/4 rate data on some freq I monitored. It was probably part of a Cap Plus system -- and I haven't been monitoring them lately. 1/2 and 3/4 are conspicuously absent from the ConnectPlus I'm monitoring. On a standalone TRBO repeater for a county citizen transportation agency I'm seeing a ton of 1/2 rate. In the past I always suspected it was GPS, and seeing it now in Build 50 I can only surmise that it's what I'm seeing. I'm going to monitor it for a while and see if I happen upon any 1/2 text messages.

Mike

PS: GPS data is ugly