Until now, it was possible to enter also invalid S2S QSOs into the SOTA database, e.g., between activators at the same SOTA summit (intra-AZ QSOs) and S2S QSOs with oneself (erroneously or intentionally).
In such cases, the distance is correctly reported as 0 km.
At first glance, such incorrect entries have increased over the year (many new SOTA enthusiasts, overzealous point hunters?).
Hence the demand for a simple S2S distance check and rejection of a DB entry if the distance is 0 km.
With my post, I just wanted to point out the following facts
According to the requirements, a SOTA s2s QSO is defined as a QSO between two activators in the AZ at two different SOTA summits
When uploading an activator log, the SOTA database unfortunately also accepts and honors s2s QSOs where both activators are at the same SOTA summit (identical summit ID).
The same applies if an activator logs an s2s QSO with themselves (identical summit, chaser, and activator IDs).
This weakness in the verification of activator logs appears to be exploited during joint activations to reward themselves with activator points, as well as s2s, unique, and complete points.
Quo vadis fairness?
BTW, I’m not a watchdog when it comes to SOTA, nor would I have any desire to be one, hi.
But it was and remains my principle to address the root cause of the error, not the resulting symptoms.
Perhaps Andy@MM0FMF could take another look to see if these gaps in the verification of activator logs can be eliminated with reasonable effort.
As Andrew says it just needs a rejection if the chased and activated summits are the same. That makes logs compliant with the rules.
There will be some people claiming S2S with other activators in the same AZ because they have never read the rules. Not cheating really, just a failure to understand the rules.
Where there is an issue is people claiming an activation and chase of the same summit as they activated it with someone else. Now it’s legal and I have some completions like that because the summit is activated so infrequently. I’m eager to chase those summits “properly” when I get the chance and delete the older contrived completion chase.
Whilst this is in the rules, it amazes me how many make such a pigs ear of the logging. Or better stated, they’re not smart enough to cheat at something so simple that their logs stick out a mile. We know the summit height, we know the AZ start so if people need to do this contrived completion they need to have one person 5m above the AZ start and the other 5m below to ensure errors in GPS accuracy can be taken out of the situation. A quick QSO, swap positions and another and it’s all done and legal.
But that is too hard so they make up the logs and don’t do a very good job of that. It is so obvious to anyone paying attention that there’s funny business occurring and you be surprised how many people scrutinise other’s logs. I have a list of people doing what look like dodgy completions/chases just waiting for when they claim awards
So a check on chased summit = activated summit is all that is needed.
which is an immediate assumption that cheating must be occurring which I can see is not true from looking at the logs. There are not that many entries in the database that meet the criteria of S2S with the same summit. Of those, I would estimate that 90%+ of them have the situation that the activator has had an S2S with every single chaser that worked him on that activation. That’s unlikely, because you can’t fit 30+ people in some activation zones.
That’s not “exploiting[…] to reward”, that’s just a genuine confusion between SOTA_REF and MY_SOTA_REF in ADIFs, or logging your own SOTA summit in the comments and not realising that in an FLE file that is interpreted as a S2S, or putting the summit ID in the wrong column in the activator log entry page.
And, because you only get summit points once per day for S2S, the average number of points that each QSO gets is around 1, which is hardly having a major impact on the scoring, for less than 1 in a 1000 S2S entries.
Now, we’ll fix the bug - I’ve already got the patch building - but there needs to be a reality check that:
SOTA is easily one of the most self-policing organisations in ham radio. People go out of their way to do things the right way, or correct issues that come up, and don’t exploit loopholes willy-nilly.
The vast, vast, vast 99.9999% majority of issues that are ever raised to us as cheating are actually just a logging error on behalf of whoever.
Perhaps he could, but he’s just going to pass it to me
