Login  Register

K3 programming - Text decode

classic Classic list List threaded Threaded
5 messages Options Options
Embed post
Permalink
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

K3 programming - Text decode

Mike Clarke-5
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
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: K3 programming - Text decode

Leigh L. Klotz Jr WA5ZNU
Administrator
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:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: K3 programming - Text decode

Julian, G4ILO

Leigh L. Klotz Jr WA5ZNU wrote
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
You wouldn't want to wait for 16 characters before getting the text back in CW.

Actually the KY command can accept up to 24 characters but you have to poll the status. If the buffer is empty you can send 24, if it is part full you can send (I think) 6 characters.

I have tried using TT1 but it was not reliable because it is possible for the text stream to include characters that look like responses to other commands. Wayne has stated that a command to allow a program to get the received text in a more structured manner will be available. I decided it's easier to wait for that than try to work around it.

By the way, Leigh, did you or Dave manage to look in to why Fldigi for Windows 3.11 hangs when using my k3.xml file that works fine with every previous version?
Julian, G4ILO. K2 #392  K3 #222 KX3 #110
* G4ILO's Shack - http://www.g4ilo.com
* KComm - http://www.g4ilo.com/kcomm.html
* KTune - http://www.g4ilo.com/ktune.html
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: K3 programming - Text decode

Paul Fletcher
In reply to this post by Mike Clarke-5

Mike Clarke-5 wrote
The manual states "Returned strings are never interspersed with
text data, so this can easily be done."  Ahem.
Hi Mike,

I think that (reading between the lines) it is the responses from the radio that are the issue you are concerned with because commands sent to the radio aren't a big deal.

I fully agree that text wrapped up in a command response would help you but thought I would share the approach I've used plus a few other thoughts that may help.

I have used a similar technique to one of the ones you mentioned. Each response that I'm looking for is stored in a table as the two character response code together with format info (i.e. numerals, alphas, any special characters etc) and length of response.

I examine the incoming data looking for possible matches to the start of a response, and as soon as a matching pair is found the subsequent data is examined as it arrives to make sure it matches the expected format. If it doesn't or a semicolon is received before or after it is expected the state machine goes back to looking for a valid response.

Whilst this doesn't eliminate the possibility of someone sending an exact K3 command response in CW it is more robust. This approach works for me because I know what response I am expecting as I keep track of which commands are pending a response (taking into account that commands need to be able to time out).

Another possible approach is to take the LP-Bridge route where the software maintains a virtual K3 so client apps don't talk directly to the radio. This would allow you to take complete control over the command / response cycle so you would know what responses to expect and when.

73 Paul
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: K3 programming - Text decode

Joe Subich, W4TV-4
In reply to this post by Mike Clarke-5

> How does one connect N1MM Logger to the K3 so you can execute a
> pre -recorded memory in the DVR from Logger, it will be nice option.

You will need to write custom macros in N1MM Logger using the
{CAT1ASC ...} and {CAT2ASC ...} commands.  Typically that would
be {CAT1ASC SWT21;} to play message 1 on Radio 1 or {CAT2ASC SWT39;}
to play message 4 on Radio 2.

73,

   ... Joe, W4TV
 


> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Gordan Hribar
> Sent: Friday, May 22, 2009 5:38 AM
> To: [hidden email]
> Subject: Re: [Elecraft] K3 programming - Text decode
>
>
> Hi,
>  
> How does one connect N1MM Logger to the K3 so you can execute a
> pre -recorded memory in the DVR from Logger, it will be nice option.
>  
> 73,
> E72X-Gordan
>
> --- On Fri, 5/22/09, Julian, G4ILO <[hidden email]> wrote:
>
>
> From: Julian, G4ILO <[hidden email]>
> Subject: Re: [Elecraft] K3 programming - Text decode
> To: [hidden email]
> Date: Friday, May 22, 2009, 11:05 AM
>
>
>
>
>
> Leigh L. Klotz Jr WA5ZNU wrote:
> >
> > 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
> >
> >
>
> You wouldn't want to wait for 16 characters before getting
> the text back in CW.
>
> Actually the KY command can accept up to 24 characters but
> you have to poll the status. If the buffer is empty you can
> send 24, if it is part full you can send (I think) 6 characters.
>
> I have tried using TT1 but it was not reliable because it is
> possible for the text stream to include characters that look
> like responses to other commands. Wayne has stated that a
> command to allow a program to get the received text in a more
> structured manner will be available. I decided it's easier to
> wait for that than try to work around it.
>
> By the way, Leigh, did you or Dave manage to look in to why
> Fldigi for Windows 3.11 hangs when using my k3.xml file that
> works fine with every previous version?
>
> -----
> Julian, G4ILO. K2 #392  K3 #222.
> http://www.g4ilo.com/ G4ILO's Shack   
> http://www.g4ilo.com/kcomm.html KComm for Elecraft K2 and K3  
>  http://www.wota.org.uk/ Wainwrights On The Air
>
> --
> View this message in context:
> http://n2.nabble.com/K3-programming---Text-decode-tp2954806p29
56196.html
Sent from the Elecraft mailing list archive at Nabble.com.

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html



     
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html