Re: feature request: cabrillo template
Hi Erwin, let me explain how I setup a contest (but maybe there is a better way). I have a directory called tlf, which is divided into sub-directories which all have a contest name. Below the contest name is the date (in case a contest happens more than once a year) or the year. Once I created the directory structure for the contest which is coming up, I copy all the data from the previous contest. This includes logcfg.dat, the rules file, but also any sections file or exchange file. Then I do a check of all the files, start winkeydaemon, open a terminal with a big font, go into that directory and start tlf. So for me, number one would be most convenient. I check my files anyway, also after the contest I go into the cabrillo file and do a review. But I am not very critical, whatever is easiest for you is okay with me. I will adapt ;-) 73 de Joop PG4I Ervin Hegedüs schreef op 2019-11-21 22:49: Hi all, On Sun, Nov 17, 2019 at 10:32:16AM +0100, Joop Stakenborg wrote: It would be nice to have a cabrillo template. If present, all the questions when exporting to cabrillo can be skipped. a few days ago I reviewed the possibilities, now I'ld like to discuss them here. 1. the most simple way when we add new keywords to the config files, eg. CABRILLO_CONTEST, CABRILLO_CALLSIGN, ... therefore you can use these keywords both in logcfg.dat and contest rule files PRO: easy to make it CON: you have to add the keywords everytime when you prepare a new contest 2. read the new keywords from separated file; there are two sub-solution in this case a. this file could contains only the CABRILLO related options PRO: clear and elegant solution CON: hard to implement, makes the code logic more complicated and horrible b: this fie could any keyword, we just "call it" as "CABRILLO" file PRO: *could* be clear, easy to implement CON: can lead to chaos (user can mix the options and can't see the reason of the different bevaiour) Let's start to discuss :). I prefer 2/b. 73, Ervin HA2OS
Re: Don't forget Winkeydaemon!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Thu, 21 Nov 2019 19:31:11 -0600 schrieb Nate Bargmann : > Many years ago (late 2007) Rein, PA0R, wrote up a Perl script to work > with the K1EL series of Winkeyers. I found that it worked with my > HamGadgets MK-1 which has a K1EL compatible interface. > ... > > The winkeydaemon is a drop-in replacement for cwdaemon for the K1EL > Winkeyer series and any compatibles, like mine. I have used it > throughout a weekend with Tlf with no issues. > Same here. I have the K3NG arduino based nanoKeyer. It works without hassle. 73, de Tom DL1JBE > > All that said, if anyone has one of the Winkeyer USB models, I'd > appreciate some testing. A friend has been having trouble getting his > to work with winkeydaemon and we've not gotten together to try > troubleshooting it. > > 73, Nate > - -- "Do what is needful!" Ursula LeGuin: Earthsea - -- -BEGIN PGP SIGNATURE- iF0EARECAB0WIQTY6BXzAKH/Wa02IMhB7i6pdiBT1QUCXdeE8QAKCRBB7i6pdiBT 1f+XAJ9pT1OyI3uwE5Z07qID5KCmuz3/fgCfbkQSp4FKUECXxQDXZa1CtDqypgk= =Jo8e -END PGP SIGNATURE-
Re: TLF-1.4.0 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Nate, Am Thu, 21 Nov 2019 20:17:41 -0600 schrieb Nate Bargmann : > Some items to add to your list, Tom. > snip . I will add the points to the list. Thanks. I am sure there will be some discussion about the menus. Let us see. One last point: > - 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. > Vertical resize is already done in TLF-1.4.0. Just try it. It could use a more flexible screen layout during resize, but in the moment you get a lot of vertical space for the bandmap display. Horizontal resize has still to be done. 73, de Tom DL1JBE - -- "Do what is needful!" Ursula LeGuin: Earthsea - -- -BEGIN PGP SIGNATURE- iF0EARECAB0WIQTY6BXzAKH/Wa02IMhB7i6pdiBT1QUCXdeENAAKCRBB7i6pdiBT 1ZysAJ4zxyQ1yZ5rmaJhO+lpuFudQYpj1gCfU5TWBhM/bHO7dUbwxjDA8Dt6UCA= =Nczr -END PGP SIGNATURE-
Re: TLF-1.4.0 release
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 signature.asc Description: PGP signature
Re: Using hamlib for CW keying
It should be possible. We've had a few threads on this topic: https://lists.nongnu.org/archive/html/tlf-devel/2015-08/msg0.html https://lists.nongnu.org/archive/html/tlf-devel/2015-12/msg1.html https://lists.nongnu.org/archive/html/tlf-devel/2018-11/msg00027.html I seem to recall trying to figure out how this might be done in Tlf and got lost... 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
Don't forget Winkeydaemon!
Many years ago (late 2007) Rein, PA0R, wrote up a Perl script to work with the K1EL series of Winkeyers. I found that it worked with my HamGadgets MK-1 which has a K1EL compatible interface. Joop had done some development with it to include it in Debian, as near as I could tell, back in January 2008. I think it was dropped from Debian several releases ago. I am unaware of any other distributions that may include it. Wilbert, PE7T, did some development work and hosted his modified version on his Web site. I gathered together the various pieces and put them into Git and have hosted the code at GitHub for some time: https://github.com/N0NB/winkeydaemon Wilbert has added more contributions over the years, as have Zoltan Csahok and Tom, DJ1JBE, (Tom fixed a bug just a couple of weeks ago!). The winkeydaemon is a drop-in replacement for cwdaemon for the K1EL Winkeyer series and any compatibles, like mine. I have used it throughout a weekend with Tlf with no issues. Yes, the code is Perl 5 which is quite stable but does have the Perl characteristic of looking like line noise at times, however, this script is easy to follow, so new contributions are welcome! All that said, if anyone has one of the Winkeyer USB models, I'd appreciate some testing. A friend has been having trouble getting his to work with winkeydaemon and we've not gotten together to try troubleshooting it. 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
Hi Ervin
Tnx fer your script it has been in good use until now.
Den 21.11.2019 kl. 14.58 skrev Ervin Hegedüs:
Hi Christian,
On Thu, Nov 21, 2019 at 12:29:38PM +0100, Christian Treldal wrote:
A year or something ago Ervin wrote a quick Python2 script for keying via
hamlib. It has n
I MADE A PYTHON SCRIPT? :D
Could share with me/us? :)
Yes Ervin AND THE EVIDENCE!!!
https://www.dropbox.com/s/ofn5p482dsf49tv/rigkeyer.py
I've been trying to convert it to Py3 , no capitals in socketserver and
remove .decode("utf8") and is seems to run; but it don't send anything
to the radio.
been working flawlessly until now. I've upgraded to Fedora31 and Python2 has
been depreciated. I am trying to convert it to python3;
But I think it is a good time for a humble feature request for Tlf 1.x.x. A
build in hamlib keyer, so at least I can avoid stressfull expiriences like
this.
All modern rigs have keying via hamlib.
you mean aboue like K3? Once I started to review how does it
works, but IMHO it's too difficult. We discussed about this topic with
Zoli HA5CQZ, but now I don't remember the results.
I've been using it with my KX3 and no problems. In the beginning there
was a buffer overflow in hamlib; but it seems to be ok now
I tested today $echo "+\send_morse'test'" | nc -w 1 localhost 4532 to a
IC-7610 and it cw happily
73, Ervin
HA2OS
73 Chris
OZ1GNN
--
Med venlig hilsen
Christian Treldal
"Remember Darwin; building a better mousetrap merely results in smarter mice."
Re: getting ready for the CQWW CW
Yes it works, thank you Ervin! PS. I feel stupid... Joop PG4I Op 21-11-19 om 22:39 schreef Ervin Hegedüs: Hi Joop, On Thu, Nov 21, 2019 at 10:30:35PM +0100, Joop Stakenborg wrote: Hello girls and boys, I can't seem to get the correct rules file for the CQWWCW this weekend. In the CQWW both the CQ zone and the country count as a multiplier. I have: MY_COUNTRY_POINTS=0 MY_CONTINENT_POINTS=1 DX_POINTS=3 MULT_LIST=zones.txt DX_&_SECTIONS Looks good okay? just fyi, Tlf supports CQ-WW "out-of-box", this contest is "hardcoded". From the man tlf: It supports the CQWW, WPX, ARRL-DX, ARRL-FD, STEWPERRY, PACC and EU SPRINT contests as well as a lot more basic contests, ... so this is enough: CONTEST=cqww LOGFILE=cqww.log CONTEST_MODE ... F1=+++TEST ---% +++TEST--- F2=% ... (note: of course, you can put more "+" to the begin of the TEST... :)) The first QSO I make with DL1AA in zone 14: 1 point, 1 multiplier for country (should be 2, one for country and one for section) The second QSO with W2GD in zone 5: 3 points, 1 mutiplier for section (should be 2, one for country and one for section) Is my setup okay? I think just try that one above. 73, Ervin HA2OS
Re: feature request: cabrillo template
Hi all, On Sun, Nov 17, 2019 at 10:32:16AM +0100, Joop Stakenborg wrote: > It would be nice to have a cabrillo template. If present, all the questions > when exporting to cabrillo can be skipped. a few days ago I reviewed the possibilities, now I'ld like to discuss them here. 1. the most simple way when we add new keywords to the config files, eg. CABRILLO_CONTEST, CABRILLO_CALLSIGN, ... therefore you can use these keywords both in logcfg.dat and contest rule files PRO: easy to make it CON: you have to add the keywords everytime when you prepare a new contest 2. read the new keywords from separated file; there are two sub-solution in this case a. this file could contains only the CABRILLO related options PRO: clear and elegant solution CON: hard to implement, makes the code logic more complicated and horrible b: this fie could any keyword, we just "call it" as "CABRILLO" file PRO: *could* be clear, easy to implement CON: can lead to chaos (user can mix the options and can't see the reason of the different bevaiour) Let's start to discuss :). I prefer 2/b. 73, Ervin HA2OS
Re: getting ready for the CQWW CW
Hi Joop, On Thu, Nov 21, 2019 at 10:30:35PM +0100, Joop Stakenborg wrote: > Hello girls and boys, > > > I can't seem to get the correct rules file for the CQWWCW this weekend. In > the CQWW both the CQ zone and the country count as a multiplier. I have: > > MY_COUNTRY_POINTS=0 > MY_CONTINENT_POINTS=1 > DX_POINTS=3 > MULT_LIST=zones.txt > DX_&_SECTIONS > > > Looks good okay? just fyi, Tlf supports CQ-WW "out-of-box", this contest is "hardcoded". >From the man tlf: It supports the CQWW, WPX, ARRL-DX, ARRL-FD, STEWPERRY, PACC and EU SPRINT contests as well as a lot more basic contests, ... so this is enough: CONTEST=cqww LOGFILE=cqww.log CONTEST_MODE ... F1=+++TEST ---% +++TEST--- F2=% ... (note: of course, you can put more "+" to the begin of the TEST... :)) > The first QSO I make with DL1AA in zone 14: 1 point, 1 multiplier for > country (should be 2, one for country and one for section) > > The second QSO with W2GD in zone 5: 3 points, 1 mutiplier for section > (should be 2, one for country and one for section) > > > Is my setup okay? I think just try that one above. 73, Ervin HA2OS
getting ready for the CQWW CW
Hello girls and boys, I can't seem to get the correct rules file for the CQWWCW this weekend. In the CQWW both the CQ zone and the country count as a multiplier. I have: MY_COUNTRY_POINTS=0 MY_CONTINENT_POINTS=1 DX_POINTS=3 MULT_LIST=zones.txt DX_&_SECTIONS Looks good okay? The first QSO I make with DL1AA in zone 14: 1 point, 1 multiplier for country (should be 2, one for country and one for section) The second QSO with W2GD in zone 5: 3 points, 1 mutiplier for section (should be 2, one for country and one for section) Is my setup okay? Regards, Joop PG4I
Re: GLib version?
Hi Tom, hi Nate, Thanks for the feedback. My conclusion is that it's safe to assume that GLib >=2.40.0 is generally available. Will change configure.ac accordingly (hard check). I'm still wondering though where are the debian pkg dependencies specified and how come Tlf 1.4.0 has different settings. BTW in debian Tlf recommends sox and xplanet, but not cwdaemon. Could this also be improved? 73, Zoli On Thu, Nov 21, 2019 at 06:53:49AM +0100, Thomas Beierlein wrote: > Hi Zoli, > > Am Wed, 20 Nov 2019 19:48:12 +0100 > schrieb Csahok Zoltan : > > > I would like to use GLib version >=2.40 for set-related hash table > > functions (g_hash_table_add). > > I tried the same back in 2015 while coding the focm.c contest module. > > At that time 2.40 was just out for some months but not widely in use. > So I had to fall back to g_hash_table_replace with key and value the > same (see there). > > In meantime nearly all distributions should provide an more actual > version of GLib. > > > > > A quick check of Debian buster shows that it contains GLib 2.58. > > On the other hand, tlf in that release (1.3.2) requires only GLib > > 2.35.9. Similar (or even worse) for sid: tlf 1.4.0 requires 2.30.0 > > for non-alpha/powerpc, whereas GLib 2.62 is deployed. > > > > configure.ac doesn't explicitly mention the required version, so this > > must come from somewhere else. Could this and the Debian (and other > > distro) packages be fixed so that at least 2.40 is required? > > If we need 2.40 we should state so in the configure.ac. > > 73, de Tom > > > -- > "Do what is needful!" > Ursula LeGuin: Earthsea > -- >
Re: Using hamlib for CW keying
Hi Christian, On Thu, Nov 21, 2019 at 12:29:38PM +0100, Christian Treldal wrote: > > A year or something ago Ervin wrote a quick Python2 script for keying via > hamlib. It has n I MADE A PYTHON SCRIPT? :D Could share with me/us? :) > been working flawlessly until now. I've upgraded to Fedora31 and Python2 has > been depreciated. I am trying to convert it to python3; > > But I think it is a good time for a humble feature request for Tlf 1.x.x. A > build in hamlib keyer, so at least I can avoid stressfull expiriences like > this. > > All modern rigs have keying via hamlib. you mean aboue like K3? Once I started to review how does it works, but IMHO it's too difficult. We discussed about this topic with Zoli HA5CQZ, but now I don't remember the results. 73, Ervin HA2OS
Re: Using hamlib for CW keying
When you ask for keying by hamlib, you are asking for keying via CAT, correct? (I would have to look to see if hamlib supports anything besides the CAT port on rigs, like the key line.) I wrote a python application that acts like cwdaemon listening on a network socket, and drives a USB to key adapter (K1EL WinKeyer USB). I need to push a python3 version of that to github. (I plan to do over next week's holiday.) That works great, but I have been thinking about trying keying from the CAT port. It might work great functionally. Reducing cabling would be a benefit. But, I'll probably keep the ability to use a key line interface for playing with HB or old rigs. On my todo list was to look at the hamlib server mode. It will talk to a network server version of itself, no? So, that might be an interesting way for me to insert my own application. Would still need to have TLF modified to use hamlib for keying, though. Alternatively, for fun, my application could use CAT for keying, but it could present both a hamlib socket interface for CAT and a cwdaemon interface for keying. This could work with existing TLF. Please point me to Ervin's Python 2 script or send me a copy. Chances are good that I can port it to Python 3 for you. (I routinely deal with the socket and pyserial issues that 2to3 doesn't automagically fix.) Best regards, Drew n7da On Thu, Nov 21, 2019 at 11:31 AM Christian Treldal wrote: > > Hi guys > > First I want to thanks the developers for the new ver. 1.4.0 > > A year or something ago Ervin wrote a quick Python2 script for keying > via hamlib. It has n > > been working flawlessly until now. I've upgraded to Fedora31 and Python2 > has been depreciated. I am trying to convert it to python3; > > But I think it is a good time for a humble feature request for Tlf > 1.x.x. A build in hamlib keyer, so at least I can avoid stressfull > expiriences like this. > > All modern rigs have keying via hamlib. > > > 73 de OZ1GNN > > -- > Med venlig hilsen > > > Christian Treldal > "Remember Darwin; building a better mousetrap merely results in smarter mice." > >
Using hamlib for CW keying
Hi guys First I want to thanks the developers for the new ver. 1.4.0 A year or something ago Ervin wrote a quick Python2 script for keying via hamlib. It has n been working flawlessly until now. I've upgraded to Fedora31 and Python2 has been depreciated. I am trying to convert it to python3; But I think it is a good time for a humble feature request for Tlf 1.x.x. A build in hamlib keyer, so at least I can avoid stressfull expiriences like this. All modern rigs have keying via hamlib. 73 de OZ1GNN -- Med venlig hilsen Christian Treldal "Remember Darwin; building a better mousetrap merely results in smarter mice."
