Understanding SDRTrunk and OP25

[ethanbowering24]

New to radio and am trying to understand what my setup is actually doing. I have an RTL-SDR and have some success decoding P25 with SDRTrunk and Boatbod OP25.

If my understanding is correct, SDRTrunk can monitor the entire available bandwidth around some frequency of the SDR dongle and if that's enough to contain all the channels of a trunked P25 system then it can use the control channel to track which channels are active and decode all of them at once? If there's not enough bandwidth then it can shift around the spectrum a bit if there's enough bandwidth to simultaneously monitor the control channel and a current active channel? How does it decide which channels to actually play on the speakers? I see that it can play a different channel on the left and right speakers but how is it decided which one to use, and what happens if more than two calls are active? Are they recorded and played back once the recorded transmission ends and an audio channel is free?

I've also been struggling to understand what's happening in OP25, I'm not sure how it handles multiple channels but I think it retunes the dongle between the control channel and an active voice channel? I had some difficulty setting this one up as I think that encrypted channels kept interrupting playback of unencrypted ones even though I had the nocrypt and skip options set, they seemed to play some noise and then go quiet. I set up a blacklist for encrypted talkgroups and that seems to have resolved the issue. Can OP25 handle multiple channels simultaneously (even if it can only play one at a time over audio, but maybe through recording)? If not then is it just going to tune to whichever channel the control channel happened to transmit at the time, and any other calls that happened while it was tuned away are lost?

Thank you!

 

[boatbod]

OP25 has two "apps" within it's distro. The legacy app (rx.py) behaves a little differently to the newer app (multi_rx.py)

rx.py:
- single channel receiver that only uses a single RTL dongle to track a voice tgid from a P25 trunked system or a single P25 Conventional frequency.
- will jump between multiple p25 systems to provide crude scanning functionality.
- low cpu utilization in most situations (works on RPI3/4)

multi_rx.py:
- single or multiple channel receiver that can share physical hardware between logic channels (wideband sdr when set to fixed freq) or dedicated to a specific channel (narrowband sdr allowed to re-tune)
- can define multiple channels per P25 trunked system (for separate streaming) with shared control channel
- can define multiple independent P25 trunked systems
- available cpu is generally the primary factor that limits total system capacity. e.g. wideband sdr uses significant cpu for usb transfer and filtering

 

[ethanbowering24]

OP25 has two "apps" within it's distro. The legacy app (rx.py) behaves a little differently to the newer app (multi_rx.py)

rx.py:
- single channel receiver that only uses a single RTL dongle to track a voice tgid from a P25 trunked system or a single P25 Conventional frequency.
- will jump between multiple p25 systems to provide crude scanning functionality.
- low cpu utilization in most situations (works on RPI3/4)

multi_rx.py:
- single or multiple channel receiver that can share physical hardware between logic channels (wideband sdr when set to fixed freq) or dedicated to a specific channel (narrowband sdr allowed to re-tune)
- can define multiple channels per P25 trunked system (for separate streaming) with shared control channel
- can define multiple independent P25 trunked systems
- available cpu is generally the primary factor that limits total system capacity. e.g. wideband sdr uses significant cpu for usb transfer and filtering

Thanks Boatbod

I did read the docs regarding the differences between the two apps, but I think I misunderstood the differences between the two apps (I have been using legacy "rx.py"). Does "multi_rx.py" work with a single SDR dongle? I thought the idea was that "rx.py" was for a single SDR dongle and "multi_rx.py" was for more than one?

 

[ethanbowering24]

rx.py:
- single channel receiver that only uses a single RTL dongle to track a voice tgid from a P25 trunked system or a single P25 Conventional frequency.

And sorry, I think I still don't understand what you mean with the legacy "rx.py". It will track a voice tgid by listening for it on the control channel?

multi_rx.py:
- single or multiple channel receiver that can share physical hardware between logic channels (wideband sdr when set to fixed freq) or dedicated to a specific channel (narrowband sdr allowed to re-tune)

