Spotting frequency errors

The issue of how activators and chasers enter frequencies of spots was raised by an MT Member some weeks ago. Despite this the problem seems to be worsening.

Entering frequencies in KHz when they should be entered in MHz completely spoils the SOTA DX Cluster representation of the frequency on which you are transmitting. Take for instance what I see again this morning:

ScreenHunter 466

Out of 23 spots 5 are corrupted, these errors render CAT control of a transceiver unusable.

73 Phil G4OBK

How and where are the wrong frequencoes being posted ?

Can the system accepting these spots not be fixed to either not to post the spot (with a suitable error message) or if it can determine from the information given that the number 1,000 or 1,000,000 times bigger than it should be correct it before allowing the spot ?

HI Stewart

I know they can be wrongly posted using SOTA Spotter as I did it myself last week - I promptly deleted the spot and re-entered it in MHz. Maybe it is possible using other apps also. It is also possible to enter KHz into SOTAWatch using PC browser - just sent test spot 14200 without decimal point indicating MHz and it was accepted no problem and displayed erroneosly as 14200000.0 rather than 14.200.

73 Phil

You should have marked it as a test spot, Phil, I bet there are chasers searching for this mythical dv activation right now!

Thought I had done an instant delete, check a few mins later and realised I hadn’t. Sorry about that Brian, my mistake.

73 Phil

I’ll set the pattern regex that validates the frequency to require a decimal point and set the backend API to do some sanity checking, but it won’t pick up a misplaced 30m spot that thinks it’s a 3cm spot. Give me a day or two


Thanks for info, Andrew.

A question from an attentive activator on this: Does a user of a 3rd party app using the API gets back then an error message from his 3rd party app that his frequency entered is not valid, or have the 3rd party apps to introduce a new error message handling as soon as you realize this “.” update? It could happen that he gets an “OK/spotted” form his app (or at least no error message) but the spot is not sent to the network all the same because the API had rejected it.

Tnx in advance and vy 73 de Markus, HB9DIZ

Yes they will. Whether they do anything with it remains up to them, of course.

Thanks for clarifying. Hoping here that they will do so, hi. E.g. Sotlas already offers a “.” check, with a gentle comment where I was failing.

73, Markus

Within VK port-a-log unexpected API error messages are displayed to the user when received. Expected error messages, such as server timeout due to poor Internet coverage, are not shown.

I’ve just pushed a fix for this. In the end, I kept the regex the same and instead placed some logic on the API end. Basically, any frequency less than 1000 is assumed to be OK and in MHz. Anything above that is tested for being within boundaries of amateur bands. There is overlap with 60m and 6cm and 30m and 3cm. The rest should be OK, and the API returns a message of “Invalid frequency - perhaps try MHz?”

1 Like

Almost there many thanks - SOTAWatch will still accept 10118 (SHOULD BE 10.118) but the fix works for the other popular freqs that get messed up such as 14285 (14.285) 7032 (7.0320) ETC and they are rejected.

Phil G4OBK

1 Like

Can’t do anything about that, especially with Andy ordering in some 3cm gear and going to want to be spotting 10GHz spots :slight_smile:


Sure we can live with the 10 MHz and 5 MHz situation Andrew now that you have covered the money bands.

All the best and stay safe

Thanks @VK3ARR - it does as you say and this app behaves as expected - no new code needed :slight_smile:



I’ve also, for good measure, just pushed a build that includes checks on summit code and association codes for Spots and Alerts. The summit code check will allow wildcard (??? or XXX) numbers and region codes for those on their multi-day shenanigans. The association code check is simpler - just requiring up to 3 characters.


@MM0FMF Andy, I guess the “deactivated” accounts are reactivated?

Would it be an option to add a “divide by 1000” operation after the failed band check and retest against the band limits. If both fail then ignore spot otherwise place spot in MHz? (Maybe append to comment: QRG corrected by system)

73 Joe

To the best of my knowledge, no one ended up being deactivated.

I’m always a bit sceptical about overly massaging user input (as opposed to accepting a broad range of inputs but not modifying what comes in). In any case, the error message serves a training purpose :slight_smile: