Dave, K5GN writes:
> I had some unusual things happen with SO2R in SS this year. I was using
> 6.45 with the config files as attached.
>
> 1. Alt-D did not clear the old callsign after I worked him. If I
> pressed the space bar after that as though I had entered a new call (to
> work another guy), it would call again on the other radio (DE K5GN,
> e.g.) as normal. Then realizing what has happened, after editing the
> call and continuing, when I pressed return it only sent the first two
> digits of the number or something like that. Rather strange. If I
> worked someone with Alt-D, then entered another call via Alt-D, it
> worked just fine.
This appears to be a side effect of having SPRINT QSY RULE = TRUE.
Doc - please put a note on this feature to only use it in the SPRINT.
It will cause problems with the TWO RADIO MODE in the SS.
> 2. I had several places in the course of the contest when a partial
> call in the call window would bring up pieces of Alt-N notes, always
> with the / character near the beginning or embedded in the text string.
This was created when a note moved off the editable log and TR tried
to process it for initial exchange information. I have added a test
to abort the processing of initial exchange data if the QSO doesn't
look correct. This is fixed for the next release.
> 3. I also had something hang up in the 15 minutes before SS. Dunno
> what happened. Just got me nervous about a repeat. No repeats!
I had Internet Explorer hang on me about 4 times today at work.
> 4. Ever since the invention of Alt-D, there has been a problem for me
> when aborting an Alt-D QSO where pressing the Escape key many times to
> get to "ground zero" leaves me in CQ mode on the alternate rig instead
> of on the original run rig. I think it happens when I abort during the
> sending of the callsign; it may be just after that. The reason for
> aborting is to catch someone who answered the CQ on the run rig, but
> after a pause, during which I pressed the space bar to start the Alt-D
> QSO process. If I don't remember to check, I will end up answering the
> guy on the wrong radio, sending on top of the Alt-D CQer. Not friendly,
> and not efficient. Can you trap this so that after enough Esc's you
> always end up back at "ground zero" on the original run rig?
This happens when you abort sending "DE K5GN" with the ESCAPE key.
When this happens, the program should return to the "CALL READY TO
WORK" state - but it wasn't. This resulted in the QSO getting setup
as if you were still going to make it, and the wrong radio being
selected.
This was an easy fix for the next release.
> 5. In POST, I find that after having executed Alt-U to flush the .TMP
> file into the log file, the .TMP file still exists, so I get an error in
> the first routine I run (TMP file found ...). The TMP file used to be
> deleted so that this would not happen.
This bug was found just after sending out 6.45. There is a .TMP
file that has about 10 bytes in it, and the POST program was thinking
this had data in it. This has already been fixed for the next release.
> In addition to the bug reports above, I offer the following possible
> improvements. One or two might be easy.
>
> 1. Please rearrange the order of business so that the QSO B4 message is
> sent to the CW port before the lookup function slows the computer to
> find previous QSO info. There is sort of a hiccup on slower computers
> or people not using disk cache. E.g., "W9YK <lookup pause> QSO B4".
> The pause is nearly long enough for the person to get confused and reach
> for the paddles again.
Done for the next release.
> 2. After completing an Alt-D QSO, the computer is all set to send a CQ
> on the run radio. This is not appropriate if the "dummy" CQ sent while
> receiving the Alt-D QSO exchange got an answer. May I suggest that the
> program check to see if there are characters entered in the callsign
> window; if the call window is not empty then don't send the CQ, merely
> return to CQ Mode on the run radio and begin processing the contents of
> the callsign window, as usual. You can't enter the characters as the
> answer occurs, but you can enter them before the CQ starts, or so it
> works on my machine.
This might be tricky and will require some study.
> 3. Why do the control-memories only work in CQ Mode? I need more
> memories in Exchange Mode (like resending my check, section, number, or
> precedence, or asking for the same from the other guy). Can they be
> enabled in the Exchange Mode as well?
Turns out the Alt-P command didn't work - but the memories were
there (see the config file commands). I have fixed them in the
Alt-P menu for next release.
> TR worked very well this weekend other than the Alt-D confusion, which
> happened too many times to count.
Looks like you will have a much better experience next time.
Also, I noticed that ALL CW MESSAGES CHAINABLE was set to TRUE, which
was adding a space to the start of all the CW function keys (even if
a message wasn't in progress). I have fixed this so a space is only
added if some CW is already being sent.
Tree
--
FAQ on WWW: http://www.contesting.com/trlogfaq.html
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
|