Understanding Capacity Plus trunking, some more

[thewraith2008]

Looking at 'HYT Enc Voice.wav' some more, it looks more like Hytera TIII payload channel than XPT.

• SLCO:0/1 are been used which seems to be showing the right activity for the both slots

I can get decodes on the call maintenance PDUs (FLCO:0 FID:104).
Problem is, they are decoding with the XPT code on the account of the FID:104 where the Hytera TIII is normally FID:8 (from memory) .

I think most of the issues here are possibly due to a bad recording.

 

[lwvmobile]

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.

I was getting bad CSBK and data headers on that as well. As well as random lc opcodes and fid values, and bad emb.

Should be noted that the 'HYT Enc Voice.wav' and 'Hytera Enc Voice 2.wav' files are the same file (same HASH)

Oops. They originally had two different names in my folder, didn't even realize they were the same file.

Looking at 'HYT Enc Voice.wav' some more, it looks more like Hytera TIII payload channel than XPT.

Yeah, I just figured that was a Tier II Hytera Repeater, I just had to playback a known Hytera TIII trunking sample I have, didn't even realize its payload channels doesn't carry the P_SYS_Parms SLC that other TIII systems have, it just has the activity update hashes on it. Seems like every tune on that sample was late tuning, so couldn't catch a single VLC to check to see which fid it used in setup. I'd upload it, but its about 500 MB.

I didn't make any of those samples, its just what people have sent me to work with. I figured they were pretty bad shape mostly, but you can still get some good decodes and things out of them as well. Does make it more difficult to know what is supposed to be, and what is just bad sometimes.

 

[lwvmobile]

Back on the subject of Capacity Plus for a moment, something I found in the file named 'Cap+ RAS.wav" that was submitted here, I have found another CSBK on it that seems to come in every 4th or 5th beacon at the end after the channel status update. DSD+ FL identifies it as 59? but then seemingly decodes it as LCP IRB, no idea what that means, but it spits out a neighbor list.

+DMR                slot2    BS DATA       DCC=1  CSBK [LB=1 CSBKO=59 (?) FID=10 v16=E40D id1=4334130 id2=5333248]
3B 10 E40D 422232 516100
101110110001000011100100000011010100001000100010001100100101000101100001000000000001001111010010
Cap+ Site=1 RestCh=4
+DMR           slot1         BS DATA       DCC=1  CSBK LCP IRB  Sync; Site=1 RestCh=4  Neighbors = 4 2 3 5 6
Sync: no sync

My own dump of the CSBK shows it has this layout, and I coded it with the assumptions that the 4 MSB in each octet is the neighbor, and the 4 LSB in each octet is the current rest channel for that site (just an assumption). It also seems to have the same earlier octets and bit set up for the FL, TS the CSBK is active in, and the current rest channel. This occurs at the very start of the wav file, about 12-13 seconds into it, and repeats often when in beacon mode. There also appears to be an octet 0x0D in there, which may be some sort of flag.

05:32:58 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK
 Capacity Plus Channel Status - FL: 3 TS: 0 RS: 0 - Rest Channel 4 - Single Block
  Ch1: Idle Ch2: Idle Ch3: Idle Ch4: Rest
  Ch5: Idle Ch6: Idle Ch7: Idle Ch8: Idle
 DMR PDU Payload [BE][10][C4][00][00][00][00][00][00][00][7D][C3]
05:32:58 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Capacity Plus Neighbor List S[4]-R[2] S[2]-R[2] S[3]-R[2] S[5]-R[1] S[6]-R[1]
 DMR PDU Payload [BB][10][E4][0D][42][22][32][51][61][00][13][D2]
 SLCO Capacity Plus Site: 1 - Rest Channel 4 - RS: 00
 SLCO Completed Block [F1][00][40][81][C0]
05:32:59 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK
 Capacity Plus Neighbor List S[4]-R[2] S[2]-R[2] S[3]-R[2] S[5]-R[1] S[6]-R[1]
 DMR PDU Payload [BB][10][C4][0D][42][22][32][51][61][00][68][BA]

 

[thewraith2008]

Not sure what "LCP IRB" is but yes, CSBKO:59 is used for a linked CAP+ and shows the neighbor sites and rest channel for those sites.

