DMR Talker Alias

posted in: DMR, GD-77, Ham radio | 3

This story starts a few days ago, when the Australian DMR MARC based network temporarily cut off access to hotspots.

Like many other people I switched to using Brandmeister while the DMR MARC server was offline, but I noticed that my “Last Heard” screen in Kai’s open source GD-77 firmware was behaving very oddly.

Initially the Last Heard screen would display the callsign and name as usual, but after about 1 second the display would update to show a completely different ID, and after another second it would display another different ID number, before finally returning back to displaying the callsign and name.

This process seemed to be in a loop of 3 different IDs.

 

The effect only happened on my Last Heard screen, and does not manifest itself on the Channel or VFO screens, and also is not a problem in the official GD-77 firmware.

 

To work out what was going on I added some programming code to write the contents of the DMR data header to a debugging terminal, and I immediately noticed something strange was happening.

 

Normally the DMR Data header looks like this

 

00 00 00 00 00 5B 2F 65 11 40 AF 2C

 

which breaks down to

 

00 00 00     I didn’t know the meaning of these bytes but they were always 00 00 00 on DMR MARC

00 00 5B     This is the talkgroup number in hexidecimal. In this case 0x5B = 91 (Brandmeister Worldwide)

2F 65 11     This is the stations ID number which in this case happens to be 3106065 as the station was KJ6QBM

40 AF 2C    I don’t know what these bytes contain, but it seems to be different for each station. (I’m sure some of you clever people can tell me what these are for !)

 

Anyway. On Brandmeister, the data stream I observed looked like this.

Note. I’ve added padding bytes of 00 00 00 00 at the end as it makes it easier for me to put the data into this post, as I used the HxD hexidecimal editor to look at the data because it puts the ASCII text character for each byte at the end of the line

 

00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
05 00 20 53 65 61 6E 00 00 C8 AF 2C 00 00 00 00 .. Sean..ȯ,….
05 00 20 53 65 61 6E 00 00 C8 AF 2C 00 00 00 00 .. Sean..ȯ,….
05 00 20 53 65 61 6E 00 00 C8 AF 2C 00 00 00 00 .. Sean..ȯ,….
05 00 20 53 65 61 6E 00 00 C8 AF 2C 00 00 00 00 .. Sean..ȯ,….
05 00 20 53 65 61 6E 00 00 C8 AF 2C 00 00 00 00 .. Sean..ȯ,….
05 00 20 53 65 61 6E 00 00 C8 AF 2C 00 00 00 00 .. Sean..ȯ,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….

Then the pattern repeats from the beginning

 

I realised that Brandmeister must be sending Talker Alias data as outlined in the ETSI DMR specification

https://www.etsi.org/deliver/etsi_ts/102300_102399/10236102/02.03.01_60/ts_10236102v020301p.pdf

on page 52.

Note. The spec does not make clear precisely how the data is sent.

There is a page about TA on Brandmeister

 

https://wiki.brandmeister.network/index.php/Talker_Alias

 

But again, there aren’t any technical details of the format of this data; so I set about reverse engineering a solution based on the data I was observing.

 

 

The most noticeable thing is that the first byte seems to be either 00 or 04 or 05, and when the first byte is 00 the rest of the data is the TG and DMR ID as normal, however if the data starts with 04, the data seems to contain the callsign in ASCII text.

Note. Ignore the “K” in front of the “KJ6QBM”, this initially confused me into thinking this was a VK station, but its a KJ station, and the “V” character is just the hexidecimal value 0x56, which just happens to be in the ASCII character range.

This value isn’t always 56, it often contains completely different numbers, and currently I don’t know what this value means, however its not important, since I know the callsign is always sent from the 4th byte onwards, and seems to be a maximum of 6 characters (Though I think in theory it could be up to 7 characters)

 

In a similar way, if the first byte contains 05, there is some text that is sent from the 3rd byte onwards, for the next 7 bytes.

 

For KJ6QBM, the only data that I observed was for types 00, 04 and 05, however for other stations I observed additional data types of 06 and 07.
For example, for G6LNV

 

04 00 6A 47 36 4C 4E 56 20 58 FB 49 00 00 00 00  ..jG6LNV XûI….

05 00 44 4D 52 20 49 44 3A E8 FB 49 00 00 00 00  ..DMR ID:èûI….

06 00 20 32 33 34 34 34 36 40 FB 49 00 00 00 00  .. 234446@ûI….

07 00 34 00 00 00 00 00 00 E0 FB 49 00 00 00 00  ..4……àûI….

 

I think the text “DMR ID: 2344464” is being is either being automatically generated by Brandmeister or by this stations radio.

 

Anyway. Armed with this new knowledge, I set about modifying Kai’s firmware so that it could handle DMR traffic which contained Talker Alias data, and after an email discussion with Colin G4EML, I decided to a single text buffer large enough to store the total number of characters that can be sent in all 4 types of data block, and then to copy each block of text into the correct part of the large buffer as it arrives.

 

Additionally, since the same block of data gets sent repeatedly, I first check whether data for that block number has already been received and if it has, I don’t need to waste the CPU’s time, copying the data into the large buffer.

 

