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" <[EMAIL PROTECTED]> To: "Jack Brindle" <[EMAIL PROTECTED]> Cc: "Elecraft Reflector" <[email protected]> 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: [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 _______________________________________________ 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
