P25P2 TDMA CC & P25P1 Enhancements

[KF5HKI]

Objectives

• Add support for P25 Phase 2 TDMA control channels.
• Expand P25 Phase 1 and Phase 2 supported messages
• Improve the performance of the P25 Phase2 decoder

Development and Testing Observations

1. Discovered that the L3Harris TDMA control channel is using the 2x reserved bits in the ISCH to identify the configured role (VCH or LCCH) for each timeslot, whereas Motorola traffic channels don't appear to be using this distinction. The existing implementation was coded to an earlier version of the ICD which listed the first 3x bits of the I-ISCH as either reserved or unused (ie future support for 3 or 4 timeslot TDMA) and so it only calculated the coset words for (2^6) 127 values instead of the full (2^9) 512 potential coset words. This caused failed decoding/correction of ISCH values which in-turn caused bad descrambling when two of the VCH timeslots are scrambled and the other two LCCH timeslots are not. I further enhanced the I-ISCH error correction by separating the map of valid coset words for timeslot 1 from those of timeslot 2 so that when it error checks I-ISCH 1, it only uses coset words that would be valid for channel number 0 (ie timeslot 1) and vice-versa for I-ISCH 2. This separation doesn't increase the hamming distance (16) of the (40,9,16) binary code coset words, but it does significantly reduce the alphabet of valid coset words for each channel (96/512 are valid).

2. I discovered that the sync pattern detectors in the super frame fragment detector were using a bit error threshold that was set too high (10/40 bit errors) and that was allowing a 1-2 dibit stream misalignment that would persist across dozens of super frame fragments before finally correcting itself. I tested the hamming distance for the sync pattern when shifted left/right by 1 or 2 dibits and discovered that the sync pattern bit error threshold should be reduced to 7/40 to correctly detect this misalignment and allow the detector to self-correct and only lose 1x super frame fragment.

3. I discovered during testing against the L3Harris TDMA control channel sample (Duke energy south of Dayton, OH) that the DQPSK decoder was sporadically deleting/stuffing one or two dibits within the time period of one super frame fragment (observation 2). I'm experimenting with expanding with the dibit delay buffer by 2x dibits to the left and 2x dibits to the right to enable extracting a super frame fragment from the delay buffer that may be shifted to the left/right by 1 or 2 dibits. This enables partial recovery of a super frame fragment when the decoder stuffs or deletes dibits so that we can shift the fragment extraction by 1 or 2 dibits left/right from the delay buffer. This will then rely on the error detection and correction in each of the timeslots and ISCH fragments to indicate where the stuff/delete happened, versus throwing away the entire fragment. For this sample, this allows us to recover (26/33 = 79%) of the previously discarded super frame fragments. I need to further investigate why the decoder is allowing the dibit stream to slip +/- two dibits within the span on one super frame fragment -- the symbol timing gain may be set too high.

Followup: I also added an option where the stuff/delete happens within the fragment causing a since detect on sync1 but misaligned for sync2. In this case it creates a split fragment where the first half of the fragment uses bits up through the beginning of the second sync pattern and the second half uses everything from the second sync to the end of the fragment. This causes a corrupt timeslot 3 (between sync 1 and 2) but in many cases allows timeslots 1, 2 and 4 to be recovered.

4. Discovered that the Phase 1 HDU message parser had an error during extraction of hexbits for reed-solomon error correction where the first hexbit was pulling in 7-bits versus 6-bits which would cause the HDU to fail and be tagged as bad CRC.

5. Discovered that the Phase 2 SACCH message parser had an error extraction of hexbits for reed-solomon error correction where one of the hexbit values was being assigned to the hexbit array twice. This was normally corrected by the RS code as long as the total error count didn't exceed the max correctable errors, however it artificially introduced up to 6 bit errors before the process even started.

6. Discovered that Phase 2 audio module was not clearing out stale, queued voice timeslots when the initial PTT was detected. The audio module normally queues audio timeslots until it can make an encrypted vs not encrypted determination.

Original Issue Text

I don't think SDRtrunk has TDMA Control Channel decoding capability. I know that it works with P25 P2 with FDMA/TDMA voice channels but I can not get it to work on a System that has TDMA Control Channel.

Here is some info that may help.
https://forums.radioreference.com/threads/p25-tdma-control-channel-decoding-requesting-help-from-experts.429312/
For the AEP System https://www.radioreference.com/db/sid/9847 in East Texas.

If you need more info please let me know and I will try to help in any way I can. Thanks

[KF5HKI]

Update:
I was able to get it to work on a TDMA Control Channel by changing the playlist xml file.
From "<decode_configuration type="decodeConfigP25Phase1" ..." To "<decode_configuration type="decodeConfigP25Phase2" ..."

[KF5HKI]

If possible add a way to make that change in the GUI. And allow HEX numbers for the system IDs as that is the normal way that the P25 system info is shown in.

As in being able to set the P25 mode from Phase 1 CC to Phase 2 (TDMA) CC without having to do it in the XML file.
Screen Capture
Link to AEP site#82

Thanks..

[lwvmobile]

@DSheirer

Here is a link to a raw baseband recording from SDRTrunk of Duke Energy (Harris) P25p2 only which uses MAC_SIGNAL.

https://ufile.io/rxvsk7ka

The skinny of what the manual says is that MAC_SIGNAL (LCCH) is always unscrambled, is on DUID 13 Opcode 0 , and should be treated like a SACCH frame during RS decoding, but has a CRC16 (same as TSBK) instead of a CRC12. It carries its own NET_STS_BCST and many other Control related PDUs, but they are generally all the same format as the Phase 1 OSP TSBK/MBT for abbreviated and extended.

The manual also shows a scrambled variant of LCCH on DUID 4, but I've never seen that one before. Ignore that, that's inbound only.

Just let me know if you want or need more information.

[lwvmobile]

Also, forgot, in case you need it, this is WACN [91F14] SYS [2D7] NAC [01A]

[DSheirer]

Closing as implemented.