Understanding XPT trunking

[lwvmobile]

Yeah back in post 13 I came to the conclusion that I didn't think the 1st entry was for current site.

Yep, that definitely falls in the category of the other half that I didn't remember covering. This is why I usually end up leaving tons of comments all in my code, so I can remind myself later on.

I don't understand the point of announcing the adjacent sites but then not identifying the current site.
How does a radio verify where it is if it can move between them?

Yeah, that's what I was wondering as well. I had figured it might be in another bit range or in some link control or csbk, but I couldn't find any of the spare bits (or used bits) that made it work consistently. Maybe the radios just know what the site id should be implicitly based on which frequency its tuned to, or what its programmed for.

 

[thewraith2008]

Maybe the radios just know what the site id should be implicitly based on which frequency its tuned to, or what its programmed for.

This looks likely as you would expect the site number to be sent quite frequently (i.e. SLCO) as to speed up site registration.

Another little thing I discovered in the TLC call alert is it will tell you which repeater channel the call will take place on. On that super busy IQ file, I noticed that those call alert/protects weren't always leading to calls on the current channel, but found the 4 bits 16-20 are the indicator for which LCN (not LSN) the call will occur on. Its been pretty consistent so far in all subsequent testing.

The 4 bits do look to be indicating the repeater number.

Which frequency (and TG/RID) in that IQ file did you see it not pointing to current repeater?