There also appears to be an octet 0x0D in there, which may be some sort of flag.

The last 3 bits (101=5) indicate number of neighbor site/rest in PDU

 

[mrscanner2008]

XPT audio samples : Site 1 and 2 have the same conversations. Unfortunately not a lot of conversations.
I continue to monitor the site to have better audio samples.
XPT samples edite URL

 

[Forts]

If your Hytera recording has OTA Encrypt enabled then I don't think you would see much at all. There is a system semi-local to me using it and it hides pretty much everything. Other than seeing activity on the spectrum display, nothing shows in DSD etc.

From Hytera CPS help...

Over the Air Encrypt
This parameter allows you to set whether to enable the Over the Air Encrypt feature. With this feature enabled, the voice, data and signaling transmitted by the radio or repeater over the air interface are encrypted by using the key or encryption algorithm. The repeater can forward and the receiving radio can decrypt the voice, data and signaling only when the key value is correct. This prevents the unauthorized radio from occupying channel resources and interrupting communication.

At present, only signaling can be encrypted and decrypted.

 

[R0am3r]

XPT audio samples : Site 1 and 2 have the same conversations. Unfortunately not a lot of conversations.
I continue to monitor the site to have better audio samples.
xpt samples

"File is not publicly available." Were the samples supposed to be public?

How did you generate the audio samples? Is this something you generated from DSDPlus FL?

 

[mrscanner2008]

"File is not publicly available." Were the samples supposed to be public?

How did you generate the audio samples? Is this something you generated from DSDPlus FL?

I edited the links should work now. Audio generated with DSDPLUS FL Raw.

 

[lwvmobile]

XPT audio samples : Site 1 and 2 have the same conversations. Unfortunately not a lot of conversations.

Thanks for the samples, maybe I'll finish downloading them by the end of the day



BTW, LetsUpload is SLOOOOOOOOOOW lol.

If your Hytera recording has OTA Encrypt enabled then I don't think you would see much at all. There is a system semi-local to me using it and it hides pretty much everything. Other than seeing activity on the spectrum display, nothing shows in DSD etc.

You'd be surprised, they don't, or can't, on that sample anyways, scramble the sync patterns (that I'm aware of) nor the actual burst type (voice, link control, etc) just the actual data they contain. The Link Control is all scrambled, but consistently scrambled the same way (probably simple XOR or LFSR), and Data and CSBK also appears to be enc/protected and decode as nonsensical values. Shockingly, though, either through flaw, or oversight, or sheer stupidity, they give away their own voice privacy key value in the clear in the data blocks. Its the only sample I've ever seen do that (though I've seen others mention the same phenomena in older posts)

 

[lwvmobile]

Calls start with FLCO:9 FID:104 as a grant strangely in the TermLC.

I wouldn't have believed it unless I just saw the same thing. I would have assumed it was just a prior call with a long winded TLC, or that the sample cut in at the end of a call or something. I've noticed that sometimes the reserved bit on link control is set to 1 during these XPT call set ups and maintenance.

17:06:10 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Channel Status:
Ch1: Idle Ch2: Idle Ch3: Idle Ch4: Idle Ch5: OFF  Ch6: OFF  Ch7: OFF  Ch8: OFF
 DMR PDU Payload [0A][68][20][0F][00][00][00][00][00][00][EE][C0]
PRECALL FLC 9 Reserved Bit enabled -- svc bits? may not apply?
17:06:10 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC
 SLOT 1 TGT=54 SRC=12006 FLCO=0x09 FID=0x68 SVC=0x17 RS=1 Group Call
 DMR PDU Payload [49][68][17][20][00][36][00][2E][E6][E9][18][CB]
 SLCO Hytera XPT
 SLCO Completed Block [86][82][00][08][A0]
17:06:10 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 DMR PDU Payload [0B][68][10][20][18][10][20][10][28][20][EF][DA]
17:06:10 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC
 SLOT 1 TGT=54 SRC=12006 FLCO=0x09 FID=0x68 SVC=0x17 RS=1 Group Call
 DMR PDU Payload [49][68][17][20][00][36][00][2E][E6][E9][18][CB]