And for "multi_rx.py", what does "channel" mean in "dedicated to a specific channel (narrowband sdr allowed to re-tune)"? Do you mean talkgroup? If it was dedicated to a specific channel, wouldn't it remain on a fixed frequency and not have to retune?

 

[mtindor]

You are mostly right about SDRTrunk. But, if it has to leave the control channel to follow a voice channel out of range, that's a no-no. You want to have enough dongles / devices to support the full bandwidth needed to monitor all of the channels. So you might have to go with two or more devices. In SDRTrunk you want one device to always have access to the control channel so that it can keep track of all of the voice calls it must follow. If a voice call is on a frequency within the current bandwidth of the dongle that is monitoring the control channel, then it will tune to the voice call. If not, it will use the next available device you have available to tune to that voice channel.

Absolutely the goal is for you to have enough dongle/device coverage to ensure that all frequencies that are part of the site(s) that you want to monitor can be covered. In some cases, one could suffice. In some cases 3+ devices (dongles / airspys / sdrplays / etc) could be needed. All depending upon what systems you want to monitor and if you don't want to miss a single transmission occurring on those sites.

 

[ethanbowering24]

You are mostly right about SDRTrunk. But, if it has to leave the control channel to follow a voice channel out of range, that's a no-no. You want to have enough dongles / devices to support the full bandwidth needed to monitor all of the channels. So you might have to go with two or more devices. In SDRTrunk you want one device to always have access to the control channel so that it can keep track of all of the voice calls it must follow. If a voice call is on a frequency within the current bandwidth of the dongle that is monitoring the control channel, then it will tune to the voice call. If not, it will use the next available device you have available to tune to that voice channel.

Absolutely the goal is for you to have enough dongle/device coverage to ensure that all frequencies that are part of the site(s) that you want to monitor can be covered. In some cases, one could suffice. In some cases 3+ devices (dongles / airspys / sdrplays / etc) could be needed. All depending upon what systems you want to monitor and if you don't want to miss a single transmission occurring on those sites.

Can it retune to shift the monitored bandwidth around the control channel? Like if your bandwidth is just large enough to monitor the control channel at the low end and a voice channel at the high end, or the control channel at the high end and a voice channel at the low end can it swap between these two tunes based on data from control? In both cases the control channel is visible, but only 1 of 2 voice channels.Or will it just remain at a fixed tune?

 

[mtindor]

Can it retune to shift the monitored bandwidth around the control channel? Like if your bandwidth is just large enough to monitor the control channel at the low end and a voice channel at the high end, or the control channel at the high end and a voice channel at the low end can it swap between these two tunes based on data from control? In both cases the control channel is visible, but only 1 of 2 voice channels.Or will it just remain at a fixed tune?

I’m pretty sure it would jump around as long as you could always reach the control channel within the bandwidth. However, what happens when both of those frequencies are active? At some point it’s going to have to just not switch to the voice channel because it can’t make it without losing the control channel

But yes, it will do that

 

[brian]

The intent of SDRTrunk is to monitor the active control channel and all voice channels of a particular site/system simultaneously. So the software expects one or more receive devices (dongles) to be capable to tuning all of these frequencies simultaneously, as needed. The software will retune the dongle automatically to attempt to tune all active voice channels. Some people try to "force" this activity by using what they refer to as "dummy channels" that cause the dongle to stay in a particular range. I have never found that necessary. If the software encounters a situation where the bandwidth covered by the dongle(s) isn't sufficient, it will not tune a voice channel and report that in the activity log.

The software can monitor more than one site/active control channel at a time assuming the voice channels of all sites are within the tuning range of the receivers. The limit then becomes the resources of your PC to handle all of the simultaneous decoding of multiple/many voice channels.

