Strange behavior with SOTAwatch3

This afternoon, I did an easy activation along with an experiment for 160m that I wanted to do on Saturday night, but forgot some stuff at home.

SOTAwatch worked fine for me until about 14:23 UTC.
Probably at 14:47 UTC, I tried to spot on 1.92 SSB, then on 1.942 SSB but didn’t see my spot on the SOTA Spotter or VK port-a-log app (both Android 10) and neither on SOTAwatch3 using the latest Chrome under Android 10. I tried it several times (with different comments) to no avail, and later I realized that for some clients, my spots were readable, but not for mine, so please accept my apologies for spamming SOTAwatch with redundant spots.
A friend of mine, who used an iPhone SE (assuming he used Safari) finally could see my spots, but refreshing the page or the apps didn’t still work for me.
Now back home I can see them on SOTAwatch3 using the latest Chrome browser under Win10, albeit not all. E.g. a spot that I sent at 14:23 UTC for 5360 SSB shows as 1942 SSB.
On Android 10 using latest Chrome, I now still don’t see my spots after 14:23 UTC on the mobile representation of SOTAwatch3. To me there seems also a problem with the API, since otherwise, the two above mentioned apps would have worked…

73 Stephan

Hi Stephan,

You never know what will happen on the summit.
So it is sometimes good to have two systems together, and even better if they are supported by different operators.
I try to send spots via VK-port a log (Android on tablet) but I also have Outd log on an iPhone powered by different operator.
Anyway, something will work :wink:

73, Jarek

Hi Jarek,

True, but it still happens now, with exactly the same settings on the mobile, as well as on the desktop, both are the lastest Chrome browsers (Android 10 vs. Win10).

Desktop screenshot:

Mobile screenshot:

I still believe the error is 30cm in front of the screen :wink: but why did VK port-a-log and neither SOTA spotter show the spots?

73 Stephan

May be it is time to check with the Edge Stephan :wink:

73, Jarek

Hi Jarek,

Thanks for your suggestion, but I wanted to make other hams aware of such strange behavior, by repeating and using the most used mobile browser under Android.

As I stated in my first message, the UI problem was not shown with another browser on another OS at this moment. I also didn’t see this effect later on with Firefox mobile.

If you compare closely the two screenshots above that were taken yesterday at the same time, with the page freshly reloaded, you’ll also see that another activator is not shown on the mobile browser:

14:08 HB9IQL/P on HB/SG-046 24.950 ssb

I saw this strange SOTAwatch UI behavior on the mobile device, after I sent my spot with VK port-a-log, which didn’t show my spot and neither the SOTA Spotter app.
So I tried to send it again, by using both the logging app and SOTAwatch3, which didn’t help, but instead spammed SOTAwatch.

Since nobody else seems to have similar problems, I assume that I was just unlucky at this moment, e.g. I had for a quick moment, during the data was received, a network glitch, although the 4G signal looked pretty good to me.

I can only speculate about the exact UI mismatch reason. Maybe the not complete entries were cached and only a force-reload of the page or clearing the mobile browser cache would have helped.

Anyways, next time when I encounter a similar behavior, I will go to the system settings and clear the cache of at least the browser app, since force-reload doesn’t exist on mobile browsers and just reloading the page seems not really to refresh the page. Most likely, this might be intended, to save bandwidth and CPU cycles on the server side.

73 Stephan

No, it’s because the front end is all JavaScript so it runs client side. In fact, once you’ve accessed SOTAwatch there’s no accessing the server again until you do a forced reload.

The API, which supplies the spots to you, is what determines what is displayed. It’s highly unlikely that if one client is seeing the spots and another isn’t, that it is an API issue.

I’d clear cache and cookies and do a full reload, or try via private browsing/incognito if you see it again, which will confirm if it’s cache or not

Thanks Andrew for explaining the front end!

I will definitely clear the browser app cache, the next time I encounter this behavior, since a full reload on a mobile device is not possible afaik (like CTRL-F5 for Chrome desktop) and private browsing makes sense to only read the spots.

