Multiple Control Channels using OP25

Status
Not open for further replies.

morha13

Member
Joined
Sep 29, 2016
Messages
30
Hello,
I recently started using Osmocom op25 decoder using a Linux virtual machine. One of the systems I scan has multiple Control Channels (They all have the same NAC), but each control channel receives different talk groups. Just to be more clear, they all use the same talk group ID's, but there are specific talk groups that I receive only on one control channel, and specific ones on the other.

Since they're all the same system, what I did is entering the Frequencies of those Control Channels to the TSV file that I'm using. *Attached a screenshot of my TSV file*.

The problem is that even though I have those multiple Control Channels entered, the software just stays on the same Control Channel and doesn't scan the others.

What did I miss here? Thank you!
 

Attachments

  • 0912f8e92d0b17e25bbe0c412e06fc57.png
    0912f8e92d0b17e25bbe0c412e06fc57.png
    13 KB · Views: 575

boatbod

Member
Joined
Mar 3, 2007
Messages
3,316
Location
Talbot Co, MD
While it's normal for some sites to carry different traffic than other sites in a multisite installation, I've not heard of traffic being split between two separate but identically configured control channels; normally the NAC would be different.

If your trunk.tsv file has multiple control channel entries with distinct NACs, op25 will cycle between each one. If they are all configured with the same NAC, it would be set up like a primary and secondary control channel configuration and no cycling will take place once the application has locked on and is picking up the framing sync.
 

morha13

Member
Joined
Sep 29, 2016
Messages
30
While it's normal for some sites to carry different traffic than other sites in a multisite installation, I've not heard of traffic being split between two separate but identically configured control channels; normally the NAC would be different.

If your trunk.tsv file has multiple control channel entries with distinct NACs, op25 will cycle between each one. If they are all configured with the same NAC, it would be set up like a primary and secondary control channel configuration and no cycling will take place once the application has locked on and is picking up the framing sync.

That's exactly what I thought... But I've checked it few times and that's just how it is... I have 4 control channels on the same system, with the same NAC, but they aren't synced. There are talk groups that I get on one control channel and I don't get on the others.

The problem is that if I set in the TSV file multiple systems with the same NAC, it just picks the last one and stays on it. Is there any way to make the OP25 go through all of the control channels even though they have the same NAC?

Thank you!
 

boatbod

Member
Joined
Mar 3, 2007
Messages
3,316
Location
Talbot Co, MD
That's exactly what I thought... But I've checked it few times and that's just how it is... I have 4 control channels on the same system, with the same NAC, but they aren't synced. There are talk groups that I get on one control channel and I don't get on the others.

The problem is that if I set in the TSV file multiple systems with the same NAC, it just picks the last one and stays on it. Is there any way to make the OP25 go through all of the control channels even though they have the same NAC?

Not without changing the code, and that would have undesirable consequences for anyone who has configured a backup control channel because op25 would be forever swapping between them.
 

morha13

Member
Joined
Sep 29, 2016
Messages
30
Not without changing the code, and that would have undesirable consequences for anyone who has configured a backup control channel because op25 would be forever swapping between them.


So do you have any idea what can I do? What's the best option?
 

boatbod

Member
Joined
Mar 3, 2007
Messages
3,316
Location
Talbot Co, MD
So do you have any idea what can I do? What's the best option?

About the only way I see it working with multiple CC's on a single NAC would be multiple instances of op25 each with their own dongle.

Internally op25 builds its data structures keyed on the NAC and stores the frequency for each control channel serving that NAC as an entry under that key. It happily hunts between different NACs [see find_next_tsys() method in trunking.py] but it swaps to alternate control channels if there is a timeout [see hunt_cc() method in trunking.py].

