[Elecraft] CW sending using the CAT KY command

[Jack Brindle]

On Thursday, May 1, 2003, at 11:38  AM, Julian (G4ILO) wrote:

> I'm having trouble implementing CW sending by CAT in K2Net. According 
> to
> the docs, you can only send 24 characters at a time using the KY 
> command.
> The trouble is that the K2 doesn't automatically report when the 
> buffer is
> empty so that I can fill it with more text.

Let me take a stab at this one. It is fairly easy to make this work 
quite smoothly.

> To work around this problem, I have a timer send a KY; command at 500ms
> intervals. According to the docs, in extended response mode this will
> return a value of 0 when the buffer is full, 1 when it is 75% full and 
> 2
> when it is completely empty.

You have managed to reverse the meanings of the values. For the KY 
command, the KI2 programmers reference guide states:

"Basic RSP format: KYn; where n is 0 (CW text buffer not full) or 1 
(buffer full).
Extended RSP format: KYn; where n is 0 (buffer < 75% full), 1 (buffer > 
75% full), or 2 (buffer completely empty AND transmit of previous 
string is complete."

If you get an extended response of 0, you should be able to send at 
least six characters to the K2. A value of 2 means that you can send  
up to 24 characters, AND that the K2 has actually stopped transmitting.

> However, what I appear to be getting is a response of 0 until all the 
> text has been sent, then a response of 2.  Because I can't top up the 
> buffer with text before it becomes empty, there
> is an unacceptable gap in the sending every 24 characters. Am I going 
> about
> this the wrong way?

Your algorithm should be:
if response is 0, send five or six characters to the K2, then continue 
polling.
if response is 1, simply continue polling.
if response is 2, send up to 24 characters to fill the buffer, OR use 
the information to indicate that the previous transmission has 
completed.

A couple of items of note - the '<' and '>' characters can come in 
quite handy in the use of the KY command. Everything between a '<' and 
the next '>' is simply sent to the speaker, and not transmitted on the 
air. This can be very useful in alerting the user to some station 
condition. Be careful, though, to avoid interrupting the transmission 
(by pressing a key, for example), or you could leave the K2 in test 
mode where all further KY commands get sent to the speaker and not to 
the air. Methods of detecting this situation are left as an exercise 
for the user. ;-)

The second item is a follow-on to the first. KY transmissions can be 
interrupted by pressing a key on the front panel, or even simulating a 
keypress using the SW command. Doing so will abort the current 
transmission, meaning that everything following in the buffer will not 
be interpreted (thus the above described problem). This may also cause 
serial commands following the KY to be flushed. As an example, suppose 
you implement a 10-minute CW ID for sideband operation. Every ten 
minutes you might send the following string to the K2: "MD3;KY DE 
WA4FIB;MD1;".  This string commands the radio to go to CW mode, send 
the identification, then return to LSB mode. If the command is 
interrupted during the transmission, the radio will not execute the 
last command, and you will stay in CW mode. Thus it is important to 
check the response strings to make sure that all the commands you send 
are indeed carried out.

> Hopefully Wayne or Eric will respond to this, but as others have also 
> written remote control software for the K2 perhaps they have some 
> ideas too.

Those two are a bit busy at the moment, so don;t expect a quick 
response. Let's just say that spring is a very busy time around the 
Elecraft offices...

-Jack Brindle, WA4FIB
=======================================================================
MacDobs - helping to shift the paradigm for low-cost amateur astronomy.