Default selection is the loop-back interface. Users who require
interoperation between WSJT-X instances cooperating applications
running on different hosts should select a suitable network interface
and carefully choose a multicast group address, and TTL, that has
minimal scope covering the necessary network(s). Using 224.0.0.1 is a
reasonable strategy if all hosts are on the same
subnet. Administratively scoped multicast group addresses like those
within 239.255.0.0/16 can cover larger boundaries, but care must be
taken if the local subnet has access to a multicast enabled router.
The IPv4 broadcast address (255.255.255.255) may be used as an
alternative to multicast UDP, but note that WSJT-X will only send
broadcast UDP datagrams on the loop-back interface, so all recipient
applications must be running on the same host system.
The reference UDP Message protocol applications are being extended to
be configurable with a list of interfaces to join a multicast group
address on. By default they will only join on the loop-back interface,
which is also recommended for any applications designed to take part
in the WSJT-X UDP Message Protocol. This allows full user control of
the scope of multicast group membership with a very conservative
default mode that will work with all interoperating applications
running on the same host system.
The sent/received 'mode' parameter posted to WSPRnet.org has been
amended as follows:
WSPR-2: "2"
FST4W-120: "3"
FST4W-300: "5"
FST4W-900: "16"
FST4W-1800: "30"
this change is designed to maintain backwards compatibility with older
versions of WSJT-X and other software like WSPR-X which already post
these values:
WSPR-2: "2"
WSPR-15: "15"
It is expected that the WSPRnet.org server side will be updated in
sync with a WSJT-X v2.3.0 RC2 (or GA) release to account for this
change.
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.
This for consistency, I suspect inserting a value into the special
operations type enumeration will cause external programs some
backwards compatibility issues. We should consider reverting this and
adding the new value to the end.
The Highlight Callsign (13) UDP message now operates in a slightly
different way. The "Highlight last" field, when true valued, causes
all instances of the specified callsign to be highlighted in the
decoding period. This allows external applications to highlight DX
callsigns even when multiple stations are calling them. Before this
was unlikely to work since the external application would have to
respond to Decode (2) UDP messages exceedingly quickly to guarantee
successful highlighting before another decode with the same DX call
was printed. There should be no changes required to external
applications acting as servers to the WSJT-X UDP Message Protocol,
although using the version of the Highlight Callsign (13) with
"Highlight last" should not be required for adhoc callsign
highlighting. It should be reserved for commonly recurring targets and
limited to no more than 100 active highlighting requests at any one
time, otherwise there may be performance impacts on WSJT-X.
Bill Somerville
phl0