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

Polyphase Channelizer - Decode Channels Go IDLE After Period of Time #1353

Closed
DSheirer opened this issue Dec 11, 2022 · 9 comments · Fixed by #1354
Closed

Polyphase Channelizer - Decode Channels Go IDLE After Period of Time #1353

DSheirer opened this issue Dec 11, 2022 · 9 comments · Fixed by #1354
Assignees
Milestone

Comments

@DSheirer
Copy link
Owner

DSheirer commented Dec 11, 2022

When running multiple P25 control channels or other decoders, the channels go to an IDLE state after a period of time, indicating that they are no longer decoding the signal.

Troubleshooting

I added a channel FFT display to the Now Playing - Channel tab to verify if the channel was either not receiving sample buffers or if the channel center tuned frequency was misaligned. It turns out that each polyphase channel is misaligned by (approximately) FS/4. This seems consistent when viewing each of the multiple channels that were active when the polyphase channelizer gets into this state.

20221211_101500_screen_capture

In the screenshot, only the channels sourced by the Airspy tuner (450-460 MHz) were impacted and the VHF (150 MHz) channels sourced from a single RTL-2832 tuner were not impacted. The channel FFT added to the Channel tab indicates that the channel signal is mistuned to the right by approximately FS/4.

Work Around

  1. You can adjust the affected tuner's PPM up/down to get the polyphase channelizer to correct the mis-alignment and regain decoding on all of the channels.

or,
2. Change to the Heterodyne Channelizer in User Preferences dialog and restart the application.

Investigate

Investigate what is causing the polyphase channelizer to misalign the channel sample streams. It may be helpful to add a click to log feature that logs the polyphase channelizer's center tuned frequency and each of the sourced channel's center tuned frequency settings to determine where the disconnect lies.

@DSheirer DSheirer self-assigned this Dec 11, 2022
@DSheirer DSheirer added this to the Build 0.5.0 milestone Dec 11, 2022
@cfc62
Copy link

cfc62 commented Dec 13, 2022

Any idea of when this might have been introduced? I monitor multiple CCs across multiple systems with multiple Airspy and have not encountered this issue.

@DSheirer
Copy link
Owner Author

@cfc62 I think the issue may have been there since the initial addition of the Polyphase channelizer. I think this is a threading issue. When there are multiple control channels issuing concurrent requests for traffic channel allocations, I found that there's a chance for a disconnect between changing the tuner frequency and updating the channelizer frequency offsets where things can get out of whack. I updated the channelizer to use thread locking to be more deliberate in the tuner and channelizer frequency updates and am testing that now to see if the issue is resolved.

@cfc62
Copy link

cfc62 commented Dec 16, 2022

Thanks for the update!

@Brad-git-man
Copy link

Brad-git-man commented Dec 17, 2022

@DSheirer Thanks for working on this issue. I run 5 SDRs in an HSF cooled array (monitoring three P25 sties & several VHF freqs) and SDRT crashes after a while. I also raised the ram to 8 gigs in the JVM due to the heavy load on the program, which helped a little. I saw how to do it in an RR forum. I am running all of that on a 16 core Ryzen with 64 gigs.

DSheirer pushed a commit that referenced this issue Dec 17, 2022
…els after a period of time resulting in idle decoding channels.
DSheirer pushed a commit that referenced this issue Dec 17, 2022
…els after a period of time resulting in idle decoding channels.
DSheirer added a commit that referenced this issue Dec 17, 2022
…els after a period of time resulting in idle decoding channels. (#1354)

Co-authored-by: Dennis Sheirer <[email protected]>
@DSheirer
Copy link
Owner Author

@Brad-git-man pull down the latest branch and see if this resolves the issue for you. I ran for 24-hours continuous and didn't see the issue reappear .... it was popping up within 15 minutes to 3 hours for me previously.

@Brad-git-man
Copy link

@DSheirer I went to the latest branch page, but can't figure out how to pull it down, is it a complete version or do you just get the new Channelizer there and replace yours with the new one?

@DSheirer
Copy link
Owner Author

@Brad-git-man I'll be posting a new build shortly.

@Brad-git-man
Copy link

@DSheirer I have now installed it and I really like the improvements, the audio now seems clearer, thanks for all your great work. You are moving ever closer to version 1.0 which I know will be a truly great program.

@GTR8000
Copy link

GTR8000 commented Dec 28, 2022

0.5.0 Final, Win 10, RTL-2832/R820T, 2.4 Msps, auto-PPM enabled

I just experienced this IDLE condition for the first time that I can recall.

This install is decoding a single VHF P25 control channel, along with one "dummy" P25P1 channel that serves to keep the site's channels centered for optimal decoding. At 11:24 this morning it seems that the control channel decoder went into the idle state, according to the recordings in Trunking Recorder. There was activity 30 seconds after that last transmission which was never decoded (logged in Unitrunker), and it remained idle until I noticed it a few minutes ago.

Looking at the spectrum (the channel FFT display mentioned in the first post is nowhere to be found), the dongle was functioning and was still within the frequency range of the control channel, as expected. I restarted the channel via the Playlist Editor, and it snapped right back to CONTROL status and is now decoding voice again.

Additional info: Well that's odd, I just looked again to verify that the tuner was set to Polyphase, which is how I always run SDRTrunk, and surprisingly it was set to Heterodyne. I have no way of knowing if I somehow set that myself a long time ago, or if it changed on its own somehow.

Unfortunately I'm therefore not able to determine whether the IDLE condition happened in Heterodyne or Polyphase mode. I've set it back to Polyphase and will continue to monitor.

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 a pull request may close this issue.

4 participants