P25 Conventional - Header Info Collection

[Jord0]

Good day everyone. First off I would like to thank this excellent community for all the help they offer people. I would like to also thank all the open source developers in regards to SDR and GR. I have a question for the community and hopefully someone out there may have an answer.

I have been playing with op25 (osmo and BoatBod) and what an excellent piece of software but more geared towards playing trunked audio. All I want to do is to be able to pull P25 (conventional) headers and store in a database(ie unit ID, GPS, etc), I am using ettus UHD devices. This is our own system, Motorola P25 conventional encrypted, because of this I have no interest in voice or decrypting. What I really want to do is pull the header information (which runs in the clear) and store this information, possibly in a database but a text file would be good enough and could grep later.

I have had problems getting op25 to show me this information, actually getting OP25 to operate on conventional has been challenging. I am starting to think I may return to the drawing board and trying to put it together in GNU-Radio.

Does anyone know how to setup op25 to spit this info out for conventional?

Does anyone know of any other software than can perform this tasks?

Finally, anyone know a good set of P25 blocks for GNU Radio?

Thank you everyone, you help in this is appreciate.

 

[boatbod]

Good day everyone. First off I would like to thank this excellent community for all the help they offer people. I would like to also thank all the open source developers in regards to SDR and GR. I have a question for the community and hopefully someone out there may have an answer.

I have been playing with op25 (osmo and BoatBod) and what an excellent piece of software but more geared towards playing trunked audio. All I want to do is to be able to pull P25 (conventional) headers and store in a database(ie unit ID, GPS, etc), I am using ettus UHD devices. This is our own system, Motorola P25 conventional encrypted, because of this I have no interest in voice or decrypting. What I really want to do is pull the header information (which runs in the clear) and store this information, possibly in a database but a text file would be good enough and could grep later.

I have had problems getting op25 to show me this information, actually getting OP25 to operate on conventional has been challenging. I am starting to think I may return to the drawing board and trying to put it together in GNU-Radio.

Does anyone know how to setup op25 to spit this info out for conventional?

Does anyone know of any other software than can perform this tasks?

Finally, anyone know a good set of P25 blocks for GNU Radio?

Thank you everyone, you help in this is appreciate.

If you are monitoring P25 Conventional transmissions the modulation is going to be C4FM rather than DQPSK so you should configure op25 for modulation type "fsk4". To monitor only the protocol rather than the voice you would drop the "-V" and "-U" command line parameters and then turn the logging up to -v 11 to see verbose decode. In reality you may need to customize trunking.py so that you can log only the information you want to see rather than everything.

 

[KA1RBI]

The failure to decode HDUs (which is what I assume you mean by "headers") was noted long ago by another OP25 contributor.

In response we added a new filter_type option in multi_rx.py ("fsk4mm") which uses an alt. demod - its performance in noise and so forth appears to be slightly poorer than the standard fsk4 demod, which is why it isn't the default. However it does catch the HDUs more reliably.

If you are monitoring P25 Conventional transmissions the modulation is going to be C4FM rather than DQPSK

This is true in general but there are exceptions. There is a conventional P25 (p25p1, FDMA, repeatered, non-trunked) station within range of here that transmits LSM-style ("CQPSK") modulation...

Max

 

[Jord0]

Thank you very much, I am a little humbled getting a response from both of you, also I am a little embarrassed about missing the fsk4 in truth. Absolutely it is the HDU that I am interested in. Also the status bits being passed, I believe the status bits are layered in the LDU's as well. I was able to try out Boatbods suggestions with great results, seeing the Header Code Word broken down nicely and hex after which I think is the rest of the HDU payload. As mentioned it is not totally consistent and I will check out fsk4mm with multi_rx, this would be perferred for the ettus to take advantage of MIMO. But WOW!!!! nice work and thanks for making this available to the masses.

Part of this interest is a side project. I work in the radio industry and recently was shown a device that was commercial grade, hang on the wall, box that collect all sort of P25 data and analytics, a good chuck without decryption. Upon further digging it turns out to just be an Ettus device with proprietary software. Wanted to see what I could put together. I appreciate the interest and help, will keep you posted.

 

[boatbod]

Thank you very much, I am a little humbled getting a response from both of you, also I am a little embarrassed about missing the fsk4 in truth. Absolutely it is the HDU that I am interested in. Also the status bits being passed, I believe the status bits are layered in the LDU's as well. I was able to try out Boatbods suggestions with great results, seeing the Header Code Word broken down nicely and hex after which I think is the rest of the HDU payload. As mentioned it is not totally consistent and I will check out fsk4mm with multi_rx, this would be perferred for the ettus to take advantage of MIMO. But WOW!!!! nice work and thanks for making this available to the masses.

Part of this interest is a side project. I work in the radio industry and recently was shown a device that was commercial grade, hang on the wall, box that collect all sort of P25 data and analytics, a good chuck without decryption. Upon further digging it turns out to just be an Ettus device with proprietary software. Wanted to see what I could put together. I appreciate the interest and help, will keep you posted.

In multi_rx.py you can set the "filter_type" parameter to "fsk4mm" as Max mentioned. For rx.py it's harder to do since the filter type is not passed in to the demodulator and thus just defaults to "rc" which is the regular fsk4 version.