Interesting hypothesis about speed. I only looked back 100 spots,
beginning at 0020Z on September 4. I can't discern any pattern, though,
as to speed or signal strength. Steve was sending consistently >30
wpm. Pretty much the same goes for one other "ONxxx" that turned up a
lot during the CWO. Signal strength of the busts was all over the map,
though Steve's are as consistently strong as you might expect.
I used the callsign search feature of the RBN's web site to look for
"*N2IC", which returned the last 100 spots spots for his call and for
the ON variant. There were only 3 ON spots out of the last 100. For
the other similar callsign, there were 9 out of 100 ON2 busts of his N2
call.
Looking at the data, I'm inclined to believe that the "solution" is for
users of RBN spots to make use of the "blacklist callsign" feature
available in N1MM's Available Mults and Qs window. I don't know (yet)
whether blacklisting a spot there by right-clicking on it will also
cause it not to appear in the Bandmap window, but I suspect so.
The second case, where Skimserv thinks you're done sending the callsign
and drops the last letter, may be different. One station (a 1x2 call)
either had his last letter dropped or changed from "P" to "I" 20 times
in his last 100 spots. That suggests that the inter-letter space may be
being misinterpreted as an inter-word space rather than an inter-letter
space. In his case, speed was 28-30 wpm. I'm hopeful of hearing from
him whether he was sending his call by hand, because it seemed by ear as
if he was leaving a slightly longer space before the "I", perhaps for
emphasis. If not, then we may have another case where blacklisting the
busted versions of calls may be the only solution.
73, Pete N4ZR
Check out the new Reverse Beacon Network
web server at <http://beta.reversebeacon.net>.
For spots, please use your favorite
"retail" DX cluster.
On 9/5/2021 1:30 PM, Michael Adams wrote:
[Distribution trimmed; groups I'm not subscribed to removed.]
I just grep'd through the logs from my cluster node. You were mostly spotted
correctly, with a few stray ON2IC's and a couple of N2TC's and N2ICE's in the
mix, so I'd say that it's a demonstration of the challenges of automating
copying code in an HF environment.
One thing I did pick up on was that the error rate increased as your speed
increased. The skimmer spots showed you mostly running around 34 wpm, but you
did pick up the pace a couple of times to 36-38wpm, and when you did, you were
more frequently mis-copied.
Perhaps an argument could be made that those who like to run faster than 30-34
wpm might be well-served to throw an extra half-space around their calls.
Another argument could be made that folks who use skimmer spots need to tweak
their filters to remove some of the busted spots. I'm a firm believer that
optimizing one's spot filters is key to success (or at least maximizing fun)
when operating assisted.
I didn't notice too many busted spots yesterday (I wasn't very active in CWO,
but I do keep SpotCollector running pretty much all the time) because of my
filtering...but my filters do allow uncertain calls from uncommon entities
through. Belgium, the Czech Republic, and Denmark (ON, OK, OW) aren't
uncommon, but I do frequently get alerts for Congo and Corsica (TN, TK) on
Wednesdays during the CWTs.
(I also have my node set to reject spots for about 25 busted calls ending in "CWT" generated by
some CWT regulars whom the skimmers have trouble discerning the final space in "CQ call CWT"
transmissions. I don't think they're necessarily doing anything "wrong"; it's just a constraint on
the technology involved; an annoyance that a tweak on my end avoids.)
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
|