Inconsistent behavior of S-meter after long uptime

[0x00FE]

Hello, We have been using Gqrx for few years now in addition to a Python script to scan ATC frequencies and feed it into LiveATC.net. The script moves between frequencies and pauses when the signal level is beyond the squelch threshold. Prior to version 2.15, there was an erratic behavior of the S-meter if the software was running for several days non-stop. After 2.15, the original erratic behavior stopped, but the behavior is not consistent after about a day. (Issue happens much sooner than with the previous erratic behavior) There are what seems to be spikes on the S-meter that appears while scanning. I'm not sure if there was a transmission but it was skipped, or no transmission but a random spike is detected even with noise blankers are on. The audio chops and we have to restart the application to hear proper ATC almost every day. The restart immediately resolves the issue.

Please let me know if I can provide more data on the issue.

[argilo]

Some additional information that would be helpful:

• Which input device are you using? At what sample rate?
• How does your script work? Perhaps you could share it for testing.
• Could you make a video of the erratic behaviour?

[0x00FE]

Device: Nooelec NESDR SMArt Sample rate: 1.800 Msps (Default)

Script is based on gqrx_scan but with some improvements to suit our needs. My script, Note it isn't a very clean code. I attempted to quickly fix the pause time after the conversation is over.

Here is a four minute video where the issue appears before I restart the application. Essentially, the S-meter seems to spike as if it detects a signal, threshold passes squelch threshold and some sound can be heard as seen on the FFT but scanning continues and the sound is always chopped as the scanning continues. Sorry the video has no sound as I'm connected through vnc to the running system.

Looking at it again, I'm not sure if I can precisely claim that this is an S-meter bug or something else, depending on how the program is coded, it seems that either the S-meter gives the right value of signal strength but the program does not report that through '_update("l")', or something else is still broken or got broken since the original S-meter bug.

The issue disappears instantly after application restart and reminded me of the memory leak that was in the "Remote control" feature few years back.

Again, please let me know if there is more I can do to help.

[vladisslav2011]

Hello. It looks, like you are getting too large tuning lag, that your script can't handle. This is common result of buffers growing too high. To help us better diagnose a problem, I can advice you to

1. Set waterfall update rate and FFT size to some lower values to reduce interference from GUI updates. 15 FPS and 64k samples should be enough.
2. Disable panadapter averaging to increase GUI update speed.
3. Choose a range of frequencies for test, that would fit into the tuner bandwidth (1.8MHz) and would not require frontend retuning. If the problem is gone, then there is something, that makes osmosdr::source grow it's internal buffer. You may switch to a wieband device in this case. If the problem persists, then there is something, that makes any of subsequent GNU Radio blocks grow it's input buffer...
4. Try reducing input buffer size: add "buflen=8192" to a device string to make it look like "rtl=0,buflen=8192". Note: there are no spaces.

I have tried to make gqrx do similar things: scanning multiple frequencies and recording received messages to separate audio files. But after testing some scanner scripts (python and bash variants, both missing many messages, when there are simultaneous transmissions on different frequencies), and testing LouDou's multirx branch (mostly works, but bad user experience), I decided to make my own implementation. I don't think, that my implementation would fit your needs straight off the shelf as it would require either "record to a process" or "UDP sink per VFO" feature. I can implement either feature if you tell me, which would fit your needs better. If "audio sink per VFO" approach is what you need, then LouDou's implementation would be better. You'll need some wideband device (BladeRF, LimeSDR, HackRF, AirSPY, RSP1a or someting similar), of course...

Update: I did a small test to confirm this bug: https://www.youtube.com/watch?v=MZFYcGQUIPc There is noticeable audio lag after several hours of operation. Switching demod to NONE, as suggested in the matrix chat, clears the lag. I think, that's audio device not consuming samples fast enough. I'll add actual sample rate estimation to audio sinks and resampling ratio correction as a workaround and retest.