Re: Using hamlib for CW keying
* On 2019 23 Nov 08:26 -0600, Drew Arnett wrote: > Portable is good. So I'd ask if hamlib found it possible to support > speed changes. Yes. It is done through the set/get_level functions in rigctl with the KEYSPD token: $ rigctl -m 229 -r /dev/rig Rig command: l Level: KEYSPD Level Value: 22 Rig command: L Level: KEYSPD Level Value: 18 Rig command: l KEYSPD Level Value: 18 Rig command: b N0NB Rig command: L KEYSPD 22 Rig command: b N0NB Rig command: l Level: KEYSPD Level Value: 22 Rig command: Works on my K3. > KX3 is only 3 wire serial CAT interface, so no RTS/DTR style keying > possible. In that case, I suppose a Y cable could be fabricated that > fans out RTS/DTR to a separate key plug. That's a bit tidier perhaps. > > Another difference between rigs. Some have a jack for paddles and a > jack for key. KX3 doesn't, so I like using the external WinKeyer box > to let logging software and paddles key the rig. Using the WinKeyer > box means I'll have a common solution regardless of which rig I end up > using. (Operating at home, operating at someone else's station, FD > and other situations where the gear is an assortment from all the > participants, etc.) This is one of those "wishlist" items that understandably will not work with every radio. For those it does, it can be quite useful. > Another bonus using a WinKer (or equivalent) is that the paddle input > then pauses any sending, too. However, recently during contests, I've > been better about using CTRL-K to do fills instead of reaching for the > paddles. I'm still too green to know which method of keying for fills > I will ultimately end up preferring. All of these approaches have tradeoffs, no surprise there. Everyone has their preferred approach. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: TLF-1.4.0 release
* On 2019 23 Nov 08:14 -0600, Drew Arnett wrote: > Resize is fine, but please continue to support 80x25 long term. I > don't see classic TUI losing value anytime soon. Do you mean that Tlf should enforce a minimum 80x25 terminal size as it has in the past? Personally, I've no problem with that. > What about a 2nd application, tlf-config or easy-tlf-config, which > would have the pulldown menus etc for setting up config files. Keep > the pulldown menus out of tlf. Once you add menus, you'll add a bunch > of hotkeys. One of the nice things about TLF is that there aren't a > bunch of live keys, especially if run out of a console or terminal > rather than a windows manager. That's actually a very good idea, Drew. If such a program were to gain good enough coverage then the :SET and :CFG commands could just call it instead of an editor. As for hot keys, Tlf does have quite a few assigned already. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: tlf and the nano editor
Hi, please see the improved version on the same link as yesterday. From the commit message: > Improve editor handling > >- Uses it also for :CFG and :SET commands >- Fall back to editor defined in environment if not defined in > logcfg.dat >- Show warning if editor program not found @nate: I tested it with gedit and gvim -> works. What is emacs doing? 73, de Tom DL1JBE Am Fri, 22 Nov 2019 20:19:53 +0100 schrieb Thomas Beierlein : > Hi all, > > as the fixed choice of editors is quite a nuisance I prepared a > changed version for tests. Please find it at > https://github.com/dl1jbe/tlf/tree/new_editor > > Download the code and build TLF as told in the INSTALL file. Do not > forget the 'autoreconf -i' step. > > The new version accepts any string as editor command and will just > call that program with the logfile name as parameter. > > That means > > EDITOR=my-shiny-editor > > in logcfg.dat will call > > 'my-shiny-editor ' > > So a simple EDITOR=nano should do afterwards. > > Please test and give feedback. > > 73, de Tom DL1JBE > > Am Fri, 22 Nov 2019 11:08:52 -0600 > schrieb jim smith : > > > On Fri, 22 Nov 2019 15:06:14 +0100 > > Joop Stakenborg wrote: > > > > > I have gotten used to the GNU nano editor, but it does not seem to > > > work with tlf. When I type :edit in the callsign field, tlf exits > > > and returns straight away without opening nano. Both joe and vi > > > work okay here. It is hard to debug, have to spent some time on it > > > to see what actually happens. Maybe use gdb with a break added. I > > > will have a look next week. > > > > > > > > > 73 de Joop PG4I > > > > > > > > > Hi Joop, > > > > I don't know if this helps any, but I don't have any problems > > running nano with tlf on ubuntu 18.04. I have *not* updgraded to > > tlf 1.4 yet (was going to do that this weekend. > > > -- "Do what is needful!" Ursula LeGuin: Earthsea --
Re: tlf and the nano editor
Zoli's idea is the first thing I thought of, too. But the suggested method of using EDITOR from tlf config as first priority, then falling back on the shell environmental variable as 2nd priority I think would be better. I could image someone preferring some editor for most of their usual work, but wanting a different one for use from tlf. For example, I might usually use gvim, but want to use vim from tlf. So, EDITOR=gvim in the shell, and EDITOR=vim in the tlf config file. Best regards, Drew n7da On Sat, Nov 23, 2019 at 2:30 PM Nate Bargmann wrote: > > * On 2019 23 Nov 01:18 -0600, Csahok Zoltan wrote: > > My 2c: try with "export EDITOR=..." > > Hi Zoli, > > This is the setting in log_cfg.dat that I am testing with Tom's new > patch to allow specifying any editor, not a shell variable. > > 73, Nate > > -- > > "The optimist proclaims that we live in the best of all > possible worlds. The pessimist fears this is true." > > Web: https://www.n0nb.us > Projects: https://github.com/N0NB > GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 >
Re: tlf and the nano editor
* On 2019 23 Nov 01:18 -0600, Csahok Zoltan wrote: > My 2c: try with "export EDITOR=..." Hi Zoli, This is the setting in log_cfg.dat that I am testing with Tom's new patch to allow specifying any editor, not a shell variable. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Using hamlib for CW keying
Portable is good. So I'd ask if hamlib found it possible to support speed changes. KX3 is only 3 wire serial CAT interface, so no RTS/DTR style keying possible. In that case, I suppose a Y cable could be fabricated that fans out RTS/DTR to a separate key plug. That's a bit tidier perhaps. Another difference between rigs. Some have a jack for paddles and a jack for key. KX3 doesn't, so I like using the external WinKeyer box to let logging software and paddles key the rig. Using the WinKeyer box means I'll have a common solution regardless of which rig I end up using. (Operating at home, operating at someone else's station, FD and other situations where the gear is an assortment from all the participants, etc.) Another bonus using a WinKer (or equivalent) is that the paddle input then pauses any sending, too. However, recently during contests, I've been better about using CTRL-K to do fills instead of reaching for the paddles. I'm still too green to know which method of keying for fills I will ultimately end up preferring. Best regards, Drew n7da On Fri, Nov 22, 2019 at 10:19 PM Nate Bargmann wrote: > > * On 2019 22 Nov 14:31 -0600, Csahok Zoltan wrote: > > Hi Christian, > > > > Yes, keying does work with the script. But as far I can see > > there are two issues with hamlib keying: > > > > - in-band speed changes are not supported. one can't send "+++TEST---" > > > > - sending a large message could block rig interface until it gets queued. > > > > Given the rig protocol (KY command) and the way hamlib supports it > > I see no option to circumvent these. > > > > WinKeyer on the other hand offers in-band speed change and winkeyerdaemon > > provides the buffering for a cwdaemon compatible UDP interface. > > > > Correct me if I'm wrong here. > > You may well be correct, Zoli. As I recall, a speed change would > require sending the proper CAT command each time the change is made. > It's possible this could be done in a manner that doesn't mess up the > timing of the sent Morse, I think it would likely be very rig specific. > > One thing the K3 and the later models can do is be keyed via the RTS/DTR > line and N1MM+ takes full advantage of that, speed changes and all. > Problem is whether more rigs support that and whether Hamlib supports > it. Even though I've been a part of the Hamlib project for quite some > time, I'm not sure! There may be some provision but probably needs some > debugging. Again, this is a feature that is rig specific. > > 73, Nate > > -- > > "The optimist proclaims that we live in the best of all > possible worlds. The pessimist fears this is true." > > Web: https://www.n0nb.us > Projects: https://github.com/N0NB > GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 >
Re: TLF-1.4.0 release
Resize is fine, but please continue to support 80x25 long term. I don't see classic TUI losing value anytime soon. What about a 2nd application, tlf-config or easy-tlf-config, which would have the pulldown menus etc for setting up config files. Keep the pulldown menus out of tlf. Once you add menus, you'll add a bunch of hotkeys. One of the nice things about TLF is that there aren't a bunch of live keys, especially if run out of a console or terminal rather than a windows manager. Best regards, Drew n7da On Fri, Nov 22, 2019 at 2:17 AM Nate Bargmann wrote: > > Some items to add to your list, Tom. > > - Send Morse via Hamlib for radios that support it. > > - Rework the voice keyer so that Esc could stop the voice keyer. This >is another feature that I found in N1MM+ that is welcome. At the >moment the voice file is passed to a script so once that happens Tlf >loses control. Perhaps even something as simple as getting the PID >of the script, if possible, and killing it directly. This may have >unintended side effects so would require much testing. Another >thought is to deliver the file to ALSA or Pulse Audio directly and be >able to stop playback at will. > > - WISHLIST: Incorporate some method of pull-down menus for >configuration. Doing so might encourage more use of Tlf? I don't >know if that amount of work would be productive or not. I'm certain >it can probably generate a lot of discussion. ;-) > > - WISHLIST: Along with the above, move away from log_cfg.dat and the >rules files toward configuration through the UI and a common config >file that doesn't require hand editing. > > - WISHLIST: Rework the curses UI to avoid the 80x25 hard coded screen >size. I've looked into this a time or two and doing this won't be >easy but is probably required for enough screen estate if menus are >to be implemented. At the least, more vertical screen space could >show more log lines or DX spots, for example. > >Given that Tlf is likely to be used on a later distribution under X >or Wayland with a terminal emulator, an 80x25 limit is a bit >restrictive. OTOH, I set up an Xterm such that it is 80x25 with a >nice big font that works well. Even modern distributions use a frame >buffer on the console that is larger than 80x25. > > The last three items are "down the road", likely a 2.0 release or even > later. There is plenty of time for discussion on these. > > 73, Nate > > -- > > "The optimist proclaims that we live in the best of all > possible worlds. The pessimist fears this is true." > > Web: https://www.n0nb.us > Projects: https://github.com/N0NB > GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 >
