At 12:19 PM 2/13/97 -0800, you wrote:
>
>I think you're mis-diagnosing the problem a little bit, Bert, er, Tree.
>The main trouble I hear from others learning TR or just using it casually
>is that there are modes *at all*. Not the sequencing between them. I
>believe K3LR said, "I want a key to do the same thing every time I press
>it."
>
>The answer for this type of problem is to allow the user to lock the
>program into one mode. i.e., "S&P LOCK = ENABLE" or "CQ LOCK = ENABLE".
>(The latter would be popular on the East Coast during DX contests, hi.)
>This just keeps the program in one mode all the time.
>
This may be a good idea for a new user.
I don't pretend to be an accomplished contester, but one of the things I
like *best* about TR is the two distinct modes and their different uses of
message/Fkeys. I'd like to see a solution that keeps the separate modes.
>To deal with the automatic mode switching, a command could defeat the
>switch, while still allowing manual switching with the TAB key. i.e.,
>"AUTO MODE SWITCH = DISABLE".
>
>This combination of switches would address 95% of the mode-related
>difficulties, while avoiding a change to the full functionality that
>really makes TR special. While I'm not completely facile with all of
>these features, as I get better at it, I'm making higher scores. Don't
>break it, just allow folks to limit it.
>
>73, Bo, er, Ward, N0AX
>
I think the biggest problem I have with this (and it's really minor in most
contests, but brought out with the sprint-style contests because of the
constant change from CQ to S&P) is that the change isn't consistent. One
time is it's the TAB key (CQ to S&P) then the Escape (S&P to CQ) It goes
from S&P to CQ automatically upon a successful QSO, but after the completion
of the second QSO, doesn't automatically go back to S&P as you tune down the
band. If you hit the spacebar, it drops your call and goes into S&P okay,
but if you've entered a call into the call window, it behaves another way,
which depends on whether you've remembered to return to S&P mode or not.
It's not the fact that there are two modes, it the inconsistancies in
how/when it changes back and forth.
Now not everyone's style of operating is the same and not everyone may see
this as a problem. I may learn a better way and adapt me, rather than the
program ;-) Or, it might be useful to have another choice in how the
program responds. The way that I want to work a sprint, and this may be the
real problem, :-) is to settle into a pattern, S&P - CQ - S&P - CQ... and
only have to think about a mode change when I make a conscious change in the
pattern, such as finding a clear frequency and deciding to CQ there. Or
giving up calling CQ, and going S&P because I'm getting no takers, a case
I'm intimately familiar with!
The embedded control character that puts you into S&P mode would solve
things for me just fine. I know right where I'd put it: in the QSL MESSAGE!
If there were a corresponding code to go to CQ/RUN mode, there wouldn't even
be a need for Sprint Mode, it could all be done according to what message
was sent.
Oh well, that's enough campaigning on this idea. The good thing is no matter
what we suggest, the solution Tree comes up with is usually even better than
our suggestions!
73, Al, er, Al (!?!) AE2T, suffering from a lack of imagination in Sprint names!
P.S. - When I replied, I forgot to change the address to that of the list
and sent this to N0AX, Sorry Ward!
|