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 <c...@df7cb.de>: > 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 --
