Understanding Capacity Plus trunking, some more

[lwvmobile]

It almost appears to contradict itself in places about some items. (i.e DATA)

Thank you, I'm not the only one.

By contrast, if you ever read the TIA manuals on P25 trunking TSBKs or VPDUs, it is almost redundant to a fault, telling you how to read each element of a PDU, for every PDU in that manual. No page flipping needed. They even tell you how to read other Manufacturer's PDUs (0x90 and 0xA4).

 

[thewraith2008]

I've not spent any time on P25 as it's all encrypted around here and more than enough work is already going on in that area.
If I need to look at it, I can just fire up DSD+ for the task.

Poor ole DMR seems to be getting left behind.

 

[Forts]

@Forts Okay, so, going over a few of your samples, its definitely raised some questions from me now that I can observe some behavior that I haven't seen in any other Cap+ system yet. How many channels does your Cap+ system have, and is it configured only for private calls, or do both private and group calls occur on it?

Sorry for the slow reply to this, was a busy weekend.

Our system is relatively small (3 frequencies) and is, for whatever reason, supported by a handful of conventional DMR channels. There are no private calls in use on the system. I take care of the radios for my particular department so I just programmed two of them up to be private call capable for testing purposes.

For those wondering about samples, the original ones posted here were... well, crap. Looks like I was still too close to the dongle while tx'ing and things were getting overloaded. There was another sample made and circulated offline that seemed to be much better quality. I can repost here if requested (or make more samples as needed).

 

[thewraith2008]

I can repost here if requested (or make more samples as needed).

Speaking for myself, I would certainly appreciate if you repost the better sample please.

 

[Forts]

Sure thing, here you go...

priv_call.wav (7.23MB) - SendSpace.com

 

[thewraith2008]

Great stuff.
While the other samples helped a lot, having a sample where the private call is the only thing occurring is ideal.

This last month in this thread has me help iron out my CAP+ implementation (and understanding) and is working a treat.
Thanks to all that have helped out.

 

[lwvmobile]

On a similar note, just thought I'd ask, but does Hytera XPT work the same way (or similar) to Capacity Plus? The little bit of information I've been able to scrap together in the past seems to suggest as much, but maybe I was mistaken. Also, does anybody happen to have a sample wav file of an XPT system? The best I have is a random Hytera wav file that DSD+ suggests has 'XPT comm end' on it, but looks just like normal TLC to me, just with a Hytera MFID on it.

10:29:03 Sync: +DMR  [slot1]  slot2  | Color Code=06 | TLC
SLOT 1 TGT=51937 SRC=5422198 FLCO=0x00 FID=0x68 SVC=0x40 Group Encrypted Call
DMR PDU Payload [00][68][40][00][CA][E1][52][BC][76][FC][48][71]

+DMR           slot1         BS DATA       DCC=6  TLC XPT CommEnd Tgt=51937 Src=48246

The abbreviated SRC could indicate it would work in a similar manner to Cap+, but also could be erroneous, or similar.

All the SLC have CRC errors as well, I may dig into that and see if there is anything of merit. Could just be a bad sample Hytera samples I have to work with.

Edit: I also should note, the sample that the above info was pulled from has zero CSBK or MBC blocks, just idle, or call information.

 

[mrscanner2008]

On a similar note, just thought I'd ask, but does Hytera XPT work the same way (or similar) to Capacity Plus? The little bit of information I've been able to scrap together in the past seems to suggest as much, but maybe I was mistaken. Also, does anybody happen to have a sample wav file of an XPT system? The best I have is a random Hytera wav file that DSD+ suggests has 'XPT comm end' on it, but looks just like normal TLC to me, just with a Hytera MFID on it.

10:29:03 Sync: +DMR  [slot1]  slot2  | Color Code=06 | TLC
SLOT 1 TGT=51937 SRC=5422198 FLCO=0x00 FID=0x68 SVC=0x40 Group Encrypted Call
DMR PDU Payload [00][68][40][00][CA][E1][52][BC][76][FC][48][71]

