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 _______________________________________________ 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
