[Trlog] More WPX SSB comments

[Mike Heideman]

TR 6.72 worked very well for us in the SSB WPX contest.  Here are a few bugs 
and minor annoyances we encountered.

Using QSO NUMBER BY BAND and switching bands by typing a frequency into the 
call window leaves the serial number from the previous band next to the call 
window until the first QSO is logged on the new band.  The serial number 
immediately switches with the band when using other band-changing methods.

We set up CQ messages for 5 different ops in F1 to F5.  Using F5 did not put 
the CQ placeholder into the Bandmap for later use by LASTCQFREQ.  Is there a 
way to increase the number of function keys that are recognized as CQs?

Hitting the key mapped to LASTCQFREQ jumps to a different band when BAND MAP 
ALL BANDS is FALSE and there is no recorded CQ frequency on the current 
band.  This is unexpected and undesirable.  I found this out as a 
side-effect of the F5 problem above.

Even though we had BAND MAP ALL MODES set to FALSE we received several 
packet spots that appeared in the CW band in the bandmap.  If we used the 
key mapped to NEXTBANDMAP it would eventually wrap around to the CW spot, 
changing the mode on the rig to CW.  Once it got stuck on the CW spot it 
wouldn't jump to the next phone spot.  We had MULTIPLE MODES set to FALSE so 
it should not have switched to CW in my opinion.

We really like the bandmap feature that sets the split frequency for packet 
spots with QSX info.  It would be nice if we could spot the QSX info into 
the bandmap ourselves directly (without sending it to the packet network).  
Losing the QSX info when hitting the space bar to dupe a station is also a 
problem.  Perhaps some shifting of the space key (e.g., Ctrl-Space?) could 
be used for this purpose, prompting for the QSX frequency.

Along the same lines, it would be useful for the PACKET SPOT KEY to 
automatically add "QSX 7xxx.x" when the transmitter frequency is far from 
the receiver frequency.  There should probably be a parameter that specifies 
whether this behavior occurs or not (PACKET SPOT QSX?).

We had one QSO that was logged only to the computer on which it was entered. 
  The multi network seemed to be working at the time since QSOs before and 
after it propagated to the entire network.  I was using the only other 
active computer on the network and wasn't doing one of the usual things that 
block the network (perusing Alt-H, forgetting to answer the Ask For 
Frequency prompt, leaving the cursor in the bandmap, taking too long in 
Ctrl-N, etc.).

A feature that would be useful in the Cabrillo option of Post is to ask for 
the station call, if it's not the same as the call used.  We were surprised 
to see that WX5S now holds the W5 M/M WPX SSB record for our effort last 
year at W6YX.  It is not at all obvious that @W6YX has to be entered as one 
of the operators to get the proper call area into the log.

It would be useful for Post to rescore the log at the same time that it is 
doing one of its other post-contest checks.  Problems occur under the 
following scenarios, both of which I've experienced several times:

1. A station is intentionally duped because there was an error with the 
first QSO with the station.  The second QSO is originally scored as 0 
points.  Fixing the first QSO (logged on the wrong band, accidentally logged 
prematurely, or an error in the callsign) does not result in normal QSO 
points being assigned to the second QSO by Post.

2. The station is in the wrong continent in CTY.DAT during the contest.  
After the contest a corrected version of CTY.DAT is obtained but the score 
doesn't change when Post is run.  This happened with KG6DX in CQWW this past 
fall, who was logged as 0 points for us but should have been updated to 3.

-Mike, N7MH


_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail