@js8users
1st attempt to get linux laptop un-zip (not really an "install") of js8spotter to connect to the JS8Call running on McLinux box experienced a few bumps.
1: Although on McLinux, python3 was able to run the app without doing anything about dependencies, the laptop didn't have the "request" module.
python3 -m pip install request
...cleared that hurdle.
2: Then I set the IP of McLinux in the js8spotter settings of laptop. Restart. Still no.
Ok JS8Spotter is up and running, and when configured with the TCP parameters, says that TCP is active, and I can see some traffic on the waterfall, if that's what the two red rectangles are.
That said, no traffic is being analyzed in the background, that I can tell.
It could be said that we aren't really doing much with this right now, but exchanging heartbeats. That may be true, but in so doing, so many of us together are forming a network that is aware of it's health, in a manner of speaking.
While it may not have a capacity to heal itself, as such, proper analysis of the data gathered from the heartbeat exchange might yield such valuable information as which station(s) is/are currently the best to pass a message through, and which stations are presently best for holding a message for delivery.
The former would be characterized through analysis of current routes; one would filter for the smallest collection of that set of 'hearing/heard' stations that connect source and destination for such a message. Additionally, age information about the heartbeats can be leveraged to make informed decisions about the present reliability of a route or a station's probable status.
The latter would look at more historical data to find stations where the message recipient is most often heard.
Combined in real time, these two approaches to delivery could conceivably form a reliable station delivery mechanism in a situation where condx are highly dynamic and highly variable.