One thing that I’m still not clear about is why the two other apps, that are completely independent of the browser, showed a similar behavior, i.e. not showing my spots.

73 Stephan


During this strange spotting behavior, I somehow managed to chase myself (HB9EAJ chased HB9EAJ/P).

Screenshot of SOTA Database

Screenshot of SOTA Database

I re-checked my submitted log (combined CSV from VK port-a-log with 31 entries), but it looks perfectly fine and I can’t see a chase entry to myself in it.

I intentionally activated this summit not to gain points, but doing some experiments, so I’m aware that I got 0 points, because I activated this summit this year already.

Usually I’m good at finding mistakes of others, but not my own :wink: so any input what I might have done wrong would be helpful for the future!

Looks like an automatic database task that cause “something” ? Or are you uploading at 02:50 in the morning?

I had a similar effect and Andy took care @MM0FMF

73 Joe

Hi Joe,

Thanks for your feedback, good to know that I’m not the only one, at least with the ghost upload :grinning:

But I think the time is not UTC, since I didn’t upload the CSV at 5.59 UTC neither, but 5:59 PM UTC could be possible…

73 Stephan

I’ll be out most of this morning then I’ve got a diabetic clinic at hospital at lunchtime, my 1st since all the Covid restrictions started so I want to be in and out of there ASAP and avoid everyone else! I’ll have a look this afternoon as I have an ADIF issue to look at. Can you mail me the CSV at mm0fmf AT please Stephan?

This has been caused by clicking on the “Log Spot” button, and I can see by the logs that it was done by you (or someone logged in as you), using a mobile Safari client. On clicking on this you should be shown a dialog box to approve it, then the logging will occur. Of course, this might have been a “pocket log” or something where you didn’t realise you’d uploaded the chase. Both occured at 14:50 and 14:55 respectively (2:50pm, 2:55pm).

I wonder if the modal dialog box was up and this meant that spots weren’t updating in the interim? (doesn’t explain VK p-a-l not updating though)

The wrong times on the upload page are a bug (only the 12 hour time is stored, not the 24 hour time, and I missed it because I’m not generally doing SOTA testing later than 12:00 UTC) and this is now fixed (for future uploads).

No worries Andy, take your time, it’s definitely not urgent, just strange…
I’ll email the CSV to you.

Take care and 73 Stephan

Stephan maybe you were logging instead of spotting?
The dialog has similar elements.

That would explain that spots were not created…

73 Joe

Good point Joe, everything is possible.
Since it was very sunny and therefore deciphering the screen is sometimes not that easy!
Moreover, I tried it several times, both with the VK-port-a-log app, as well as with SOTAwatch3 and switching forth and back may introduce entry errors.

73 Stephan

Hi Andrew,

Thanks a lot for your feedback and sorry, I missed your comment.

The unintentional chase entry, e.g. by “fat fingers” is very well possible, as Joe OE5JFE also pointed out.

I just checked my mobile user-agent (Chrome on Android 10) and it also contains ‘Safari’ in it, so it makes sense.
I say that, because a friend with his iOS device using Safari was checking it as well, but he has no account and therefore couldn’t submit anything.

Anyways, this doesn’t explain why the spots were not shown, also independently by the apps.
Maybe a combination of network and caching problem, maybe even the cache in the two apps was faulty, which is unlikely but still possible.

Being on a summit, even an easy one, one has not always good ideas in solving error conditions. But now, I found a debug strategy to hunt down the missing spots in the future. I could have also tried APRS, but if I don’t have to, I try to avoid it, since the UI on the FT2D is really not that great…

Thanks again for your support and fixing the 12/24h upload time format!

73 Stephan

Is that the more polite version of bum dialling? :slight_smile:

Anyway, one less to fix and it could be your 12/24 fix will fix the ADIF I’m about to look at.

1 Like

I doubt it - given where it was - but there’s always a distinct possibility there’s another bug :slight_smile: