[Trlog] Feature request for confirming exchange components to limit paddle use

[Mike Heideman]

One of the features of TR that isn't documented in the manual as far as I 
can tell is that the first few Alt-F# characters on CW are automatically set 
up in Exchange mode to query for the default exchange components sent by the 
corresponding F-key.  For example, Alt-F1 sends "UR CALL?", Alt-F2 sends 
"AGN?" for the full exchange, Alt-F3 asks for the first component of the 
exchange, e.g., "NR?" for many contests, etc.  This feature depends on the 
EXCHANGE RECEIVED that is either set by the CONTEST statement or separately 
in the config file.  Typing Alt-P E Alt-F1 will show what is set up for the 
current contest.

These built-in queries are useful and intuitive, but I often find that after 
asking for a repeat I will have received something, such as a number, of 
which I'm not fully confident.  At this point I want to ask the other 
station to confirm the number since he's probably hearing me better than I'm 
hearing him.  So, for example, I send "1338?" with the paddle.  For myself 
and for other operators I've observed the sent component will frequently be 
garbled and missent, forcing an extra repeat.  Using F10 and the keyboard is 
also commonly error-prone.

It would be extremely useful to enable key mappings to ask these questions.  
This is already done for the callsign in Alt-F10 with Ctrl-U available as 
the corrected callsign.  My proposal is to provide corresponding default key 
mappings, such as Ctrl-F3 for F3 confirmation, Ctrl-F4 for F4 confirmation, 
etc., and provide positional variables for the exchange components.  The 
same logic that deciphers the exchange for logging could also figure out the 
components for this purpose, assuming that missing components are all at the 
end of the exchange.

There are only a few unused characters available for positional variables.  
I tried out the control characters in tables 3, 4, and 5 of the manual.  I 
notice that Ctrl-D does 3 separate things; ending a Ctrl-C sequence, space 
between chained messages, and a 13% shorter dah than normal.  
Experimentation shows that it does not produce the 13% shorter dah.  The "-" 
in the bottom row of Table 4 of the manual should be "CTRL--".  Ctrl-[ (same 
as ESC key) causes an infinitely long, uninterruptible dah if it's put into 
a message without the following @.

I was hoping that Ctrl-1, Ctrl-2, etc. were available but I had forgotten 
that there are only 32 ASCII control characters.  Bracketing a single digit 
with Ctrl-C and Ctrl-D might also work so that in SS, for instance, "NR 
<Ctrl-C>1<Ctrl-D>?" could confirm a received number.

For all of you that never make paddle mistakes I apologize for the 
bandwidth.  This idea came to me after a weekend of using WriteLog in CQP 
with the paddle connected to an external keyer.  Every time I needed to send 
something with the paddle it was at a different speed than the computer, 
causing an initial stream of gibberish.  TR with PADDLE PORT doesn't have 
the speed discrepancy but I make enough mistakes that I'd rather the 
computer send these messages than me.

73,
-Mike, N7MH

_________________________________________________________________
See when your friends are online with MSN Messenger 6.0. Download it now 
FREE! http://msnmessenger-download.com