OP25 Increase CC hunt speed

[MTL_Emergencies]

How can I increase the control channel hunting speed on OP25 (Boatbod)?
I programmed a lot of frequencies and would like to increase the hunting speed in order to make it more efficient.

 

[boatbod]

How can I increase the control channel hunting speed on OP25 (Boatbod)?
I programmed a lot of frequencies and would like to increase the hunting speed in order to make it more efficient.

For rx.py you're going to need to edit trunking.py. Look for the CC_HUNT_TIME parameter which defaults to 5.0 seconds.
While multi_rx.py doesn't support hunting between multiple sites, the timeout while searching through the primary and secondary control channels is controlled by CC_TIMEOUT_RETRIES parameter.
Neither version allow you to change the underlying 1000msec loss-of-sync timer which is hard coded down in the library code.

 

[CanesFan95]

I'd also like to speed this up for the Osmocom version. The default in trunking.py is self.CC_HUNT_TIME = 5.0. I set it to 1.0 but it seems to make no difference.

 

[boatbod]

The default in trunking.py is self.CC_HUNT_TIME = 5.0. I set it to 1.0 but it seems to make no difference.

Sorry, looks like I gave bad info because I just looked deeper into trunking.py (in boatbod repo) and found that CC_HUNT_TIME parameter is set but never checked, so I suppose there is no surprise that it's not doing anything. Try the TSYS_HOLD_TIME parameter instead.

 

[CanesFan95]

The default is self.TSYS_HOLD_TIME = 3.0. I changed it to different settings like 1.0 and 8.0 which made no difference, but I acknowledge I'm using Osmocom with multi_rx.py.

I'm wondering if that parameter applies to when you're monitoring more than 1 P25 system. (Which on a side note, OP25 doesn't seem to let you track multiple sites if they have the same NAC code.)

 

[boatbod]

The default is self.TSYS_HOLD_TIME = 3.0. I changed it to different settings like 1.0 and 8.0 which made no difference, but I acknowledge I'm using Osmocom with multi_rx.py.

I'm wondering if that parameter applies to when you're monitoring more than 1 P25 system. (Which on a side note, OP25 doesn't seem to let you track multiple sites if they have the same NAC code.)

Sorry, I've not looked at the Osmocom repo in a good while so I can't offer any advise on that.
Not being able to duplicate NAC codes has been a known issue from the beginning because trunking.py uses the nac as the primary key for tsys lookup.

 

[krutzy]

Just to verify that this what I want to do the opposite. P25 P2 Harris System using Boatbod. I want to slow down the control channel timeout. For some reason with my system, when it is dead slow, it times out on what I call the "most used control channel" times out too quick because the number of TSBKS aren't enough to hold it. What happens is that it starts searching, then it starts trying to frequency correct when locked on nothing, making it more difficult to lock in. BlueTail's solution to this issue was to set their value of their "Switch Control Channel After " to "99999" which might be over kill. But I would like to up the value to something 5 minutes. Given that there are 7 alternate Control values, making that too high could screw it up more.
Recommendations??

 

[boatbod]

Just to verify that this what I want to do the opposite. P25 P2 Harris System using Boatbod. I want to slow down the control channel timeout. For some reason with my system, when it is dead slow, it times out on what I call the "most used control channel" times out too quick because the number of TSBKS aren't enough to hold it. What happens is that it starts searching, then it starts trying to frequency correct when locked on nothing, making it more difficult to lock in. BlueTail's solution to this issue was to set their value of their "Switch Control Channel After " to "99999" which might be over kill. But I would like to up the value to something 5 minutes. Given that there are 7 alternate Control values, making that too high could screw it up more.
Recommendations??

IIRC rx.py hunts the next control channel after 6 control channel timeouts, and an individual channel timeout is defined at loss of sync for >1.0 seconds. See trunking.py line 1183. The logic used in multi_rx.py (tk_p25.py) is a little different.

Low traffic levels should not cause CC timeout, but poor signal quality certainly will. What does your constellation plot look like? (Should be four nice tight clusters at the corners of a square)

Moto systems rarely change control channels, but sadly the same is not true for Harris so you pretty much have to define them all.

 

[krutzy]

My constellation plots go in and out, 4 corners and then nothing. Signal should be fine since I literally have LOS to the tower. If anything the RTL-SDR may not be up to the job. My newer NooEl Smart 5 seems to work better.

However, while observing, the site doesn't seem to always broadcast the sync signal. I don't know if that is intentional or not. On the P25RX, which is much faster do to the Java interface, the signal does seems to go away at times, though when it does received it, it is strong. Midnight - 1 am is the odd time. It is almost like the system is down for a period of time.

I did look at that function / object on line 1183, and I see that what you are doing.

I will do some experimenting and if I can zero in on.

Thanks Boatbod.

 

[boatbod]

My constellation plots go in and out, 4 corners and then nothing. Signal should be fine since I literally have LOS to the tower. If anything the RTL-SDR may not be up to the job. My newer NooEl Smart 5 seems to work better.

However, while observing, the site doesn't seem to always broadcast the sync signal. I don't know if that is intentional or not. On the P25RX, which is much faster do to the Java interface, the signal does seems to go away at times, though when it does received it, it is strong. Midnight - 1 am is the odd time. It is almost like the system is down for a period of time.

I did look at that function / object on line 1183, and I see that what you are doing.

I will do some experimenting and if I can zero in on.

Thanks Boatbod.

Sounds like you've got a bad case of multipath if the signal is pulsing in and out. Try reducing the LNA gain a bit, or moving the antenna an inch or two in either direction.

 

[krutzy]

I certainly can try that. If I go to the "Tune" plot, it says I am getting a about an -18 dB signal, which is pretty strong, maybe too strong.

Thanks.

 

[wgbecks]

Kevin,

Can you capture and post the FFT and Constellation plots? It's quite possible that you may just have too much LNA gain but in some
locations it also possible to be experiencing overload from a nearby LTE tower or other source of local radio interference.

Another gentleman that I am familiar with recently tracked down RFI that was clobbering 800 MHz to be emanating from some light
control motion sensor switches in his home. So, you never know, but studying the FFT plots can help reveal these types of interfering
signals.

Bill

 

[krutzy]

I actually believe I might have solved the issue. I'll see. The plot got me comparing the two SDR plots, one was fine, but one not. The antennas are next to each other receiving from the same tower. When I reduced the LNA value, I got what I was getting last night, so I went the other way and bumped it up. Sure enough, the constellation plot was much better and it zeroed it immediately. So in a backhanded way that idea worked, just not for the reason suggested. I will check at midnight and see what is going on but I think that was it!

Kevin