'cdb 1' serial command on HP-1: a nice surprise

[chikin]

Hey all,

Please forgive me if this has been previously discovered and documented; I stumbled upon it a couple of days ago while trying different variations of the 'cdb 2' serial command to enable debug mode that I first saw implemented in HPe-rc.

Anyway, sending 'cdb\t1\r' to the HP-1's serial port (note the tab and the carriage return) enables what appears to be a four-level slicing mode that outputs the ASCII characters '0', '1', '2', or '3' to the serial port at a rate of about 4.8 kB/s when tuned to a P25 channel. The scanner continues to work in interactive mode, so I can hold channels, select systems, and otherwise operate the HP-1 as normal. I do notice that the slicer output doesn't appear to be just a raw slicer sampling the baseband at 4.8 kS/s; for instance, when I tune away from the control channel to an unmodulated channel, the slicer output stutters or just stops. But it does appear to work very well when following a P25 system. To confirm that the HP-1 was in fact sending slicer data, I looked first for P25 frame syncs as documented in TIA-102.BAAA. When I got a bunch of positive hits, I wrote a really basic TSBK decoder and fed the serial port data into it. The samples were successfully parsed on my local system:

28 00 00 00 00 05 5d a1 45 56 a1 f5 [a1f5]
02 00 01 ad 00 65 00 d5 09 02 67 96 [6796]
00 90 0c 6a 0c 71 0c 6a 0c 71 c6 27 [c627]
00 90 04 63 04 63 04 61 04 63 70 42 [7042]
3b 00 00 be e0 91 3e 00 41 70 a0 26 [a026]
34 00 45 05 a0 14 01 e9 4f ac 75 6c [756c]
3a 00 00 31 3e 01 01 00 41 70 14 e9 [14e9]
00 90 05 ca 05 cd 05 cd 05 cd a0 62 [a062]
09 90 14 00 00 00 00 00 00 00 04 64 [0464]
05 90 40 00 00 00 00 00 00 00 27 13 [2713]

These are TSBKs I was able to decode with the slicer output from the HP-1. The CRCs match in about 90% of the packets (I haven't implemented error correction in my rate 1/2 trellis decoder, so it's very sensitive to noise right now), so I'm fairly confident that this is what I've got.

My long-term plan for this is to have a process on a Raspberry Pi decoding trunked control channel data from the HP-1 and using that to tune a BC796D for voice decoding, then sampling and streaming the audio to the local network. (The RPi probably doesn't have the horsepower to run DSD; besides, I've heard mixed reviews, and I happen to have the extra scanner onhand.) The idea is to create a kind of custom trunked radio monitor that I can control through a webserver on the RPi that's far more capable than the HP-1's native interface. With a dedicated tuner fixed on the control channel, I can monitor for priority channels and watch system activity while listening to a selected channel on the 796, etc. I just need to find a good reference for P25 control channel messages details (nothing too fancy needed--basic voice channel grants and such).

I have Extreme!!!11! version 2.01 of the HP-1 firmware, btw.

 

[tbiggums]

Does it work on voice frames as well as trunked signalling blocks? Can you see everything in the frames, like the frame sync itself, encryption sync data (message indicator, algorithm ID, and key ID) all the vocoder bits, and the forward error correction data?

The PSR-800 outputs some stuff on the P25 voice frames, but it's mostly the encryption sync data from what I remember. I guess they figured everything else wasn't interesting to anybody.

Do you need the "Extreme" update for this feature?

 

[SCPD]

chikkin - have you tried it on ...

EDACS,
Motorola, or
DMR?

 

[chikin]

Does it work on voice frames as well as trunked signalling blocks? Can you see everything in the frames, like the frame sync itself, encryption sync data (message indicator, algorithm ID, and key ID) all the vocoder bits, and the forward error correction data?

Yes. As far as I can tell, the four-level data is everything--the frame syncs, NID/DUID fields and all appropriate packet bits (including status bits). It seems to be essentially the output of the four-level decoder in the firmware. Even better, the scanner firmware is likely tracking signal levels and synchronization and tweaking the slicer as it runs.

Do you need the "Extreme" update for this feature?

Not sure about this, but I have no reason to think it wouldn't work on the stock HP-1 firmware.

have you tried it on EDACS, Motorola, or DMR?

Not yet. I'll give it a try later this week; I'm still working on the TSBK decoder.

Speaking of Unitrunker, maybe you can help me with this one: I've been comparing its trunk channel message logs with what my software is decoding in an effort to ensure my data is good and to help me figure out how I need to interpret the TSBK bytes for the different message types. The weird thing is, assuming that what I'm reading in Unitrunker's log are 12 hex bytes of the TSBK data, none of the TSBKs that I've collected with my software have had the LB bit set (bit 7 of the first octet), whereas I see a ton of them in the Unitrunker-generated log. Yet all the packets I've collected with my simple decoder make sense at first glance and pass CRC validation, so I know I'm deinterleaving and decoding the rest of the packet correctly. It makes me believe there's a bug in my decoder, and the only thing I can think of is that I'm missing TSBKs.

My debug output says there are 360 dibits between syncs, and yet a single complete TSBK is 180 dibits if you include the nulls at the end. So my decoder essentially skips the 180 dibits between them because it doesn't start with a frame sync, and yet it doesn't seem large enough for two TSBKs. I don't have access to the relevant spec documents so I'm fumbling around a bit in the dark here.

 

[SCPD]

It's been years since I had to look at that layer.

48 bit sync (24 symbols)
64 bit NID (32 symbols)
196 bit TSBK (98 symbols)
1 status dibit every 36 symbols

98 + 32 + 24 = 154 symbols
Round up to nearest multiple of 35 and then add status symbols for total frame symbols (including sync).
For a single TSBK (eg. the "last" bit is set on it), round up to 175 symbols
Adding status symbols we have 36 * 175 / 35 = 180 symbols.

The system you are monitoring BEE09-13E sends out three TSBKs per frame. The "last" bit will be on every third TSBK (which you can clearly see from the logs).

The math for that is ...

48 bit sync (24 symbols)
64 bit NID (32 symbols)
196 bit TSBK (98 symbols) * 3
1 status dibit every 36 symbols

3*98 + 32 + 24 = 350 symbols (which is an even multiple of 35 - no wasted space bits)
Adding status symbols we have 36 * 350 / 35 = 360 symbols.

Ten years ago, when first working this stuff out - it took me a few days to figure out why I was only getting 13 TSBKs per second.

Oh yeah ... I *still* owe you a beer.

 

[chikin]

Oh yeah ... I *still* owe you a beer.

Seems it is I who should owe you a beer! Thanks for that detailed information; that was exactly what I needed to get those extra TSBKs I was missing. (I couldn't initially fathom how two extra TSBKs would fit in that space--turns out I had made a couple of off-by-one errors in my counting... oops! Working too hard lately, I guess.)

 

[EricCottrell]

Hello,

I had problems getting to work on my HP1, but it is still running a beta version of firmware.

I did get it to work on my BCD436HP. It did output on non-P25 signals when I did a custom search, but it does not appear useful. I could not see a valid DMR sync pattern when I tuned to a DMR control channel. This is likely due to the P25 filtering in the radio.

73 Eric