P25 Decoding

[kriskirkland]

Feature Request: P25 Decoding

I use the hackrf with the DSD software but it would be nice to do it with the portapack and not have to lug around a laptop.
The source for the decoding softare is available here; https://github.com/szechyjs/dsd

[furrtek]

IMBE and AMBE are proprietary and require quite a lot of processing power. Like DMR live voice, I doubt it can be done on the Portapack all alone.

[xmycroftx]

Would it be possible to identify P25 framing/usage but not decode it realtime? It might be a cool survey tool.

[ghost]

It should be possible to "decode" and display the P25 frame / PDU data which can include the NAC, Source + Destination + TG IDs, etc and simply ignore the LDU and vocoder bits completely. You would need to add C4FM and CQPSK demodulation and then re-assemble the bits as they come in off the air.

I can only see this working on a conventional system if you want to use it directly on a HackRF + PortaPack.

[chudgoo]

It might also be useful to have a log of all calls on a given system. Bonus points would be a count of the number of calls on a given TGID at the top of the log. You could get an idea of where most of the action is.

[jboone]

Agreeing with @furrtek about IMBE/AMBE. It's a lot of computation. Though for what it's worth, decoding has been done before on STM32s (see the Tytera MD380 and Travis Goodspeed's work on it).

I have done some preliminary work in GNU Radio on demodulating DMR from a local repeater, via a HackRF. The C4FM symbol recovery is a bit tricky, and is where I recall stopping, as I wasn't getting good enough results to move it to a Cortex-M4F implementation. But in the intervening year or so, lots of other projects have popped up, and perhaps I can learn from their implementations, to hand-code a demodulator that's efficient enough for real-time packet recovery, with maybe enough left over that if somebody else wanted to plug in a [AI]MBE decoder, they could.