P25 TDMA Control Channel decoding -- requesting help from experts

[mtindor]

I'm sure they replaced all the subscriber units before they started converting the sites to P25. Up here the new sites immidiately had voice calls, just not very much.

The kicker is that in order for any future capture to be "more" useful, it would have to be a capture during a time when (a) the system has voice activity and (b) even better, when the system has voice activity occuring on one of the CC timeslots. But there is no way to really do that without undue burden on the collector of the samples, since it would be like watching paint dry waiting for voice activity -- and one would have to program the non-CCs in and scan them conventionally just to even know when there was voice traffic.

Maybe a good capture can occur some day when there is inclement weather and there is a lot more traffic. I think Texas is known for inclement weather this time of year lol

 

[btt]

I was incorrect regarding the single MAC IDLE message. I was blocking everything for that message after the first one. There are at least 2225 MAC IDLE messages in the 2nd file. So, it is an idle channel. The good news is that this appears that it will be really easy to add support for.

 

[maus92]

Probably wouldn't even consider it until they see results from the OP25 / DSDPlus / BTT / SDRTrunk guys. After all, they know that these guys can do it better than they can lol.

Mike

Don't forget the Unitrunker guy, lol.

 

[nd5y]

It's going to be hilarious when public safety systems start implementing TDMA CC and all current scanners become useless there are firmware updates, which might be years or never.

 

[mtindor]

Don't forget the Unitrunker guy, lol.

Didn't mean to. I definitely would not want to leave Rick out of the mix. UT is another fantastic product.

 

[GTR8000]

Don't forget the Unitrunker guy, lol.

His list referenced software and devices that decode TDMA voice, which Unitrunker does not (as you know). In any event, I reached out to Rick earlier and he has already made a post about it in the UT group.

 

[KevinC]

And @mikey60.

 

[maus92]

It's going to be hilarious when public safety systems start implementing TDMA CC and all current scanners become useless there are firmware updates, which might be years or never.

Long way out, at least for the big systems that have a lot of channels. Smaller capacity cells / sites would be the first to use it. Not sure of the implications for interoperability which would require thousands of either new radios or firmware updates. Makes a bit more sense for closed networks that utilities operate.

 

[maus92]

His list referenced software and devices that decode TDMA voice, which Unitrunker does not (as you know). In any event, I reached out to Rick earlier and he has already made a post about it in the UT group.

Yup, I saw the post. I was a bit concerned that this finding was an encrypted control channel, but it doesn't seem like it is. But I am unclear what "scrambled" means in this context.

 

[mtindor]

And @mikey60.

@GTR8000 took care of that too, or had already planned on contacting Mikey.

 

[btt]

Yup, I saw the post. I was a bit concerned that this finding was an encrypted control channel, but it doesn't seem like it is. But I am unclear what "scrambled" means in this context.

Scrambling is not the same as encryption. In the standards document they mention the reason for scrambling: "scambling of specific PDUs is used to help reject messages from an interfering P25 TDMA system from being interpreted as a valid message to/from the primary system.". In other words, if you don't initialize the scrambler matrix with the correct WACN, SYS_ID, and NAC, then most PDU messages will fail decode (bad crc check).

 

[GTR8000]

@GTR8000 took care of that too, or had already planned on contacting Mikey.

I did? I mentioned him, but never said I was contacting him. I guess he'll get pinged now from this thread.

 

[maus92]

Scrambling is not the same as encryption. In the standards document they mention the reason for scrambling: "scambling of specific PDUs is used to help reject messages from an interfering P25 TDMA system from being interpreted as a valid message to/from the primary system.". In other words, if you don't initialize the scrambler matrix with the correct WACN, SYS_ID, and NAC, then most PDU messages will fail decode (bad crc check).

Understood. So the WACN, SYS_ID, and NAC combine is some way to create a hash / key? What's the formula for that (the TIA 102 docs I have are really old - like 1995 old, lol.)

 

[KA1RBI]

testing a lightly hacked version of OP25... The secondary CC logic is not yet done, nor is the non-TDMA identifier update logic, but here is a summary of the CC (if someone with knowledge of the system could confirm any/all of this, that would be helpful).

====== NAC 0x2c ====== TDMA ======
rf: syid 1f8 rfid 44 stid 44 frequency 854.762500 uplink 809.762500
net: syid 1f8 wacn 92715 frequency 854.762500
secondary control channel(s): 
stats: tsbks 0 crc 0

tbl-id: 8 frequency: 851.000000 step 0.012500 offset -45.000000
adjacent 859.787500: rfid: 8 stid:8 uplink:814.787500 tbl:8
adjacent 855.312500: rfid: 14 stid:14 uplink:810.312500 tbl:8
adjacent 854.912500: rfid: 41 stid:41 uplink:809.912500 tbl:8
adjacent 854.812500: rfid: 42 stid:42 uplink:809.812500 tbl:8
adjacent 854.937500: rfid: 43 stid:43 uplink:809.937500 tbl:8
adjacent 854.087500: rfid: 52 stid:52 uplink:809.087500 tbl:8

 

[scannerboy02]

testing a lightly hacked version of OP25... The secondary CC logic is not yet done, nor is the non-TDMA identifier update logic, but here is a summary of the CC (if someone with knowledge of the system could confirm any/all of this, that would be helpful).

====== NAC 0x2c ====== TDMA ======
rf: syid 1f8 rfid 44 stid 44 frequency 854.762500 uplink 809.762500
net: syid 1f8 wacn 92715 frequency 854.762500
secondary control channel(s):
stats: tsbks 0 crc 0

tbl-id: 8 frequency: 851.000000 step 0.012500 offset -45.000000
adjacent 859.787500: rfid: 8 stid:8 uplink:814.787500 tbl:8
adjacent 855.312500: rfid: 14 stid:14 uplink:810.312500 tbl:8
adjacent 854.912500: rfid: 41 stid:41 uplink:809.912500 tbl:8
adjacent 854.812500: rfid: 42 stid:42 uplink:809.812500 tbl:8
adjacent 854.937500: rfid: 43 stid:43 uplink:809.937500 tbl:8
adjacent 854.087500: rfid: 52 stid:52 uplink:809.087500 tbl:8

I'm going to guess the only way to confirm this information would be to get a sample for the neighboring sites and compare them with each other.

If @ralexander5 is unable to do this in Texas I will try to do this with the Duke Energy sites I have in my area. If time permits I will try to get a few sites while at work tomorrow, if I'm not able to get to it while at work I will get as many as I can this Saturday.

Again, I'm not 100% sure the signal I'm getting is in fact a TDMA control channel but given what work you have shown us I'm fairly sure it is.

Thank you for all the quick work on this!!

 

[mtindor]

testing a lightly hacked version of OP25... The secondary CC logic is not yet done, nor is the non-TDMA identifier update logic, but here is a summary of the CC (if someone with knowledge of the system could confirm any/all of this, that would be helpful).

====== NAC 0x2c ====== TDMA ======
rf: syid 1f8 rfid 44 stid 44 frequency 854.762500 uplink 809.762500
net: syid 1f8 wacn 92715 frequency 854.762500
secondary control channel(s):
stats: tsbks 0 crc 0

tbl-id: 8 frequency: 851.000000 step 0.012500 offset -45.000000
adjacent 859.787500: rfid: 8 stid:8 uplink:814.787500 tbl:8
adjacent 855.312500: rfid: 14 stid:14 uplink:810.312500 tbl:8
adjacent 854.912500: rfid: 41 stid:41 uplink:809.912500 tbl:8
adjacent 854.812500: rfid: 42 stid:42 uplink:809.812500 tbl:8
adjacent 854.937500: rfid: 43 stid:43 uplink:809.937500 tbl:8
adjacent 854.087500: rfid: 52 stid:52 uplink:809.087500 tbl:8

1F8-44.44 was already suspected to be George West (just based upon other peers reporting it as a neighbor), and the 02C NAC would make sense. And the CC is licensed to the George West site, and all the peers look logical (if you look on a map). So I believe your details OP25 spit out are all correct, without actually confirming anything by ear or personal monitoring of the site. And of course @ralexander5 has already indicated that he was capturing the audio from the George West site.

Nice job, Max!

Mike

 

[btt]

testing a lightly hacked version of OP25... The secondary CC logic is not yet done, nor is the non-TDMA identifier update logic, but here is a summary of the CC (if someone with knowledge of the system could confirm any/all of this, that would be helpful).

====== NAC 0x2c ====== TDMA ======
rf: syid 1f8 rfid 44 stid 44 frequency 854.762500 uplink 809.762500
net: syid 1f8 wacn 92715 frequency 854.762500
secondary control channel(s):
stats: tsbks 0 crc 0

tbl-id: 8 frequency: 851.000000 step 0.012500 offset -45.000000
adjacent 859.787500: rfid: 8 stid:8 uplink:814.787500 tbl:8
adjacent 855.312500: rfid: 14 stid:14 uplink:810.312500 tbl:8
adjacent 854.912500: rfid: 41 stid:41 uplink:809.912500 tbl:8
adjacent 854.812500: rfid: 42 stid:42 uplink:809.812500 tbl:8
adjacent 854.937500: rfid: 43 stid:43 uplink:809.937500 tbl:8
adjacent 854.087500: rfid: 52 stid:52 uplink:809.087500 tbl:8

Just curious. That information wasn't in either of these wav files from here was it? Index of /p25tdmacc

 

[KA1RBI]

Yes, that data dump was extracted from a demod/decode of

1R-DSDPlus-Raw-Input_2021-07-19@235920.zip

 

[KA1RBI]

Here's the (provisional) list of secondary Control Channel frequencies from this system

secondary control channel(s): 855.862500,857.312500,858.362500

If it really is a Harris, the system will likely cycle between all available CCs - several times per day is not out of the question...

 

[slicerwizard]

Understood. So the WACN, SYS_ID, and NAC combine is some way to create a hash / key? What's the formula for that (the TIA 102 docs I have are really old - like 1995 old, lol.)

WACN ID, SysID and NAC/DCC are combined to form a starting value for a 44 bit linear feedback shift register. LFSR is used to build a bitstream. Bitstream is xored with the bits in scrambled frames.