[FEATURE REQUEST] Dumping all visible signal levels via remote control

[grappas]

Hi. I'm modifying gqrx-scanner and one thing annoying for me is depending on sequence: set frequency (via telnet) -> get signal level (via telnet) - > compare it to squelch level (inside program). It would be much faster if I could have access to whole visible spectrum of frequencies I could get info for. It could be csv, json, or whatever format.

[neural75]

I am the author of gqrx-scanner and I would like to know if this feature has been considered: the remote control would only need the levels plotted in the main graph window (not the ones from the FFT panadapter). I've read some of the sources but I am not sure where to start. Where is the displayed data stored? Perhaps the command answer can send a small header with the current number of bins and frequencies boundaries and then the last raw levels data acquired. Would it be possible?

[argilo]

It would certainly be possible, but some details would need to be considered. For instance:

• There would potentially be a lot of data transferred, so for efficiency reasons it might be necessary to use a binary format.
• For a scanner I presume you'd want a more-or-less fixed resolution bandwidth, independent of the sample rate and user-configured FFT size. It might make sense to perform a separate FFT for this purpose. How wide would you want each FFT bin to be, approximately?

[willcode]

When I finish https://github.com/gqrx-sdr/gqrx/pull/1199 (output data via zmq), the user will be able to turn on output of various data. In the current PR, that includes raw data or fft data at either the current frame rate or a user-selectable rate. Since the output frames are tagged with a type and metadata, additional data channels can be added. I'm also considering a control channel over zmq. That function would overlap with the remote control function, so it needs some more thought.

[grappas]

There would potentially be a lot of data transferred, so for efficiency reasons it might be necessary to use a binary format.

That's not a problem honestly, as long as it will be decently documented.

[neural75]

How wide would you want each FFT bin to be, approximately?

I am not sure, my first guess was to have the entire spectrum bw from the dsp in a snapshot. It would be also fine to have a variable bin width (depending on the current settings) as long as it is possible to retrieve/calculate the resolution and tune to a frequency. The scanner could use that as an acceleration, then it can pinpoint the exact carrier frequency tuning and searching like it does already (to maximize the carrier level). Something like a hint there is something on that range to scan.

However, I would say a 10Khz bin should be fine in the most cases ( this is my default to scan step to get the rough level value). So, on a 3Mhz bw it would only need 300 samples. Regarding the variable quantity of the data on different hw, perhaps it would be beneficial to select a fixed range of frequencies from A to B to transfer the data in chunks, but this could increase the protocol complexity.

[grappas]

How about this?

• visible spectrum only
• step is defined by user (via argument in telnet) - lets say if we are scanning in NFM then step should be 12500Hz
• after passing a command we are getting on a header first frequency and array size (calculated by step value). After that array with SNR values.

Of course if we are dealing with binary format here. ;)

[neural75]

not necessary (but it is ok with binary): the answer could be text with proper marking and space separated dBFS strength values: RPT 0 F:120000000 B:10000 N:300 23.3 32.1 10.2 ... something like this would also be fine and more similar to the current protocol. The command could be something like: l FFT to get the levels for the current panadapter display, or l FFT "freq_start" "number of bins" to restrict to a specific amount. The answer could contain less samples and, in that case, it will tell with N the number of them (for the boundary condition), the current bin size with B. It does not need to be precise (we can find the peaks over the squelch level and later fine tune with a different step size). I would avoid to recalculate another FFT with a (potentially) different bin size on each request (to avoid unnecessary complexity and performance hit on the gqrx side). Just reading the already displayed one is ok for me, perhaps with a reasonable fixed down-scaling of 1 to 10 Khz resolution... now that I am thinking, 10Khz could be too much, averaging out the carriers in between so that they'll never reach the squelch level (5Khz perhaps?). The scanner can tune upfront on a start frequency and then get the bulk values from there, depending on the answer (when the limit is reached) it can tune again to the next bulk.

[grappas]

Just a reminder ;)