Power Squelch in combination with AGC3 outputting to a file sink results in files with NaN values.

[victhor393]

What happened?

I have a few flowgraphs that are used as part of an airband streaming setup. It basically works like this: [python script generated by grc] --(named pipe)--> [gstreamer] --> [icecast] The output of the script is a file sink, which connects to the named pipe.

Usually, I reconfigure them, using grc, whenever ATC decides to switch to alternate frequencies (i.e. they are fixed frequency streams, instead of scanners), and during one of these events, I received reports that the audio was completely muted after the stream was reconfigured.

During my investigation, I discovered that this was caused by an interaction between the AGC3 and the Power Squelch blocks. When the flowgraph outputs to an audio sink (pipewire), no abnormal behavior is observed from the flowgraph and audio is outputted as normal, the squelch silencing the audio during periods of inactivity as expected. However, outputting to a file sink results in files that are full of -NaNs.

If the squelch is permanently opened (by setting too low of a threshold) or disabled, the file output by the flowgraph contains valid audio.

The cause appears to be the following line on the script generated by GRC, related to the instancing of an AGC3 block:

self.analog_agc3_xx_0 = analog.agc3_cc((1e-0), (1e-4), 1.5, 0.0025, 1, 65536.0)

I noticed that a previous script, generated by an older version of GRC (3.10.4.0), instanced AGC3 in a different way:

self.analog_agc3_xx_0 = analog.agc3_cc((1e-0), (1e-4), 1.5, 0.0025, 1)
self.analog_agc3_xx_0.set_max_gain(65536.0)

which is how I discovered the cause of this issue. Changing the instancing of AGC3 to this different style results in correct operation of the flowgraph and valid audio is output from the file sink, as expected.

Here is the flowgraph that was used: am_rx_121850.grc.gz

System Information

OS: openSUSE Tumbleweed GR Installation Method: Package from hardware:sdr repository

GNU Radio Version

3.10 (maint-3.10)

Specific Version

3.10.8.0

Steps to Reproduce the Problem

1. Open attached flowgraph, or any other flowgraph with Power Squelch, AGC3 and file sink, with GRC.
2. Generate python script.
3. Run python script.
4. Open output file in hex editor or audio editing software.
5. File should contain -NaN values only if the squelch was closed during recording.

Relevant log output

No response

[marcusmueller]

However, outputting to a file sink results in files that are full of -NaNs.

That's interesting; the block has no way of knowing what it's attached to. So, there might either be timing issues (which would be a bad bug, but I'm not ruling that out), or you simply don't hear a couple of NaNs in your audio stream (because they get coerced to 0, probably, during the conversion to fixed-point numbers for the audio system), whereas they (understandably) upset gstreamer.

Sadly, your flowgraph is a bit bad for reproduction, because it not only requires the reproducing party to also have a LimeSDR, but to receive a signal like yours. Could you save what you receive with your LimeSDR source directly to a file sink, and share that, so that we can locally replace the LimeSDR Source with a File Source and get the same result?

[marcusmueller]

Note to self I fixed a bug in AGC3 a while ago, that fix should have appeared in 3.10.5.0, iirc.

[victhor393]

Hi Marcus,

Gstreamer LAME and Vorbis encoders actually handle the -NaN situation just fine, though the output after decoding is simply silent.

The source block should have been a Soapy custom source... as that's what I use with my SDRs (Mirics and RTL). Strange that it shows up as a LimeSDR.

I made an IQ recording of a signal that should work with that flowgraph. It's in CS8 format, it can be ingested using a IChar to Complex block with a scale factor of 1.0. Sampling rate is 1.536 MSPS, and the signal of interest is +50 kHz from the center. A threshold of -32 on the Power Squelch should suffice for this test. It starts with a brief period of silence, and 2 brief transmissions, ending with another silent period. recording.iq.gz

Strangely enough, testing this recording right now, I can't replicate my own previous results while using an audio sink, now it behaves as it did with the file sink. With the squelch operational, the audio sink output is completely dead, and pavucontrol shows a constant, maxed output level for GRC when the flowgraph is running, even outside the silent periods where the squelch is closed, so I guess it is outputting constant -NaNs into pipewire now. This doesn't seem to affect audio on my machine, however, and I can listen to other programs with seemingly no problems.

[marcusmueller]

The source block should have been a Soapy custom source... as that's what I use with my SDRs (Mirics and RTL). Strange that it shows up as a LimeSDR.

Sorry, that was my human transcription error

[marcusmueller]

Thanks for the extensive data! Will reproduce tomorrow, hopefully! (Full docket …)

[argilo]

I had a quick peek at the AGC3 implementation, and I see that agc3_cc::make doesn't pass through the max_gain parameter:

https://github.com/gnuradio/gnuradio/blob/044f5450e32e812a669290a88500f74eb64f1fa6/gr-analog/lib/agc3_cc_impl.cc#L28-L37

It looks like the bug was introduced in #6624.

[argilo]

Fix: #7053