This is correct, and exactly what happens. As noted below, a mode
change will change the setting of the mode for the current band. An
ensuing band change will then take effect and restore the previously
saved mode for the new band. This makes a lot of sense, and should be
considered a bug in any program that expects things to happen the
opposite way.
On Jun 20, 2004, at 6:24 AM, Stewart Baker wrote:
On Sun, 20 Jun 2004 14:08:46 +0100, Brendan Minish wrote:
I don't see any logical reason to do it backwards, most radios have
band
stacking memories or at least remember frequency and mode by band.
Sending the mode change command before setting the frequency is simply
doing things backwards.
I mentioned this to the developers of Dxbase and they said that
kenwood
protocol worked this way around because some early kenwoods (TS940s
vintage) required it this way.
***************************************************************
Thanks for that Brendan, I was hoping that someone would give me a
reason
'Why they do it that way"
***************************************************************
Well mode must be set after the frequency not the other way around
otherwise you just change the mode on the band you are leaving and
arrive on the new band in whatever mode was used there last time.
**************************************************************
That is the way I believe it should be commanded, Frequency then Mode.
There are some things to be considered here. The K2 does not have the
ability to keep track of when a command comes in. Characters are
received and placed in the serial input buffer. The K2 then proceeds to
parse and execute the commands when it has time to do so. Things that
may slow this down are AuxBus traffic, front panel activity and other
important activities. Very high in this list are menu functions. When
the K2 is in the menu mode, the radio continues to receive characters,
but does not parse them until menu mode is exited. So, commands can
stack up in the queue awaiting execution, and will then be executed, in
order, when normal operation is restored. Again, the K2 does not know
when the character was received, just the order. Thus order is very
important. Don't ask for Wayne to save the character RX time, there
isn't enough ram/code space, and it really isn't that useful.
Personally, I believe that any rig that handles commands out of order
is simply asking for trouble. Computer software should issue commands
in the order they need to be performed, which is exactly the way you do
things when writing the software. You would not expect the result of an
addition to be stored before the addition is performed, so why expect
the radio to divine what you want instead of what you actually asked it
to do?
OK, off my soap box. It is far easier for software writers to fix their
errors than for firmware to be changed, so I suggest that requests to
those folks might be in order.
_______________________________________________
Elecraft mailing list
Post to: [email protected]
http://mailman.qth.net/mailman/listinfo/elecraft
You must subscribe to post.
Subscriber Info (Addr. Change, Unsub etc):
http://mailman.qth.net/subscribers.htm
Elecraft page: http://www.elecraft.com
