Re: Hamlib keying

[Thomas Beierlein]

Hi Chris,


Am Tue, 30 Nov 2021 20:28:10 +0100
schrieb Thomas Beierlein :
> 
> > > - Sending Fx-messages does not work at all and gives no error or
> > >   warning.
> > 
> > That shouldn't make a difference and is probably a followup error
> > from the above. Do the Fx keys start by issuing a stop morse
> > command? That would explain the trouble.
> >   
> No, not really. There are also no error messages at all. Maybe it is a
> problem with my rig (TS590), so I will dig a little bit deeper myself.
> 
I just had a look into it.

1. I have to correct myself as there are error messages, but after only
after the time the message  should need for sending

2. It shows that the message strings are '\n' terminated. Seems Kenwood
does not accept that character in hamlib_send_morse() but cwdaemon and
other rigs just ignores them.

Tested with '\n' removed and the message gets send.

Let me look how to handle it best (drop newline from the message body
or filter it out during message send).

73, Tom


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Hamlib keying

[Thomas Beierlein]

Hi Chris,

after CQWW is finished now, back to your PR. Thanks for driving it
forward.

 Am Fri, 26 Nov 2021 21:22:11 +0100
schrieb Christoph Berg :

> I finally found the time to finish this. Thanks to Nick Craig-Wood
> (@ncw) for merging his patch with this one!
> 
> Pull request: https://github.com/Tlf/tlf/pull/294
> 
> Re: Thomas Beierlein
> > > The general feature (calling stop_morse) already works, only the
> > > support in rigctld was missing.
> > >   
> > Just made some first tests (TS590S + Hamlib-4.3.1) with mixed
> > results:
> > 
> > - Sending CW per keyer window works as expected.
> > 
> > - Leaving keyer window (ESC) gives me a messsage about missing
> >   supported for stopping - first time with the default error colors
> >   (white on blue), after that only black on white.   
> 
> Hmm. Either I didn't understand the way Tlf reports errors correctly,
> or this is generally a problem. Part of the pull request is one commit
> that attempts to print better Hamlib errors.
> 
I will look into the color problem wrt TLF_INFO and friends.

> Generally, only few rigs support stopping morse sending. Mine does, so
> it wasn't a problem for me, but possibly we should catch that on
> startup, print a warning, and then just not do anything at runtime.
> 
Right, I just commented the problem on the PR with teh same suggestion. 
Just saw your mail to late :-(.

May be good to add a warning about the stop support in the man page.

> > - The delay after the message maybe a little bit long.  
> 
> That's the default delay in TLF_LOG_WARN.
> 
Should be no problem, as soon as we change as above.

> > - Sending Fx-messages does not work at all and gives no error or
> >   warning.  
> 
> That shouldn't make a difference and is probably a followup error from
> the above. Do the Fx keys start by issuing a stop morse command? That
> would explain the trouble.
> 
No, not really. There are also no error messages at all. Maybe it is a
problem with my rig (TS590), so I will dig a little bit deeper myself.

> > > Earlier this evening I used the patch in the MWC contest both in
> > > S and running mode, and everything seemed ok.  
> > 
> > Fine. I think it could need some more tests from different rigs. I
> > can imagine a period of time during which not all rigs will support
> > stopping CW. That should be handled more graceful.  
> 
> Agreed.
> 
> > > I guess that means I have to write some documentation now :)
> > >   
> > At least the keyword needs to be documented in the man page.   
> 
> The feature is documented now.

Looks good.

73, Tom


-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Hamlib keying

[Christoph Berg]

I finally found the time to finish this. Thanks to Nick Craig-Wood
(@ncw) for merging his patch with this one!

Pull request: https://github.com/Tlf/tlf/pull/294

Re: Thomas Beierlein
> > The general feature (calling stop_morse) already works, only the
> > support in rigctld was missing.
> > 
> Just made some first tests (TS590S + Hamlib-4.3.1) with mixed results:
> 
> - Sending CW per keyer window works as expected.
> 
> - Leaving keyer window (ESC) gives me a messsage about missing
>   supported for stopping - first time with the default error colors
>   (white on blue), after that only black on white. 

Hmm. Either I didn't understand the way Tlf reports errors correctly,
or this is generally a problem. Part of the pull request is one commit
that attempts to print better Hamlib errors.

Generally, only few rigs support stopping morse sending. Mine does, so
it wasn't a problem for me, but possibly we should catch that on
startup, print a warning, and then just not do anything at runtime.

> - The delay after the message maybe a little bit long.

That's the default delay in TLF_LOG_WARN.

> - Sending Fx-messages does not work at all and gives no error or
>   warning.

That shouldn't make a difference and is probably a followup error from
the above. Do the Fx keys start by issuing a stop morse command? That
would explain the trouble.

> > Earlier this evening I used the patch in the MWC contest both in S
> > and running mode, and everything seemed ok.
> 
> Fine. I think it could need some more tests from different rigs. I can
> imagine a period of time during which not all rigs will support
> stopping CW. That should be handled more graceful.

Agreed.

> > I guess that means I have to write some documentation now :)
> > 
> At least the keyword needs to be documented in the man page. 

The feature is documented now.

Christoph

Re: Hamlib keying

[Thomas Beierlein]

Am Mon, 1 Nov 2021 22:36:08 +0100
schrieb Christoph Berg :

> Re: Thomas Beierlein
> > Am Fri, 29 Oct 2021 22:40:10 +0200
> > schrieb Christoph Berg :
...
> > > 
> > > \stop_morse was simply not implemented in rigctld yet, but the
> > > patch has already been merged:
> > > 
> > > https://github.com/Hamlib/Hamlib/commit/8cba9d7ee939b47dffbf057284d70aefafd65b41
> > > 
> > > Christoph
> > >   
> > 
> > That means the feature will be implemented in coming hamlib version
> > starting from 4.4? So I think we should have it ready for TLF around
> > that time.  
> 
> The general feature (calling stop_morse) already works, only the
> support in rigctld was missing.
> 
Just made some first tests (TS590S + Hamlib-4.3.1) with mixed results:

- Sending CW per keyer window works as expected.

- Leaving keyer window (ESC) gives me a messsage about missing
  supported for stopping - first time with the default error colors
  (white on blue), after that only black on white. 

- The delay after the message maybe a little bit long.

- Sending Fx-messages does not work at all and gives no error or
  warning.


> 
> Earlier this evening I used the patch in the MWC contest both in S
> and running mode, and everything seemed ok.

Fine. I think it could need some more tests from different rigs. I can
imagine a period of time during which not all rigs will support
stopping CW. That should be handled more graceful.
> 
> I guess that means I have to write some documentation now :)
> 
At least the keyword needs to be documented in the man page. 

73, Tom



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Hamlib keying

[Christoph Berg]

Re: Thomas Beierlein
> Am Fri, 29 Oct 2021 22:40:10 +0200
> schrieb Christoph Berg :
> 
> > Re: To tlf-devel@nongnu.org
> > > In fact aborting the message does work, but rigctld isn't properly
> > > forwarding the request through for the IC-7610 here.  
> > 
> > \stop_morse was simply not implemented in rigctld yet, but the patch
> > has already been merged:
> > 
> > https://github.com/Hamlib/Hamlib/commit/8cba9d7ee939b47dffbf057284d70aefafd65b41
> > 
> > Christoph
> > 
> 
> That means the feature will be implemented in coming hamlib version
> starting from 4.4? So I think we should have it ready for TLF around
> that time.

The general feature (calling stop_morse) already works, only the
support in rigctld was missing.

I rebased the patch, included the typo fix you spotted, and pushed a
new version to https://github.com/df7cb/tlf/tree/hamlib-cw .

Earlier this evening I used the patch in the MWC contest both in S
and running mode, and everything seemed ok.

I guess that means I have to write some documentation now :)

73,
Christoph DF7CB

Re: Hamlib keying

[Thomas Beierlein]

Am Fri, 29 Oct 2021 22:40:10 +0200
schrieb Christoph Berg :

> Re: To tlf-devel@nongnu.org
> > In fact aborting the message does work, but rigctld isn't properly
> > forwarding the request through for the IC-7610 here.  
> 
> \stop_morse was simply not implemented in rigctld yet, but the patch
> has already been merged:
> 
> https://github.com/Hamlib/Hamlib/commit/8cba9d7ee939b47dffbf057284d70aefafd65b41
> 
> Christoph
> 

That means the feature will be implemented in coming hamlib version
starting from 4.4? So I think we should have it ready for TLF around
that time.

Tom

-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Hamlib keying

