This is a first cut at this to evaluate buffer size adjustments on
supported platforms. A final version might limit status bar reports to
>1000 dropped frames or similar.
Adjusting these may help with audio drop-outs, particularly on slower
CPU systems or heavily loaded systems. Smaller buffer sizes leave less
margin for process interruptions, larger sizes waste resources that
could impact other processes.
Includes a re-factoring of the WSPRNet class, particularly to handle
direct spot posts as well as via a file from wsprd. Switched from GET
http request method to POST method.
FST4W spots post the same information a WSPR spots except the drift
field is always zero (FST4W has no drift compensation, so no drift
figure is calculated by the decoder), and the mode field reflects the
T/R period in minutes. This means FST4W-120A will be similar to
WSPR-2, an FST4W-900 will be similar to WSPR-15. I don't see any way
to view the mode field on either the new or old database format
queries on WSPRnet, so it is hard to tell if that field is actually
stored.
Updated ways to implement a user defined hardware controller which is
executed just after band changes during WSPR band hopping operation.
Allows the user_hardware executable to be located in any directory on
the PATH environment variable. On Windows any file extension listed on
the PATHEXT environment variable may be used, the first match using
PATH and PATHEXT will be executed. On Windows this is achieved by
using CMD.EXE with a '/C' command line flag, i.e. the user's hardware
controller is executed like this:
CMD.EXE /C user_hardware nn
where 'nn' is the new band as an integer in meters.
On non-Windows systems the user's executable will be run if it is
found on the directories specified by the PATH environment variable,
and it is executable, i.e. it is equivalent to something like:
/bin/sh -c user_hardware nn
where 'nn' is the new band as an integer in meters.
In all cases the user_hardware controller should exit with a zero
status, otherwise it have been deemed to have failed. On Windows avoid
an exit status of one as that is utilized by CMD.EXE to indicate the
file was not found, which WSJT-X ignores silently.
This change means the prior need to put the user's hardware controller
into a WSJT-X installation directory like /usr/local/bin or
C:\WSJT\wsjtx\bin is no longer necessary.
The wsjtx process creates control files .start, .stop, or .quit and
the jt9 process deletes them. This is intended to avoid any race
conditions that get the processes out of sync.