You could try hacking hunt_cc() to remove the check for timeouts and it *might* hunt every time, but I cannot say what unintended behavior you may encounter. I suspect at the very least it's going to spend way too much time retuning.
Code:
    def hunt_cc(self, curr_time):
        [b]if self.cc_timeouts < 6:
            return[/b]
        self.cc_timeouts = 0
        self.cc_list_index += 1
        if self.cc_list_index >= len(self.cc_list):
            self.cc_list_index = 0
        self.trunk_cc = self.cc_list[self.cc_list_index]
        sys.stderr.write('%f set trunk_cc to %s\n' % (curr_time, self.trunk_cc))
 

morha13

Member
Joined
Sep 29, 2016
Messages
30
About the only way I see it working with multiple CC's on a single NAC would be multiple instances of op25 each with their own dongle.

Internally op25 builds its data structures keyed on the NAC and stores the frequency for each control channel serving that NAC as an entry under that key. It happily hunts between different NACs [see find_next_tsys() method in trunking.py] but it swaps to alternate control channels if there is a timeout [see hunt_cc() method in trunking.py].

You could try hacking hunt_cc() to remove the check for timeouts and it *might* hunt every time, but I cannot say what unintended behavior you may encounter. I suspect at the very least it's going to spend way too much time retuning.
Code:
    def hunt_cc(self, curr_time):
        [b]if self.cc_timeouts < 6:
            return[/b]
        self.cc_timeouts = 0
        self.cc_list_index += 1
        if self.cc_list_index >= len(self.cc_list):
            self.cc_list_index = 0
        self.trunk_cc = self.cc_list[self.cc_list_index]
        sys.stderr.write('%f set trunk_cc to %s\n' % (curr_time, self.trunk_cc))

Thanks for your advice, I will try it tomorrow. If it won't work, I will try to modify the code so every control channel will have its own ID and it won't use the NAC as the data key.

I will keep you updated
 

boatbod

Member
Joined
Mar 3, 2007
Messages
3,316
Location
Talbot Co, MD
Thanks for your advice, I will try it tomorrow. If it won't work, I will try to modify the code so every control channel will have its own ID and it won't use the NAC as the data key.

I will keep you updated

Good luck with that; you'd basically need to rewrite trunking.py
 

morha13

Member
Joined
Sep 29, 2016
Messages
30
Good luck with that; you'd basically need to rewrite trunking.py

I tried your idea, the code just went crazy :D :D

I went over the code a little bit I can see what you mean by "Good luck" ;)
Let's see how much effort I'm gonna put into this. I'll try tomorrow and let you know what I did. If it will even work good I will post the code here for other users.
 

boatbod

Member
Joined
Mar 3, 2007
Messages
3,316
Location
Talbot Co, MD
I tried your idea, the code just went crazy :D :D

I wondered if it might because it tries to hunt for the control channel after every message (tsbk) is received from the lower layers. Eliminating the check for timeout was going to cause it to retune a whole heck of a lot and probably not get any real work done.

Perhaps you could implement a 1000ms timer in that same hunt_cc() code block and make the test conditional on either cc_timeout or timer_expiry? Problem is that you're always going to miss some traffic when it's monitoring one CC and not the other.
 

morha13

Member
Joined
Sep 29, 2016
Messages
30
I wondered if it might because it tries to hunt for the control channel after every message (tsbk) is received from the lower layers. Eliminating the check for timeout was going to cause it to retune a whole heck of a lot and probably not get any real work done.

Perhaps you could implement a 1000ms timer in that same hunt_cc() code block and make the test conditional on either cc_timeout or timer_expiry? Problem is that you're always going to miss some traffic when it's monitoring one CC and not the other.

I will try setting a timer.

About losing traffic, isn't it the same when scanning multiple systems?
And does another dongle can help?

Thanks
 

boatbod

Member
Joined
Mar 3, 2007
Messages
3,316
Location
Talbot Co, MD
I will try setting a timer.

About losing traffic, isn't it the same when scanning multiple systems?
And does another dongle can help?

Thanks

Yes, there is potential for traffic loss whenever you increase the number of monitored system. Splitting between control channels just makes it worse.

