Locking onto P25 data channel vs control channel

[blantonl]

I'm having an issue on this Phase II system Trunk-recorder is holding on a data channel that is broadcast on one of the site's frequencies, but that data channel is NOT the control channel.

https://www.radioreference.com/db/sid/7349

This system seems to run a full time data channel, presumably for IP data or other, on most of the sites that trunk-recorder will lock on to, but not decode. This results in TR not moving on to the control channel if it happens to comes across this data channel first in the list of control channel frequencies.

[kb2ear]

I have this problem on a fairly regular basis. on systems all over the country. Have to manually change main.cc to not load CC list from CC stream, and remove the offending channel from the list. There has to be a better way.

[rosecitytransit]

If this is still an issue, shouldn't there be some specific messages seen in a short while, and have the program time out and move on after a bit if not seen? Is the program reporting a decoding rate that's above the no-signal threshold?

I've had enough issues with control channel switching (see #826) along with signal issues to comment out the switching.

[taclane]

There is a patch submitted to the rc/5.0 branch that seems to have addressed this in testing so far.

Rather than rework the control channel logic too much:

• Non control channel messages and invalid messages are removed from the rate count
• TDU link control messages on an active control channel initiate an immediate retune

One or both of those seems to have worked in testing among the users who were having an issue getting stuck on data channels.

edit:fixed link

[rosecitytransit]

I should fire up a test of 5.0 and see if 826 is still a problem.

[taclane]

There's also a 4.x patch at https://github.com/robotastic/trunk-recorder/pull/954/ that tested okay.

Since 5.0 has a lot of moving parts, the idea was held back for further evaluation, but last I remember the 4.x version didn't show any issues.

[tadscottsmith]

@blantonl can this issue be closed? This should have been fixed in Release v5.0.

[blantonl]

I haven't personally tested it yet, however let's close it and I'll reopen it if it's still an issue.