I have a situation where the site I monitor has voice channels and the control channel in the 851-854MHz range which can be covered by 2 RTL SDRs. Then it has a few voice channels in the 858-860MHz range. It skips the 854-857MHz range. Three dongles are sufficient to tune all voice channels, with the dongles retuning to accommodate the active ones.

As far as which channels/talkgroups are active on the two audio channels (left and right) there is no pattern or way to control that, from what I can tell. You can't steer a talkgroup to one audio channel or the other. It seems like the left channel is always used first, with the right channel used when needed (when a 2nd talkgroup set to "Listen" becomes active). Any active transmissions beyond the 2nd one won't be heard (even though the software tunes to the channel). You can set talkgroup monitoring priorities that will let higher priority channels be played before lower ones, but this check only applies at the beginning of a transmission. The software won't interrupt a transmission in progress to play a transmission from a talkgroup with a higher priority.

Many people use secondary party apps like rdio-scanner and trunk-recorder to handle playback of audio recordings created by SDRTrunk. These apps provide more control over playback that is included natively in SDRTrunk .

 

[boatbod]

Thanks Boatbod

I did read the docs regarding the differences between the two apps, but I think I misunderstood the differences between the two apps (I have been using legacy "rx.py"). Does "multi_rx.py" work with a single SDR dongle? I thought the idea was that "rx.py" was for a single SDR dongle and "multi_rx.py" was for more than one?

And sorry, I think I still don't understand what you mean with the legacy "rx.py". It will track a voice tgid by listening for it on the control channel?


And for "multi_rx.py", what does "channel" mean in "dedicated to a specific channel (narrowband sdr allowed to re-tune)"? Do you mean talkgroup? If it was dedicated to a specific channel, wouldn't it remain on a fixed frequency and not have to retune?

The intention is that rx.py is superceeded/replaced completely by multi_rx.py. I consider rx.py to be "legacy" in that it has been around a long time (it arrived in second generation op25 circa 2017, replacing the original scope.py app), has architectural issues, and is quite limited in capabilities compared to multi_rx.py. My problem is that it just won't die quietly in a corner somewhere...

multi_rx.py can handle single or multiple dongles, and can do everything rx.py can do with the exception of time sharing between multiple P25 systems on a single dongle. IMO rx.py does a crappy job of that, and in the process it misses a lot of voice traffic. Considering that dongle are cheap ($25-$35) there really is no compelling reason to go that route if you want to monitor multiple systems.

In op25 multi_rx terminology, a "channel" is a single software receiver capable of receiving one voice or control channel. In a trunked environment, channels are assigned to trunked systems and are under the trunked system's control. They can be given their own blacklist or whitelist, or inherit that of the trunked system. If you want multiple simultaneous voice decodes (i.e. tgids) you define multiple channels and give each it's own whitelist of tgids that you want it to pick from.

Channels rely on available hardware devices when attempting to tune to whatever frequency has been requested by the trunked system handler. Devices are defined as either tunable (can be retuned) or fixed frequency. Typically tunable devices are going to be narrowband sdr (e.g. RTL) 1-2Mhz that can be dedicated to a single channel. Conversely, wide-band hardware such as Airspy and HackRF can tune 3, 6, 10Mhz or more, and are best parked on a frequency that gives you the best coverage, and the whole of the received bandwidth can be utilized by multiple channels simultaneously. There is of course a tradeoff between cost of the hardware, capabilities of the device, usable width of received bandwidth, and cpu cycles required to tune/decimate/filter the desired slice of IF. In many cases multiple small cheap dongles incur significantly less cpu impact than a single expensive high-end device.

Operationally, multi_rx always tries to keep one software receiver (channel) tuned to the control channel. That said, if voice traffic needs to be decoded, and only the control channel receiver is available, it will tune to the voice channel instead. Fortunately the P25 protocol includes the ability for trunking messages to be passed in parallel with the voice stream, so op25 keeps appraised of what's going on even when no receiver is tuned to the control channel.

