Re: enable python Plugin
Re: Csahok Zoltan > Hello Herve, > > python-config in Debian/Ubuntu is part of python3-dev package. Not sure about > the OS you are using. > For a reference you can check the step "Install dependencies" in > https://github.com/Tlf/tlf/blob/master/.github/workflows/ci-build.yml Also make sure you don't have an ancient python version installed in /usr/local/. > >checking for /usr/local/bin/python3 version... (cached) 3.1 73, Christoph DF7CB
Re: ToDo item: switch logfile to database
Re: Thomas Beierlein > Two points here: > > - Journaling is easy, but to be honest TLF provides quite some > robustness in that sense too. I have not heard any complies about > lost data in all the years. Some time last year, I was auditing (well, reading) the tlf source to check that. There are sync() and fsync() calls in there, so it's probably mostly safe, but since calls that write to disk are spread over the code, data safety looks quite ad-hoc. If power goes out while the log is just being written, I'd bet there will be problems. Switching to sqlite would get us crash safety for free since that's a library specifically written for that. https://www.sqlite.org/howtocorrupt.html But sqlite is not a networking database. If you want that, use PostgreSQL. 73, Christoph DF7CB
Re: Hamlib keying
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
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
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
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
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
Hamlib keying
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
Re: why 25 rows?
Re: Drew Arnett > Dumb question: why 25 rows? Sorry for asking first, before examining code. I think you can start with more rows and then resize to 20 rows and it still works. The restriction seems to remain from the time where resizing the window wasn't supported. (With less rows things start to overwrite each other.) Christoph
Re: Anyone else compiling with GCC 10.2 on Debian Testing?
Re: Nate Bargmann > ../../tlf/src/cqww_simulator.c:155:15: warning: adding 'int' to a string does > not append to the string [-Wstring-plus-int] > "+++" + 3 - slow); > ~~^~~ > ../../tlf/src/cqww_simulator.c:155:15: note: use array indexing to silence > this warning > > I'm going to be puzzling that one out for a bit. As it says, use array indexing: "+++"[3 - slow] Christoph