[Christoph Berg]

Re: To tlf-devel@nongnu.org
> In fact aborting the message does work, but rigctld isn't properly
> forwarding the request through for the IC-7610 here.

\stop_morse was simply not implemented in rigctld yet, but the patch
has already been merged:

https://github.com/Hamlib/Hamlib/commit/8cba9d7ee939b47dffbf057284d70aefafd65b41

Christoph

Re: Hamlib keying

[Christoph Berg]

Re: Thomas Beierlein
> But anyway - your work looks promising. What most users will miss is
> the ability to abort the message. It would be good to have a
> solution for that problem before merging it in.

In fact aborting the message does work, but rigctld isn't properly
forwarding the request through for the IC-7610 here. rigctld is also
introducing some modestly annoying 500ms delay before sending which
might indicate it's having some trouble with that trx. Will have to
debug that on the hamlib side.

> > One problem I have is the baroque handing of CW speed in Tlf:
> > 
> > #define CW_SPEEDS   "06121416182022242628303234363840424446485060"
> > /*< speed string with 2 chars each (in WPM) */
> 
> I did some search in historic versions of TLF (0.9.10, 0.9.38). The
> code above is an ancient left over from former times. (Maybe original
> author Rein was a BASIC fan - quite a lot of operations were done as
> string manipulations). See it as just a weird coded table.
> 
> Having the speed settings as a table allows for a nonlinear stepping -
> heavily used in 0.9.10, now only seen on both ends. A plain up/dwn 
> by +/- 2wpm would loose that ability. 

Hmm. I'd say it's not really used now, except for the two jumps at
either end. It would make some sense to have smaller steps for lower
speeds, and bigger steps at higher speeds, but right now it's always
2 wpm.

> Maybe we should extend here and allow the user to set its own speed
> stepping. Any thoughts on that?

If you are thinking of letting the user provide their own CW_SPEEDS
strings, that's probably a lot of programming effort for little gain,
and also not really nice UX.

A single setting WPM_ADJUST = int 1/2/3/4 is more intuitive and
possibly good enough.

Thanks for the feedback, will continue working on this.

73,
Christoph DF7CB

Re: Hamlib keying

[Thomas Beierlein]

Hi Christoph,

there were some request for that feature from time to time. Iirc the
last time someone told us there was some cwdaemon like program talking
to the rig via hamlib.

But anyway - your work looks promising. What most users will miss is
the ability to abort the message. It would be good to have a
solution for that problem before merging it in.

> One problem I have is the baroque handing of CW speed in Tlf:
> 
> #define CW_SPEEDS   "06121416182022242628303234363840424446485060"
> /*< speed string with 2 chars each (in WPM) */

I did some search in historic versions of TLF (0.9.10, 0.9.38). The
code above is an ancient left over from former times. (Maybe original
author Rein was a BASIC fan - quite a lot of operations were done as
string manipulations). See it as just a weird coded table.

Having the speed settings as a table allows for a nonlinear stepping -
heavily used in 0.9.10, now only seen on both ends. A plain up/dwn 
by +/- 2wpm would loose that ability. 

Maybe we should extend here and allow the user to set its own speed
stepping. Any thoughts on that?

73, de Tom DL1JBE



 Am Mon, 25 Oct 2021 00:05:19 +0200
schrieb Christoph Berg :

> Hi,
> 
> I've been poking around with adding support for CW keying via Hamlib
> to Tlf. I have it somewhat working. :)
> 
> https://github.com/df7cb/tlf/tree/hamlib-cw
> 
> Basically the status is:
> 
> Working:
> * Hamlib keyer is activated by HAMLIB_KEYER keyword
> * CW sending works
> * setting CW speed works
> * reading CW speed from rig (when adjusted via knob or menu) works
> 
> TODO:
> * rig CW support is detected by rig type, but should be queried
> from the actual rig (makes a difference with rigctld)
> * aborting CW doesn't work yet
> * less than ideal interaction with the cw speed stepping in Tlf
> * no other keyer commands (pitch etc) supported yet
> 
> I've been reading through
> 
> https://www.mail-archive.com/tlf-devel@nongnu.org/msg02341.html
> 
> and I don't have a solution for implementing in-message speed changes
> yet (+++TEST---), but if it turns out not to be feasible, I'd think
> having the general feature would still be nice - less cables, and the
> ability to turn the keyer speed knob on my IC7610 and having Tlf pick
> that up is already nice.
> 
> One problem I have is the baroque handing of CW speed in Tlf:
> 
> #define CW_SPEEDS   "06121416182022242628303234363840424446485060"
> /*< speed string with 2 chars each (in WPM) */
> 
> What's the reasoning behind that? Storing the desired WPM in a plain
> integer would be much cleaner, and PgUp/PgDn could still adjust the
> speed in 2-wpm steps instead of doing string mangling all the time.
> 
> Christoph DF7CB
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--