I noticed a (data) call not setup on 468.675 for TGT:10001 SRC:742.
This was indicating that the call was targeted for repeater 3. (which is what this repeater # is)
There where about 14 FLCO:9 sent:

• 10 of them I noticed the 4 bits (21-24) are = 7
• 4 of them I noticed the 4 bits (21-24) are = 2

I think normally when a call is setup, the 4 bits (21-24) are = 0 for the last few FLCO:9 PDUs.

Not sure if this is some type of acknowledgement (request/response) of called ms presence or not.
Prehaps if the value is not 0, then don't setup for a call.
So far I've seen the values 0,1,2,7. (maybe: 0=OK, 1=NotOK?, 2=NotOK, 7=WAIT for MS ACK)

 

[lwvmobile]

Which frequency (and TG/RID) in that IQ file did you see it not pointing to current repeater?

I don't know if I can find it again on those busy IQ samples, too much activity. But I did observe it on the Quebec systems. Here are a few examples of bits 16-20 indicating the the repeater the call will occur on, and matching Free Repeater on bits 24-28, and also examples of those two not matching, with a Free Repater that is different than the repeater the call will occur on.

18:52:28 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC 
 SLOT 1 FLCO=0x09 FID=0x68 TGT=54 SRC=12006 Hytera XPT Group Call Alert
  HSK=0; Handshake - Ordinary; Call on LCN 2; Free LCN 2;  <--call on 2, free on 2
 DMR PDU Payload [49][68][27][20][00][36][00][2E][E6][EF][B4][02]

 SLCO Hytera XPT - Free LCN 2 - PRI LCN 0 - PRI HASH: 00
 SLCO Completed Block [86][82][00][08][A0]

18:52:28 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Site Status - Free LCN: 2 SN: 0
 LCN 1 - LSN 01: ST-0 Idle; LSN 02: ST-0 Idle;
 LCN 2 - LSN 03: ST-3 054;  LSN 04: ST-0 Idle; <--LCN 2
 LCN 3 - LSN 05: ST-3 Null; LSN 06: ST-3 Null;
 DMR PDU Payload [0A][68][20][CF][00][00][36][00][00][00][93][A5]

18:57:11 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC 
 SLOT 1 FLCO=0x09 FID=0x68 TGT=73 SRC=24006 Hytera XPT Group Call Alert
  HSK=0; Handshake - Ordinary; Call on LCN 1; Free LCN 2; <--call on LCN 1, free on 2
 DMR PDU Payload [49][68][10][20][00][49][00][5D][C6][B6][7C][0C]

18:57:11 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Site Status - Free LCN: 2 SN: 0
 LCN 1 - LSN 01: ST-3 073;  LSN 02: ST-0 Idle; <--call on LCN 1
 LCN 2 - LSN 03: ST-0 Idle; LSN 04: ST-0 Idle;
 LCN 3 - LSN 05: ST-3 Null; LSN 06: ST-3 Null;
 DMR PDU Payload [0A][68][2C][0F][49][00][00][00][00][00][DD][85]

Here is another site that has free on 1 and calls on 1 and 2

19:00:50 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC 
 SLOT 1 FLCO=0x09 FID=0x68 TGT=63 SRC=17015 Hytera XPT Group Call Alert
  HSK=0; Handshake - Ordinary; Call on LCN 1; Free LCN 1; <--call on 1, free on 1
 
19:00:50 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Site Status - Free LCN: 1 SN: 0
 LCN 1 - LSN 01: ST-3 063;  LSN 02: ST-0 Idle; <-- call on 1
 LCN 2 - LSN 03: ST-0 Idle; LSN 04: ST-0 Idle;
 LCN 3 - LSN 05: ST-3 Null; LSN 06: ST-3 Null;

Here, one call is already starting, and another call rolls in, but we see the free repeater change from 1 to 2 but both calls happen on 1;

19:04:27 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC 
 SLOT 1 FLCO=0x09 FID=0x68 TGT=72 SRC=23006 Hytera XPT Group Call Alert
  HSK=0; Handshake - Ordinary; Call on LCN 1; Free LCN 1; 
 DMR PDU Payload [49][68][17][10][00][48][00][59][DE][7F][AE][9A]
 
19:04:27 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Site Status - Free LCN: 1 SN: 0
 LCN 1 - LSN 01: ST-3 072;  LSN 02: ST-0 Idle; <-- 72 call on 1
 LCN 2 - LSN 03: ST-0 Idle; LSN 04: ST-0 Idle;
 LCN 3 - LSN 05: ST-3 Null; LSN 06: ST-3 Null;
 DMR PDU Payload [0A][68][1C][0F][48][00][00][00][00][00][DE][F9]
 
19:04:27 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC 
 SLOT 1 FLCO=0x09 FID=0x68 TGT=72 SRC=23006 Hytera XPT Group Call Alert
  HSK=0; Handshake - Ordinary; Call on LCN 1; Free LCN 2; 
 DMR PDU Payload [49][68][17][20][00][48][00][59][DE][E7][6B][1D]
 
19:04:27 Sync: +DMR   slot1  [slot2] | Color Code=01 | TLC 
 SLOT 2 FLCO=0x09 FID=0x68 TGT=54 SRC=12006 Hytera XPT Group Call Alert
  HSK=0; Handshake - Ordinary; Call on LCN 1; Free LCN 2; 
 DMR PDU Payload [C9][68][17][20][00][36][00][2E][E6][4F][60][B4]

19:07:44 Sync: +DMR   slot1  [slot2] | Color Code=01 | TLC 
 SLOT 2 TGT=54 SRC=12006 FLCO=0x00 FID=0x68 SVC=0x00 Hytera XPT Group Call 
 DMR PDU Payload [00][68][00][20][00][36][00][2E][E6][20][AF][F9]
19:07:44 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK
 Hytera XPT Site Status - Free LCN: 2 SN: 0
 LCN 1 - LSN 01: ST-0 Idle; LSN 02: ST-3 054; <-- 54 call on LCN 1
 LCN 2 - LSN 03: ST-0 Idle; LSN 04: ST-0 Idle;
 LCN 3 - LSN 05: ST-3 Null; LSN 06: ST-3 Null;
 DMR PDU Payload [0A][68][23][0F][00][36][00][00][00][00][E7][DE]

19:11:21 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Site Status - Free LCN: 2 SN: 0
 LCN 1 - LSN 01: ST-0 Idle; LSN 02: ST-0 Idle;
 LCN 2 - LSN 03: ST-3 072;  LSN 04: ST-0 Idle;
 LCN 3 - LSN 05: ST-3 Null; LSN 06: ST-3 Null;
 DMR PDU Payload [0A][68][20][CF][00][00][48][00][00][00][73][8A]
 
19:11:21 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC 
 SLOT 1 FLCO=0x09 FID=0x68 TGT=72 SRC=23002 Hytera XPT Group Call Alert
  HSK=0; Handshake - Ordinary; Call on LCN 2; Free LCN 2;

Anyways, here are the samples where these observations were made, they were recorded while I was able to trunk the system and change to the proper frequencies to listen in and record them.

Upload files for free - quebec_xpt.zip - ufile.io

Download quebec_xpt.zip for free from ufile.io instantly, no signup required and no popup ads

ufile.io

 

[thewraith2008]

With your trunking, what are you doing to filter out DATA calls?
With that IQ file, there are a squillion of them occurring which does make the logical channel activity indicator go nuts and setting up a voice only call would be a challenge since so far there does not seem to be a flag to indicate voice or data calls. (in FLCO:9 or CSBKO:0x0A).

Back in post 4 I mentioned a possible way but still have not tried to do it. (can't try on live system)

 

[KevinC]

Going to interlope a bit...

I really appreciate all the professionalism in this thread. No infighting, and no one claiming they were first to figure this or that out or any crap like that.

Back to your technical discussions...no need to reply to this and start polluting the thread more than I already did.

 

[lwvmobile]

With your trunking, what are you doing to filter out DATA calls?

I'm not even sure if there is a way to filter out data calls without a lot of extra coding shenanigans to perpetually check for preamble csbks and data related bursts. I would say go filter by status bits being = 2 but I think that handles both private data and private voice calls. The systems I've been monitoring aren't so busy that the data calls would create a problem I don't think, I actually haven't even seen a single data call on the systems the entire time I've been monitoring it, at least, not that I'm aware or remember.

20:14:33 Sync: +DMR   slot1  [slot2] | Color Code=10 | CSBK
 Preamble CSBK - Individual Data - Source: 10001 - Target: 420 - Hash: 96 
 DMR PDU Payload [BD][68][80][06][10][01][A4][00][27][11][1B][83]
20:14:33 Sync: +DMR  [slot1]  slot2  | Color Code=10 | CSBK
 Hytera XPT Site Status - Free LCN: 1 SN: 0
 LCN 1 - LSN 01: ST-0 Idle; LSN 02: ST-2 Priv; <-- really beginning to second guess this
 LCN 2 - LSN 03: ST-0 Idle; LSN 04: ST-2 096;  
 LCN 3 - LSN 05: ST-2 187;  LSN 06: ST-2 088;  
 DMR PDU Payload [0A][68][12][2A][00][00][00][60][BB][58][B2][8A]
 SLCO Hytera XPT - Free LCN 1 - PRI LCN 0 - PRI HASH: 00
 SLCO Completed Block [86][81][00][07][30]
20:14:33 Sync: +DMR   slot1  [slot2] | Color Code=10 | CSBK
 Preamble CSBK - Individual Data - Source: 10001 - Target: 420 - Hash: 96 
 DMR PDU Payload [BD][68][80][05][10][01][A4][00][27][11][C3][01]
20:14:33 Sync: +DMR  [slot1]  slot2  | Color Code=10 | CSBK
 Hytera XPT Site Status - Free LCN: 1 SN: 1
 LCN 4 - LSN 07: ST-0 Idle; LSN 08: ST-2 140;  
 LCN 5 - LSN 09: ST-3 Null; LSN 10: ST-3 Null; 
 LCN 6 - LSN 11: ST-3 Null; LSN 12: ST-3 Null; 
 DMR PDU Payload [4A][68][12][FF][00][8C][00][00][00][00][D3][C3]
20:14:33 Sync: +DMR   slot1  [slot2] | Color Code=10 | CSBK
 Preamble CSBK - Individual Data - Source: 10001 - Target: 420 - Hash: 96 
 DMR PDU Payload [BD][68][80][04][10][01][A4][00][27][11][7B][60]
20:14:33 Sync: +DMR  [slot1]  slot2  | Color Code=10 | TLC  
 SLOT 1 FLCO=0x09 FID=0x68 TGT=10002 SRC=9850 Hytera XPT Private Call Alert 
  TGT Hash=187; HSK=0; Handshake - Ordinary; Call on LCN 2; Free LCN 1;  
 DMR PDU Payload [09][68][21][10][27][12][00][26][7A][84][C2][9A]
 SLCO CRC ERR
20:14:34 Sync: +DMR   slot1  [slot2] | Color Code=10 | DATA 
 Slot 2 Data Header - INDIV - Short Data: Defined - Source: 10001 Target: 420 Hash: 96 
  SD:D [DD_HEAD] - SAP 09 [Prop PDU] - BLOCKS 03 - DD 15 - PADb 16 - FMT 15 [UTF-16LE]
 DMR PDU Payload [0D][93][10][01][A4][00][27][11][55][10][E9][17]

I am beginning to second guess the status bits = 2 with null/0 value in them as to what they mean exactly.

 

[thewraith2008]

The 0 is not NULL but slot idle (1 = slot busy)

I see the 'repeater state' 4 bits ('abcd') as:

• 'a' - TS1 - 0=Idle / 1=Busy
• 'b' - TS1 Type - 0=Private call / 1=Group call
• 'c' - TS2 - 0=Idle / 1=Busy
• 'd' - TS2 Type - 0=Private call / 1=Group call

 

[lwvmobile]

The 0 is not NULL but slot idle (1 = slot busy)

I may have misspoken earlier, I am using status 0 to indicate idle, and others to indicate activity. What I am having happen is for the status to be not idle, but for there to be no corresponding 8-bit value to indicate the group TG value or private tgt hash value further down in the CSBK.

Which bit range are you using again for the repeater state? I am starting at bit 20, and reading 2 bits for each 6 logical slots. Then, I am looking at bit 32, and reading 8 bits for the first lsn, the next 8 bits for the next lsn, the next 8 bits for the 3rd lsn, and so on until I arrive at bit 72, read 8 for the 6th lsn to round out to 80 bits.

For example, what I am seeing is this:

20:14:33 Sync: +DMR  [slot1]  slot2  | Color Code=10 | CSBK
 Hytera XPT Site Status - Free LCN: 1 SN: 0
 LCN 1 - LSN 01: ST-0 Idle; LSN 02: ST-2 Priv; <-- status is 2,
 LCN 2 - LSN 03: ST-0 Idle; LSN 04: ST-2 096; 
 LCN 3 - LSN 05: ST-2 187;  LSN 06: ST-2 088; 
 DMR PDU Payload [0A][68][12][2A][00]--[00]<--LSN 2 TG/TGT value is NULL/zeroes [00][60][BB][58][B2][8A]

 

[thewraith2008]

I think we are reading the same way.
For the CSBKO: 0x0A "XPT_CH_Status" PDU.

First 16 bits are: SN[2], CSBKO[6], FID[8]
Then the following 80 bits as:

• Free repeater[4]
• Repeater A* state[4] - as described in post 27
• Repeater B* state[4]
• Repeater C* state[4]
• Repeater A* hashed address[8] - TS1
• Repeater A* hashed address[8] - TS2
• Repeater B* hashed address[8] - TS1
• Repeater B* hashed address[8] - TS2
• Repeater C* hashed address[8] - TS1
• Repeater C* hashed address[8] - TS2
• CRC-16[16]

Bit rusty here but I think the HASHED addresses only apply to private addresses

• Group TGs are only up to 240 (Gateways and Emergency IDs are 241-249, 250-255), so the 8 bits can represent them directly.
• My guess is, private radio ids 1-255 will still be hashed.

* Depending on sequence number: (A,B,C can be for the following repeaters)
SN:0 - Repeaters 1-3 (Logical CH 1-6)
SN:1 - Repeaters 4-6 (Logical CH 7-12)
SN:2 - Repeaters 7-9 (Logical CH 13-18) **
SN:3 - Repeaters 10-12 (Logical CH 19-24) **

** I think only 8 repeaters can be addressed at a time (whether voice or data) (so repeaters 9, 10, 11, 12 are reserved)
XPT mentions it can have 8 Voice and 8 DATA repeaters. (x2 for logical CH count)

The system can support up to 16 voice channels and 16 data channels at a time

I would guess that DATA repeaters are handled separately to the voice repeaters when used.
You obvious can still have DATA on voice repeater as we have seen this. But not the other way round I think.

 

[lwvmobile]

Bit rusty here but I think the HASHED addresses only apply to private addresses

That's been my experience so far, the hash only applies to private calls where the tgt value is 16-bit. When its group calls, the group id in the link control is present as-is in the status csbk.

My guess is, private radio ids 1-255 will still be hashed.

Yeah, most likely, I would imagine not being consistent on this could lead to issues.

I would guess that DATA repeaters are handled separately to the voice repeaters when used.
You obvious can still have DATA on voice repeater as we have seen this. But not the other way round I think.

That sounds about right, looking at the system application notes. If this is the case, then perhaps the easiest way to not tune data calls (or mitigate them) is just to not load frequencies for data only repeaters into your application so it can't trunk what it can't tune to. In the system notes, it shows that the voice call channels are indexed at the beginning, while data repeaters are indexed at 15+, so its possible that when looking at the csbk status in order from least to greatest value, that tuning voice calls on a lower indexed LSN would take precedent over a higher indexed calls. That's the way dsd-fme has been coded to handle both capacity plus and xpt anyways, and its free to tune at any time as long as there is no voice activity within a 1-2 second window then its free to tune again.

Another thing I started to look at are bits 20-24 on the TLC Call Setup, I've observed these values sometimes change during the course of the setup prior to a call occurring. Taking either bits 20-24, or just 21-24 (just speculating here) that these values will change when a call is requested, and when its connected. I've also been looking at bit range 48-56 and 72-80 on the same TLC setup to see if anything relevant happens there, but haven't been able to make a direct correlation that's consistent with anything.

 

[thewraith2008]

These are the 4 bits (20-23) I was referencing in post 22.

• The 4 bits 16-19 are the ones you said where the repeater number (index) of a call possibly about to be setup.

I noticed a (data) call not setup on 468.675 for TGT:10001 SRC:742.
This was indicating that the call was targeted for repeater 3. (which is what this repeater # is)
There where about 14 FLCO:9 sent:

• 10 of them I noticed the 4 bits (20-23) are = 7
• 4 of them I noticed the 4 bits (20-23) are = 2

I think normally when a call is setup, the 4 bits (20-23) are = 0 for the last few FLCO:9 PDUs.

Not sure if this is some type of acknowledgement (request/response) of called ms presence or not.
Prehaps if the value is not 0, then don't setup for a call.
So far I've seen the values 0,1,2,7. (maybe: 0=OK, 1=NotOK?, 2=NotOK, 7=WAIT for MS ACK)

edit: corrected bit positions (to use 0 as starting point)

 

[lwvmobile]

I'm terrible about not going back and re-reading old posts to remember what we have already discussed , who needs them there reading books anyways.

 

[thewraith2008]

I've also been looking at bit range 48-56 and 72-80 on the same TLC setup

That would be out of range for the TLC.

In addition there is: 28-31 (bits after free repeater)

I've noticed my usage of bit positions sometimes starts at 0 or 1, Sorry about that.
Normally I start at zero as this is same as reading the buffer in code.

• My bit position references using 0 as starting point for FLCO:9 should be:
  Repeater number: bits 16-19
• ???: bits: 20-23 (possible ack for setup?)
• Free repeater: bits 24-27

 

[lwvmobile]

That would be out of range for the TLC.

Oh yeah, that's right. I keep thinking its a CRC16 like the CSBK. Good thing I didn't actually do anything with those bits in the TLC.

Normally I start at zero as this is same as reading the buffer in code.

That's usually what I do as well, but I understand all to well getting messed up or saying the wrong bit position. Doesn't help when you look at a manual and it shows the MSB is bit 7, and LSB is bit 0, but decoding it is the opposite.

Just a random screenshot I had to demonstrate my point.

 

[thewraith2008]

The patents refer to the spare 4 and 8 bits as usage for priority call.
I think this can appear in SLCO and FLCO PDUs. (the FID:104 (0x68) ones)

The Application Notes do refer to this priority call feature been able to be setup.
I think I read it only comes in to play on a full/busy system to free resources to allow priority call to proceed.

 

[thewraith2008]

Doesn't help when you look at a manual and it shows the MSB is bit 7, and LSB is bit 0, but decoding it is the opposite.

This is just indicating that the data is stored big-endian (MSB to LSB) in the buffer.

I know it was fun with the indices for de-interleaving the various received buffers.
Not kidding when they say scrambling.

 

[lwvmobile]

I know it was fun with the indices for de-interleaving the various received buffers.

I think I went cross eyed when I did the de-interleave on the Phase 2 2v/4v back when I implemented it.

Oh, did you ever figure out or mention what LC FID: 0x68 FLCO: 0x13 might be. I see that often. At first, I thought it was just in the embedded link control, but it also appears to be in the TLC as well during a call setup.

13:50:03 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Site Status - Free LCN: 2 SN: 0
 LCN 1 - LSN 01: ST-3 054;  LSN 02: ST-0 Idle;
 LCN 2 - LSN 03: ST-0 Idle; LSN 04: ST-0 Idle;
 LCN 3 - LSN 05: ST-3 Null; LSN 06: ST-3 Null;
 DMR PDU Payload [0A][68][2C][0F][36][00][00][00][00][00][5D][1A]
13:50:03 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC 
 SLOT 1 FLCO=0x09 FID=0x68 TGT=54 SRC=12016 Hytera XPT Group Call Alert
  HSK=0; Handshake - Ordinary; Call on LCN 1; Free LCN 2; 
 DMR PDU Payload [49][68][17][20][00][36][00][2E][F0][2D][2F][22]
13:50:03 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT CSBK 0x0B - SN: 0
 XPT Adjacent Site:1 Free:2; Site:3 Free:1; Site:4 Free:2; Site:5 Free:1;
 DMR PDU Payload [0B][68][08][20][18][10][20][20][28][10][3F][42]
13:50:03 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC 
 SLOT 1 Hytera  FLCO=0x13 FID=0x68 <--what does this mean
 DMR PDU Payload [13][68][20][08][21][18][20][21][28][D1][3B][E8] <-- relevant bytes
 SLCO Hytera XPT - Free LCN 2 - PRI LCN 0 - PRI HASH: 00
 SLCO Completed Block [86][82][00][08][A0]

I thought it might have something to do with either current site identification or site status, but couldn't really figure anything out on it. Could also be any one of the many radio 'featuers' from the application notes, like Smart Battery Report or Quick GPS? No idea.

 

[thewraith2008]

No.
FLCO: 0x04, 0x05 and 0x13 (for FID:0x68) have been noted as been seen but I have not done to much in the way to analyze them.

My notes show they where present in the EMB signalling during a voice transmission and they didn't seem to carry the TG/TGT/SRC addresses or free repeater.

If they are TX MS related feature PDUs, it maybe hard to determine what exactly they are for.
GPS or TX Alias is the only ones that spring to mind as well.

 

[lwvmobile]

FLCO: 0x04, 0x05

My experience has been that on Hytera, 0x04, 0x05, 0x06 and 0x07 are indeed embedded talker alias, I've seen Hytera use it with both FID 0x68 and 0x0 (standard) on XPT and TIII.

20:25:06 Sync: +DMR  [SLOT1]  slot2  | Color Code=01 | VC6
 Embedded Alias: PET
 DMR PDU Payload [04][68][D4][00][50][00][45][00][54]

20:25:07 Sync: +DMR  [SLOT1]  slot2  | Color Code=01 | VC6
 Embedded Alias: PETER
 DMR PDU Payload [05][68][00][45][00][52][00][20][00]

---
20:31:35 Sync: +DMR  [SLOT1]  slot2  | Color Code=01 | VC6 
 Embedded Alias: BUR
 DMR PDU Payload [04][68][CC][00][42][00][55][00][52]

20:31:36 Sync: +DMR  [SLOT1]  slot2  | Color Code=01 | VC6 
 Embedded Alias: BUREAU
 DMR PDU Payload [05][68][00][45][00][41][00][55][A5]

Also, speaking of embedded talker alias, if you ever see opcodes 0x14, 0x15, 0x16, and 0x17, I've found out that with FID 0x10, those are also embedded talker alias as well. I see them often on CapMax systems, but could probably be any Moto system.

 

[thewraith2008]

My experience has been that on Hytera, 0x04, 0x05, 0x06 and 0x07 are indeed embedded talker alias, I've seen Hytera use it with both FID 0x68 and 0x0 (standard) on XPT and TIII.

In the output samples I have of 0x04 and 0x05 from XPT, they seem to contain a lot of zeros in them to be suitable as text.
I did not note which recordings I saw them in, but it would be from one of the recordings obtained from this thread.

Also, speaking of embedded talker alias, if you ever see opcodes 0x14, 0x15, 0x16, and 0x17, I've found out that with FID 0x10, those are also embedded talker alias as well. I see them often on CapMax systems, but could probably be any Moto system.

I don't think I've seen them used on the CapMAX systems I've looked at yet.