17:06:10 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Channel Status:
Ch1:  054 Ch2: Idle Ch3: Idle Ch4: Idle Ch5: OFF  Ch6: OFF  Ch7: OFF  Ch8: OFF
 DMR PDU Payload [0A][68][2C][0F][36][00][00][00][00][00][5D][1A]
17:06:10 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC
 SLOT 1 TGT=54 SRC=12006 FLCO=0x09 FID=0x68 SVC=0x17 RS=1 Group Call
17:06:10 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Channel Status:
Ch1:  054 Ch2: Idle Ch3: Idle Ch4: Idle Ch5: OFF  Ch6: OFF  Ch7: OFF  Ch8: OFF
 DMR PDU Payload [0A][68][2C][0F][36][00][00][00][00][00][5D][1A]
 ...
START OF CALL - FLC 0 reserved bit set to 0
17:06:10 Sync: +DMR  [slot1]  slot2  | Color Code=01 | VLC
 SLOT 1 TGT=54 SRC=12006 FLCO=0x00 FID=0x68 SVC=0x00 RS=0 Group Call
...
EMB LC 0x13 - Unknown Values - RS bit set to 0 (often lots of CRC err or FEC err)
17:13:17 Sync: +DMR  [SLOT1]  slot2  | Color Code=01 | VC6 
 SLOT 1 Hytera XPT FLCO=0x13 FID=0x68 RS=0 
 DMR PDU Payload [13][68][20][10][21][18][20][12][28]

(also has embedded aliases in EMB)
...
END OF CALL FLC 0 - reserved bit set to 0
17:13:19 Sync: +DMR  [slot1]  slot2  | Color Code=01 | TLC
 SLOT 1 TGT=54 SRC=12006 FLCO=0x00 FID=0x68 SVC=0x00 RS=0 Group Call
 DMR PDU Payload [00][68][00][20][00][36][00][2E][E6][20][AF][F9]

Still trying to wrap my head around all of this, probably will take a while.

 

[thewraith2008]

The reserved bit[4] seem to work as a g_i element as FLCO:9 is a general grant used for both group and private calls.
In the call maintenance PDUs, only FLCO:0 is used (for both group/private) rather than FLCO:0 for group and FLCO:3 for private like normal.

Edit: For context, this is for the XPT system.

May need to split this thread into and XPT only thread.
How would one go about this? Create new thread and get mods to move posts or can they do the lot?

 

[lwvmobile]

How would one go about this? Create new thread and get mods to move posts or can they do the lot?

Maybe if you ask nicely and take her out to dinner first.

So, if XPT TGs are only 8-bit values, was there a consensus as to what the 16 bits before it do?
For that matter, are ALL Hytera TG values (on FID 0x68) only ever 8 bit?

 

[thewraith2008]

Because the PDUs handles both group and private, the TG/TGT and SRC address allocations are always 16 bit for XPT (like it is for CAP+).
The preceding 8 bits are the un-used 8 bits of the otherwise normal 24 bit address field.
In XPT: (I think)

• The first 8 bits (before the TG/TGT address) are used (only the first 4 bits - Free repeater ID?)
• The second 8 bits (before the SRC address) are un-used

 

[thewraith2008]

Problem I see with some of the fields in XPT SLCO/FLCO, are the fields that may indicate 'Free repeater' or 'Repeater ID' never seem to change during a call or even when both slots are active.

Way I understand it is, if both slots are active, there should be some indication of a new 'free repeater' been broadcast.

 

[lwvmobile]

Here is what Denny seems to think the bits of CSBK 10 are (best I can tell this is for 10)

