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
|