K2 commands - software guru help needed

[Stewart Baker]

Hi,
I hope that someone in the group who has intimate knowledge of the K2 software
command structure and can help resolve a problem.
I am trying to use a well know Freeware logger program with my K2.
As the program supports the Kenwood command set, and that is what I am using.
The interface works well with one exception, that is the Mode selection.
It does not always correctly set the correct mode when clicking on a cluster
spot, however a second click on that spot always gets the correct mode.

As the program has a Debug window I am able to look at the commands sent by the
program. I have used Hyperterminal to send these captured commands to the K2,
and observe the result. I need  know if the order of the commands sent to the K2
is critical.

My question is, do each of the following command strings have the same effect on
the K2 ?

a)   FR0;MD1;FA00003727000;  - VFOA;LSB;3737
b)   FR0;FA00003727000;MD1;  - VFOA;3727;LSB

I know that the frequency changes correctly. Kenwood rigs do not appear to have
this problem.

Any help will stop me scratching my head to pieces....

73
Stewart G3RXQ

_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[Don Wilhelm-2]

Stuart,

In the examples you gave, b) should work while a) will not necessarily
produce the mode you specify.  I don't think it matters whether you are
driving the K2 from the computer or the front panel - it is the sequence
that matters.

Recall that the K2 remembers the band and mode and filter setting after
having no change for 30 seconds - so your two examples will do the
following:

a) Change to VFOA, then set LSB (on the band currently selected), then
switch bands to 3737 kHz (K2 will be in the mode you had last used on 80
meters).

b) Change to VFOA, go to 3737 kHz, set the mode to LSB - all ends up as
expected.

73,
Don W3FPR

Life is what happens when you are making other plans
----- Original Message -----

As the program has a Debug window I am able to look at the commands sent by
the
program. I have used Hyperterminal to send these captured commands to the
K2,
and observe the result. I need  know if the order of the commands sent to
the K2
is critical.

My question is, do each of the following command strings have the same
effect on
the K2 ?

a)   FR0;MD1;FA00003727000;  - VFOA;LSB;3737
b)   FR0;FA00003727000;MD1;  - VFOA;3727;LSB

I know that the frequency changes correctly. Kenwood rigs do not appear to
have
this problem.



_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[Stewart Baker]

On Fri, 18 Jun 2004 07:42:22 -0400, Dan Barker wrote:

> Yes, they have different meanings.
> a)   FR0;MD1;FA00003727000;
> Select VFO A
> Set mode to LSB
> Set Freq to 3737 and if that is in a different band, change mode to the
> "remembered" mode.
> b)   FR0;FA00003727000;MD1;
> Select VFO A
> Set Freq to 3737 and if that is in a different band, change mode to the
> "remembered"
> mode.
> Set mode to LSB
> "Remembered" is the mode that was used at the last Band change or stayed
> there for 30 seconds or some such.
> So, method a) depends on the current state of the radio memories, and method
> b) does not. However, in practice, once your rig "knows" you like LSB on 80
> meters, both will do the same thing.
> Dan / WG4S / K2 #2345

Reply to Don & Dan,

Thanks guys for your explanations, they are both very similar.

The scenario of the problem shown when using either of 2 well known logging
programs is this:-

1) Set the K2 to 80m LSB. Leave for >30secs so that  freq and mode are stored.

2) Clicking once on a 20m spot:-
 the logger program sends FR0;MD2;FA00014xxxxxx;
3) The K2 changes to 14xxx.xx. Leave for >30secs so that  freq and mode are
stored.

4) Clicking once on a 80m spot:-
the logger program sends FR0;MD1;FA000037xxxxxx;
5) The K2 changes to 37xx.xx, but stays on USB. WHY ? (a) the mode was
originally stored (b) the software sent an MD1 command to change to LSB.
6) A second click on the spot sends FR0;MD1;FA000037xxxxxx;
7) The K2 then changes to LSB.

It is as though on the first time round the mode change gets ignored.
Does the above make any sense, or have I totally lost my marbles ?

73
Stewart G3RXQ





_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[Stewart Baker]

On Fri, 18 Jun 2004 12:52:12 -0400, Don Wilhelm wrote:

