I’ve sent a test which works with Ubuntu but I failed to add in the correct note to please ignore. I thought I had but I hadn’t.
I guess this could be a bit more idiot (by that I mean me) proof
@G7KSE Alex,
Yes, it will only run on 64-bit OS on all platforms.
Yes, on Linux you need to provide command line parameters, and the easiest way to test would be in a terminal window and type the parameters on the command line. The exceptions are that your callsign, password, and gridsquare (the required parameters) may be optionally defined by environment variables rather than command line parameters. I use that approach since I don’t want my developer project file to have my password in GitHub!
If it says “Connected to WSJT-X…” then that is good! If it gets that far I’m perplexed why it doesn’t work. Try with the Debug option.
AB6D
Note: it should be easy to make a 32-bit build. If you are a developer the code is on GitHub, if not, I’ll try to make you one soon.
Windows based testers having issues:
If you see all the reception reports stream in inside the SOTAmatWSJTskimmer app window when using the “-d” debug mode, but your own SOTAmat messages don’t get sent to the SOTAmat server: it could be a firewall issue. When you run the first time Windows will ask if the app should be enabled to run on the local network or the public network. You likely need to enable both since it talks to WSJT-X locally and talks to the SOTAmat server in the public internet. By default Windows only enables the local network and you might need to enable both.
I’m not sure about this. I thought the firewall rules applied only to inbound connections and my SOTAmatWSJTskimmer app only makes outbound connections. But maybe Windows firewall protects both directions. When I got the Windows Firewall dialog I enabled both public and private. That might explain why it works for some of us but not others!
I have to research this. You can try changing that setting if you can figure out how.
I really appreciate the time you are donating. We’ll polish these rough edges as we learn.
-AB6D Brian
1 Like
It didn’t work without the “-d” switch but did with it? Hmmm. I don’t think that would make a difference.
Are you sure WSJT-X saw the SOTAmat spot, and that the SOTAmatWSJTskimmer app didn’t print a message saying it saw a candidate message?
One way I test is to configure WSJT-X to use my computer microphone. I use the mobile app to play the sound in the room. Once testing shows that path works, I then add in the radio or the over the web WebSDR stuff and only then test with real RF.
-Brian
2 Likes
It didn’t bring up the firewall question with me Brian.
It did have the usual warnings where one has to keep / run anyway etc. that come from any App that hasn’t paid for a Microsoft key as far as I understand it.
In my case, in the debug display, my callsign did not come up - but I think this could be a webSDR issue - so let me set up my private “on-air” scenario with two rigs tomorrow and see if that works. If it does, then we’re close.
73 Ed DD5LP.
1 Like
I noticed one other issue. At least some of @DD5LP ‘s SOTAmat spots were for a frequency of 7.000MHz which is not a legal/allowed frequency by SOTA Watch and will create a server side error when the SOTAmat server connects to the SOTA Watch API.
That might be intended since we are not trying to test the last leg of the communication and mainly trying to test the path from WSJT to the skimmer plugin to the SOTAmat server.
You can see those 7.000 MHz spots on the SOTAmat activity web page, but not on SOTA Watch. So if you were not looking at the Activity page you might not know that your messages were received and recorded.
Brian
1 Like
Ed, before bothering with 2 rigs, I’d try to get it working with straight audio from the mobile app to your laptop’s microphone into WSJT-X. Once that path is working all the way to the server , we can expand into trying RF. It is quicker to run many tests that way.
Brian
1 Like
Hi Brian, use of band end (e.g. 7000) with Mode OTHER and TEST IGNORE in the Spot has been common practice for a number of years with SOTAWatch - these spots are not blocked and chasers see that they can’t be real spots straight away.
73 Ed.
1 Like
Thanks Ed. That makes sense. I see it worked for you. I do know that I’ve seen an API error on a band edge before. It might have been a different mode. So yes your screen shot shows band edge works and yes I’m certain I helped another user when a band edge was causing an API error.
It might work for OTHER and fail for SSB. ??? More exploration needed.
-Brian
1 Like
At the moment, my suspicion is simple propagation and location of the WebSDRs that I have been trying to use. We know the App is sending the correct messages as it is getting into SOTAMat via RF from other monitoring stations, hence picking my own frequency away from the normal FT8 frequencies to do a local RF test will exclude the other stations from the equation as they won’t be listening on my frequency.
Did you see that one of the stations that picked up the 40m test at 1700 UTc was in ZL - weird for that time of day - the band must be long and hence (possibly) my issue with WebSDRs not hearing me when other stations are.
OK - enough for today - Good night all.
73 Ed.
2 Likes
Well as Other is upper side band (or it can be - other is normally data and data is normally USB) - hence 7000 kHz is a “valid” frequency whereas SSB on 40m is normally LSB and that would mean operating on 7000 kHz as a dial frequency, the station would be operating out of band. This would be logical to be blocked.
73 Ed.
I agree that the presence or absence of the -d command should have nothing to do with it. Latest try on 6m I once again got clean decodes on WSJT-X and the skimmer recognized it as a SOTAMat message, but the server returned a failure code about a missing paramater, “missing delta time” - screenshot attached. Same thing happened when I used the computer mic as the input source rather than RF. Now I’m confused. never saw this on previous failed spot tests … does this just mean my phone has wandered too far out of time sync? (The computer should be bang on, I’m using Dimension 4.)
1 Like
Hi Ken,
On my (Android) phone I use the ClockSync App which tells me how far off I am and then I give that value (rounded) e.g -0.4 using the “FT8 device time correction” slider in the lower part of the settings page of SOTAmÄt.
The Gotchya can be that once you have set this value, it sticks and the next time, you use SOTAMÄT your phone might be off by +0.7s - and if you don’t correct the value in settings - you could be off (in this example) by 1.1s and that will give issues.
The error message you are getting sounds like there is no correction set - which in itself should not be an issue but I guess the logic has somehow realised you are off-sync.
73 Ed.
1 Like
Hi Brian,
OK, did that, and also used the PC microphone to “send” FT8 to WSJT-X - both worked well, but
there seems to be a problem with my login authentication. This doesn’t come as a surprise since, at least 1/2 hour before conducting this test, I’d asked in the sotamat main site for a new password … however, it seems that part of your site doesn’t appear to be working, since I have until now not received any reply to that request
BUT - see EDIT below…
So, some progress has been achieved here so far. NOT using the -d flag, also results in a successful decode, but seems to take a little longer.
HTH, Rob
EDIT: OK, my mistake with the authentication login password - I was using “p=sotamat” in the skimmer shortcut properties string instead of “p=MYREALLOGINPASSWORD”. I’d set it to the former just as a placeholder, and then forgot to change it.
- it’s now working here with me, using the PC mic + smartphone sotamat app as FT8 message generator;
- also working here now via radio + radio mic + app + WebSDR at Maasbree, Netherlands;
- also working here now via radio + radio mic + app + KiwiSDR at Alberschwende, Austria.
Rob
1 Like
After my previously successful test, by using two HF radios and sending a test spot, yesterday evening, I gave it another try.
This time, I tested it by using a WebSDR along with a virtual audio device and sending out a predefined email message.
Short version: It was working!
The longer version: This time it wasn’t that quick 'n easy, I needed several attempts.
I don’t think it’s software related at all, but because of the current (bad) propagation.
The WebSDR I used for my experiments was Twente, which is about 520 km away from my home QTH and one of the most used in Europe.
First I tried it on 40m, where my signal was decoded by other stations, but not received in Twente. Today, looking at the archive of PropQuest, I think I know why it didn’t work on 40m. I suspect the pretty low F2@500km MUF of about 6.5 MHz at this time was the culprit. The MUF was measured at Dourbes, which is somewhere between my QTH and Twente, so it should be pretty accurate.
After two unsuccessful attempts (separated by more than 15 Minutes), I gave 80m a try and this seemed to do the trick, albeit only with an SNR of -16dB (see above). Moreover, I was only decoded once out of four redundant FT8 transmissions. Of course, my compromised antenna also plays an important role.
As noted by others, this WSJT-X plugin solution is extremely quick, compared by using the PSK Reporter route (that may take up to five minutes alone), it’s almost instantaneously.
BTW: Because of this (sometimes) long PSK Reporter delays, last Saturday I was spotted at the same time on the same 20m frequency as another activator. Such conflicts are seldom but they can happen, especially if the time from sending the spot until it is distributed takes some time.
Conclusion: Two of two tests using this WSJT-X plugin worked, both with different setups. I call that a success! Moreover, it’s not always the software fault when something doesn’t work as expected.
73 Stephan
2 Likes
Update from here, is that I have the email feature working but not yet via my skimmer:
I have tried using the QRP radio into a dummy load and the home station receiving directly - although I can hear myself fine on the IC7300 when using the G106 - what is being sent is not being decoded by my instance of WSJT-x. Putting the G106 onto the main antenna and the IC-7300 onto another antenna just for receive - I still don’t decode my own signal (however someone else does do).
Apart from the UDP settings, is there anything else to change in WSJTx? I am using version 2.6.1.
I’m going to turn the timing correction off in the Sotamät app to see if that is part of my problem.
Ed.
UPDATE:
Now working to WSJTx
and decoded by the skimmer:
But its still other stations who are posting the reception back to the SOTAMAT server -
No errors shown from the skimmer but also no message to say it has transferred anything - should it give some kind of message in debug mode when it transfers a received SOTAMÄT FT8 transmission direct to the SOTAMAT server?
2 Likes
Hi Ed,
Yes - as in this example:
…
Message decoded: CQ PD0SHP JO12
Message decoded: CQ OZ6CM JO55
Message decoded: CQ HB9EKJ JN47
Message decoded: STM DM1CM/24H
SOTAmat Message Received! Sending to SOTAmat Server: STM DM1CM/24H
Message decoded: S57W DL3BAG R+03
Message decoded: CQ EA1C IN82
Message decoded: CQ DG1IU JN49
Message decoded: CQ OO0Q JO11
…
Cheers, Rob
1 Like
Hi Ed,
I’m also using WSJT-X 2.6.1 on Win10 64bit.
About the time correction: this could be a corner case against your WSJT-X, but working with other skimmers.
Make sure you set the time correction to the opposite value than indicated against the standard clock time difference. E.g. if the time on your smartphone is -2 seconds (2 seconds behind), set it to +2 seconds in the SOTAmat app.
73 Stephan
1 Like
Is there no way for an app to access the GPS raw data on Android/iOS. This should have a precise datetime ?
1 Like
I use the AtomicClock app on my Android phone to keep the phone clock synchronized. At least that’s what I believe it to do, and I’ve had no problems sending FT8 audio messages out on time…