+DMR           slot1         BS DATA       DCC=6  TLC XPT CommEnd Tgt=51937 Src=48246

The abbreviated SRC could indicate it would work in a similar manner to Cap+, but also could be erroneous, or similar.

All the SLC have CRC errors as well, I may dig into that and see if there is anything of merit. Could just be a bad sample Hytera samples I have to work with.

Edit: I also should note, the sample that the above info was pulled from has zero CSBK or MBC blocks, just idle, or call information.

I have XPT audio sample, I will post here tomorow.

 

[thewraith2008]

I often thought the same.
The one XPT system I've seen appears to have two repeaters but it contains such little activity that it's not really helpful to determine much from it.
Both repeaters are in beacon mode, one outputs CSBKO:10/11 and the other only sees CSBKO:10 when idle.

Calls start with FLCO:9 FID:104 as a grant strangely in the TermLC.
Seems to use the normal call maintenance PDUs FLCO:0/3 (as FID:104).

Some documentation I've seen makes reference to master/home repeater and free repeater.

Here are my assumptions:
The free repeater seems to be akin to the CAP+ rest channel. (sort of).
MSs (or a TGs) are assigned a home repeater so many TGs could be spread across the repeaters that make up the system.
If the home repeater (of the TG) is idle, when a TG starts a call, it will be on one of the home repeaters slots.
If all slots are busy on the home repeater (of the TG), then call will be setup on one of the 'free repeaters' (see below)
I think when home repeater is busy, all TGs not in call move to free repeater then will move back when it frees up again.
I don't think there are announcements of other calls on the repeater network.

I don't think repeaters broadcast their repeater ID. (in CSBKO:10/11) as the two repeaters I've seen, see the same PDU contents.
Not sure if a free repeater ID is broadcast or a list of free repeaters (as idle/active flags(x8)) are broadcast. (in CSBKO:10/11)
Flags would make sense and explain usage of 0xFF seen in CSBKO:11. (1=idle, 0=busy)

When there is a call, nothing seems to change in the CSBKO:10 PDU.
For me, this is always 0xFFFF000000000000 (these are bytes after FID and excluding CRC)
Maybe for the free repeater flags to show busy (when = 0), both slots of the repeater need to be busy.

Having a few samples of a XPT system with some activity might shed some light on it's operation.

 

[thewraith2008]

All the SLC have CRC errors as well, I may dig into that and see if there is anything of merit. Could just be a bad sample Hytera samples I have to work with.

Denny (of SDRTrunk) had a mention of this sometime ago and it was suggested that it was part of Hytera secret squirrel full encryption.
I never saw any follow up to his findings.

 

[racingfan360]

Here are my assumptions:
The free repeater seems to be akin to the CAP+ rest channel. (sort of).
MSs (or a TGs) are assigned a home repeater so many TGs could be spread across the repeaters that make up the system.
If the home repeater (of the TG) is idle, when a TG starts a call, it will be on one of the home repeaters slots.
If all slots are busy on the home repeater (of the TG), then call will be setup on one of the 'free repeaters' (see below)
I think when home repeater is busy, all TGs not in call move to free repeater then will move back when it frees up again.
I don't think there are announcements of other calls on the repeater network.

@thewraith2008 I've recently had a ton of audio files from a busy XPT network shared with me, I've been trying to figure out the TG mappings to repeaters (the network is for a race track, and gets very busy but for only a few days a year). It had at least 24 Channels (12 Freqs, 2 slots each). From the analysis I can put a tick against all of your above assumptions. In short each TG seemed to have a preffered Home Repeater slot to go to, then - if busy - it would go the same Repeater but a diffrent slot, and occassionally you'd see it pop up on a different Repeater altogether.

I'd be interested in that documentation that 'makes reference to master/home repeater and free repeater' if you could share?

 

[thewraith2008]

Thanks for the reply.

Information was gleaned from Hytera's own documentation and this YT video on XPT trunking.

