Re: [Xlog-discussion] Xlog Keyer Bug....

[Rob Frohne]

Hi Tomi,

I did a bit more looking into this, and it appears that the real issue
is at the unixcw level.  That program provides routines that will block
your program until an element is sent, but not for a whole character.
Perhaps Simon can advise us.

Most of us get around the keying problem by using VOX, but not all rigs
have that. 

Yes, cwdaemon uses UDP.  TCP/IP has possible issues with no arrival time
guaranteed, but that should be minimal with most CW, and network
connections to localhost. 

To  me this problem seems like a pretty serious lack for any program
that actually keys the transmitter.

73,

Rob, KL7NA

On Mon, 2007-09-03 at 22:36 +0300, Tomi Manninen wrote:
> Rob Frohne wrote:
> 
> > I did a little poking around and looking at the issues involved here,
> > and I need some advice from those more sage than I when it comes to
> > programming.  The problem is that in cwdaemon, letters are cued to
> > unixcw as fast as they come in.  Once they are cued, they cannot be
> > recalled easily, it appears.    
> 
> This is the problem I have with gMFSK as well. To be able to support
> cwdaemon (and thus CW keying with hardware) properly, I would need
> 1) feedback on when a letter has been sent, 2) feedback on when the
> whole message is sent (so I can release PTT). Doing #1 and only
> queuing one character at a time would also enable correcting for
> typos.
> 
> > What we want I believe is a message from unixcw when a character is
> > about to be finished, (maybe when it just finished the last sound of a
> > character) at which time we can cue another character with unixcw.  In
> > another thread in cwdaemon, we maintain the buffer that can be edited.  
> 
> I think cwdaemon could just as well stay single threaded. It just needs
> to somehow "block" the client (client would need to be multithreaded to
> not freeze completely while talking to cwdaemon). I think we need a TCP
> based version of cwdaemon as it might be unnecessarily difficult to
> implement this properly with UDP (cwdaemon still uses UDP doesn't it?).
> 
> > Is this the best way to do this?  Another way would be to assume that
> > the speed is correct, and do a calculation that tells cwdaemon how long
> > to wait until it sends the next character.  I am tempted to do this
> > because I think I have a much better idea how to do it, though it may
> > not be as accurate as I would like.
> 
> I don't think this is a good idea. It might work but it just
> isn't the Right Way (tm) to do it IMHO.
>