[Elecraft] K3 programming - Text decode

[Leigh L. Klotz, Jr WA5ZNU]

I recommended a while back that there be a mode where the RX text comes 
back as the TX text command in 16-byte packets (which I think is the max 
for the KY send command.

 KYCQ CQ DE WA5ZNU;

You might take a peek at the Python library I did; also, I have plans to 
update it to use the fldigi rig.xml format instead of hard-coding the 
commands.  A Ruby interpreter for the fldigi rig.xml format would be nice.

Leigh/WA5ZNU
> Hi all,
>
> I'm playing around with writing a control interface for the K3 in
> Ruby, and am currently working on the low-level interface
> classes.
>
> Mostly it's all going well, but I do have a few questions about
> the Text To Terminal functionality.  I'd like to be able to use
> the interface classes to support a program that sends commands to
> and receives data from the K3 on behalf of other clients, and
> also 'filters out' decoded text.
>
> The manual states "Returned strings are never interspersed with
> text data, so this can easily be done."  Ahem.
>
> The problem is, how does one recognise a response of the form
> 'XX.*;' and pull it out of the incoming stream of bytes?
>
>     * You could buffer characters until you see a ';' and then
>       match backwards.  You'd need to shift off the front of the
>       queue when you pass the maximum possible length of a
>       response, but this would still introduce a lot of latency.
>
>       This also presents the problem of depending on ';' -- is it
>       guaranteed that the K3 will never interpret an incoming ';'
>       from CW or a data mode?  If not, it's possible that a
>       remote station could send you a string that looks like a response
>       from the rig, possibly with unfortunate consequences.
>
>       Conversely, you could end up printing unrecognized commands
>       to the user, instead of silently ignoring them.
>
>     * You could try and match the bytestream against a tree
>       representing the possible set of responses the K3 might
>       send.  This allows you to return any characters that aren't
>       part of a possible match immediately, but you are still
>       subject to the unrecognized command and ';' problems.
>
>     * You could try and use timings, on the basis that the
>       spacing between characters directly from the K3 is likely
>       to be a lot less than spacing between interpreted CW or data mode
>       characters.  This seems a bit unclean though, and would
>       require careful calibration of the timeout value to be used.
>       I'll admit to not having done the maths here yet.
>
>       This is also not necessarily as easy as one might hope in
>       higher-level languages; especially if the program
>       itself is threaded as well.  Before anyone says "Well, you
>       should be using C anyway for low-level serial interface
>       work", there are good reasons for using a more dynamic and
>       flexible language!
>
> I'd be very interested to hear from anyone with experience of
> doing this, but I also have an associated feature request.
>
> How about a second mode for text-to-terminal, whereby text would
> be sent one 'word' at a time, but wrapped up as a message from
> the K3.  This could perhaps be activated with TT2;
>
> Disadvantages:
>
> * Bandwidth overhead on the serial line
> * Introduces a bit of extra latency.  This could be minimized by
>   sending a string whenever the K3 would insert a space in its
>   own display, and after a timeout.  The K3 is probably better
>   placed to make these decisions.
>
> Advantages:
>
> * Much easier for a program to handle the incoming data, because
>   everything is wrapped up inside a message and can therefore be
>   handled uniformly.
> * Unrecognized responses (due to incomplete protocol
>   implementation, future extensions or noise on the serial line)
>   can be silently ignored, instead of being seen by the users.
> * No problems with ';' being sent by other stations (although
>   you'd need some kind of escaping system in place.)
> * The messages could be structured to allow a client program to
>   distinguish between messages sent and messages received, so
>   they can be treated separately.
> * Messages could include the speed of incoming CW.  This might
>   seem odd, but would them allow a client program to provide a
>   means to easily, and temporarily, match a calling station's
>   speed (for example, during a contest).
>
> An example format might be:
>
> XXYY:Foo bar baz;
>
> Where XX is the command code, and YY: specifies the speed of the
> incoming CW.  Special values of YY could indicate the difference
> between incoming and outgoing CW.
>
> Thoughts?
>
> Thanks and 73,
>
>