> Stewart,
> My memory is foggy for the 'when', but I do recall a time when the K2 did
> not remember the mode on a per band basis - it just remembered the last mode
> used 30 seconds ago, and so would end up in USB on 80 meters as you stated
> in your example.
> I know version 2.03 firmware DOES remember the mode on a per band basis - so
> if you are using something prior to that level, consider upgrading to the
> most recent level.  Even at that, if your software sets the mode before
> setting the band, you will still end up with the last mode used on the new
> band rather than what the software tried to set.
> 73,
> Don W3FPR

Don,

I have checked my firmware, and it is version 2.04 which as far as I know is the
latest. The way the old firmware worked could fit the symptoms.

I have had a number of email (mainly off the group) which detail the same
problem, and the software that is effected. These are the ones I know about.

DXlabs - The author is aware of the problem, and has indicated that he will
probably change his software to fit (timescale unknown)
XMlabs - This software has been modified to cure the problem.
Logger32 - On going. They need more information.

So that is the state of play as of now. I would appreciate comments from Wayne
or Eric.

73
Stewart G3RXQ


_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[Tony Wells]

Stewart,

Sometimes (and there seems to be no predictability about this)  the K2 does
not take kindly to too many commands sent in one go especially when a band
change is involved in the string.

To test your character strings in Hyperterminal use the paste buffer to send
the strings fast, rather than typing slowly.

Regards

Tony
G7IGG


_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[Stewart Baker]

On Sat, 19 Jun 2004 11:24:44 -0700, Jack Brindle wrote:

> Stewart;
> I haven't been paying too much attention since I'm currently on
> vacation, but if you will re-describe the problem for me I will take a
> look into the situation and see what suggestions we can come up with.
> The K2 has a limited buffer that can be overflowed rather easily. When
> this happens, the K2 can do weird things. This is the reason we tell
> people to disconnect the KRC2 from the K2 before downloading update
> code to the KRC2. The long data strings the KRC2 receives will really
> "mess up" the K2.
> So, sorry for not having been paying attention, but send me the details
> of what you have been seeing, and I will look into it, consulting with
> Wayne as needed.

Jack;

There seems to be a problem with K2 mode selection when using a number of
different logging programs. I have received mails from other K2 users with the
same problem. These logging programs assume that the K2 responds exactly as a
Kenwood rig when it comes to setting frequency and mode via the RS232.
The order in which commands to select frequency and mode appear to be crucial.
It would appear that logger programs when selected to Kenwood, output :-
VFOx;MODE;FREQxxxx.  
The end result is that the mode selection is somewhat unpredictable.
My experiments with Hyperterminal show that :-
VFOx;FREQxxxx;MODE works everytime.

It would be nice to get to the bottom of this so that the correct information
can be made available to the authors of the programs. They can then choose (or
not) to implement any necessary changes to their code.

I would greatly appreciate your help in resolving this matter.

73
Stewart G3RXQ



_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[Tony Wells]

Hi Stewart,

This rang a bell with the findings I had when developing the long-awaited
K2Z.

Probably the only design issue with K2 serial IO  is that there is no
feedback from some of the commands making it difficult to pace the sending
of commands. I'm not sure how this compares to Kenwoods etc. However I've
looked at the code from K2Z and I got round the buffering issue as follows.
Firstly I never send more than one command at a time.  I also identify
commands that do not issue a response. For those commands I waited before
sending the next command. Normally the wait period is relatively short -
20ms. In the case of a potential band change the delay is 1000ms.

In the software you are using are there any macros for introducing delays
into the string sending?

If this is an intractible problem with no simple solution, there is one
really inelegant kludge that could be implemented. Provided the software you
are using does not do direct IO to the chips, it is possible introduce a
"hook" to catch all serial IO and perform some intelligent buffering based
on identifying the commands sent. The "hook" would be an independent piece
of software which is run before the main program. This "hook" method is not
new - it is the method used by serial port "spyware" to capture serial IO
for debugging purposes etc.

Regards

Tony
G7IGG

----- Original Message -----
From: "Stewart Baker" <[hidden email]>
To: "Jack Brindle" <[hidden email]>
Cc: "Elecraft Reflector" <[hidden email]>
Sent: Sunday, June 20, 2004 7:55 AM
Subject: Re: [Elecraft] K2 commands - software guru help needed


