Op25 multiple control channels
- Thread starter Watton925
- Start date
- Status
boatbod
Member
There is no way to simultaneously monitor multiple control channels on the same system, but it is possible to monitor multiple control channels simultaneously on multiple systems. It is also possible to specify a comma-separated list of alternate control channels for a single system, but only one will be active at any time. Can you be more specific about what you are trying to achieve and I'll try to provide further guidance.
boatbod
Member
I don't see a way for that to work under rx.py as you have to configure each control channel on a separate line of trunk.tsv, but each line has to have a unique NAC value.
Utilizing the new tk_p25.py trunking module under multi_rx.py it would be possible to configure multiple trunking sysnames each with it's own control channel, but then you'd either need to dedicate one RTL device per receiver channel, or have a wide-band SDR that encompasses the total bandwidth of the whole set of systems.
wgbecks
Active Member
Watton925,
Can you elaborate on exactly what you mean by your systems has multiple control channels with the same NAC? Are you talking about
multiple control channels at the same site or just a list of a single primary with multiple alternates? If the latter than just enter them
as a comma separated list in the control channel field in trunk.tsv and rx.py will scan through the list to find the active frequency.
Can you elaborate on exactly what you mean by your systems has multiple control channels with the same NAC? Are you talking about
multiple control channels at the same site or just a list of a single primary with multiple alternates? If the latter than just enter them
as a comma separated list in the control channel field in trunk.tsv and rx.py will scan through the list to find the active frequency.
boatbod
Member
That's unusual. Am I right thinking it's not Motorola hardware?
Do you have a link to the RRDB entry for this system?
Does each control channel only carry traffic for it's country or is it shared across the whole system?
On the face of it you can probably monitor this system using the new multi_rx version of op25 tk_p25.py, but you are likely to need multiple RTL devices so that you can dedicate one to each county. With the right information I should be able to help you set it up.
- Joined
- Aug 26, 2019
- Messages
- 58
Here is link for system West Virginia Statewide Interoperability Radio Network (SIRN) Trunking System, Statewide, West Virginia - Scanner Frequencies. From my observation of system not all transmissions go thru the whole system just depends on what control channel I’m monitoring. I can see them transmit in fmp24 and then click on them but the source was not from CC I was monitoring
wgbecks
Active Member
Watton925,
I just looked at the SIRN system and it's a standard P25 Phase-I SmartZone system. Each site (RFSS) will have it's own primary and alternate control and voice trunk channels. You'll find the frequencies assigned to each of the sites part of a pool that are periodically reused throughout the system in accordance with engineering practice designed to maximize frequency reuse with a minimum of interference potential between sites.
It's also common practice to assign different NAC's among cochannel (same frequency) sites that plays a key role in the operation
of the subscribers units (SU's) ability to qualify control channel messages and voice trunk traffic that might be originating from a another site within the same system or from a from a foreign system on the same frequency, and where System ID and WACN also play an important role
in this regard.
Now back to your original post. There's no need to simultaneously monitor multiple control channels unless you have a need for multiple receivers set to scan specific talkgroups home to those sites and that you can actually receive said sites form your particular location with requisite equipment to do so.
All that is necessary for a single receiver per site is to ensure the primary and alternate control channels (frequencies) are listed in your trunk.tsv file along with the correct NAC for that site. Alternatively, boatbod's version of op25 provides for the ability to set the NAC to 0x0 that will tell rx.py to use the first NAC is sees when searching the list of control channel frequencies populated in your trunk.tsv file. This capability is very helpful when initially setting up op25 for when you may now know the NAC or are uncertain of what it is.
Another unique application of the 0x0 NAC feature is that it gives one the ability to setup a device like a Raspberry PI for portable or mobile applications where you only need to populate a comma separated list of control channels in your trunk.tsv file and whereby setting the 0x0 NAC to will maintain decoding of system control channels as you roam about regardless of the NAC employed at any given site that you may be in range to receive.
Thank you @boatbod for this very useful and wonderful feature!
Bill
I just looked at the SIRN system and it's a standard P25 Phase-I SmartZone system. Each site (RFSS) will have it's own primary and alternate control and voice trunk channels. You'll find the frequencies assigned to each of the sites part of a pool that are periodically reused throughout the system in accordance with engineering practice designed to maximize frequency reuse with a minimum of interference potential between sites.
It's also common practice to assign different NAC's among cochannel (same frequency) sites that plays a key role in the operation
of the subscribers units (SU's) ability to qualify control channel messages and voice trunk traffic that might be originating from a another site within the same system or from a from a foreign system on the same frequency, and where System ID and WACN also play an important role
in this regard.
Now back to your original post. There's no need to simultaneously monitor multiple control channels unless you have a need for multiple receivers set to scan specific talkgroups home to those sites and that you can actually receive said sites form your particular location with requisite equipment to do so.
All that is necessary for a single receiver per site is to ensure the primary and alternate control channels (frequencies) are listed in your trunk.tsv file along with the correct NAC for that site. Alternatively, boatbod's version of op25 provides for the ability to set the NAC to 0x0 that will tell rx.py to use the first NAC is sees when searching the list of control channel frequencies populated in your trunk.tsv file. This capability is very helpful when initially setting up op25 for when you may now know the NAC or are uncertain of what it is.
Another unique application of the 0x0 NAC feature is that it gives one the ability to setup a device like a Raspberry PI for portable or mobile applications where you only need to populate a comma separated list of control channels in your trunk.tsv file and whereby setting the 0x0 NAC to will maintain decoding of system control channels as you roam about regardless of the NAC employed at any given site that you may be in range to receive.
Thank you @boatbod for this very useful and wonderful feature!
Bill
Last edited:
Watton925, are you trying to monitor local talkgroups such as sheriff, EMS, or fire for more than one county? If that is the case, you may have a situation where the nearest SIRN site won't carry all the traffic you want to hear, hence your desire to receive more than one active control channel (site). Is that the issue?
A relative who lives on the border of two counties in WV has scanners programmed to receive SIRN sites in both counties to hear the local talkgroups for both.
A relative who lives on the border of two counties in WV has scanners programmed to receive SIRN sites in both counties to hear the local talkgroups for both.
AB5ID
Member
I have a situation where the control channels for the 2 systems I monitor would go months without changing. All of the sudden they are changing 2-3 times a week to alternates.
I have a couple of questions
1) Can I just add the alternate CC's in my Trunk.tsv file "control channel" field separated by commas as mentioned above?
2) Will there be any noticeable performance hit while monitoring (as OP25 alternates between two systems)? I'm assuming each time it switches from one system to another it has to "look" for the potential control channel before it settles in?
Are you running one dongle or two?
AB5ID
Member
one
yes. comma separated within quotes.
I don't have multiple p25 systems to monitor, so I can't say how it would operate. I only run a single instance for a single system. I would assume a brief hesitation as it changes systems.
boatbod
Member
Correct. IIRC it's three timeouts then hunt for new CC.
What is the 'timeout' to 'mississippi' equivalent?
boatbod
Member
After checking the code it looks like 6 timeouts are required for a hunt_cc()
Each timeout is 1000000usec, so 6 mississippis total
Each timeout is 1000000usec, so 6 mississippis total
One reason for control channels "rolling" is atmospherics and subsequent co-channel interference from distant stations, particularly in coastal regions during the summer.. The "rolling" should go away as weather conditions / seasons change - or their could be an equipment problem with the system that needs to be addressed. The cch should not change as frequently as you describe.
- Status
Similar threads
