Talker Alias Data Format

[IK8JHL]

Reading the TalkerAlias ​​log I noticed something that is not clear to me 1) when I receive the TA via RF the DATA FORMAT is always 0 whatever format I choose, 7-bit Format Unicode Format 8-bit Format 2)when I receive via network normally the DATA FORMAT is 1 but it becomes 2 if I receive through the DSTAR transcoding

looking in the ETSI TS 102 361-2 V2.3.1 (2016-02) specifications, I found instead is it an issue, or am I misinterpreting the data?

[g4klx]

AFAIK the data displayed is decided directly from the TA data in the frame. There may be a bug in either the host or even the radio. I’d be surprised if it was in the host.

Sent from Yahoo Mail for iPhone

On Saturday, March 6, 2021, 14:29, IK8JHL notifications@github.com wrote:

Reading the TalkerAlias ​​log I noticed something that is not clear to me

• when I receive the TA via RF the DATA FORMAT is always 0 whatever format I choose, (8-bit, 7-bit, Unicode)

2)when I receive via network normally the DATA FORMAT is 1

but it becomes 2 if I receive through the DSTAR transcoding

looking in the ETSI TS 102 361-2 V2.3.1 (2016-02) specifications, I found instead

is it an issue, or am I misinterpreting the data?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[randybuildsthings]

What radio are you using for this? The code for talker alias decoding is pretty simple, so it's just displaying what it gets from the modem. I have doubts that it's a problem with the modem either, but that's a different code base that I'm not looking at.

[IK8JHL]

AFAIK the data displayed is decided directly from the TA data in the frame. There may be a bug in either the host or even the radio. I’d be surprised if it was in the host. Sent from Yahoo Mail for iPhone On Saturday, March 6, 2021, 14:29, IK8JHL notifications@github.com wrote: Reading the TalkerAlias ​​log I noticed something that is not clear to me - when I receive the TA via RF the DATA FORMAT is always 0 whatever format I choose, (8-bit, 7-bit, Unicode) 2)when I receive via network normally the DATA FORMAT is 1 but it becomes 2 if I receive through the DSTAR transcoding looking in the ETSI TS 102 361-2 V2.3.1 (2016-02) specifications, I found instead is it an issue, or am I misinterpreting the data? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

Is it possible to know what 0, 1 or 2 means after the "Data Format"? Another thing that is not clear to me is when it writes "Received 0/2 char" but instead received all three blocks including the Header. Another strange thing when he writes "Received 13/8" does not make sense I think this indication .. are all BUGs?

[IK8JHL]

What radio are you using for this? The code for talker alias decoding is pretty simple, so it's just displaying what it gets from the modem. I have doubts that it's a problem with the modem either, but that's a different code base that I'm not looking at.

the tests via RF were done with an Anytone 578, with three formats 7-bit, 8-bit, and unicode, via the network I received on Brandmeister, the Dstar test always arrived on Brandmeister from a transcoding

[randybuildsthings]

@g4klx I think @IK8JHL has something here. It's a bug in the RF talker alias processing in DMRSlot.cpp

There are two places in that file where talker alias is received from the modem (header, and blocks 1 through 3). The first is when talker alias is received over the air, and is sent to be decoded on the following line

https://github.com/g4klx/MMDVMHost/blob/b64359a157e3118d22926676b5a16bd00f40e885/DMRSlot.cpp#L659

Notice the "data" being passed as-is

And later in the file, the processing of incoming packets over the network is handled, and talker alias is extracted from the network packets.

https://github.com/g4klx/MMDVMHost/blob/b64359a157e3118d22926676b5a16bd00f40e885/DMRSlot.cpp#L1468

Here, the "data" is being passed with an offset of 2

Since the first nibble of every TA LC PDU is going to be nothing but zeroes, the data being passed to CDMRTA for decoding will always result in a type of '0'. Packets received over the network are being offset when sent to CDMRTA, and so they decode correctly.

Thanks for reporting this, @IK8JHL

I can make a patch for this relatively fast, but I'm running on fumes right now (nearly 1AM here), perhaps it would be easier for you, I'll check in the morning.

[randybuildsthings]

AFAIK the data displayed is decided directly from the TA data in the frame. There may be a bug in either the host or even the radio. I’d be surprised if it was in the host. Sent from Yahoo Mail for iPhone On Saturday, March 6, 2021, 14:29, IK8JHL notifications@github.com wrote: Reading the TalkerAlias ​​log I noticed something that is not clear to me - when I receive the TA via RF the DATA FORMAT is always 0 whatever format I choose, (8-bit, 7-bit, Unicode) 2)when I receive via network normally the DATA FORMAT is 1 but it becomes 2 if I receive through the DSTAR transcoding looking in the ETSI TS 102 361-2 V2.3.1 (2016-02) specifications, I found instead is it an issue, or am I misinterpreting the data? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

Is it possible to know what 0, 1 or 2 means after the "Data Format"? Another thing that is not clear to me is when it writes "Received 0/2 char" but instead received all three blocks including the Header. Another strange thing when he writes "Received 13/8" does not make sense I think this indication .. are all BUGs?

The "Received 0/2" is a less noticeable bug due to the fact that it is printing out how many characters it decoded "0" and how long the buffer for the talker alias is (which I guess is 2). It got to the point that once I figured out the offset problem in the DMRSlot.cpp file, I quit looking at this part of the problem.

[randybuildsthings]

I've created a PR for this: #684. It's a code-only fix, since I don't see any tests to run against. I also don't have a handy way to test this, but given my reading of the code, it's a cosmetic fix that has every likelihood of working.

And no, I do not understand how this happened. The code has been this way since @g4klx committed #479 more than two years ago. I guess people don't read TA that comes in over RF? Did the modem code originally truncate the first two octets of LC for RF packets? I doubt it.

[randybuildsthings]

Actually, it goes back even further, the data+2 thing goes back to 3a9c011dfa1431641a80dc5bc84d787d7002d1b8 in October 2017. Prior to that, the RF and Network talker alias were being treated the same way.

Whew. What a rabbit hole.

[IK8JHL]

Thank you Randy , i will test when its ready

[g4klx]

PR applied. If this persists, open a new issue with new examples of the problem.