I’m looking for Beta testers for a SOTAmat skimming utility that will support your fellow SOTA/POTA Activators.
Some SOTAmat users express “range anxiety”: will my SOTAmat FT8 self-spot message be heard by one of the compatible skimmers? SOTAmat encodes your self-spot command as a callsign+suffix in an FT8 “Free Text” message (13 characters of general text) BUT normal skimmers (like WSJT-X, OpenWebRx, CWSL_DIGI, etc…) aren’t looking for callsigns in the “Free Text” message and thus don’t report sightings to PSKreporter (where SOTAmat picks them up).
Currently only SOTAmat-compatible skimmers find callsigns in “Free Text” messages:
SparkSDR - there are 94 of these worldwide.
This was the first skimmer to support Free Text callsigns. This provides the backbone for SOTAmat. The downside is that SparkSDR only supports certain SDR hardware, which most people don’t have. I run my own SF Bay Area SparkSDR skimmer listening for FT8 and PSK31 on 40m, 20m, 15m, 10m simultaneously with a Hermes-Lite 2 SDR.
CWSL_DIGI - there are 29 of these worldwide.
It almost works like SparkSDR, but has a bug. The developer is working on a fix. SOTAmat currently blocks these reports due to the bug, so zero of these skimmers is currently working.
OpenWebRX - there are 351 of these worldwide, however only 1 of them supports SOTAmat:
a SOTA user developed a custom build for his own station in New Zealand to support SOTAmat excursions. He asked the OpenWebRX maintainers to integrate his changes and they have not agreed to do so (yet).
My data shows that “range anxiety” is not as real as people expect. Even in highly remote areas on QRP the FT8 signals manage to get to one of the SparkSDR stations even in Northern Canada, New Zealand, Australia, and other remote locations (as long as you transmit your message redundantly 4 times).
Even so, more skimmers is better by reducing both range anxiety and the delay from self-spot to SOTAwatch.
My new solution that needs Beta Testers:
I have a SOTAmat plugin for WSJT-X that filters WSJT-X reception reports and sends potential SOTAmat messages to the SOTAmat server directly for processing. It skips PSKreporter and thus shaves off up to 5 minutes of delay. You can test this a variety of ways:
One WSJT-X instance on one radio tuned to one FT8 frequency for skimming, or
Multiple WSJT-X instances connected to multiple radios tuned to multiple FT8 bands, or
Even if you don’t have a radio in your home shack, you can use http://websdr.org/ to connect someone else’s radio+antenna over the web and use a “virtual sound card” to pipe the WebSDR sound from your web browser into WSJT-X for decoding and connection to the SOTAmat plugin. In this way you can place virtual skimmers in many places around the world (wherever there is a WebSDR receiver).
Are you willing to work on testing any of these scenarios, even for just a basic single-radio skimmer?
You can help fellow SOTA/POTA activators get heard and thus get spotted by SOTAmat.
Here are the files (including docs) to get started, but please contact me before using so I know who to look for on the server.
P.S. The code is built to be portable and once initial testing completes, I expect to build for Linux and Mac too. I’m just starting with Win64 to work the bugs out!
[Update: I added Win/Mac/Linux 64-bit for Intel and ARM processors, see new post below]
For those who think they will be out of range of a compatible receiver, but in range of their home station, they could even go “self-service” and set up their home station (perhaps on 80m or 2m for the correct range) before heading out for the activation knowing that their SOTAMäT signal will “call home” via FT8 and relay to the SOTAWatch system via your server.
I also like the idea of being able to “add the feature” remotely to existing WebSDR or KiwiSDR receivers who don’t normally support capture-and-forward of SOTAmät messages!
Files downloaded and I’ll get testing this coming week.
@DD5LP This is embarrassing but I didn’t know about KiwiSDR! Cool! I was aware of the OpenWebRX but not the rest of it. There are way more SDR’s on KiwiSDR’s map than WebSDR.org’s. With the plugin I can place a skimmer in places better for remote activators. I hope we can get several people using this approach to “fill in” any dark spots. Thanks for the tip!
I’m not sure if your software may need a change to work with the KiwiSDRs API.
I believe there was a period when the person who set up the KiwiSDR network had, had enough and closed the indexing down, whether he handed it over to someone else or whether it is now an Open Source supported project, I’m not sure but I think you are right there are more Kiwi SDRs than the original WebSDRs. The KiwiSDR network can also be used to triangulate and trace where a particular signal is coming from.
73 Ed.
UPDATE: It appears to be OpenWebRX who have taken over KiwiSDR as opening a local KiwiSDR here, it’s first prompt is to click to open OpenWebRX - but behind the prompt is the KiwiSDR code.
Nothing, it was so easy, but maybe I’m not the best tester for spotting ambiguities. I’m terrible good at finding hidden bugs, but all worked as expected.
I’ll let you know by PM when I see something.
I’d like to help with this, although I can only offer a one-radio, one WSJT-X instance configuration and relatively pathetic IT skills. I think I have the skimmer app downloaded, command line parameters set per your instructions, and connected to WSJT-X, but it’s not easy to tell if it’s working. I see your note calling for volunteers requests they contact you to advise of participation but there’s no specifics about whether to do that here on the SOTA reflector or by email or whatever. Anyway, SOTAMat is really looking good so far in VE6 where we have lots of cell & digipieater dead zones - thanks for this innovation!
Normally the app is pretty silent: it starts out with this sequence:
Prints app title and version information
Prints a message saying it is trying to connect to WSJT-X
Prints a message when the connection succeeds
…then it is silent… until… it… receives… a potential SOTAmat message!
If a potential SOTAmat message is received, it will tell you so and that it is sending to the server.
If the connection to WSJT-X is lost (try killing the WSJT-X app and see what happens) an error message will be printed after 30 seconds. It will silently try and reconnect. If re-connection succeeds then it returns to step #3.
However, if you want continuous feedback at step #4 then you can add the “-d” debug option to the command line. The “-d” option will print every reception report (SOTAmat or otherwise) it gets from WSJT-X and prints it to the console.
…and even better feedback is to send a test SOTAmat message and validate that that it gets received. You can do this over-the-air on radio, or you can configure WSJT-X’s audio input to just be your computer’s microphone input and have the SOTAmat mobile app play the tones in your room.
But the “-d” option should provide lots of chatty feedback if you want it from all the over-the-air FT8 signals received by all the hams out there.
As for notifying me: you just did. Now that at least 2 external people have done a sanity check test on the system, I don’t need notification anymore (just bug reports!). I’ll cross out that request from my earlier message so other people don’t get hung up on it.
Thank-you!! It is great to have testers, including single-radio single-band! Appreciated.
After several test cycles using two different WebSDRs and two different bands, I can definitely send FT8 signals out here and they will be picked up by WSJT-X. Ed @DD5LP has also been helping out and configuring and testing his own setup.
Signals from both of us appear in the WSJT-X Band Activity pane, and several online sotamat skimmers have picked us up so that we appear in the SOTA spots list (apologies to all for cluttering the Spots list with our test signals). But my sotamat skimmer here has failed to register any sotamat messages, despite being connected to WSJT-X, and “Listening for SOTAMAT messages…”, and WSJT-X receiving sotamat-generated messages. And, yes, the VB Cable audio is setup correctly.
Both JWST-X and the sotamat skimmer have been re-started several times, each time as admin. The skimmer doesn’t appear to be working here on this PC Win 10 64-bit, up-to-date.
I’m having a bit more success so far - just ran 2 tests on the 2m band at 144.174 MHz to make sure everything was purely local. Tx was on an FT-817 at 1W in my backyard and rx was my chimney-top 2m/70 cm vertical. Did an email to myself and an SMS to myself; both worked flawlessly the first time. Reduction in latency by not going through PSK Reporter is quite noticeable – I had the incoming SMS chirp on my phone just after it had sent the very first burst of FT8 audio! Will have to try a test spot a bit later but so far, so good!
@DM1CM It looks like you are doing everything right. I’m not sure what the issue is. The fact that WSJT-X is decoding messages shows that your virtual audio cable is working. The SOTAmatWSJTskimmer messages look good (it connected to WSJT-X).
The screen shot is very helpful. Thank-you for including.
I would try the following:
On the SOTAmat web site, change your configuration so that your have 2 or 3 “Testing Email” messages so you can test without spotting to SOTA Watch. These testing emails can be sent to your own email address. You need more than one message since SOTAmat blocks duplicates in a 15 minute window, so if you are doing rapid fire testing you need to send different messages so they don’t get considered as duplicates.
Since you just changed your configuration, remember to reload that configuration into your cell phone SOTAmat app under the “Setup” tab. Always keep them in sync!
When you run the SOTAmatWSJTskimmer program on your computer, add the “-d” command line option for “debug” mode. In this mode you should now see a debug message for every WSJT message decoded even if they aren’t SOTAmat messages. This will test if the connection is working.
Send over the air your new SOTAmat email test message to yourself. Take a screen shot of the message getting decoded in WSJT. It should have a format similar to “S DM1CM/xxxx” where the “S” might be “SM” or “STM” depending on how long a suffix you end up with (the total message is always 13 characters).
Looks like it is working for two testers, and not working for two testers. This is why I needed help testing!
I’m not sure what the cause is yet, but the debug mode will help eliminate some paths.
I had a go with a RPi and whilst the executable launches WSJT and I can pipe audio from a websdr to WSJTX I didn’t see where to add in the username etc properties. So assume that no spots will come through.
Was the intention for linux users to append details to the executable and launch via terminal? Because that’s what I did and it seems to be listening
./SOTAmatWSJTskimmer -c= *** -p=*** -g=***
Tried on a RPi but it coughed presumably because the prebuilt is 64Bit and the OS I have loaded is 32Bit
Hi Brian,
I am seeing a similar result to Rob, however a question - is it possible that while another station is receiving our test transmissions your server is seeing the messages coming from either Rob or my “WSJTxSkimmer” as duplicate records and ignoring them?
I am getting duplicate errors shown on the SOTAMAT website - but none from Rob or my skimmer.
Should the command window display when it sees and processes a SotamÄt packet?
Also, does the skimmer need to run as an administrator under Windows 10?
UPDATE:
With the debug option turned on and running the skimmer as Administrator, I am getting a list of “Message decoded” So far no SOTAMäT messages though.
This is using a WebSDR which “should” hear me as it’s far enough away, however, I’ll see if I can simply set up my normal radio plus a portable tomorrow, to make sure I am heard (i.e. without using a WebSDR) - this should isolate where the issue is.
I just tried an unsuccessful test self-spot using the 6m band on 50.313 MHz- as with my earlier 2m email/SMS tests to minimize the possibility of another station being involved (and also to not have my tx and rx antennas in near-field proximity.) Tx was my FT817 at 5W on a mag loop, rx was a 6m EDZ hung from the house, connected to an FT991A at the WSJT-X end. All transmissions were successfully decoded by WSJT-X and show the right suffix, but were not picked up by the skimmer and as a result did not show up on SOTAWatch as a result. I will turn on de-bug mode and have another go a bit later; interesting that email and SMS worked but spot did not, although the change of bands from 2m ro 6m could also have been a contaminating factor. 73, Ken
Yes, thanks, on my second try the skimmer worked and passed it through fine to SOTAWatch, so good stuff. I’m not sure why it did not work the first time I tried a self-spot a half-hour earlier; there was no change of band, frequency, power, etc. – only that I had turned on the debug parameter in the command line. Mmmm … 73, Ken
.
