[Elecraft] K2 commands - software guru help needed

[Stewart Baker]

On Sun, 20 Jun 2004 13:12:33 -0700, Jack Brindle wrote:
> 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.

Thanks Jack,

Now I clearly understand the situation I will  ASK the software writers if they 
would change their software accordingly. I use the word ASK, because with one 
exception all of the software that I use to interface with the K2 has been 
written free of charge, and in other peoples spare time. If commercial software 
(or firmware) had a deficiency then my approach would be much more robust.

Again thanks to you, and all those on the group for your help.

73
Stewart G3RXQ