• XPT Digital Trunking System Technology White Paper
• XPT System Application Notes

Strange you mention use of 24 Channels (12 Freqs, 2 slots each) as the documentation only states:

The number of traffic channel can be extended to 16 (8 x 2 Time Slots).

But I did see some mention of linking them which may account for additional channels but it could be more like TIII sites and neighbors.

Are the recordings only of the conversational audio?
If recordings are IQ or demodulated audio that can be used with a decoder for replay, any chance you could make some of the recordings available to the cause? (publicly or private) This would be much appreciated if you can.

 

[racingfan360]

Thanks for that, let me go back and check the records make sure I have all the facts on numbers of channels and slots.

The recordings are unfortunately only DSD+ output wav files or TRX audio files, no Raw recordings or IQ files. I might have some older dsd+ logs if that helps? files

 

[racingfan360]

One really odd feature of this system is how a Whistler TRX1 logs the TG's on this XPT network....

It looks like it decodes TG=1 as either TG1, TG1048577, TG2097153, TG3145729, TG4194306, or TG524881 (ie increments of +1048576 each time, and consistently across all TGs....ie TG2 will also show as TG1048578, TG2097154 etc).

DSD+ gets the XPT TG decode right each time. I assume the Whistler simply doesn't handle the XPT network decoding right each time.

 

[thewraith2008]

Yes those TGs are out of the ranges stated.

Radio ID range from 1 to 65535, group ID from 1 to 249, emergency group ID from
250-254, and all call ID is 255.

 

[thewraith2008]

With my custom DSD, it handles call setups and TG/RIDs OK but only when on the repeater its tuned too.
Moving to other repeater is not handled since I don't know how it works yet. DSD+ is the same I guess.

 

[racingfan360]

Ok so my info from earlier was erroneous, my apols. The system has 12 channels (6 freqs, 2 slots each) not 12 freqs. 10 channels operating as an XPT trunk and 2 as a conventional DMR repeater. Some users can move between the XPT and the Conventional DMR system.

DSD+ will decode the TG and RIDs ok, but can't follow the calls on an XPT trunk AFAIK. The TRX doesnt trunk either (obviously) and often reports erroneous TG's on the XPT - always out by a factor of 1,048,576 (or 100000000000000000000 in binary).

For beacons DSD+ reports:
2022.05.14 4:52:54 +DMR slot2 BS DATA DCC=11 CSBK ERR4 [LB=0 CSBKO=11 (?) FID=68 v16=0CF0 id1=0 id2=0]
2022.05.14 4:52:54 0B 68 0CF0 000000 000000
2022.05.14 4:52:54 000010110110100000001100111100000000000000000000000000000000000000000000000000000100111000101011

Not seen any CSBKO=10 data.

 

[lwvmobile]

Denny (of SDRTrunk) had a mention of this sometime ago and it was suggested that it was part of Hytera secret squirrel full encryption.