Feel free to ask more questions! I'm happy to expand on anything mentioned so far, or something we haven't yet touched on.

 

[Napalm]

The intention is that rx.py is superceeded/replaced completely by multi_rx.py. I consider rx.py to be "legacy" in that it has been around a long time (it arrived in second generation op25 circa 2017, replacing the original scope.py app), has architectural issues, and is quite limited in capabilities compared to multi_rx.py. My problem is that it just won't die quietly in a corner somewhere...

multi_rx.py can handle single or multiple dongles, and can do everything rx.py can do with the exception of time sharing between multiple P25 systems on a single dongle. IMO rx.py does a crappy job of that, and in the process it misses a lot of voice traffic. Considering that dongle are cheap ($25-$35) there really is no compelling reason to go that route if you want to monitor multiple systems.

In op25 multi_rx terminology, a "channel" is a single software receiver capable of receiving one voice or control channel. In a trunked environment, channels are assigned to trunked systems and are under the trunked system's control. They can be given their own blacklist or whitelist, or inherit that of the trunked system. If you want multiple simultaneous voice decodes (i.e. tgids) you define multiple channels and give each it's own whitelist of tgids that you want it to pick from.

Channels rely on available hardware devices when attempting to tune to whatever frequency has been requested by the trunked system handler. Devices are defined as either tunable (can be retuned) or fixed frequency. Typically tunable devices are going to be narrowband sdr (e.g. RTL) 1-2Mhz that can be dedicated to a single channel. Conversely, wide-band hardware such as Airspy and HackRF can tune 3, 6, 10Mhz or more, and are best parked on a frequency that gives you the best coverage, and the whole of the received bandwidth can be utilized by multiple channels simultaneously. There is of course a tradeoff between cost of the hardware, capabilities of the device, usable width of received bandwidth, and cpu cycles required to tune/decimate/filter the desired slice of IF. In many cases multiple small cheap dongles incur significantly less cpu impact than a single expensive high-end device.

Operationally, multi_rx always tries to keep one software receiver (channel) tuned to the control channel. That said, if voice traffic needs to be decoded, and only the control channel receiver is available, it will tune to the voice channel instead. Fortunately the P25 protocol includes the ability for trunking messages to be passed in parallel with the voice stream, so op25 keeps appraised of what's going on even when no receiver is tuned to the control channel.

Feel free to ask more questions! I'm happy to expand on anything mentioned so far, or something we haven't yet touched on.

Question: I monitor a Phase 2 system that often has 6-8 simultaneous voice grants. With two dongles on SDRTrunk I can capture all of these calls.

Will boatbod do this? I'm trying to replace my windows machine with a mini PC for my calls node

 

[boatbod]

Question: I monitor a Phase 2 system that often has 6-8 simultaneous voice grants. With two dongles on SDRTrunk I can capture all of these calls.

Will boatbod do this? I'm trying to replace my windows machine with a mini PC for my calls node

If you have sufficient hardware to cover the full spectrum of a P25 system you can configure op25 with the hardware set at fixed frequencies and then receive as many traffic channels as you have cpu cycles to handle the decoding workload. That said, if you are looking to run a "calls node" you might look at TrunkRecorder because it explicitly supports the API to Broadcastify. Streaming from op25 is real-time (not file-based) and works best via liquidsoap.

In configurations where you have less total hardware bandwidth than a fullP25 system, it's best to use the hardware configured to be tunable, in which case you can monitor as many simultaneous conversations as you have discrete dongles.

 

[ethanbowering24]

Why does Smartzone trunking require 2 dongles but P25 does not?

 

[Napalm]

If you have sufficient hardware to cover the full spectrum of a P25 system you can configure op25 with the hardware set at fixed frequencies and then receive as many traffic channels as you have cpu cycles to handle the decoding workload. That said, if you are looking to run a "calls node" you might look at TrunkRecorder because it explicitly supports the API to Broadcastify. Streaming from op25 is real-time (not file-based) and works best via liquidsoap.

