SOTAwatch broken 11/6/19

@vk3arr @MM0FMF

As of 1900z or so, both sotawatches are broken. Sotawatch3 won’t load (seems to be stuck in SSO forwarding), old sotawatch won’t accept new spots directly.

SMS spotting seems to work sometimes? @NR3E and @wG0AT got it to work, but I couldn’t yet.

Listening for calls as I am available and posting spots to DX clusters in the meantime.

Sotamaps states:

If you are spotting NM5S then you need to spot the frequency in MHz not kHz. i.e. it’s 14.061 not 14061

Looks the sso is less than happy.

Much appreciated Andy. I went back and RTFM and realized that mistake as well. Unfortunately only after he stopped calling, but we made our contact.

The man who never made a mistake never made anything; as an old mentor of mine used to say.

1 Like

I have tried to login to sotawatch3 for the firsttime and the web page will not load and on sota mapping project the site is playing up its slow and not loading and the list of the summits in the region is not showing up on the left .If you click a summit ref for more info a proxy server error comes up also .

Anyone else having issues ?

Matt 2E0FGX

The only page that is working well is the reflector to me … 502 proxy error comes up


One of the SSO servers got into a bind and needed rebooting. This would have impacted about half of the queries to it, so this would be intermittent

Thanks for the fix Andrew! It seemed odd that the SMS gateway spots made it through, but RBNHole did not. Is there the possibility in the future of routing RBNHole (and the APRS gateway, which was also broken) through the same side door that SMS gets to use, so they wouldn’t break should this scenario happen again?

Your description of the SSO configuration makes it sound like “reload lots of times” might have been a valid workaround, although I’d never encourage that for any server that is already having issues. :slight_smile:

Andy took action a few weeks back to update his SMS gateway to use the new API. I started the work on that for RBNHole last night. The catch with RBNHole is the fact that the summit checking code in the API has to be disabled, as people use RBNHole with catch-all (but technically invalid) summit IDs, like “VK3/VC-???” if they aren’t sure what order or access they have to summits.

When that work is completed (later today?) RBNHole will not be impacted, but until Jon and I can coordinate on how to disable the summit checking for RBNHole (we know how, we just need to work out when), that particular feature may be missing.

I’m not often ahead of the game so I shall revel in this moment. :sunny:


RBNHole is now using the API to spot, which means that wildcard spotting won’t be available until Jon and I sort out the endpoint mentioned above. However, we’re no longer dependent on spotLite (and now dependent on SSO :slight_smile: )

I posted alerts today for W6/NC-008 and W6/CC-011. RBN copied my signal (I checked the RBN site). But — SOTAWatch did not convert the RBN data to SPOTS. The Alerts/RBN/Spots tool has been a great asset when activating remote peaks.

Question when Alerts/RBN/Spots tool is not working would spotting using APRS be successful?

My guess is that the various updates going on have created a temporary issue and that all will be resolved when the updates are completed.

2M FM saved the day and I was able to get 4-6 QSO’s on each summit!

See my post above

Yes, thank you! I should have read all before posting - My problem was not mine (whew) and all will be well! Time to plan the next trip!!!

Wildcard spotting is now back.