The more I go down this rabbit hole, along with a few of the Hytera samples I do have, I really begin to understand the frustration and reason why other projects don't code for Hytera or XPT. In addition to the SLC errors, I also often get bad TACT info out of some Hytera signals, especially during calls. I've often wondered if they have tons of Reverse Channel stuff going on, but unless I've coded it incorrectly, I've never seen the RC sync, and with bad tact and bad embs, I have no idea if the power indicator bit is on. Also, could just be that all the Hytera samples I have are just bad quality, weak signal, or noisy or something. Here is a link to three of them, two with enc voice, and one with OTA encyryption (you'll know it when you seen the link control) Oddly enough, the Hytera OTA encyrpt sample is the one that usually has good SLC CRC.

OTA Encyrpt:

02:16:16 Sync: +DMR   slot1  [slot2] | Color Code=07 | DATA
 Slot 2 Data Header - GROUP - Short Data: Defined - Response Requested - Source: 10276218 Target: 2886713
  SD:D [DD_HEAD] - SAP 04 [IP Based] - BLOCKS 02 - DD 18 - PADb 187 - FMT 18 [UTF-32LE] - Confirmed Data (FEC OK) (CRC ERR)
 DMR PDU Payload [CD][42][2C][0C][39][9C][CD][7A][62][BB][97][57]
02:16:16 Sync: +DMR  [slot1]  slot2  | Color Code=07 | IDLE
02:16:16 Sync: +DMR   slot1  [slot2] | Color Code=07 | DATA
 Slot 2 Data Header - GROUP - Unified Data Transport (UDT) - Response Requested - Source: 3271364 Target: 10915803
  SAP 0E [Reserved] - FMT 10 [Mixed UTF] - PDn 12 - SF 1 - PF 0 OP 30 (FEC OK) (CRC ERR)
 DMR PDU Payload [E0][EA][A6][8F][DB][31][EA][C4][61][B0][F1][63]
02:16:16 Sync: +DMR  [slot1]  slot2  | Color Code=07 | IDLE
 SLCO Activity Update TS1: 0 Hash: 00 TS2: A Hash: D7
 SLCO Completed Block [10][A0][0D][7B][A0]
02:16:16 Sync: +DMR   slot1  [slot2] | Color Code=07 | R12C  (FEC OK) (CRC ERR)
 DMR PDU Payload [46][47][B8][5A][45][5D][47][3C][B5][4C]
02:16:16 Sync: +DMR  [slot1]  slot2  | Color Code=07 | IDLE
02:16:16 Sync: +DMR   slot1  [slot2] | Color Code=07 | R12C
 Slot 2 - Multi Block PDU Message CRC32 ERR 652282BA - B046C34F
 Slot 2 - Multi Block PDU Message
  [46][47][B8][5A][45][5D][47][3C][B5][4C][3B][DE]
  [69][54][47][38][65][22][82][BA] CRC - EXT 652282BA CMP B046C34F
 Short Data: ASCII
FG ZE]G< L; iTG8e"    (FEC OK) (CRC ERR)
 DMR PDU Payload [3B][DE][69][54][47][38][65][22][82][BA]

02:16:18 Sync: +DMR  [slot1]  slot2  | Color Code=07 | VLC 
 SLOT 1 Protected LC  FLCO=0x28 FID=0xD3
 DMR PDU Payload [E8][D3][37][D5][82][76][C4][B7][52][FA][1D][98]

02:16:18 Sync: +DMR  [SLOT1]  slot2  | Color Code=07 | VC6
 SLOT 1 FLCO FEC ERR  (FEC ERR) (CRC ERR)
 DMR PDU Payload [80][90][12][02][A7][E9][FA][7C][52]
  SB: 00100000000 - 100 (FEC ERR) 7

02:19:48 Sync: +DMR  [slot1]  slot2  | Color Code=07 | TLC 
 SLOT 1 Protected LC  FLCO=0x12 FID=0x23
 DMR PDU Payload [D2][23][9E][43][B6][ED][A3][72][B8][E8][4D][F6]
 
 SLCO Activity Update TS1: 8 Hash: 07 TS2: 0 Hash: 00
 SLCO Completed Block [18][00][70][07][60]

Upload files for free - Hytera Junk.zip - ufile.io

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

ufile.io

So, anybody ever get any XPT samples before I get too discouraged to look at any of them

 

[thewraith2008]

It could be if the samples where IF IQ data rather than demodulated audio, it may yield better decodes.
If the original signal was a bit off frequency then the demodulate audio will not be 100%. The damage is done but if the samples where IF IQ samples, it would allow a little bit of fine tuning if it is off frequency.

Downloading now to have a look at what your seeing.

 

[thewraith2008]

I see what you mean about the playback.
The 'Hytera-OTA-Encryption.wav' file plays back a lot better for me. All looks OK with the following exception:

• Voice Header LC, EMB and TermLC PDUs CRCs are bad.

Should be noted that the 'HYT Enc Voice.wav' and 'Hytera Enc Voice 2.wav' files are the same file (same HASH)
This file (audio) looks to have a bad DC offset.