Idea for improvement to remote control for scanning

[Robin Sheat]

Hi, i've been playing with gqrx-scan, and it works well for what it's supposed to do, however I find that if you have 20 or so frequencies in it, it can take a fair while to scan over them.

Given that we can see huge blocks of frequency at one time, it seems that a faster way would be for the remote control interface to allow querying for the strength of many frequencies at once.

For example:

s [for scan] 75225000 75250000 75275000 485225000

the last one being deliberately far away, could return:

-69.4 -70.1 -65.2 OUTOFRANGE

Additionally, querying for the sample rate:

sr
16000000

would allow the scanning software to group the frequencies it wants to scan, set the centre frequency appropriately (via another new option), query the frequencies in range, then change the centre frequency for a group that's elsewhere. If it sees something that's strong enough to care about, it can use 'f' to set the modulator there.

This ought to mean that you can scan many frequencies with very little time taken to notice something is there and jump to it, especially if they're all pretty close together, but even if they aren't it'll be able to minimise the number of tuner changes needed.

Any thoughts on this?

Cheers, Robin.

[Alexandru Csete]

Hi Robin,

Sounds like what you are asking for would be much better accomplished
if implemented inside gqrx, in which case gqrx-scan would no longer be
necessary, or do I misunderstand?

Now that we have bookmarks in gqrx, one could implement a scanning
functionality that scans certain memory groups. Gqrx can already
decide whether to do a software or hardware tuning and is in fact
applied when setting the frequency remotely. But who has the time and
interest to implement the rest?

Alex

> --
> You received this message because you are subscribed to the Google Groups
> "Gqrx SDR" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gqrx+uns...@googlegroups.com.
> To post to this group, send email to gq...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gqrx/11e93ee7-dc2f-4c87-a090-787187c0ded6%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Robin Sheat]

Op dinsdag 19 mei 2015 09:41:07 UTC+12 schreef Alexandru Csete:

Sounds like what you are asking for would be much better accomplished
if implemented inside gqrx, in which case gqrx-scan would no longer be
necessary, or do I misunderstand?

Well, I was proposing making the remote control interface do more things so that things that use it, like gqrx-scan, can in turn be made smarter. This would allow a much faster scan->demodulate the strongest freq->record/listen type flow than is currently possible. This still keeps the logic for what's going to happen in an external program as there's probably other things that people can do with this sort of functionality that I haven't thought of (e.g. attaching a dummy load and walking through the whole spectrum in small increments to find where the birdies are for a specific device - possible currently but probably a fair bit slower, stuff like that.)
 

Now that we have bookmarks in gqrx, one could implement a scanning
functionality that scans certain memory groups.

It's probably a good idea in general, though my ideas for the remote control interface will allow more custom functions to be implemented by anyone.
 

Gqrx can already
decide whether to do a software or hardware tuning and is in fact
applied when setting the frequency remotely.

I found it was very easy to get a pathological case of this where every request caused the hardware tuning to move, just because it was going through a list slightly larger than the received bandwidth in sorted order. If you choose not to move the hardware frequency as part of the 's' operation, then it forces the author of the remote control script to handle this case, and they're more likely to have full knowledge of the whole list of frequencies to scan and so can reorder them and choose an appropriate centre point.
 

But who has the time and
interest to implement the rest?

Hopefully someone :) either that or I may have to dust of my extremely rusty C++...