command line frequency switching

[rainstar]

So, I don't know the specific mechanism that would be needed for this, but I know it would be very useful.
The idea is that users can set up events in their operating system event manager and attach a command line script to run.
The script would call a sdr-console executable with an instance and a memory as command line flags.
The result is that when the event happens and the script is run, the running sdr-radio console session immediately changes frequencies.
Multiple instances and any number of frequency changes would be readily supported by this mechanism.
event "C:/directory/executable" --changeplaces --instance:1 --memory:4

[pauldbnut]

Hi, that sounds interesting.
Can you give some concrete examples of how that might be used, please?

[PD3LK]

usefull idea, maybe including a --startrecord switch?

[rainstar]

Hi, that sounds interesting.
Can you give some concrete examples of how that might be used, please?

Let's say that you want to monitor traffic happening on specific stations during the daytime, and others at night.
Lets assume you are a SWLing user who listens to WWCR, voice of korea, and various other stations.
Specific programs on specific stations are of interest to you, so you configure your sdr-radio software with memories for the channel
frequencies. To help determine your reception, you also configure it for 2.5, 5, and 10 mhz time signal frequencies.

Finally, you go to windows task manager, and you create a task to switch the frequency on the primary instance at the desired times.
You set tasks to record an interesting program by mr jones about the world order's secret hand sanitizer monopoly, and also to
check 5mhz briefly beforehand so you will know if your WWCR reception is bad because of band conditions and not your antenna setup.
You configure sdr-radio to record continually and not to lock the frequency, and then you lock the interface against accidental changes.
You then go to bed and dream pleasant dreams, and the next morning, you get up and check your recordings and make a nice blog post.

[pauldbnut]

Interestinger and Interestinger.

First reaction was Data Scheduler. That would seem to offer a clean "in house" solution without the need for involving memories and batch files.
And then I realised (never having tried it before) that the scheduler is designed for repetitive recordings on one specific frequency.

But then I thought, all the scheduler does is create a set of records sorted by time. So add a new schedule on a different frequency. Yep, that works too.
Although I was disappointed to find no editing facility for existing entries - only deleting a whole schedule.
Except that there is a Copy button to clone a schedule into a new definition. Rather good, that!
Just maybe Simon might provide an editor one day to allow more flexible editing.

Only reservation is that every chunk is a separate file, but that's unavoidable with I-Q recordings.

And then I realised maybe you were talking about audio recordings???

If that's true (and you need to change demodulator for different frequencies) then Memories do need to come into the picture?
So, what about an Audio Scheduler partner to the Data one? Just maybe with selectable Demod mode to avoid Memories?
Warning: all-in-one file would lose time line information.

Time for bed.

[McRadioface]

I can see multiple use cases for this...
gqrx for example has an interface that can be sent commands and during hurricane season, I used this to write scripts to scan through frequencies of interest.

The first thing I'd do is write a scanner in a shell type language to loop through all the milair stuff I've gathered over time.
The utility of this in my perspective is staggering. The ability to log signal strengths per 'hit' is another dimension entirely thats useful for long term monitoring for the obsessive compulsive frequency collectors/hoarders like myself who dream about that capacity now that its possible.
*deep breath*
thank you for listening.

[pauldbnut]

How I hate the term "use case" and prefer the word "scenario" .

My feeling is you might get better answers by explaining those "use cases" in more detail, backing off ideas on implementation, allowing Simon to judge what's feasible and letting him decide how it might be done?

[rainstar]

When I say memories, I mean frequency memories. I use memories to change frequencies quite often.
Memories seem to preserve a few aspects of the setting- the demodulation, the zoom on the waterfall, the frequency.
I am not sure if there is another kind of "memory" in the interface. I am aware of favorites, but i dont use them.

Let's say you have a new sdr and a new antenna setup you want to obtain data on.
You load up all of the primary Ft8 frequencies in your sdr-console memory bank, and you set up your psk reporting tool.
The audio output/recording facilities of sdr-console are immaterial to the use scenario, whatever it picks up, it outputs on virtual cable one.
You then set up the tasks to switch the frequency being used on the periodic basis, and, i dont know if it can be done with wsjt-x; but
probably - and you auto-psk report all of the ft8 on 40, 30, 20, etc

the heart and soul of this request has nothing to do with using sdr-console as the all-inclusive internal tool for signals.
rather, it is to do with the ability to reliably reconfigure sdr-radio as you would any rig.

This feature would also likely be eventually used by a lot of other open source software to control sdr's that they do not natively support.