> > One concern about the possibility of new Precedence indicator. -
> > If I decide in the
> > eleventh hour to turn on the packet to find the missing VE8, and
> > change my prec, I may
> > hose up the log checkers. Some thought should be given to this
> > potential problem.
> Seems similar to the guy who, after 24 hours, decides to turn on the
> amp and goes from A to B. What happens then?
Or another example - a multi op where the operators use their actual
check.
All of these problems were encountered during the checking process of
the '98 Sweepstakes. The solution was to detect "unstability" in the
information and when the information isn't stable enough, not use it
during the checking process.
For '99, I am hoping to improve the ability of the software to detect
patterns in unstable information and be able to still do checking if
a strong case can be made that the pattern is understood. For
example, if someone is logged as sending "A" for their precedence
for 99 percent of their QSOs under QSO number 500, and then is found
sending "U" for 99 percent of the QSOs after 500, then I could still
use that in the checking process.
Obviously this adds a lot of complexity to the program and it would
be "nicer" if everyone would just send the same thing for the whole
contest... but the real world situation isn't that black and white.
There were about 500 unstable stations in the SSB database. Most of
these were guys that showed up in a small number of logs (less than
five) and one of them exchanges was different than the rest.
However, about 50 of them were cases where patterns were seen to
indicate the sent information was being changed. For example, I
saw things like this:
Checks received for WB6ZVC:
63 63 63 63 79 63 63 63 63 79 63 63 73 63 63 63 79 63 63 63 63 63 63 63
63 63 79 63 63 63 ...
So - would you say the 79's were errors? Probably not. In this case,
the program will probably say that 79 or 63 is okay, but the 73 isn't.
Another pattern I see a lot is something like this:
Precedences received from WA6TUT:
B B B B B B B B Q B B B B B B B B B A B B B B B B B B B B B B B B B
A A A A A A A A A A A Q A A A A A A A A A B A A A A A A A A A A A A
In this case, it would be nifty if the program could bust both of the
Qs, and the first A and last B.
In average, there will be a 5 percent error rate in the information
received. As long as the detected errors fall into that range, I think
the process is working.
If the error rate for a specific station gets too high, I start to look
at putting it into the unstable category. It has been interesting to
see that some QRP stations suffer from higher error rates on the information
received by other stations than high power stations. This could almost
be a tool to verify compliance with the maximum power levels!!
Back to net.
Tree (aka. They) N6TR
n6tr@contesting.com
--
CQ-Contest on WWW: http://www.contesting.com/_cq-contest/
Administrative requests: cq-contest-REQUEST@contesting.com
|