Customer Feature Request: P25 monitoring
syedkarim opened this issue · 5 comments
An application that uses one (or more) sdr's to monitor a P25 (or others
depending) while the rest scan through the input frequencies (i.e. 700Mhz + 30,
or 800Mhz -45) to find local activity, and show what system(s), group id, and
radio id is on that frequency. With option to log naturally. Another idea: Is
it possible to 'bridge' two Kraken together to act as one 10 channel system?
The other software (GQRX, etc.) has a slow scan speed (approx. 8
freq's/second), and using several sdr's to 'leap frog' through a frequency list
would speed things up. But you would know about that more than I would.
Anyway, thank you very much. Looking forward to get out 'in the field'.
You can use the multiple SDRS inside a Kraken/Kerberos with trunk-recorder:
https://github.com/robotastic/trunk-recorder
Coherency isn't needed for this application, so you can also use multiple individual SDRs in addition to or instead of the Kraken.
I don't understand, @syedkarim can you clarify with the customer, does he want to use the unit as a scanner/decoder or does he want to locate the source of P25 transmissions.
If it's just as a scanner/decoder, as @aaknitt mentions there are already many options out there. I think SDR Trunk is another option that also easily supports multiple dongles.
If he wants P25 info to tag along with direction finding data, then this is more complicated. It's something we want to do in the future, but it's going to be a bit of work and time.
I'm not the customer referenced above, but I am a customer, and I am interested in the latter "more complicated," configuration. If this feature isn't going to be available in the near future, would you be willing to please sketch out how one would go about implementing it oneself?
Basically in the signal_processor code we get a chunk of IQ data some number of ms long each cycle. By default each chunk is around 400ms long.
In each chunk of IQ data it's possible that there could be more than one signal transmission, or only a partial transmission (with the rest of the data being in the prior or subsequent block). So some logic to figure out how to cut up the IQ data, or stitch together two IQ blocks, to obtain full chunks of individual transmit periods would be required. (It might also be possible to get ID data from a partial signal too, this needs to be investigated)
Those individual transmit chunks of IQ data then need to be demodulated, then passed into a P25 decoder in order to get the ID information. We can then filter by ID, and send the wanted transmissions to the DOA algorithm and discard the rest.
For the P25 decoder, we can probably reuse open source code from DSD (not DSD+ as that is closed source) or SDR-Trunk.
Closing. P25 and custom decoders for digital voice etc with the ability to select out specific TDMA users is something we have planned to look at in the future. But it is a massive task that will take significant time.