Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inherit P25 Trunked Preferred Tuner To Traffic Channels #1808

Merged
merged 2 commits into from Jan 30, 2024

Conversation

Nokoa
Copy link
Contributor

@Nokoa Nokoa commented Jan 25, 2024

While monitoring a P25 Trunked system, the control channel will follow the preferred tuner conguration, however all of its traffic channels will not. They may use any Tuner.

The preferred tuner value is null for all the traffic channels, as they are not inherited from the parent.

TunerManaer received a null preferred tuner string value.

I manually set the preferred tuner from the parent in all references on the P25TrafficChannelManager class

This allows all voice channels associated with the P25 site to attempt to first use the preferred tuner.

Please test if this works

#1763

@GTR8000
Copy link

GTR8000 commented Jan 25, 2024

This would definitely have benefits in some scenarios, but could potentially be problematic in other scenarios.

For example a mixed 700/800 site where the control channel is 800 and some of the traffic channels are 700. Obviously no single tuner is going to cover 769-860. So what happens when the 800 control channel has Tuner 1 set as preferred tuner, and there's a voice grant on 700 and the traffic channel tries to inherit the preferred tuner of the 800 control channel? Is it going to throw an error that the tuner is out of range, or would it select another tuner that is able to decode the 769-775 range? And if the latter, is it quick enough not to miss activity?

@Nokoa
Copy link
Contributor Author

Nokoa commented Jan 25, 2024

From what I understood of it. It is just the preferred tuner. If tuner 1 is set as preferred and used for 800 mhz and is locked, should it receive a call grant for 700mhz, I believe it will first try tuner 1, see that the frequencies are not in range, and that it cannot be retuned, before moving to the next tuner. Tuner 1 will not be forced to be used. I don't think that this affects that logic. Because traffic channels prior had no preference at all, and they may or may not go in this order of trying irrelevant tuners anyhow.

I have 2 tuners plugged in Airspy and RTL-SDR. My entire P25 system can be received fully on the Airspy. The Airspy also has the proper antenna equipped for that system, yet SDRTrunk will tune some channels on the Airspy but also utilize the RTL-SDR, and tune significant amount of channels there too, even thought it doesn't at all need to. It feels quite random. Or I am missing something.

Right now though, I do see several issues with tuning that can be improved also. Tuners' frequencies get changed while running even though the entire bandwidth of the system is well within range.

Or in Cap+ with 2 frequencies, SDRTrunk may retune the center frequency as it's moving between channel 1 and channel 2, even though they can be received at the same time well within the bandwidth of the SDR.

I believe some more logic can be implemented as a whole for tuning, one which can keep track of all the trunked voice frequencies, and adapt the SDRs center frequencies as needed to cover all of them. However for people who don't have the hardware available to cover all the frequencies all the time, this may cause an issue.

I believe when a preferred tuner is selected this was the expected behavior, that the entire site attempt to use the preferred tuner first.

@GTR8000
Copy link

GTR8000 commented Jan 25, 2024

I agree that the tuning logic is sometimes...well, illogical.

I have a RSP2pro running @ 10 MHz (8.5 MHz usable) decoding a few P25 sites in the 769-775 block. Obviously more than enough bandwidth to handle the entire band. Still, I had to create "dummy" channels on 768 and 776 to keep the heart of the target spectrum centered in order to avoid dropoff at the edges, because SDRTrunk wanted to keep re-tuning the center frequency. Actually quite frustrating, and being able to manually lock a center frequency would eliminate the need to create those silly "dummy" channels to prevent re-tuning when it's wholly unnecessary.

Anyway as I said, what you've done will definitely be beneficial in some cases where a single tuner can handle all of the traffic frequencies associated with the site's control channel, and frankly any attempt to fine tune SDRTrunk's handling of spectrum and center channels and tuning is most welcome. Thanks!

@DSheirer DSheirer added this to the Version 0.7.0 milestone Jan 30, 2024
@DSheirer DSheirer merged commit 5222bff into DSheirer:master Jan 30, 2024
3 checks passed
@DSheirer DSheirer modified the milestones: Version 0.7.0, Version 0.6.1 Feb 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants