[CQ-Contest] Mobile operation uploads to LOTW

Michael Coslo mjc5 at psu.edu
Thu May 7 05:29:31 PDT 2009


On May 6, 2009, at 7:18 PM, Ed K1EP wrote:

> At 5/6/2009 11:07 AM, Michael Coslo wrote:
>
>> On May 4, 2009, at 7:40 PM, Robert Chudek - K0RC wrote:
>>
>> > Someone reported on this list (probably last year) when they
>> > questioned the
>> > LoTW desk about this, their suggestion was to upload the log twice,
>> > once as
>> > the root CALLSIGN and then as CALLSIGN/M in order to increase the
>> > likelihood
>> > of a qso match.
>>
>> I'm speechless! Entering double logs may be the worst workaround I've
>> ever seen.
>
> I have done this and it has been recommended by the LoTW people (at  
> least to me).  I have logs with callsign/# and callsign.  Some log  
> the /# and some don't.  If I upload the same log signed both ways,  
> then more will get a match.  I have a lot of logs with callsign/M   
> or callsign/CTY also.  I have uploaded both.  I don't see why it is  
> "the worst workaround".

A matter of temperament, I guess. It's the reason I don't order two  
steak dinners in case one isn't to my liking. 8^)

I deal to a fair degree in databases. Duplicate data in a database is  
not a good thing. Almost the same data that is kinda duplicated but  
not really sorta is even worse. Are both correct? Is only one correct?  
If the database rationale is such that a "/m" is mandatory between  
both, or the lack of "/m", depending on what the other station  
copied,  it is really messy. Besides if the rationale is that strict,  
then the callsign had better be exactly as you sent it to the other  
OP, or he didn't copy it correctly, therefore it is a busted QSO.  
Thats a little verbose, but strict begets strict, and it isn't a good  
idea to have a database so strict that you have to enter multiple and  
different entries (therefore going from strict to two entries per QSO  
- talk about going from one end the the other!) to get a match. That's  
a big indicator that something is wrong.

We're dealing with humans, and evolving modes of logging and operating  
over time, so we need a rationale that takes that into account. People  
are going to append things to their callsign, we aren't going to stop  
it,  and we'll probably get a resolution to that about the same time  
we settle the argument of 73 versus 73's. 8^)

A better rationale is to

1. insist that the callsign be correct, that is to say if W1AZX is in  
a log, we should have that part right.

2. Due to human nature, and the differences in how callsigns are often  
done now and that  /'s were once a bigger part of the picture, and are  
still required in some cases, (upgrade period between testing and  
getting the wallpaper), the slash should indicate that what comes next  
might be ambiguous, so it should be ignored or included without  
judgement.

3. search queries should be made with the callsign, and not the data  
to the right of a slash. I suspect that the log that did not have the / 
m would pull up a match if it was searched first, not not the other  
way around.

This is a function very much like dupe searching in logging software,  
except we want the duplicate. If say counties are included to the  
right of the slash, most software that checks dupes will show all the  
counties, as long as just the callsign is entered.

And that is why it is a bad workaround. There shouldn't be a  
workaround, there should be a bit of rewrite.

-73 de Mike N3LI -




More information about the CQ-Contest mailing list