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, > > ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[email protected] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