{
    private static final int[] SEQUENCE_NUMBER = new int[]{0, 1};
    private static final int[] FREE_REPEATER = new int[]{16, 17, 18, 19};
    private static final int[] REPEATER_A_STATE = new int[]{20, 21, 22, 23};
    private static final int[] REPEATER_B_STATE = new int[]{24, 25, 26, 27};
    private static final int[] REPEATER_C_STATE = new int[]{28, 29, 30, 31};
    private static final int[] REPEATER_A_TS0_ADDRESS = new int[]{32, 33, 34, 35, 36, 37, 38, 39};
    private static final int[] REPEATER_A_TS1_ADDRESS = new int[]{40, 41, 42, 43, 44, 45, 46, 47};
    private static final int[] REPEATER_B_TS0_ADDRESS = new int[]{48, 49, 50, 51, 52, 53, 54, 55};
    private static final int[] REPEATER_B_TS1_ADDRESS = new int[]{56, 57, 58, 59, 60, 61, 62, 63};
    private static final int[] REPEATER_C_TS0_ADDRESS = new int[]{64, 65, 66, 67, 68, 69, 70, 71};
    private static final int[] REPEATER_C_TS1_ADDRESS = new int[]{72, 73, 74, 75, 76, 77, 78, 79};

sdrtrunk/HyteraXPTSiteState.java at 75ef3217ac12d380d3622bf1b9fcf2c1d627ebea · DSheirer/sdrtrunk

A cross-platform java application for decoding, monitoring, recording and streaming trunked mobile and related radio protocols using Software Defined Radios (SDR). Website: - sdrtrunk/HyteraXPTSit...

github.com

 

[thewraith2008]

He states:

Note: I've only seen this documented in the patent and haven't yet seen it in the wild.

If it where like that, then multi-block PDU would be expected to describe when more than three repeaters used.
The "SEQUENCE_NUMBER" would probably work like LSCC/FL fields, but it does show they are in place of the LB/PF fields.
Since XPT is capable of a maximum 8 repeaters, that would be 3 blocks required when 8 are used? How would it go about private call announcements since only 8 bits are allocated for TG/MS address in what he describes.

I think if you could record all the repeaters at same time during high activity, it might show a better picture than just observing one repeater.

@mrscanner2008
Thanks again for the samples (still D/Ling them)
Do you know how many repeaters are used in that site for XPT?

 

[lwvmobile]

Thanks again for the samples (still D/Ling them)

It only took me about 2 and a half hours. Well, more like about an hour altogether to download those at a blistering 45 kb/s or something.

he "SEQUENCE_NUMBER" would probably work like LSCC/FL fields, but it does show they are in place of the LB/PF fields.

Yeah, I was wondering about that part, those samples don't seem to indicate either bit as on at any point that I've noticed. I suppose they aren't busy enough for it. If it truly uses that, I'll have to make a quick check/bypass to make an execption to that, since I don't run protected CSBKs to minimize any falsing.

On the site1 wav file and site 2 wav file with the call occurring at the same time, you can see the activity occurring in the CSBK 0x0A (10) at the repeater A TS 0 position on one, and the repeater B TS 0 position on the other.

Site 2 WAV:

06:15:17 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Site Status:
 XPT RPT Free: 2 RPT A: C RPT B: 0 RPT C: F
 Ch1:  054 Ch2: Idle Ch3: Idle Ch4: Idle Ch5: Idle Ch6: Idle
 DMR PDU Payload [0A][68][2C][0F][36][00][00][00][00][00][5D][1A]

Site 1 Wav: (same call)

06:17:01 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Hytera XPT Site Status:
 XPT RPT Free: 2 RPT A: 0 RPT B: C RPT C: F
 Ch1: Idle Ch2: Idle Ch3:  054 Ch4: Idle Ch5: Idle Ch6: Idle
 DMR PDU Payload [0A][68][20][CF][00][00][36][00][00][00][93][A5]

 

[mrscanner2008]

@mrscanner2008
Thanks again for the samples (still D/Ling them)
Do you know how many repeaters are used in that site for XPT?

Next time I will use another faster file repo. the system has 4 sites and only 1 frequency by site.

 

[thewraith2008]

Does look to fit the pattern.
I guess 0 (0000) for site state means both slots available.
F (1111) means either both slots busy or repeater not available (no entries would indicate the latter)
C (1100) means slot0 busy
3 (0011) means slot1 busy

I wonder if the 2 bits have another meaning. (1000, 0100, 0010, 0001 etc...)

On another sample I have, contents of CSBKO:10 does not change regardless of idle, 1 or 2 slots active.
0x0A 68 FF FF 00 00 00 00 00 00
Is that Free repeater: F (15) and 3 repeaters not available?

 

[thewraith2008]

Next time I will use another faster file repo.

I find MEGA pretty good.
If two people have it, you can then just copy stuff over to your account without the need to download straight away.