W9WI wrote:
> I worked N2NL/MM, but the program (6.79) wouldn't accept either "R2" or
> "MM2" as the exchange. I just entered "2" and edited the Cabrillo file
> manually before submitting to ARRL.
N6TR replied:
> Great solution Doug. For reasons I almost don't remember any more, this
> special case is a really difficuly problem for TR. I know I have tried
> to find an easy way to work around it several times, and have ended up
> being defeated.
I applied the same solution here, and that works for me.
It's not a big deal, and I meant to test this before the contest, but
would it work to just add r1, r2 and r3 to the appropriate domestic mults
file? Seems like we did that for IARU or some other contest years ago and
it worked.
While I'm at it, I noticed two slightly annoying things this weekend.
First, I should say we were running M/S with two computers networked and
packet.
1) As background I somehow managed to get data into the QTH field for a
few non-U.S. stations in my TRMASTER file. This is not a huge deal,
although it seems silly to take up space to tell me S50A's QTH is S5, so I
generally try to keep that info out of TRMASTER by filtering it out of the
log before I run POST UEFF. But for this contest, I noticed a slightly
more serious problem with having that info in TRMASTER.
I had "INITIAL EXCHANGE = QTH". So when K7RAT calls me, the initial
exchange is set to "OR" and I just need to hit <Enter> to log the QSO if
that info is still valid. If K7RAT sends "5NN WY", then I can just type
"WY" and TR Log will use the last entry.
The problem comes when NP4A calls me. If I have his QTH info in TRMASTER,
the exchange will be pre-filled with "KP4". But if he sends "5NN 1234"
and I enter "1234" after the pre-filled part, TR Log will not log the QSO.
I have to delete the initial exchange before entering his correct
exchange. I know I could solve this by skipping INITIAL EXCHANGE or
removing all the QTH data from the non-U.S. calls in my database
(somehow), but it would be nice if TR Log handled this a little more
gracefully.
2) I couldn't figure out the pattern, but there are times when a worked
station shows up in the band map on one computer with an asterisk, but
doesn't have the asterisk on the other computer. Or sometimes the
asterisk is missing on both computers. At times, I would say this
affected maybe 20% of the calls in the band map. And I couldn't see a
correlation between whether the spot came in via packet or was dupe
checked on one of the PCs. Sometimes the asterisk would be missing from
one PC (either one), and sometimes both. Fortunately, if it was a mult,
the smiley face always seemed to be there. But late in the contest, we
were jumping on any new call that didn't have an asterisk, and there were
times when we unknowingly tried to call a dupe. The good news is that TR
Log wouldn't actually let us call the guy, and as soon as we tried, it
would put the asterisk on both PCs' band maps. If it would help, I can
try to do some more rigorous testing to find a pattern.
Finally, we didn't notice any problem with the remaining DX mults display.
We used a custom list (added to the bottom of CTY.DAT), and had BIG
REMAINING LIST = TRUE.
73,
Tim Totten, n4gn@n4gn.com
http://www.n4gn.com
_______________________________________________
Trlog mailing list
Trlog@contesting.com
http://lists.contesting.com/mailman/listinfo/trlog
|