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 .