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