Re: Hamlib keying

[Onno VK6FLAB]

Nice!

After writing my ssbdaemon wrapper around cwdaemon, it occurred to me today
that I might be able to do a similar thing with hamlib, using socat or
something like that. It will have to wait until after CQWW this weekend :-)

73, de Onno VK6FLAB

On Mon, 25 Oct 2021 at 15:41, Christoph Berg  wrote:

> Re: Onno VK6FLAB
> > Hi Christoph,
> >
> > Out of interest, why did you not add hamlib functionality to cwdaemon
> > instead?
>
> I want to get rid of extra moving parts. Tlf is already talking to
> Hamlib directly for the frequency and mode, why not use that
> connection for keying as well?
>
> I have a cwdaemon-compatible daemon that talks to Hamlib, but that's
> something extra I have to take care of when starting CW operation, and
> it doesn't have the ability to read the keyer speed from the rig to
> feed back into Tlf:
>
> https://github.com/df7cb/df7cb-shack/blob/master/cwdaemon/hamlibcw.c
>
> Christoph
>


-- 
73, de Onno VK6FLAB

Listen to the Foundations of Amateur Radio Podcast
 or check out the eBooks
.

Re: Hamlib keying

[Christoph Berg]

Re: Onno VK6FLAB
> Hi Christoph,
> 
> Out of interest, why did you not add hamlib functionality to cwdaemon
> instead?

I want to get rid of extra moving parts. Tlf is already talking to
Hamlib directly for the frequency and mode, why not use that
connection for keying as well?

I have a cwdaemon-compatible daemon that talks to Hamlib, but that's
something extra I have to take care of when starting CW operation, and
it doesn't have the ability to read the keyer speed from the rig to
feed back into Tlf:

https://github.com/df7cb/df7cb-shack/blob/master/cwdaemon/hamlibcw.c

Christoph

Re: Hamlib keying

[Onno VK6FLAB]

Hi Christoph,

Out of interest, why did you not add hamlib functionality to cwdaemon
instead?

On Mon, 25 Oct 2021 at 06:05, Christoph Berg  wrote:

> Hi,
>
> I've been poking around with adding support for CW keying via Hamlib
> to Tlf. I have it somewhat working. :)
>
> https://github.com/df7cb/tlf/tree/hamlib-cw
>
> Basically the status is:
>
> Working:
> * Hamlib keyer is activated by HAMLIB_KEYER keyword
> * CW sending works
> * setting CW speed works
> * reading CW speed from rig (when adjusted via knob or menu) works
>
> TODO:
> * rig CW support is detected by rig type, but should be queried from
> the
>   actual rig (makes a difference with rigctld)
> * aborting CW doesn't work yet
> * less than ideal interaction with the cw speed stepping in Tlf
> * no other keyer commands (pitch etc) supported yet
>
> I've been reading through
>
> https://www.mail-archive.com/tlf-devel@nongnu.org/msg02341.html
>
> and I don't have a solution for implementing in-message speed changes
> yet (+++TEST---), but if it turns out not to be feasible, I'd think
> having the general feature would still be nice - less cables, and the
> ability to turn the keyer speed knob on my IC7610 and having Tlf pick
> that up is already nice.
>
> One problem I have is the baroque handing of CW speed in Tlf:
>
> #define CW_SPEEDS   "06121416182022242628303234363840424446485060"
> /*< speed string with 2 chars each (in WPM) */
>
> What's the reasoning behind that? Storing the desired WPM in a plain
> integer would be much cleaner, and PgUp/PgDn could still adjust the
> speed in 2-wpm steps instead of doing string mangling all the time.
>
> Christoph DF7CB
>
>

-- 
73, de Onno VK6FLAB

Listen to the Foundations of Amateur Radio Podcast
 or check out the eBooks
.