In configurations where you have less total hardware bandwidth than a fullP25 system, it's best to use the hardware configured to be tunable, in which case you can monitor as many simultaneous conversations as you have discrete dongles.

Thank you for the reply.

 

[boatbod]

Why does Smartzone trunking require 2 dongles but P25 does not?

That's an excellent question and the answer has to do with the difference between P25 and Smartzone signaling and specifically the information transmitted in-call on the voice channel. With P25 there is extensive voice channel signaling that allows op25 to maintain a view of all calls in progress as well as critical events such as when a voice call has ended. With Smartzone, voice calls can be analog or digital, and as a result op25 doesn't have a good way of determining when the call has ended other than looking for loss of sync or carrier drop. Consequently I made the decision that op25 should monitor the control channel at all times so that it can tear down the voice call when it sees the ongoing voice grant cease. Perhaps this is not the most efficient (there is sub-audible signaling even on analog channels) but it is inexpensive ($25) and easy. Considering Smartzone is a dying technology I didn't want to dedicate too much more time on it.

Note: if you have a wide-band SDR (e.g. airspy) that can cover the whole spectrum of a Smartzone system, you don't actually need a second piece of sdr hardware. Under those circumstances you'd just configure the hardware to be non-tunable and part it on a center frequency so that it is available for use by multiple logical channels.

 

[ethanbowering24]

That's an excellent question and the answer has to do with the difference between P25 and Smartzone signaling and specifically the information transmitted in-call on the voice channel. With P25 there is extensive voice channel signaling that allows op25 to maintain a view of all calls in progress as well as critical events such as when a voice call has ended. With Smartzone, voice calls can be analog or digital, and as a result op25 doesn't have a good way of determining when the call has ended other than looking for loss of sync or carrier drop. Consequently I made the decision that op25 should monitor the control channel at all times so that it can tear down the voice call when it sees the ongoing voice grant cease. Perhaps this is not the most efficient (there is sub-audible signaling even on analog channels) but it is inexpensive ($25) and easy. Considering Smartzone is a dying technology I didn't want to dedicate too much more time on it.

Note: if you have a wide-band SDR (e.g. airspy) that can cover the whole spectrum of a Smartzone system, you don't actually need a second piece of sdr hardware. Under those circumstances you'd just configure the hardware to be non-tunable and part it on a center frequency so that it is available for use by multiple logical channels.

So if my understanding is correct, assuming this is a setup with a tunable dongle that does one channel at a time, it's because on a P25 system there is extra control information in a voice channel during a voice transmission, so it can keep track of control even when decoding a voice channel? But on smartzone if it's tuned to a voice channel there is no extra control data, so you require a second channel/device to remain on control?

If that's the case, I think I should be able to get away with my single RTL-SDR on the smartzone system here since the frequencies only span 1.6 MHz.

I have only two dongles at the moment and one is dedicated to another system already, they are a bit more expensive up here in Canada but I'll probably collect more over time.

 

[boatbod]

So if my understanding is correct, assuming this is a setup with a tunable dongle that does one channel at a time, it's because on a P25 system there is extra control information in a voice channel during a voice transmission, so it can keep track of control even when decoding a voice channel? But on smartzone if it's tuned to a voice channel there is no extra control data, so you require a second channel/device to remain on control?

If that's the case, I think I should be able to get away with my single RTL-SDR on the smartzone system here since the frequencies only span 1.6 MHz.

If your entire system fits in a 1.6Mhz spread, then yes, configure a single rtl device to be "tunable": false and set "frequency": to the mid point. Then configure two decoder channels as normal, one for control channel and one for voice, but configure the "device": parameter to point them both at the same hardware device.

I have only two dongles at the moment and one is dedicated to another system already, they are a bit more expensive up here in Canada but I'll probably collect more over time.