[Elecraft] K3 programming - Text decode
Mike Clarke
clarkema at clarkema.org
Thu May 21 19:37:28 EDT 2009
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,
--
Mike, M0PRL
More information about the Elecraft
mailing list