Noticed that the confirmed check box is missing from the Chaser Log options. I find it useful to verify whether my entry coincides with a given activators log. Is this permanent or hopefully, a temporary omission?
In the past it was mentioned that some information in the database was being “massaged” to be whatever was necessary to get confirmation status for every logged contact. The integrity of the data was being sacrificed just to achieve a confirmation.
That was not appreciated by the database manager, and a general “warning” was put out to stop it. Eliminating the confirmation indications was a very real possibility, but several users came to its defense. It survived that round.
Then another seemingly unrelated discussion was started. It eventually evolved to include confirmations.
READ ALL OF THIS
The notification that it was going to be turned off comes up near the end of the discussion. I would not hold my breath waiting for it to come back, but who knows. I personally don’t miss it or care. I track my own confirmations. Running a little better than 80%, and it would be a little bit higher except for a few early /P snafus.
Mike, it’s been disabled whilst its future is considered.
It was always a bit hit and miss in how it worked and was not that much of a QSL indication. For a start it ignores the time, mode and band of the QSO. It essentially boiled down to see if the chaser call was in the activator’s log for the same summit. Now there is a big issue and it comes from the fact that the SOTA DB only contains the information needed for the awards manager to issue awards. It’s not a replacement for your own log, be that paper or computerised. It was never designed to be a general amateur log for users but a log of SOTA activities. It omits stuff that full blown logs do support. Couple that with some of the SOTA rules which are left vague by the MT because the MT feel a vague rule can be better than an extremely precise rule and you get a recurrent problem situation.
An example of a deliberately vague rule is the statement “the final ascent must be person powered”. Many times people have asked for a definition of how much, how far, how long for that statement. We don’t have one for the simple reason it depends on who is doing the ascent. If we said last 50m of vertical height gained must be done unaided then we exclude and number of less-able bodied people. We would need a plethora of rules then for people with heart conditions who can walk a few hundred metres unaided, or people with arthritis, or degrees of muscle impairment. Instead we expect people to do their best such their peers would not think they were slacking. For very fit people, we expect to you to do lots of effort. I can understand that some people would much rather have a specific rule but that pushes a never ending rule writing task on to the MT.
Another vague rule is how long an activation is. We can tell you the rules that matter, we can tell you that you need 4 QSOs to be able to claim points, we can tell you that you can only activate a summit once/year for points and once/year for bonus points. I can tell you the DB wont let you enter 2 activations for the same summit the same day. (I think perhaps it should and score one of them as zero points but the current code is plain and simple and doesn’t allow it.) But we can’t tell you how long an activation is because we don’t define it. We do know you cannot do two activations at once. I don’t think it matters that there is no definition, as such, of the length.
The database takes the view the activation starts on the day you tell it and the activation ends when you tell the database you have no more QSOs for that activation. The database doesn’t know the date the activation ends. Before you get to enter the data, there is a check you haven’t claimed this summit for the day already and you get to enter data if you have no claim for the summit on this day. The database doesn’t store the time and date of each QSO, it stores a summary (summit, activator callsign, an ID number for this activation and some points info) and then it stores the QSO (chase call, band, mode, time, comments and an ID for the QSO). In addition it links all the QSOs to the activation summary. If you enter manually, when you have decided you have entered the all the QSOs you click the button to say all done. The database app then checks you have enough QSOs and works out the points etc. For uploads, there are rules on the uploading page that explain how to place multiple activations in a file. If there is one activation in the file then the activation ends when there is no more data.
Why doesn’t the database store the data for each QSO? Well the original author didn’t see the need and I can agree with that. The data stored is enough to score for awards and run the honour rolls etc. Yes, there can be a fuzziness in the date for places where you were active when the time changed from 2359UTC to 0000UTC. Does this preclude any of what SOTA is about? I don’t think so. What it does do is make difficult for an activator to pull down their activation log from the database and import that to their logging software. I think 99.99% of activators will be entering QSOs into their logging software and exporting the logs for upload, i.e. the other way round.
For activators and chasers where activations occur when the UTC date changes is does cause confusion at first. Do they need to log 2 activations for before and after the date change? No, it doesn’t affect honour rolls or awards if they enter one log and that is the preferred way as activation statistics reflect what is happening. A chaser who logs a chase after UTC date change will enter the current date and that would be one day on from the date the activation started. In this case no star is awarded. If the activator logs 2 activations then the chaser will get a star. Logging multiple activations to accommodate a date change that is ignored does skew statistics in making some associations look busier than they are. Not a massive issue but something that needs considering when looking at overall activity levels. There is no advantage to an activator of doing that other than chasers are more likely to get a star that has already been described to be of limited accuracy.
Now I could change the schema for the database to save a date for each QSO. It hardly adds much more data. I could rewrite just about all the activation code to handle the extra data, uploading, manual entering and the log exporting functions. I would need to process all 217000 activations to try to interpolate existing QSOs to fill in the missing dates. I also have to handle both new and old formats at the same time as plenty of people have a flow for working with the database as is. A lot of work that gains the MT no advantage and most activators little if any advantage. Perhaps I’d get less abuse for fixing this issue! A lot work for no obvious benefit. Other than chasers get the star without the activator logging 2 activations.
The MT have discussed improving this many times with all sorts of plans for better checking and background tasks that do rigorous matchings so as not to affect normal loging etc. We decided large amounts of effort had no real gain so we should either turn it off or leave it and accept it was a bit pish.
The downside to the lower accuracy is log massaging. Or the gerrymandering of logs so that stars appear. Such as being aware there is a date issue so the chaser logs the QSO on the wrong date just to get the star. Or when an activator has used some callsign variation during an activation (for perfectly valid reasons) and because they can only log one activation cannot reflect the callsign change. That results in some chasers logging the wrong callsign to get the star. What we have then is people deliberately logging the wrong data to get an indication they have logged the data that matches! I know that is wrong and you know that is wrong and they know it too. But they do it.
So by turning off the star, it takes away the reason for people logging the wrong data on purpose. There is no benefit to logging multiple activations as nobody gets the star and chasers can now log what they heard/worked not what gives them the star. It punishes all the meticulous chasers however. Something I accept. These people used the star to find their logging errors which they could fix and not to get a star at any cost.
I think that something that works the way the activator log “show who chased me” function works is better. It can be a “show the activator logs I appear in” function that shows all the activations the chaser has been logged in recently
I did have a play to make the current star code run in strict mode and loose mode. I couldn’t tell whether it worked because so many people where this date change is prevalent are still entering multiple logs. What is annoying is that no matter how many times I explain the stars are not used, no matter how many times I explain the logging is not a replacement for a personal logs, no matter how many times I tell people the lack of stars does not indicate suspicious operation, people complain about the missing star from their log. When they are told not to worry I get emails telling me I’m wrong and don’t know what I’m doing.
2 Likes
I appreciate the background information. As a very new SOTA participant (3 mos) I wasn’t aware of the issues involved. Thank you for the reply and thanks very much for all the effort it takes to keep the system running. Confirmation is/was a great feature, but as you mention, not essential. Hope that someday it can be resolved.
1 Like
Thankyou Andy,
This explanation answers the question I posted in the other thread about how date and times are worked out.
It makes sense too with only the “header” storing the date and all detail being assumed to be that date.
There is little benefit to the activator for date/time being stored against each contact apart from the dec 31st/jan 1st rollover where an activator would need to submit 2 logs if making distinct activations. For all other dates the activator can just submit 1 log even if making 2 activations of same summit.
And now with the removal of the * system makes even more sense.
Activators and chasers should log what they hear not what it should have been. Activators can be forgiven for writing things down incorrectly with cold hands or on wet paper and their logging errors should be forgiven.
Ian
G7ADF
Whatever else the confirmation was or was not good for, it helped to see whether you entered your data correctly. It’s easy to hit a wrong key and end up with a wrong date, time, or callsign. Of course, that requires at least one of the two log records to be correct …