[Elecraft] K2 commands - software guru help needed

[Jack Brindle]

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.