On Sat, 19 Jun 2004 11:24:44 -0700, Jack Brindle wrote:

> Stewart;
> I haven't been paying too much attention since I'm currently on
> vacation, but if you will re-describe the problem for me I will take a
> look into the situation and see what suggestions we can come up with.
> The K2 has a limited buffer that can be overflowed rather easily. When
> this happens, the K2 can do weird things. This is the reason we tell
> people to disconnect the KRC2 from the K2 before downloading update
> code to the KRC2. The long data strings the KRC2 receives will really
> "mess up" the K2.
> So, sorry for not having been paying attention, but send me the details
> of what you have been seeing, and I will look into it, consulting with
> Wayne as needed.

Jack;

There seems to be a problem with K2 mode selection when using a number of
different logging programs. I have received mails from other K2 users with
the
same problem. These logging programs assume that the K2 responds exactly as
a
Kenwood rig when it comes to setting frequency and mode via the RS232.
The order in which commands to select frequency and mode appear to be
crucial.
It would appear that logger programs when selected to Kenwood, output :-
VFOx;MODE;FREQxxxx.
The end result is that the mode selection is somewhat unpredictable.
My experiments with Hyperterminal show that :-
VFOx;FREQxxxx;MODE works everytime.

It would be nice to get to the bottom of this so that the correct
information
can be made available to the authors of the programs. They can then choose
(or
not) to implement any necessary changes to their code.

I would greatly appreciate your help in resolving this matter.

73
Stewart G3RXQ



_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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




_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[Brendan Minish-2]

On Sun, 2004-06-20 at 07:55, Stewart Baker wrote:

> There seems to be a problem with K2 mode selection when using a number of
> different logging programs. I have received mails from other K2 users with the
> same problem. These logging programs assume that the K2 responds exactly as a
> Kenwood rig when it comes to setting frequency and mode via the RS232.
> The order in which commands to select frequency and mode appear to be crucial.
> It would appear that logger programs when selected to Kenwood, output :-
> VFOx;MODE;FREQxxxx.  
> The end result is that the mode selection is somewhat unpredictable.
> My experiments with Hyperterminal show that :-
> VFOx;FREQxxxx;MODE works everytime.

I too came across this one when doing the K2 support for Dxbase, Happily
due to the way in which Dxbase does radio support I was able to find a
complete workaround and Dxbase now supports the k2 perfectly.

I think the k2 behaves exactly as it should. In my opinion commands
should happen in the order they are sent so sending a mode change
followed by a band change is going to cause problems under certain
circumstances.

It appears that all modern Kenwoods can handle the information in either
order so I would love to find out which legacy kenwood radios absolutely
requires the mode change first. Hacking up the K2 software to hold onto
the mode change until after the frequency has also been set would be a
bad idea and probably just slow things down. The K2 is pretty quick to
respond to commands compared with some radios.
Far better to contact the authors of your favourite logging package and
explain the problem.

Elecraft's choice of kenwood protocol for rig control was in my opinion
the best choice out of a bad bunch of protocols and elecraft have added
a significant number of useful improvements / extensions to the
protocol.

Anyone know of any open source Linux logging packages that do radio
support?

73
Brendan EI6IZ

_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[Stewart Baker]

On Sun, 20 Jun 2004 11:51:13 +0100, Brendan Minish wrote:

> On Sun, 2004-06-20 at 07:55, Stewart Baker wrote:
>> There seems to be a problem with K2 mode selection when using a number of
>> different logging programs. I have received mails from other K2 users with
>> the
>> same problem. These logging programs assume that the K2 responds exactly as
>> a
>> Kenwood rig when it comes to setting frequency and mode via the RS232.
>> The order in which commands to select frequency and mode appear to be
>> crucial.
>> It would appear that logger programs when selected to Kenwood, output :-
>> VFOx;MODE;FREQxxxx.
>> The end result is that the mode selection is somewhat unpredictable.
>> My experiments with Hyperterminal show that :-
>> VFOx;FREQxxxx;MODE works everytime.
> I too came across this one when doing the K2 support for Dxbase, Happily
> due to the way in which Dxbase does radio support I was able to find a
> complete workaround and Dxbase now supports the k2 perfectly.