Currently the overall algorithm I developed works like this.

When a non TA data block is received, i.e one containing the TG and DMR ID, I check if this station has been heard before; in that its in the last 16 station log I use for the Last Heard screen.

If the ID is not in the log, I add it to the log, and attempt to lookup the ID in the DMR ID database that I loaded into the radio. The screen then displays either the Callsign and name from the database or simply the ID number.

 

As an example, I was listening on TG91 and the radio initially displayed this ID number, because the ID was not in the DMR ID database in the radio

 

After around half a second, the radio receives the first block of Talker Alias data (block code 04), which on Brandmeister always seems to contain the station’s callsign.

And the firmware automatically updates the screen to show the updated information.

 

After about another half a second, the radio receives another TA block type (block code 05), which is “Block 2” of the data
(In this case the I think the station has manually entered their name into the Brandmeister “SelfCare” APRS screen)

 

and the firmware puts this new data into the appropriate location in the master TA buffer and updates the screen, to show the full extend of the TA memory, which now contains

“JL1WCW Norio”

 

 

This transmission only contained block code 04 and 05, so, after this the display did not change as the station continued to transmit

 

Once the station stops transmitting, the screen returns back to displaying the information about the channel, but if the same station transmits again, their TA data is still stored in the Last Heard log, and the screen immediately shows the TA data that it has already received.

 

Initially I designed my Talker Alias display algorithm to prioritise the TA information instead of the DMR ID database information (loaded into the radio), however I’ve found that the TA data from Brandmeister is not very consistent and sometimes have entered their callsign into the APRS text , so it simply displays the callsign twice, and also that the TA often contains the Text DMR ID:xxxxx, which IMHO is completely pointless, since the DMR data already sends the ID as part of the initial traffic.

So at the moment, I have changed the display algorithm to use the DMR ID database data if the ID is in the data, and if not to use the TA data if its present.

 

For anyone using Brandmesiter, I’d advise they login and look at the APRS data section of the SelfCare screen, and simply put their name and possibly their location etc into the APRS data field, because Brandmeister automatically sends the callsign, so there is no need to enter the callsign into the APRS data box.

 

 

As this makes the best use of the Talker Alias data that will be sent.

 

In my case I’ve entered my name and also my location, with Australia being truncated to “Aus” because of the 20 character limit in the APRS Text section.

Note. I’m not sure if there needs to be a space before the name. I’ll need to investigate this, but its difficult to test unless I use both my VK3 and G4 callsigns, since I’m using a simplex hotspot on BM and hence I can’t listen to the traffic back from BM that will have my TA data appended to it.

 

The Talker Alias display is now working quite well, on both the Channel and VFO screens, however I’m having some problems integrating it into the Last Heard screen.

I can get the Last Heard screen to display the TA data if the station retransmits but updating the data dynamically, is currently causing the firmware to crash and I’ve not had chance to debug why that’s happening.

 

The open source TA firmware has been tested by a few people, including LB9AB, and he reports that the firmware has a bug where it reboots about once every 2 hours, however I think the reboot problem may not actually be related to the Talker Alias display feature, but is probably caused by another underlying problem in the firmware where there is a buffer overflow in the AMBE codec.

I don’t know for sure what’s going on, but I have noticed some weird things happening when I modify the code, because changes to unrelated parts of the firmware cause the DMR audio to stop completely.

But I think the bug will probably become clearer as time goes by and will need to go onto the bugs list at the present time.

 

 

 

I know people will also ask me whether it would be possible to patch the official Radioddity firmware to support Talker Alias…. I think the answer is, in theory yes, but in practice It could take me weeks of work to add this to the official firmware, and my time is better spent on Kai’s open source firmware, since eventually we will have full DMR and FM transmit and receive functionality, which will render the official firmware redundant 😉

 

 

3 Responses

  1. ken
    |

    very interesting. thank you

  2. Pardo Vitulli
    |

    Roger,

    I’m very impressed with what you are doing with all this… I’m quite new to HAM and currently in the process of getting my license, in Canada, after 30+ years of thinking about it ;).

    After a renewed interest, I happened to get the GD-77, almost by mistake, but am glad I did. I see that there are many possibilities to mod and more importantly to learn. In the few days I’ve had the unit, because I like to tinker, I have made and adapted some of the mods that Jason Reilly had posted from the various user/participants. I’m careful not “brick” the unit but am afraid that the bug to learn and ticker is stronger than me…

    I especially like the tweaks you did in FW 3.2.1, namely with the RSSI signal strength display… I was wondering if that was available for 3.2.2.

    In any case, I will continue to follow the progress of the CPS version your working on, as I find it fascinating. Even as a newbie, I felt the stock CPS seemed to have holes in it . I couldn’t put my finger on it… (as one would say) but it was clear that it did not present all the hooks that would allow one to tailor the device for their specific uses or whims.

    Keep up the good work.

  3. W1AEX - Rob
    |

    Really impressive work with implementing Talker Alias into the independently developed firmware Roger. The scope of the project is mind boggling to an analog brain like mine! Thanks for all the work you and Kai are doing! 73, Rob W1AEX

Leave a Reply