Understanding XPT trunking

[thewraith2008]

This thread is for the discussion of Hytera XPT (Extended Pseudo Trunk).
It is meant as a technical discussion about the inner workings and some of the unknowns with the XPT system in an effort to improve decoding and trunking.
This is not meant as a how do you setup software X to listen/monitor to XPT, please start a new thread for that.
Before this discussion, not much had been worked out with XPT and information was sparse for it.

The original discussion was started within another thread "Understanding Capacity Plus trunking, some more" and got more involved than we expected in that thread.
If you wish to look at the things that where posted there, here is a summary of those 53 posts related to the XPT discussion:

• From page: 5 - (# posts = 14): 87 - 100
• From page: 6 - (# posts = 2, 16) - 101 - 102, 105 - 120
• From page: 7 - (# posts = 20) - 121 to 140
• From page: 8 - (# post = 1) - 141

If a system admin or forum mod feels inclined to move those posts here, that would be great otherwise the above links will have to suffice.

 

[thewraith2008]

I was looking at the FLCO:9 PDU some more and I'm beginning to think this is more like the P_PROTECT PDU (in function) than a type of grant.

The P_PROTECT is used to cleardown (remove) any TG's/MS's from a payload channel who are not specified by the TGT/SRC address fields in that PDU.

For XPT, this would mean either: (speculation)

• Ignore this upcoming call because you are not one of the addressed and the home repeater still has an idle slot to use so Ok to remain and monitor other slot for call.
• Ignore this upcoming call because you are not one of the addressed and move to the free repeater to wait a potential targeted call because both the home repeater slots are busy.

The FLCO:9 is sent at the beginning of a call in the TermLC (SlotType PDU) and is seen regardless of call type: Group Voice, Private Voice or DATA.
The PDU does not seem to indicate what the call type is which would make it hard to use as a grant.

 

[lwvmobile]

I was looking at the FLCO:9 PDU some more and I'm beginning to think this is more like the P_PROTECT PDU (in function) than a type of grant.

The P_PROTECT is used to cleardown (remove) any TG's/MS's from a payload channel who are not specified by the TGT/SRC address fields in that PDU.

That does make more sense when you put it that way. I see the CSBK P_Protect (Illegally Parked) all the time on a T3 Tait system that has tons of private voice calls, its function is just as you say, to tell other traffic to move back along to the control channel. In this case, I would guess its to tell the MS units to move to the new Free RPT channel.

The FLCO:9 is sent at the beginning of a call in the TermLC (SlotType PDU) and is seen regardless of call type: Group Voice, Private Voice or DATA.
The PDU does not seem to indicate what the call type is which would make it hard to use as a grant.

From a MS units perspective, I guess it doesn't care what the type is, if its meant to be there it'll figure it out when it gets there (or stays there, rather). Of course, from a scanner/software trunking perspective, its one of those things where you'll find out when you find out. I do recall seeing tons of CSBK preamble incoming data header on that super busy Hytera XPT IQ file though, so I guess that's your sign on if its private or group data, and the normal VLC header would be the same on private or group voice.

 

[thewraith2008]

From a MS units perspective, I guess it doesn't care what the type is, if its meant to be there it'll figure it out when it gets there (or stays there, rather). Of course, from a scanner/software trunking perspective, its one of those things where you'll find out when you find out. I do recall seeing tons of CSBK preamble incoming data header on that super busy Hytera XPT IQ file though, so I guess that's your sign on if its private or group data, and the normal VLC header would be the same on private or group voice.

Agreed.

One of the trunking methods I come up with is to use the CSBKO:10 announcement of calls, then select one (1st, random, priority) go to repeater to determine if call is voice or data by waiting to see if Voice Header LC (0/3) is seen or the CSBK0:61 (Preamble) is seen. If the latter, then data so ignore and return to monitoring the CSBKO:10 otherwise continue to listen to call.

There will need to be more logic involved for the various outcomes but you should get the idea.

This approach won't work for a single repeater XPT configuration as it seems it does don't use CSBKO:10 to announce any calls (on either of the 2 slots). I guess there is no need for it. In this case you would setup call like a BS.

I have not implemented or tested this method as the current available samples don't provide enough activity to experiment with.
An IQ sample like the one you provided: "SDRSharp_20181105_172709Z_467931250Hz_IQ.wav" would be good as it sees all the repeaters and would allow testing to following to the repeaters when they become active. Problem is, these types of files can get large.

 

[lwvmobile]

I think I might have just broke your theory on the CSBK 0x0B - CSBK:11. I'm getting two different sets of values out of it with the new samples from @mrscanner2008

21:04:34 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC 
 SLOT 1 TGT=72 SRC=23005 HASH=255 CH=2 FLCO=0x09 FID=0x68 Hytera XPT Group Call Grant F-Rpt 2
 DMR PDU Payload [49][68][17][10][00][48][00][59][DD][6D][E6][5A]
 SLCO Hytera XPT - Free RPT 2
 SLCO Completed Block [86][81][00][07][30]
21:04:34 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Site Id: 1 - Free RPT: 2
 XPT Adj Site(s): 4 (2) 2 (2) 5 (1)
 DMR PDU Payload [0B][68][08][20][20][20][10][20][28][10][3D][8B]
21:04:34 Sync: +DMR  [slot1]  slot2  | Color Code=01 | VLC 
 SLOT 1 TGT=72 SRC=23005 HASH=255 FLCO=0x00 FID=0x68 SVC=0x00 Hytera XPT Group Call 
 DMR PDU Payload [40][68][00][10][00][48][00][59][DD][F8][62][D6]
21:04:34 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Site Id: 10 - Free RPT: 15
 XPT Adj Site(s):
 DMR PDU Payload [4B][68][54][F0][00][00][00][00][00][00][E9][8F]
21:04:34 Sync: +DMR  [slot1]  slot2  | Color Code=01 | VLC 
 SLOT 1 TGT=72 SRC=23005 HASH=255 FLCO=0x00 FID=0x68 SVC=0x00 Hytera XPT Group Call 
 DMR PDU Payload [40][68][00][10][00][48][00][59][DD][F8][62][D6]
 SLCO Hytera XPT - Free RPT 2
 SLCO Completed Block [86][81][00][07][30]
21:04:34 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Site Status - Free RPT: 2 SN: 0
 Ch01: ST-3 072  Ch02: ST-0 Idle Ch03: ST-0 Idle
 Ch04: ST-0 Idle Ch05: ST-3 Null Ch06: ST-3 Null
 DMR PDU Payload [0A][68][1C][0F][48][00][00][00][00][00][DE][F9]

 

[thewraith2008]

When I can get access to DL samples, I'll have a look.
Which file did you use and see this on?

I've noticed that the 4th entry has the protect flag (PF) bit set:

21:04:34 Sync: +DMR slot1 [slot2] | Color Code=01 | CSBK Hytera XPT Site Id: 10 - Free RPT: 15
XPT Adj Site(s):
DMR PDU Payload [4B][68][54][F0][00][00][00][00][00][00][E9][8F]

This maybe the reason for odd results?
Bad decode or is PDU encryption been used?

EDIT: Changed "privacy" to "protect flag"

 

[lwvmobile]

I've noticed that the 4th entry has the protect flag (PF) bit set:

Ordinarily, yes, that is the protect bit. This is the backwards world of Hytera, where nothing is standard. On the Calixte sample, it happens frequently, I thought it was a TS bit. It also passes the CRC, so it isn't a bad decode. So, its either a TS bit, or its a SN bit. My guess at least.

Here are some more of the same 10/11 CSBKs from the IQ sample that show the first two bits being manipulated in various ways.

11:51:20 Sync: +DMR  [slot1]  slot2  | Color Code=10 | CSBK
 Hytera XPT Site Status - Free RPT: 2 SN: 0
 Ch01: ST-0 Idle Ch02: ST-0 Idle Ch03: ST-0 Idle
 Ch04: ST-2 088  Ch05: ST-0 Idle Ch06: ST-0 Idle
 DMR PDU Payload [0A][68][10][20][00][00][00][58][00][00][BB][6C]
11:51:20 Sync: +DMR   slot1  [slot2] | Color Code=10 | CSBK
 Hytera XPT CSBK 0x0B
 DMR PDU Payload [8B][68][08][20][18][10][00][00][00][00][F7][80]
11:51:20 Sync: +DMR  [slot1]  slot2  | Color Code=10 | CSBK
 Hytera XPT Site Status - Free RPT: 2 SN: 1
 Ch07: ST-3 Null Ch08: ST-3 Null Ch09: ST-3 Null
 Ch10: ST-3 Null Ch11: ST-3 Null Ch12: ST-3 Null
 DMR PDU Payload [4A][68][1F][FF][00][00][00][00][00][00][2C][5C]
 SLCO Hytera XPT - Free RPT 2
 SLCO Completed Block [86][81][00][07][30]
11:51:20 Sync: +DMR   slot1  [slot2] | Color Code=10 | CSBK
 Hytera XPT Site Status - Free RPT: 2 SN: 0
 Ch01: ST-0 Idle Ch02: ST-0 Idle Ch03: ST-0 Idle
 Ch04: ST-2 088  Ch05: ST-0 Idle Ch06: ST-0 Idle
 DMR PDU Payload [0A][68][10][20][00][00][00][58][00][00][BB][6C]
11:51:20 Sync: +DMR  [slot1]  slot2  | Color Code=10 | CSBK
 Hytera XPT CSBK 0x0B
 DMR PDU Payload [8B][68][08][20][18][10][00][00][00][00][F7][80]
11:51:20 Sync: +DMR   slot1  [slot2] | Color Code=10 | CSBK
 Hytera XPT Site Status - Free RPT: 2 SN: 1
 Ch07: ST-3 Null Ch08: ST-3 Null Ch09: ST-3 Null
 Ch10: ST-3 Null Ch11: ST-3 Null Ch12: ST-3 Null
 DMR PDU Payload [4A][68][1F][FF][00][00][00][00][00][00][2C][5C]
11:51:20 Sync: +DMR  [slot1]  slot2  | Color Code=10 | CSBK
 Hytera XPT Site Status - Free RPT: 2 SN: 0
 Ch01: ST-0 Idle Ch02: ST-0 Idle Ch03: ST-0 Idle
 Ch04: ST-2 088  Ch05: ST-0 Idle Ch06: ST-0 Idle
 DMR PDU Payload [0A][68][10][20][00][00][00][58][00][00][BB][6C]
 SLCO Hytera XPT - Free RPT 2
 SLCO Completed Block [86][81][00][07][30]

 

[thewraith2008]

When the PF bit is set, I would just write off the PDUs as encrypted and ignore them and only use them when PF is clear.

These PDUs maybe encrypted but could just be a red herring.
I think the latter is true because why not just encrypt all of them and be done with it rather than interleave good ones with bad ones.

The green DCC indicates when PF is set.

 

[lwvmobile]

When the PF bit is set, I would just write off the PDUs as encrypted and ignore them and only use them when PF is clear.

No other known XPT PDUs (FLC or CSBK) use the first two bits PF/LB/RS bit for their 'standard' function, so I wouldn't expect them to use it for this CSBK either.

These PDUs maybe encrypted but could just be a red herring.
I think the latter is true because why not just encrypt all of them and be done with it rather than interleave good ones with bad ones.

I'm still thinking that bit has a meaning. I don't believe its a TS indicator, because on the 'Covey' sample, we get back to back 0x0B with different timeslots, so it may be a sequence number, or the first two bits are used as a sequence number like they are on CSBK10, in which case, this extra little bit of data is meant to append to CSBK11, just not sure why Adjacent Site 10 and Free RPT 15 don't seem like they would fit as yet another adjacent site. Could just be that its appended data of some kind, but all zeroes in this instance.

 

[thewraith2008]

If you use the first two bits as sequence number, then doesn't that just indicate there is another PDU in a sequence that lists Site: 10 Repeater: 15 as just another adjacent site in the list?

Like you said, who knows if that's a real repeater in the multi-site network.
This is where an IQ sample would benefit (so long as all repeaters/sites are visible in that spectrum)

The one XPT I have here indicates free repeater 15 and CSBKO:10 does not indicate any call activity when there is some.
I'm thinking that 15 indicates that the site is only a single repeater site (XPT conventional?).
I've also seen free repeater as 0 which indicates all repeaters are busy.

 

[lwvmobile]

The one XPT I have here indicates free repeater 15 and CSBKO:10 does not indicate any call activity when there is some.
I'm thinking that 15 indicates that the site is only a single repeater site (XPT conventional?).

Yeah, I have no idea on that one, just thought it was unusual for it to be 15 and zero activity, or minimal activity.

I've also seen free repeater as 0 which indicates all repeaters are busy.

Yeah, I was wondering about that. I do a +1 to all of them, my thought was that it started at index value 0, but maybe 0 means there isn't a free repeater available, completely busy.

If you use the first two bits as sequence number, then doesn't that just indicate there is another PDU in a sequence that lists Site: 10 Repeater: 15 as just another adjacent site in the list?

That's the only other thought I had, but it doesn't feel like it fits in with the rest of them. I wonder if the 0x54 and 0xF0 is meant to be a flag or something instead. End of message flag or something.

 

[lwvmobile]

I've also seen free repeater as 0 which indicates all repeaters are busy.

I think this is correct now. I did a little testing trying to find where I had the Free RPT of 0 in that IQ file, and found that just prior to it going to zero, all other channels were showing busy, then a new TLC 'Protect' rolls in and sets up a data call, and the SLC shows Free RPT 0 a few times until one of the other calls drops and then bounces from 0 to 3 a few times (presumably data call on and off a few times)

23:11:59 Sync: +DMR  [slot1]  slot2  | Color Code=10 | CSBK
 Hytera XPT Site Status - Free RPT: 2 SN: 1
 Ch07: ST-3 Null Ch08: ST-3 Null Ch09: ST-3 Null
 Ch10: ST-3 Null Ch11: ST-3 Null Ch12: ST-3 Null
 DMR PDU Payload [4A][68][2F][FF][00][00][00][00][00][00][6A][80]
 SLCO Hytera XPT - Free RPT 2 - PRI RPT 0 - PRI HASH: 00
 SLCO Completed Block [86][82][00][08][A0]
23:11:59 Sync: +DMR   slot1  [slot2] | Color Code=10 | TLC 
 SLOT 2 TGT=9317 SRC=930 HASH=198 FLCO=0x03 FID=0x68 SVC=0x40 Encrypted Hytera XPT Private Call 
 DMR PDU Payload [03][68][40][20][24][65][00][03][A2][56][8D][05]
23:11:59 Sync: +DMR  [slot1]  slot2  | Color Code=10 | CSBK
 Hytera XPT CSBK 0x0B
 DMR PDU Payload [8B][68][08][40][18][30][00][00][00][00][4C][2E]
23:11:59 Sync: +DMR   slot1  [slot2] | Color Code=10 | TLC 
 SLOT 2 TGT=9317 SRC=930 HASH=198 FLCO=0x03 FID=0x68 SVC=0x40 Encrypted Hytera XPT Private Call 
 DMR PDU Payload [03][68][40][20][24][65][00][03][A2][56][8D][05]
23:11:59 Sync: +DMR  [slot1]  slot2  | Color Code=10 | CSBK
 Hytera XPT Site Status - Free RPT: 2 SN: 0
 Ch01: ST-2 035  Ch02: ST-2 181  Ch03: ST-0 Idle
 Ch04: ST-2 198  Ch05: ST-2 187  Ch06: ST-2 187 
 DMR PDU Payload [0A][68][2A][2A][23][B5][00][C6][BB][BB][DE][7C]
 SLCO Hytera XPT - Free RPT 2 - PRI RPT 0 - PRI HASH: 00
 SLCO Completed Block [86][82][00][08][A0]
23:11:59 Sync: +DMR   slot1  [slot2] | Color Code=10 | TLC 
 SLOT 2 TGT=9317 SRC=930 HASH=198 FLCO=0x03 FID=0x68 SVC=0x40 Encrypted Hytera XPT Private Call 
 DMR PDU Payload [03][68][40][00][24][65][00][03][A2][4D][0B][FF]
23:11:59 Sync: +DMR  [slot1]  slot2  | Color Code=10 | TLC 
 SLOT 1 TGT=10001 SRC=9346 HASH=178 CH=3 FLCO=0x09 FID=0x68 Hytera XPT Private Call Protect F-Rpt 0
 DMR PDU Payload [09][68][20][00][27][11][00][24][82][D3][9C][E3]
23:11:59 Sync: +DMR   slot1  [slot2] | Color Code=10 | TLC 
 SLOT 2 TGT=9317 SRC=930 HASH=198 FLCO=0x03 FID=0x68 SVC=0x40 Encrypted Hytera XPT Private Call 
 DMR PDU Payload [03][68][40][00][24][65][00][03][A2][4D][0B][FF]
23:11:59 Sync: +DMR  [slot1]  slot2  | Color Code=10 | TLC 
 SLOT 1 TGT=10001 SRC=9346 HASH=178 CH=3 FLCO=0x09 FID=0x68 Hytera XPT Private Call Protect F-Rpt 0
 DMR PDU Payload [09][68][20][00][27][11][00][24][82][D3][9C][E3]
 SLCO Hytera XPT - Free RPT 0 - PRI RPT 0 - PRI HASH: 00
 SLCO Completed Block [86][80][00][02][40]
23:11:59 Sync: +DMR   slot1  [slot2] | Color Code=10 | TLC 
 SLOT 2 TGT=9317 SRC=930 HASH=198 FLCO=0x03 FID=0x68 SVC=0x40 Encrypted Hytera XPT Private Call 
 DMR PDU Payload [03][68][40][00][24][65][00][03][A2][4D][0B][FF]
23:11:59 Sync: +DMR  [slot1]  slot2  | Color Code=10 | TLC 
 SLOT 1 TGT=10001 SRC=9346 HASH=178 CH=3 FLCO=0x09 FID=0x68 Hytera XPT Private Call Protect F-Rpt 0
 DMR PDU Payload [09][68][20][00][27][11][00][24][82][D3][9C][E3]
23:11:59 Sync: +DMR   slot1  [slot2] | Color Code=10 | TLC 
 SLOT 2 TGT=9317 SRC=930 HASH=198 FLCO=0x03 FID=0x68 SVC=0x40 Encrypted Hytera XPT Private Call 
 DMR PDU Payload [03][68][40][30][24][65][00][03][A2][D5][CE][78]
23:11:59 Sync: +DMR  [slot1]  slot2  | Color Code=10 | TLC 
 SLOT 1 TGT=10001 SRC=9346 HASH=178 CH=3 FLCO=0x09 FID=0x68 Hytera XPT Private Call Protect F-Rpt 3
 DMR PDU Payload [09][68][20][30][27][11][00][24][82][4B][59][64]
 SLCO Hytera XPT - Free RPT 0 - PRI RPT 0 - PRI HASH: 00
 SLCO Completed Block [86][80][00][02][40]
23:11:59 Sync: +DMR   slot1  [slot2] | Color Code=10 | TLC 
 SLOT 2 TGT=9317 SRC=930 HASH=198 FLCO=0x03 FID=0x68 SVC=0x40 Encrypted Hytera XPT Private Call 
 DMR PDU Payload [03][68][40][30][24][65][00][03][A2][D5][CE][78]
23:11:59 Sync: +DMR  [slot1]  slot2  | Color Code=10 | CSBK
 Preamble CSBK - Individual Data - Target [10001] - Source [9346]
 DMR PDU Payload [BD][68][80][06][00][27][11][00][24][82][6F][2B]
23:11:59 Sync: +DMR   slot1  [slot2] | Color Code=10 | TLC 
 SLOT 2 TGT=9317 SRC=930 HASH=198 FLCO=0x03 FID=0x68 SVC=0x40 Encrypted Hytera XPT Private Call 
 DMR PDU Payload [03][68][40][00][24][65][00][03][A2][4D][0B][FF]
23:11:59 Sync: +DMR  [slot1]  slot2  | Color Code=10 | CSBK
 Preamble CSBK - Individual Data - Target [10001] - Source [9346]
 DMR PDU Payload [BD][68][80][05][00][27][11][00][24][82][B7][A9]
 SLCO Hytera XPT - Free RPT 3 - PRI RPT 0 - PRI HASH: 00
 SLCO Completed Block [86][83][00][0D][D0]
23:11:59 Sync: +DMR   slot1  [slot2] | Color Code=10 | TLC 
 SLOT 2 TGT=9317 SRC=930 HASH=198 FLCO=0x03 FID=0x68 SVC=0x40 Encrypted Hytera XPT Private Call

 

[thewraith2008]

I think the first site in adjacent list CSBKO:11 (0xB) is not the current site (bummer).
The indicted free repeater # for site does not match what the current repeater site is.

csbko: 11 (XPT_Sys_Sites) fid: 104 (Hytera - 104) - [SN:2] Adjacent> Site:2-1 Adjacent> Site:3-1
csbko: 10 (XPT_CH_Status) fid: 104 (Hytera - 104) - Free_repeater:4 - R1:1-PRV:#215 R2:1-PRV:#117 R3:1-PRV:#187 R3:2-PRV:#198

Using IQ file: "SDRSharp_20181105_172709Z_467931250Hz_IQ.wav"

When selecting a different site, I can see the site indicate repeater 4 as free repeater.

csbko: 11 (XPT_Sys_Sites) fid: 104 (Hytera - 104) - [SN:2] Adjacent> Site:1-4 Adjacent> Site:3-1

There also could be a possibility that when the sequence number is used for CSBKO:11 (0xB) that it may indicate an "Announcement_type" like a broadcast (BCAST) PDU CSBKO:40 (0x28) where the contents can be different things.
The above file uses SN:2 but the "1R-DSDPlus-Raw-Input_2023-02-23@XPT Calixte.wav" file uses SN:0 and SN:1.

NOTE: SN = Sequence number (normally LB, PF bits)

 

[lwvmobile]

There also could be a possibility that when the sequence number is used for CSBKO:11 (0xB) that it may indicate an "Announcement_type" like a broadcast (BCAST) PDU CSBKO:40 (0x28) where the contents can be different things.

Yeah, that's kind of what I was thinking, assuming there isn't any other sort of flag in there to tell the difference. Makes you wonder why, when a CSBKO has 6 bits to work with, why they try to cram it all into 2 opcodes out of a possibility of 64 (minus their own T3 offerings). Better yet, if its appended data somehow, I always wondered why they (or Cap+) didn't use the MBC Header and Blocks instead.

 

[thewraith2008]

I think using MBC increases the delay to talk plus using VLC adds to that delay.
I guess not sending LCN and TX/RX frequencies and using a custom channel plan makes life a little harder. (for us)

The only thing I can see changing with CSBKO:11 (0xB) when using the "1R-DSDPlus-Raw-Input_2023-02-23@XPT Calixte.wav" file:

• When it's SN:0 and the free repeater changes, it sees the 4th byte change (0x02 to 0x01)
• 0x0820202010102810 - Current Free Repeater: 1
• 0x0820201010102810 - Current Free Repeater: 2

This byte change (0x02 to 0x01) is opposite to what I was expecting where it may have matched the repeater number.

 

[lwvmobile]

I know its been a quick minute since we talked about XPT, it took me a day or two to remember half of the stuff again since the last time. I've been whittling away at it again, for better or worse, and got a few new small samples with some interesting properties. These samples have no voice on them, but show some interesting values for Free Repeater channel values and channel status, particularly st calixte. I'm getting a lot of Free Repeater Channel 15/0xF and NULL values on all LSN channel activites.

10:45:26 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT CSBK 0x0B - SN: 0
XPT Adj Site(s): Site:1 Free:15; Site:4 Free:15; Site:2 Free:15; Site:5 Free:15;
DMR PDU Payload [0B][68][0C][F0][24][F0][14][F0][2C][F0][DC][44]
10:45:26 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK
Hytera XPT CSBK 0x0B - SN: 1
XPT Adj Site(s): Site:10 Free:15;
DMR PDU Payload [4B][68][54][F0][00][00][00][00][00][00][E9][8F]
 SLCO Hytera XPT - Free LCN 15 - PRI LCN 0 - PRI HASH: 00
 SLCO Completed Block [86][8F][00][03][00]
 10:45:26 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT CSBK 0x0B - SN: 1
 XPT Adj Site(s): Site:10 Free:15;
 DMR PDU Payload [4B][68][54][F0][00][00][00][00][00][00][E9][8F]
Hytera XPT Site Status - Free LCN: 15 SN: 0
 LSN 01: ST-3 Null LSN 02: ST-3 Null LSN 03: ST-3 Null
 LSN 04: ST-3 Null LSN 05: ST-3 Null LSN 06: ST-3 Null  <--all NULL with the 15/F value on Free Repeater as well
 DMR PDU Payload [0A][68][FF][FF][00][00][00][00][00][00][2E][7F]

My current guess is that means the entire system is offline or in some sort of maintenance mode? I also combed through some of the white papers/manuals posted in the other thread and found a mention of data channels starting at an index+15, so was wondering if that somehow played into the free repeater channel value being 15, or a status value other than 0 or 3.




Anyways, here are some small samples I collected this morning exhibiting the behavior I mentioned.

Upload files for free - 20230410_new_xpt_samples.zip - ufile.io

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

ufile.io

 

[thewraith2008]

I was thinking the Free repeater = 15 could indicate usage as a site with only one repeater (and does not need to use the free repeater value) or just a conventional repeater.

In a multi-site configuration with a few of these 15's, each of these sites could be used as a channel that is a open repeater to any TG (or TGs are not used) rather than tying TG's to each home repeater.

 

[lwvmobile]

Same system that was showing all 15 yesterday seems to be back to its usual state. Only Site 10 is showing 15 now, the others sites seem to have seemingly 'normal' free repeater channel values again, and the site status isn't completely NULL now like yesterday.

10:22:29 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT CSBK 0x0B - SN: 1
 XPT Adj Site(s): Site:10 Free:15;
 DMR PDU Payload [4B][68][54][F0][00][00][00][00][00][00][E9][8F]
10:22:29 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK
 Hytera XPT Site Status - Free LCN: 1 SN: 0
 LSN 01: ST-0 Idle LSN 02: ST-0 Idle LSN 03: ST-0 Idle
 LSN 04: ST-0 Idle LSN 05: ST-3 Null LSN 06: ST-3 Null
 DMR PDU Payload [0A][68][10][0F][00][00][00][00][00][00][A8][1C]
 SLCO Hytera XPT - Free LCN 1 - PRI LCN 0 - PRI HASH: 00
 SLCO Completed Block [86][81][00][07][30]
10:22:29 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Site Status - Free LCN: 1 SN: 0
 LSN 01: ST-0 Idle LSN 02: ST-0 Idle LSN 03: ST-0 Idle
 LSN 04: ST-0 Idle LSN 05: ST-3 Null LSN 06: ST-3 Null
 DMR PDU Payload [0A][68][10][0F][00][00][00][00][00][00][A8][1C]
10:22:29 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK
 Hytera XPT CSBK 0x0B - SN: 0
 XPT Adj Site(s): Site:1 Free:2; Site:4 Free:2; Site:2 Free:2; Site:5 Free:1;
 DMR PDU Payload [0B][68][08][20][20][20][10][20][28][10][3D][8B]

Also, had nary a lick of voice activity yesterday on one of the other hytera systems, now is voice traffic on and off this morning swapping between both repeaters available. Good news is, I think I'm actually trunking that system correctly now.

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.

10:31:53 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC 
 SLOT 1 FLCO=0x09 FID=0x68 TGT=54 SRC=12001 Hytera XPT Group Call Alert
  HSK=0; Handshake - Ordinary; Call on LCN 1; Free LCN 2; 
 DMR PDU Payload [49][68][10][20][00][36][00][2E][E1][A7][6A][94]
 SLCO Hytera XPT - Free LCN 2 - PRI LCN 0 - PRI HASH: 00
 SLCO Completed Block [86][82][00][08][A0]
10:31:53 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT CSBK 0x0B - SN: 0
 XPT Adj Site(s): 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]
10:31:53 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC 
 SLOT 1 FLCO=0x09 FID=0x68 TGT=54 SRC=12001 Hytera XPT Group Call Alert
  HSK=0; Handshake - Ordinary; Call on LCN 1; Free LCN 2; 
 DMR PDU Payload [49][68][10][20][00][36][00][2E][E1][A7][6A][94]
10:31:53 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Site Status - Free LCN: 2 SN: 0
 LSN 01: ST-3 054  LSN 02: ST-0 Idle LSN 03: ST-0 Idle
 LSN 04: ST-0 Idle 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]

Ignore the handshake stuff (bits 28-32), not entirely convinced that is applicable here, only ever seen 0 value there (aside from possibly a few erroneous decodes). Its in the patent, but I still haven'tt seen the patent opcode, so either its an earlier revision that got sent up, or its intentionally erroneous just to patent some elements without giving away the secret sauce recipe.

 

[lwvmobile]

Another thing I'd like to bring up, examining the Hytera systems in Quebec more, we had discussed that the first site in the 'adjacent site' CSBK was the current site, but I don't think this is accurate. Having sampled from and observed multiple related (or seemingly related) XPT sites in the area, the first listed site is always site 1. I believe this CSBK carries information only regarding adjacent sites, and not its own site.

On the earlier example of 'Site A', we have sites listed as Site:1 Free:2; Site:4 Free:2; Site:2 Free:2; Site:5 Free:1; and Site:10 Free:15;
Note the missing number in the sequence for Site 3.

10:22:29 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK
 Hytera XPT CSBK 0x0B - SN: 0
 XPT Adj Site(s): Site:1 Free:2; Site:4 Free:2; Site:2 Free:2; Site:5 Free:1;
 DMR PDU Payload [0B][68][08][20][20][20][10][20][28][10][3D][8B]

10:22:29 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT CSBK 0x0B - SN: 1
 XPT Adj Site(s): Site:10 Free:15;
 DMR PDU Payload [4B][68][54][F0][00][00][00][00][00][00][E9][8F]

Here, we have another site in the system that has sites listed as Site:1 Free:2; Site:3 Free:1; Site:4 Free:2; Site:5 Free:1;
Note the missing number in the sequence is for Site 2. There is no SN: 1 or SN: 2.

10:31:53 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT CSBK 0x0B - SN: 0
 XPT Adj Site(s): 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]

 

[thewraith2008]

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

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?

I need to get more time to look into this more but since I don't have an active XPT near me, it's not high on the list of things to do of late.