[Elecraft] K2 commands - software guru help needed

[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" <stewart at baker.nildram.co.uk>
To: "Jack Brindle" <jackbrindle at earthlink.net>
Cc: "Elecraft Reflector" <elecraft at mailman.qth.net>
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: Elecraft at mailman.qth.net
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