We used TR 6.79 in our M/S effort from P40L in CQWW CW. TR mostly worked
great but there were a few cases where it didn't do what we expected or was
missing functionality that would have been useful.
The paddle speed should revert to the base CW speed when a message with
sped-up (Ctrl-F) characters is interrupted. Our CQ message was "TEST \"
with TEST sped up by 3 Ctrl-F's. We'd hear a late caller just as the Enter
key was hit, interrupt the CQ messsage, then use the paddle to send a
question mark and the one or two characters copied. This almost always was
a QLF moment because the paddle would send much faster than we expected.
If you change bands from the high end of a band with a large number of
bandmap entries, forcing the bandmap to be shifted right, to a band with a
small number of bandmap entries then the bandmap is right-shifted on the new
band and doesn't show anything. This typically happened when moving from 20
to 10 meters - the 10-meter bandmap would be empty. Typing Ctrl-End is a
workaround that causes the bandmap to refresh correctly.
It would be useful to have a bandmap option that only shows unworked
multipliers. Most of the time our bandmap was filled with unworked stations
that were not mults. We often couldn't even see all the mults on the band
we were on, much less all the available mults on all bands. For the mult
station in a M/S being able to see only mults on all bands would be a nice
feature.
We found ourselves accidentally hitting the ` key occasionally while
running. We didn't want to turn off packet spotting, but it might be useful
to add a third value to PACKET SPOT DISABLE, perhaps "PACKET SPOT DISABLE =
CQ MODE" that would allow packet spotting in S&P mode but not in CQ mode.
We were already using the EDIT ENABLE option so this would avoid hitting a
bunch of ESCs to remove the spotting prompt.
When bandmap dupes are toggled on and off then spots at the high end of the
band are sometimes removed from the bandmap. This may be an interaction
with BAND MAP CUTOFF FREQUENCY, but it also seemed that some spots below
this limit were also removed. We didn't think to increase the 20-meter
limit above 14100 and would lose our own spots on 20 when this happened.
Sometimes if a callsign and zone correction were both made in the Exchange
window then it wasn't possible to log the QSO until the original zone was
deleted. For example, if the Exchange window contained "17 RW3WWW 16", then
the 17 would have to be deleted to log the Q. We wondered if it was
sometimes interpreting one of the numbers as an RST, but the zones are only
2 digits so this shouldn't happen on CW.
Callsign corrections in the Exchange window are sometimes sent in messages
that include @, but much of the time the original Call Window contents are
sent. Should we be using { instead of @ if we're making callsign
corrections in the Exchange window?
Occasionally the Enter key would fail to send the QSL message but would log
the QSO, as if Ctrl-Enter were hit instead.
I realize that a new version of TR is about to be released so I thought I'd
get these requests out just in case it's possible to get any of them
fixed/done.
73,
-Mike, N7MH
_______________________________________________
Trlog mailing list
Trlog@contesting.com
http://lists.contesting.com/mailman/listinfo/trlog
|