A second dongle and a second instance of OP25 would allow you to monitor both control channels at the same time. All you have to do is set up two sets of data files (trunk.tsv and the startup shell script) and both can run out of the same directory. I have something similar running here; as I recall the only gotcha is you need to make WIRESHARK_PORT a command line parameter so you can run the two rx.py instances on different udp ports.
 
Last edited:

morha13

Member
Joined
Sep 29, 2016
Messages
30
Yes, there is potential for traffic loss whenever you increase the number of monitored system. Splitting between control channels just makes it worse.

A second dongle and a second instance of OP25 would allow you to monitor both control channels at the same time. All you have to do is set up two sets of data files (trunk.tsv and the startup shell script) and both can run out of the same directory. I have something similar running here; as I recall the only gotcha is you need to make WIRESHARK_PORT a command line parameter so you can run the two rx.py instances on different udp ports.

Ok I will surely try that later, thanks for all of your advices!
I just finished making a new feature, remote control from my smartphone so I can lock on certain channels ;)
 

Project25_MASTR

Millennial Graying OBT Guy
Joined
Jun 16, 2013
Messages
4,164
Location
Texas
While it's normal for some sites to carry different traffic than other sites in a multisite installation, I've not heard of traffic being split between two separate but identically configured control channels; normally the NAC would be different.

Austin's GATRRS system actually has a working example of this. Two simulcast systems co-located right on top of one another. County Wide (Simulcast 1), is a 10 site simulcast system and E620 (Simulcast 2) is an 8 site system (all 8 sites are co-located with County Wide sites). That means, two active control channels at the co-located sites but each one provides a different site ID. What site a subscriber affiliates to is defined by the talk group. Talk groups can be designated wide area, or local but it's all controlled by the system controller. If a unit tries to affiliate on CW with a TG designated to E620, the system will roam the unit over to E620 automatically.

How you'd go about programming it is programming it as two separate sites. How OP25 will handle it really depends on the coding and as to whether or not it'll keep an eye on multiple control channels at once.
 

boatbod

Member
Joined
Mar 3, 2007
Messages
3,316
Location
Talbot Co, MD
Austin's GATRRS system actually has a working example of this. Two simulcast systems co-located right on top of one another. County Wide (Simulcast 1), is a 10 site simulcast system and E620 (Simulcast 2) is an 8 site system (all 8 sites are co-located with County Wide sites). That means, two active control channels at the co-located sites but each one provides a different site ID. What site a subscriber affiliates to is defined by the talk group. Talk groups can be designated wide area, or local but it's all controlled by the system controller. If a unit tries to affiliate on CW with a TG designated to E620, the system will roam the unit over to E620 automatically.

How you'd go about programming it is programming it as two separate sites. How OP25 will handle it really depends on the coding and as to whether or not it'll keep an eye on multiple control channels at once.

Same NAC but different SYSID or different NACs?

In the former case OP25 will have much work to do to the trunking.py module :(
 

morha13

Member
Joined
Sep 29, 2016
Messages
30
Good luck with that; you'd basically need to rewrite trunking.py

DONE! It's working :D
It took me about 3 hours.
I wrote it like sh*t but it works amazingly!

Are you interested in the code?

P.S.
It requires adding an "id" column to each system
 

boatbod

Member
Joined
Mar 3, 2007
Messages
3,316
Location
Talbot Co, MD
DONE! It's working :D
It took me about 3 hours.
I wrote it like sh*t but it works amazingly!

Are you interested in the code?

P.S.
It requires adding an "id" column to each system

Cool! You should send it to Max - he is the gatekeeper for op25 patches and can actually put them into the git repository.
 

boatbod

Member
Joined
Mar 3, 2007
Messages
3,316
Location
Talbot Co, MD
Different NACs and different site IDs.
That would work fine with the code as currently written.

The case I had is same nacs for different sites on the same system. I had to rewrite the trunking.py module so it can scan multiple sites with the same NAC.
It'd be interesting if someone has a TIA-102 (P25) spec and can investigate whether this is a legitimate configuration scenario or some sort of manufacturer-specific extension.
 
Status
Not open for further replies.
Top