v1.591: FT8/4 autorun
From the CHANGE_LOG file:
v1.591 Apr 3, 2023
FT8: Added autorun function. Works the same as WSPR autorun. See Admin > Extensions > FT8 page.
FT8/4 autorun channels display "NNN decoded", much like WSPR, where NNN is a count of pending
spots to be uploaded to pskreporter.info Pending, because uploads to pskreporter.info only
occur once every 5 minutes.
Comments
Hi John - Thanks for the autorun addition. Is there still an issue running wspr and ft8 on the BBAI?
But there seems to be an interaction issue between FT8 and WSPR on BBAI/AI64 Kiwis. So don't run FT8 on AI/AI64 Kiwis running the WSPR extension for now (either manually or via autorun).
I did some (but not a lot) of testing on a BBAI (thanks Jim!) It seemed to be okay. So give it a try and see what happens. The spot uploads to pskreporter.info and wsprnet.org seemed to work in parallel.
Hi John,
This is another great addition.
I can't remember if it has been discussed before, but would it be possible to have auto-run operate as a background task when there are receiver slots available, but gradually stops when more users connect.
This is possible with OpenWebRX and is quite a useful feature.
Regards,
Martin
@G8JNJ I've avoided this idea because it has an associated chicken-and-egg problem. When a new connection request comes in you'd obviously need to kick one of the existing autorun connections. But doing so involves stuff like shutting down the sound and waterfall processes and releasing certain resources. Things which can't be done in the non-blocking, non-delayable context of the new connection. So it's difficult to do. I'd have to experiment with some strategies and see if something could be made to work.
Let me ask a practical question about how OpenWebRX (the current one) works. Does it allow differentiation of autorun channels w.r.t. being kicked? I'm thinking of scenarios like this: You might want LF and 10m WSPR to never be kicked (presumably because you don't want to miss rare decodes), but for other bands it's fine. You might also want to designate certain bands as "first priority" to be kicked and others as "second priority, kick in round-robin order" to even out their exclusion. Does OWRX offer anything like that. And if not, is something like that valuable? I think it would be almost a necessity.
Hi John,
I'm not even sure it would be possible with a KiWi, it was just a thought.
The way OWRX works us that you define spot frequencies and digital modes within the required profiles for specific bands. These are typically associated with a hardware device, such as an RTL dongle, that has been setup to cover specific bands of frequencies. It is only possible to have one active band at a time, shared between all users, unless multiple hardware devices are available, and allocated to different bands.
If a user selects a band that includes digital modes and frequencies that have been defined within that band, then OWRX will decode and upload any spots.
If there are no users, then a band will be automatically selected from a pre-defined schedule, and as before any defined digital modes and spot frequencies that are within the frequency limits of that band will be decoded and uploaded.
In all cases it is possible to define multiple frequencies for a specific digital mode, and have multiple digital modes within a band.
Details can be found in the Github documentation.
https://github.com/jketterl/openwebrx/wiki/Background-decoding
With a KiWi, I think you would need to prioritise the bands to be decoded when a receiver became available, and maybe do a round robin or timed schedule for bands to make best use of propagation.
If you want to take a look around a working OWRX install, send me a PM and I'll give you some logins.
Regards,
Martin