>> Hi Brendan, I am not familiar with Dxbase, but in my experience DXlabs and
>> Logger32 show the problem.

> I think the k2 behaves exactly as it should. In my opinion commands
> should happen in the order they are sent so sending a mode change
> followed by a band change is going to cause problems under certain
> circumstances.

>> My experience shows the opposite.

> It appears that all modern Kenwoods can handle the information in either
> order so I would love to find out which legacy kenwood radios absolutely
> requires the mode change first. Hacking up the K2 software to hold onto
> the mode change until after the frequency has also been set would be a
> bad idea and probably just slow things down. The K2 is pretty quick to
> respond to commands compared with some radios.

>> I don't believe that this is a timing problem

> Far better to contact the authors of your favourite logging package and
> explain the problem.

>> When I am able to establish exactly what needs to be done, I will do that.

> Elecraft's choice of kenwood protocol for rig control was in my opinion
> the best choice out of a bad bunch of protocols and elecraft have added
> a significant number of useful improvements / extensions to the
> protocol.

> Anyone know of any open source Linux logging packages that do radio
> support?

>> Sorry, can't help you with that one Brendan.

73
Stewart G3RXQ

> 73
> Brendan EI6IZ
> _______________________________________________
> Elecraft mailing list
> Post to: [hidden email]
> 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

_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[Stewart Baker]

On Sun, 20 Jun 2004 12:31:35 +0100, Tony Wells wrote:
> Hi Stewart,
> Stewart wrote:
>>> I think that timing may be a separate issue in this case.
> IMHO it is not separate. Careful timing enables the software to bypass the
> buffer overflow issue. This is because of the "lack" of flow control.

>> OK, Tony.
>> Your mail gave me a chance to re-think.
>> I now understand that a major difference between the Kenwood and K2 RS232 is
>> not the command set, but the fact that Kenwood uses hardware flow control and
>> the K2 doesn't. (Takes a while for the penny to drop !!)

>> This means that sending out commands to a K2 without some delay between
>> them is questionable, and strings of commands are potentially dangerous.
>> If that is so then the K2 cannot be really thought of as Kenwood compatible.

>> I now think that what I was seeing re the order of the commands was a 'smoke
>> screen'  for what is really going on. Where now ??

73
Stewart G3RXQ

> Regards
> Tony
> G7IGG



_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[Stewart Baker]

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.
**************************************************************
 
73
Stewart G3RXQ


_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[Tony Wells]

Hi Stewart,

I guess in the first instance talk to the developers. A 1Sec delay after
band change should be good for a first iteration.

If someone has the time to write an intelligent "hook" that would be good.
I'm out of the loop because I'm up to my eyeballs writing a different kind
of wrapper for a much bigger, but much less interesting project :-)

Regards

Tony
G7IGG
----- Original Message -----
From: "Stewart Baker" <[hidden email]>
To: "Brendan Minish" <[hidden email]>
Cc: "Elecraft Reflector" <[hidden email]>
Sent: Sunday, June 20, 2004 2:24 PM
Subject: Re: [Elecraft] K2 commands - software guru help needed


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.
**************************************************************

73
Stewart G3RXQ


_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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




_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[Bob Nielsen]

On Sun, Jun 20, 2004 at 11:51:13AM +0100, Brendan Minish wrote:
>
> Anyone know of any open source Linux logging packages that do radio
> support?

TLF does, using hamlib for the radio interface.  I haven't yet
interfaced my K2 with my computer, so I don't know how complete the
support for a K2 is implemented in hamlib.  If there are any other
logging programs using hamlib, they should also support a large variety
of radios.  Links to these can be found at <http://radio.linux.org.au>.

73,
Bob N7XY


_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[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.

_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[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

_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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

[Tony Wells]

Jack 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.

I suspect it is not a bug, more like the developer(s) worked on a
transciever that behaved like my TS140S. Mode settings on my TS140s do not
change when the band changes.

Regards

Tony
G7IGG


_______________________________________________
Elecraft mailing list
Post to: [hidden email]
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