Re: [Tlf-devel] TLF
* Henri Honda <[EMAIL PROTECTED]> [2005 Oct 23 06:18 -0500]: > > Hi Rein: > > I installed Ubuntu Hoary OS and when I did that, I lost everything on my > computer! I want to download your TLF and do not have the web site. (I > lost that, too!) ( I only have backups of Windows.) > > Would appreciate if you can give me a site to download your TLF program. > > Thank you in advance! > > Have a nice week-end! > > 73, > > Hank K6DON/7J9AAD Here is the link, Hank: http://home.iae.nl/users/reinc/TLF-0.2.html 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] cwdaemon & TLF **SOLVED**
* Ed <[EMAIL PROTECTED]> [2005 Nov 13 09:59 -0600]: > I hope this is useful to someone, as I spent several hours trying to get > this up and running. BTW I just accidently came across the /etc/default > file, I saw no mention of it anywhere. I see you are running Debian as well. As you've probably discovered, /etc/default has a lot of config files in it. Sometimes I'm not sure if this is a feature or a bug, but I've trained myself to look there first. I would suggest that you file a bug report against cwdaemon (it's as easy as running "reportbug cwdaemon" and following the prompts. I did see mention of transitioning to /etc/default/cwdaemon in /usr/share/doc/cwdaemon/changelog.gz which is not the most intuitive place to look. When you file the bug set it to be a normal priority and a Wishlist and explain that /etc/default/cwdaemon should probably be explained in the /usr/share/doc/cwdaemon/README.debian file. Thanks for the info. 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] TLF trainer idea
I had an idea strike me today about some sort of trainer for TLF and Morse Code using cwdaemon. First, some background. I have an AEA Morse Machine (sadly no longer made) that has a neat DX contest function. Some years ago I rigged up my computer with CT and, if I recall, rigged it to send to the MM. This made for a good way to train and play contester without on the air embarrassment. :-) For some reason all of that came back today. Maybe it's my mental decompression from Field Day where my CW skills (never great) weren't as sharp as I'd like. So I recalled that trainer setup, but I'd like to do it with a twist and without additional equipment. I am thinking of a seperate program that could extract calls out of a file like MASTER.DTA or the file formatted for PED (the CT trainer) and send it to cwdaemon for playback through the speakers. The operater would enter it into TLF and use its facilities to send the call and exchange which could be echoed back to the program which could then respond with an exchange based on the contest rules in use. Finally, the trainer could keep its own log that the TLF log could be scored against. It sounds like a lot to do, and like XTLF, Perl might be the fastest way to get started. I've only played with TLF a little bit, but from what I know, it should need no modification. I'm not familiar with the internals of cwdaemon so I'm not sure how difficult it would be to enable it to echo the text it receives from TLF so the trainer could receive what is sent from TLF. The trainer for starters could send its text through cwdaemon and at some point would be useful to send to the sound card directly to enable pile-up, QRM, QRN, QSB, etc. simulation (which would take someone with considerable audio programming skill to accomplish). The trainer could not only vary the speed but the weighting as well. I'm no expert coder and I may start hacking at this in the near future. Something like this wouldn't just be a good trainer, it could be a good pursuit in and of itself using the same software as an on the air contest. If something like this already exists, I'll play with it to avoid duplication of effort. Otherwise, I think this would be a fun addition to TLF. What does everyone think? 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF trainer idea
* Rein Couperus PA0R <[EMAIL PROTECTED]> [2006 Jun 30 02:53 -0500]: > Nate, do you mean something like the TLF simulator mode with some > additions like text output? The TLF simulator takes its calls from the > callmaster file and simulates the cqww-cw, (single calls only, as it > uses cwdaemon for output). I forgot about that. That shows how much I've stayed away from ham radio in recent years. :-( But, yes, The simulator mode would probably be a very nice addition. > I have thought about moving the simulator mode into xtlf, but I am not > sure if it is needed... If XTLF is the replacement for the terminal based TLF, then it would be *very nice* to have it included. Even if it is just feeding one call at a time, it is useful for people like me who have been used to other programs and need some training. > One program I use for this purpose is 'Morse runner'. I use it under > ubuntu/vmwareplayer/XP. It would be a LOT of work to port it into Xtlf, > and I cannot do it myself as I am no soundcard programmer. I just had a look at that and it looks very nice. Perhaps the author could be invited to look at a Linux port? Thanks for the good work and info, Rein. 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF trainer idea
* Rein Couperus PA0R <[EMAIL PROTECTED]> [2006 Jun 30 02:53 -0500]: > One program I use for this purpose is 'Morse runner'. I use it under > ubuntu/vmwareplayer/XP. It would be a LOT of work to port it into Xtlf, > and I cannot do it myself as I am no soundcard programmer. Thanks for turning me onto this one. I hadn't heard of it before. I loaded on another Win2k machine I had access to and it works very well. So, I've been trying to get it working under WINE and I've solved a sound issue (load kernel snd-seq module) and a DLL that is needed for the log window. After that it just stops. The buttons work, but the clock never starts and pressing any of the F keys results in no sound. Obviously, some WINE debugging is needed. ;) I can use it, at least, and it is pretty much what I had in mind. 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF trainer idea
* Rein Couperus PA0R <[EMAIL PROTECTED]> [2006 Jun 30 02:53 -0500]: > One program I use for this purpose is 'Morse runner'. I use it under > ubuntu/vmwareplayer/XP. It would be a LOT of work to port it into Xtlf, > and I cannot do it myself as I am no soundcard programmer. Okay, I have Morse Runner working flawlessly under WINE. Success happened today when I was able to upgrade to WINE 0.9.15 which landed in Debian Sid within the past few days. I found that one native DLL is required, riched20.dll (required for the log window apparently), to be installed under ~/.wine/drive_c/windows/system The winecfg program is then used to set an override so that the native DLL is used instead of the builtin one. For now I have it as a global setting since I am only using Morse Runner under WINE at this time. Perhaps I should reopen one of the old WINE bugs to mark the missing functionality. All is well and this program is fantastic! Thanks for turning me onto it, Rein. 73, de Nate >> P.S. I still like the idea of putting the trainer into XTLF, if that is feasable. -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF trainer idea
A couple more details that I forgot to mention. When I ran winecfg the first time to set up the directories, etc., I selected Windows XP as the emulation. The default is Windows 2000, so I'm not sure if this makes a difference. When winecfg ran, I got an error that /dev/snd/seq could not be opened. I solved that by loading the snd-seq module (modprobe snd-seq) and udev created /dev/snd/seq automatically. HTH, 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Hamlib slows XTLF Wayyyyyy Doooowwwwwwnnnnnnn
Hi All. I'm playing with xtlf for the first time and getting one thing going at a time. I'm pleased with the response until I started TRX control and then things slow way down. CW response varies from immediately upon keypress to maybe almost a second after. Is this just an implementation issue or is my 1.33 GHz Athlon too slow? ;-) 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Hamlib slows XTLF Wayyyyyy Doooowwwwwwnnnnnnn
* Rein Couperus PA0R <[EMAIL PROTECTED]> [2006 Jul 08 03:26 -0500]: > I can't imagine ;) I will look into that. It should not have that > effect, it just runs rigctl every 10 seconds or so. Problably something > else hogging the CPU. I noticed through the ps ax command that rigctl and a shell script were running. Is there a reason the hamlib perl bindings aren't useful? I'm sure Stephane would be interested. I'd think that for simple TRX control that the Perl bindings should be useful. My CPU load normally runs 0.00 to 0.05 at idle with 91 processes running at the moment. With xtlf running it was around 0.22 or so and didn't increase when TRX control was enabled, but the xtlf gui becomes very slow to respond as does the response sending to cwdeamon. One cwdaemon began sending, I didn't notice any problems so I think cwdaemon can be excused as a source of the trouble. > Oh well, it keeps me busy so I don't get funny idaes :) We gotta keep you focused! :-D > Does the effect go away when you stop TRX control? Yes. 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Hamlib slows XTLF Wayyyyyy Doooowwwwwwnnnnnnn
Since I am listed as one of the Hamlib developers, I will get that to you. As I recall, you'll need get/set frequency, rig select, and port select. I played with a Perl script some time back and yes, even for me (not the world's greatest developer, mind you ;-) ), it is a bit arcane. I agree, good docs are needed as is more rig development. Sigh. BTW, I think I figured out the basics of xtlf now. My parallel interface was locking up due to RF, so I decided to use my new RigBlaster Plus, but I needed to add a stereo mini plug. After about a half hour of searching I found two new ones. So I soldered one on and guess what, it was open inside. So I tried the next one and it works. At least the RigBlaster isn't bothered by RF and I've got a few in the log now. It took me a couple of QSOs in S&P mode to learn that the first sends *my* call and the second sends the exchange and logs it. I'm too used to CT I suppose. Now that I have the most basic thing figured out, I need to explore more, for example, how to edit the log if I need to make a correction. I have so much fun trying to play in contests! Thanks for playing a part in that. 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Xtlf 1.0.3 Beta IARU hf !!
* stephane <[EMAIL PROTECTED]> [2006 Jul 09 09:56 -0500]: > I have resolved the 'adjust point" It's a bad manipulation from me, but > anyone can confirm than the iaru.pm rules is ok for this week end contest > because I am not sure for the point/multi after reading the information on a > french web site contest. While it is nice to know your final score, it really isn't necessary as the ARRL/IARU folks will run your Cabrillo log through their software and determine your correct score (after busted calls, missed exchanges, etc.). Just make sure your qso.cbr file is correct for everything else and email it to them. 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Example Perl files
Hi Rein.
Here are a couple of files that I hope will help illustrate how Hamlib
may be used from its Perl interface. The file listmodels.pl shows how
to extract the model strings from the Hamlib namespace.
Meanwhile, I modified perltest.pl somewhat and transformed it into
testrig.pl which uses the "Dummy" rig backend. Any real radio you have
available may be specified for real world testing.
I hope this helps.
73, de Nate >>
--
Wireless | Amateur Radio Station N0NB | Successfully Microsoft
Amateur radio exams; ham radio; Linux info @ | free since January 1998.
http://www.qsl.net/n0nb/ | "Debian, the choice of
My Kawasaki KZ-650 SR @| a GNU generation!"
http://www.networksplus.net/n0nb/ | http://www.debian.org
#!/usr/bin/perl -w
# Example code to extract RIG* constants from the Hamlib namespace
use Hamlib;
# Here the goal is to grab the rig model name constants from the Hamlib
# namespace and put them into a list so we can select one to pass to the
# 'new' Rig constructor. We can do this to extract mode names, etc.
# %Hamlib:: is a hash containing all of the values (variables, constants,
# functions, etc.) imported into the Hamlib namespace.
foreach (sort keys %Hamlib::) {
if (m/^RIG_MODEL_.*/) {
push(@rigs, $_);
}
if (m/^RIG_MODE_.*/) {
push(@modes, $_);
}
}
# and print them out in a nice sorted list, or whatever needs to be done
print "Model Hamlib Name\n";
foreach (sort @rigs) {
($rig = $_) =~ s/^RIG_MODEL_//;
printf STDOUT "%-20s%-20s\n", ($rig, $_);
}
print "\n\nMode Hamlib Mode Name\n";
foreach (sort @modes) {
($mode = $_) =~ s/^RIG_MODE_//;
printf STDOUT "%-10s%-10s\n", ($mode, $_);
}
#!/usr/bin/perl -Iblib/arch -Iblib/lib
# Modified from perltest.pl included with Hamlib.
use Hamlib;
print "Perl test, version: $Hamlib::hamlib_version\n";
# Examples showing the values of the mode constants in the Hamlib namespace
print "AM: $Hamlib::RIG_MODE_AM\n";
print "CW: $Hamlib::RIG_MODE_CW\n";
print "USB: $Hamlib::RIG_MODE_USB\n";
print "LSB: $Hamlib::RIG_MODE_LSB\n";
print "RTTY: $Hamlib::RIG_MODE_RTTY\n";
print "FM: $Hamlib::RIG_MODE_FM\n";
# Change to RIG_DEBUG_TRACE for diagnostic output
Hamlib::rig_set_debug($Hamlib::RIG_DEBUG_NONE);
# Create a new instance of class Hamlib::Rig and off we go!
# Note! RIG_MODEL_* must be used, the integers used with rigctl will fail.
$rig = new Hamlib::Rig($Hamlib::RIG_MODEL_DUMMY);
# replace "/dev/Rig" with your path to serial port
$rig->set_conf("rig_pathname","/dev/Rig");
# replace with needed serial speed (some backends may not allow change)
$rig->set_conf("serial_speed","9600");
$rig->open();
# 1073741944 is token value for "itu_region" (dunno where *that* came from -N0NB)
$rpath = $rig->get_conf("rig_pathname");
$rate = $rig->get_conf("serial_speed");
$region = $rig->get_conf(1073741944);
print "get_conf: path=\"$rpath\", baud rate=$rate, ITU region=$region\n";
$rig->set_freq(1200, $Hamlib::RIG_VFO_A);
$f = $rig->get_freq();
print "freq: $f\n";
$rig->set_mode($Hamlib::RIG_MODE_CW, $Hamlib::RIG_PASSBAND_NORMAL);
($mode, $width) = $rig->get_mode();
print "get_mode: $mode, width: $width\n";
$rig->set_vfo($Hamlib::RIG_VFO_A);
$vfo = $rig->get_vfo();
print "get_vfo: $vfo\n";
# The following is FYI, but probably not too important for XTLF
print "ITU region: $rig->{state}->{itu_region}\n";
print "Copyright: $rig->{caps}->{copyright}\n";
$inf = $rig->get_info();
print "get_info: $inf\n";
$rig->set_level("VOX", 1);
$lvl = $rig->get_level_i("VOX");
print "level: $lvl\n";
$rig->set_level($Hamlib::RIG_LEVEL_VOX, 5);
$lvl = $rig->get_level_i($Hamlib::RIG_LEVEL_VOX);
print "level: $lvl\n";
$chan = new Hamlib::Chan($Hamlib::RIG_VFO_A);
$rig->get_channel($chan);
print "get_channel status: $rig->{error_status}\n";
print "VFO: $chan->{vfo}, $chan->{freq}\n";
$rig->close();
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Hamlib + tlf + FreeBSD
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2006 Nov 15 16:54 -0600]: > Once again, the vagaries of FreeBSD rear their heads. This > question is more for the user base than for the developers, > but has anyone been successful in configuring and building > tlf on a FreeBSD machine with the hamlib library support? > > I've built the hamlib libraries from the FreeBSD ports, and > also built tlf that way, but no options are offered during > the build for hamlib support. So, I deinstalled it, and > decided to try to build it by hand. > > When I run ./configure, it fails with: > configure: error: Hamradio control libraries not found.. I take it this is TLF's configure script? > Once again, IANAP [I am not a programmer], and can't find > where in any of the configuration [or other] files I can > manually set the location of the hamlib library. It is > found in /usr/local/include/hamlib on my machine. This should work as it is the generic location for the Hamlib header files when it is built locally. Is rig.h there? What are its permissions? It should probably have 0644 at a minimum. Can you as a normal user cd into /usr/local/include/hamlib and view rig.h and other files? > Anyone figured this one out? Thanks. The configure script is generated from other scripts on the developer's system and editing it directly is a temporary fix at best (actually, it's scary looking at one of those scripts and we normally don't do it). However, searching configure for "hamlib" may give you an idea of where it's looking. Perhaps whoever generated configure erred by not having it look in /usr/local/include/hamlib assuming that it will always be in /usr/include/hamlib. HTH, 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Hamlib + tlf + FreeBSD
* Jim <[EMAIL PROTECTED]> [2006 Nov 16 06:28 -0600]: > From looking at the script, I think that configure uses the variable > $LIB to do its processing, but uses that variable for each library it > needs to process. IOW, $LIB gets assigned different values during the > configure. I can't figure out how to assign it to > =/usr/local/include/hamlib. > > I did run the configure with '--enable-hamlib', which is when I get the > error message that the hamlib libraries aren't found. I don't know if this will make a difference, but what is --prefix set to? Generally, --prefix=/usr/local is passed when compiling a package locally. If all of this has failed, then you may need to ask the upstream maintainer of the TLF package (I take it this isn't the source tarball from Rein's page). 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] XTLF Field Day rules?
Yeah, I know this is getting toward the last minute... Has anyone written rules modules for ARRL Field Day for XTLF? If not, then I have some studying to do. Has the ability to accept log input from FLDigi or gMFSK been implemented? Is XTLF 1.0.0beta3 still the latest release? So many questions... ;-) 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLD and ARRL Field Day
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007 Jun 30 09:51 -0500]: > Hey gang; > > Other than the ops "keyboarding" each other, since there can only be one > transmitter per band/mode on Field Day, is there an advantage to > networking such stuff together for a contest such as Field Day. Unless each station is dedicated to a band or mode or both, then the dupe checking becomes very handy. One year I was involved with a 2A station and the club didn't have enough CW ops to keep one station going. So I networked a pair of computers with CT and all we had to make sure of was to not be working SSB on the same band. It gave each station the freedom to pick a band and for both stations to work phone for about half the FD period. Since then I've been involved in 1A efforts. As it turned out, the logs still got slightly out of sync on the primitive CT network and some work was involved afterward merging them. > I suppose that log backup over the network would be useful, but can't that > be done easily enough outside of the logging software anyways ? A near real time merge seems like it could be very useful for a multi-multi type station. Done right, the programs running on the various computers can sync more quickly and accurately than an individual can afterward. > I am sure I am missing something, but I cannot seem to see the advantage > during this particular contest/operating activity. Those features are driven by the top contesting teams. They evidently find value in them. 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLD and ARRL Field Day
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007 Jul 01 11:28 -0500]: > > As it turned out, the logs still got slightly out of sync on the > > primitive CT network and some work was involved afterward merging them. > > Ug, CT is NOT a good logging program, as it was designed by a committee of > 1000 monkeys working on it for 100 years, or so it seems. (GRIN !) Ouch! As a long time CT user (since 1993), that smarts just a little. :-) I've tried TLF a number of times and can't seem to get my head around it. Perhaps it's a left brain/right brain thing. One thing I like about CT is that it does seem to be intiutive to many who sit down in the op's chair. Type the call, , type the report elements with between them and hit to log the QSO. Next! Need to edit? Arrow up. Clear the input fields? Hit F11. Then teach them how to change bands and modes with a cheat sheet and they're off an running from there. Perhaps it's because I know the program and had I started with TR years back, I'd probably think the CT way is obtuse. That said, I'm glad to see the reports of TLF being put to good use as it means more hams are finding Linux to be a useful addition to their hamshack. > >> I suppose that log backup over the network would be useful, but can't > >> that be done easily enough outside of the logging software anyways ? > > > > A near real time merge seems like it could be very useful for a > > multi-multi type station. Done right, the programs running on the > > various computers can sync more quickly and accurately than an > > individual can afterward. > > Multi-multi is NOT field day, and that was what I was referring to. Yes, and no. Field Day is also not a contest per se and perhaps computer logging should be disallowed? ;-) Different horses for different courses and all that. That's why we have different programs for different approaches to the same problem. Enjoy the buffet. 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF and ARRL Field Day
* Scott Emery <[EMAIL PROTECTED]> [2007 Jul 04 09:38 -0500]: > I don't know exactly what is implied by "Multi-Multi". My understanding is "multi-operator, multi-station" and in Field Day it may include multi-mode as well. 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] XTLF message queuing
Nice to hear from you, Rein, on the FLDigi list. I was afraid that development on XTLF had stopped as it hadn't seen any updates for about a year. I've been learning what I can of using it and I think I finally have a handle on it, so long as my brain doesn't revert to CT! One "bug" I encountered involves the queuing of CW messages. In CT and my Super CMOS III keyer pressing a key or button multiple times results in the messages being queued with a word space between them. As near as I can tell, XTLF only inserts a letter space between the messages. A work-around has been to add a space a the beginning or end of a message, although this has a certain disadvantage. I've been studying the source. I'm still trying to get a handle on the scoring so I can add ARRL Field Day for next year. It takes me a while to learn the logic of a program. Here is a feature request. How about a switch to allow log entry with one press of ? This would be most useful to me in SSB mode as I don't use a voice keyer. 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] fldigi & tlf
* Ed <[EMAIL PROTECTED]> [2007 Nov 20 11:09 -0600]: > I have been trying to get the 2 of these to work as gmfsk & tlf did. But I > am not having much luck. I created the .log and auto_file , did the echo > pskmailserver, but nothing gets sent to fldigi. Am I to assume that with > all the changes to pskmail that fldigi is not being used as a modem and > that a different type of interface is now being used, or am I just > completely missing something obvious. Thanks Isn't the data supposed to go from Fldigi to TLF? It works that way with XLog here and I assume TLF can receive it the same way. It's been a while since I played wit TLF. 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] fldigi & tlf
* Ed <[EMAIL PROTECTED]> [2007 Nov 22 05:51 -0600]: > The only alternative is to install MS-XP and use N1MM with MMTTY to be able > to work a RTTY contest and submit a cabrillo file. Do neither of those two programs work with Wine? 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] fldigi & tlf
* Wilbert Knol <[EMAIL PROTECTED]> [2007 Nov 22 15:10 -0600]: > How this can be implemented under Linux I am not sure. I guess changes would > need to be made to cwdaemon, and perhaps a near real-time kernel is needed... > Another solution is to move cwdaemon to hardware (winkey) or, preferably, an > open-source version of winkey. There has been an interesting discussion on the Yahoo group LinuxHam, which is the mailing list for Fldigi, concerning the generation of Morse on Linux. Their implementation involves using the sound card since they can control the timing to a closer degree. You might check that group and read the thread archive. The consensus is that even an RT Linux kernel has limitations due to timing and that QRQ operation isn't feasable. How well this is being accomplished on the Win programs, I don't know. 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] fldigi & tlf
* Rein Couperus <[EMAIL PROTECTED]> [2007 Nov 29 09:37 -0600]: > Now that pskmail is in a useable state I want to pick up tlf again. One of > the projects should be to add an interface to Fldigi, another to build a > simple GUI-driven contest configurator. Curses TLF, XTLF or both? :-) Stephane has started work on a rigctld to get away from the Swig generated interface for Perl and Python. Hopefully this will help XTLF better use Hamlib. 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Amateur radio exams; ham radio; Linux info @ | free since January 1998. http://www.qsl.net/n0nb/ | "Debian, the choice of My Kawasaki KZ-650 SR @| a GNU generation!" http://www.networksplus.net/n0nb/ | http://www.debian.org ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] GRig, rigctl, FT-1000 & SuSE 10.3
* William Liporace <[EMAIL PROTECTED]> [2008 Jan 26 16:03 -0600]: > I have tried to get hamlib to work on my SuSE 10.3 box with my FT-1000. I > have tried things as a root or the user. I do not get any difference. I am > using a FTDI Chip USB to TTL cable. The cable and radio work fine with the > logging software KB and jLog (jlog needs a special program). I believe the > issue is how the programs sets the port settings. I do get one or two blinks > from the CAT light. One more thought. There was in issue with the EPROM version in the FT-1000 as I recall where CAT was broken. You may want to do some searching and see what the relevant versions are. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] GRig, rigctl, FT-1000 & SuSE 10.3
* William Liporace <[EMAIL PROTECTED]> [2008 Jan 26 16:03 -0600]: > I have tried to get hamlib to work on my SuSE 10.3 box with my FT-1000. I > have tried things as a root or the user. I do not get any difference. I am > using a FTDI Chip USB to TTL cable. The cable and radio work fine with the > logging software KB and jLog (jlog needs a special program). I believe the > issue is how the programs sets the port settings. I do get one or two blinks > from the CAT light. > > Here are the commands given with the error codes: > grig -m 103 -r /dev/ttyUSB1 s=4800 > 2008/01/26 16:42:33;;GRIG;;2;;rig_daemon_start: Failed to open rig port > /dev/ttyUSB1 (permissions?) > > rigctrl -m 103 -r /dev/ttyUSB1 s=4800 > rig_open: error = Communication timed out > > > I am open to some suggestions. I have held off on trying hamlib. It has not > improved for me. Can you forward the output of the following commands: ls -l /dev/ttyUSB1 groups It may be that your normal user is not allowed to access the ttyUSB1 device. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF Improvement Suggestions
Speaking of editing. I've found nothing as simple as CT--simply scroll up to the incorrect QSO, either arrow or Page Up, make the changes and hit and scroll back down to entry line. All the while the cursor stays in the logging screen. What could be easier? Dumping a computer logging newbie into vi on FD is a sure way of getting them to swear off Linux for logging forever. In my experience, CT is easy to teach as only a half dozen or so keystrokes need be memorized. We keep a cheatsheet with more less used commands next to the laptop. Since we operate 1A, our needs are quite simple and CT has served us well. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://n0nb.us/index.html ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Source files license boilerplate discrepancy
I've been poking at the various source files for a while and have found a discrepancy in the license boilerplate (this is from changepars.c, others are quite similar): /* * Tlf - contest logging program for amateur radio operators * Copyright (C) 2001-2002-2003 Rein Couperus * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU Library General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ The discrepancy is the line: GNU Library General Public License for more details. as the included file COPYING is only for the GNU General Public License. I presume this is an honest copy and paste error that has gone unnoticed. The proper fix would be to simply remove the word "Library" from that one particular line of all source files provided that all copyright holders on each file give their approval. I am willing to make the corrections and submit a patch once such approval is made public to this list. As I see it, leaving the text as-is results in some ambiguity although I think that other evidence points to the intent of the source being licensed under the GPL and not the LGPL. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Source files license boilerplate discrepancy
* On 2013 06 Jul 12:56 -0500, Rein Couperus wrote: > I don't have a problem with doing that... in 2003 the problem did not exist, > at least I was not aware with it... Things happen once in a while. :) Tom, I'll work a patch set and send you a pull request. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] cwdaemon or winkeyer
* On 2013 20 Nov 06:13 -0600, Ed wrote: > On Wed, 20 Nov 2013 09:57:44 +0100 > Ervin Hegedüs - HA2OS wrote: > > > Hello, > > > > On Wed, Nov 20, 2013 at 09:04:55AM +0100, Fabian Kurz wrote: > > > On Wed, Nov 20, 2013 at 09:00:18AM +0100, Thomas Beierlein wrote: > > > > To expand the question a little bit. There are some other keying > > > > devices supported (but not good as I fear). Maybe we can get some > > > > more feedback. Let us make a table and append to it: > > > > > callcwdaemon winkeyer MFJ1278 ORIONkeyer > > == > > DL1JBE x > > DJ1YFK x > > OK1RR x > > HA2OS x > W3NR x N0NB x Caveat, I have a Ham Gadgets Master Keyer 1 which implements the K1EL protocol. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Tlf scoring for Stew Perry?
I use 'git grep' a lot as it limits the search to the code Git knows about in a given repository. I use grep for built files in the build directory. A lot of options to be sure. I have yet to spend time with ctags or cscope, I'm sure they're fine tools. I know a quick example would help me understand any improvements over grep options. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Tlf scoring for Stew Perry?
* On 2013 10 Dec 00:04 -0600, Thomas Beierlein wrote: > You did a grep for some identifier and afterward want to look at all > the places it is used. So you have to start less or vi or whatever with > all the filenames you found - that maybe a lot of typing. > > With cscope you get the search result as a list you can choose from. > No typing of each found filename. I suspect that were I more clever git grep would get me the same place. I did play with cscope a bit last night and didn't find it an advantage over git grep. I then tried Kscope and was rather disappointed. I do use git grep with Perl Compatible RE enabled, since Debian now enables it, which makes it easier for me to narrow searches along with colorized output and file names and line numbers enabled. I do like that git grep will not only grep in added/committed files but also will output matches in uncommitted changes in tracked files. I found on Stack Exchange another trick that git grep can search in earlier commits without needing to check out the desired commit and so on. > But to be honest I do use grep, sed and other tools as well. It is > good to have a well filled and sorted toolbag. I haven't spent the time to learn how t use ctags effectively either. Unfortunately, my favorite editor Geany doesn't use native ctags but has its own implementation. While I use Vim for email editing, I like the GUI for C work or Midnight Commander's editor for editing in a shell. So many tools, so little time! 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Quick change CW <> SSB -- which key to use?
* On 2013 10 Dec 07:41 -0600, FS wrote: > Another proposal would be +F1 to toggle through the modes. > That would be compatible to other programms. We should include all > modes to toggle through for normal qso mode. Except that X desktop window managers grab the Ctl-Fx keys for desktop switching. Asking users to disable those keys in their window manager may be too much. Alt-Fx keys are also often in use for various desktop functions. On the Linux console the Ctl-Fx keys may be available but the console driver uses Alt-Fx for virtual console switching. It seems that use of either Ctl-Fx or Alt-Fx are problematic. Using something like :CW or :LSB seems not a great burden unless one would be switching modes with every QSO. Using the leading colon in the call field informs the key stroke parser that a command is following. I'm not a high speed op, so I may be far off base! 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Tlf scoring for Stew Perry?
* On 2013 13 Dec 11:58 -0600, Mike Waters wrote:
> > ==%==
> > #include
> > #include
> >
> > int main(int argc, char ** argv) {
> > double s1long, s1lat, s2long, s2lat;
> > char s1qra[] = "EM37cg";
> > char s2qra[] = "jn97om";
> > double dist = 1000, az = 90;
> >
> > locator2longlat(&s1long, &s1lat, s1qra);
> > locator2longlat(&s2long, &s2lat, s2qra);
> >
> > printf("W0BTU coords: lat: %f lon: %f\n", s1lat, s1long);
> > printf("HA2OS coords: lat: %f lon: %f\n", s2lat, s2long);
> >
> > qrb(s1long, s1lat, s2long, s2lat, &dist, &az);
> >
> > printf("distance between W0BTU and HA2OS: %f km, dir: %f\n", dist, az);
> > return 0;
> > }
> > ==%==
> >
> > You can compile that code with this command:
> >
> > gcc -Wall qrasrc.c -lhamlib
> >
>
> It didn't work. Here is the gcc output:
>
> mike@mike-ubuntu:~/local/share/tlf/tlf-devel$ sudo gcc -Wall gridtest.c
> -lhamlib
> [sudo] password for mike:
Just as info, sudo is not required to run gcc in your home directory.
> gridtest.c:1:1: error: expected identifier or ‘(’ before ‘==’ token
> In file included from /usr/include/stdio.h:75:0,
> from gridtest.c:2:
I'm guessing that you left the lines that have "==%==" in the file.
This should not be there, so delete those lines. Try it without those
lines and try it again.
73, de Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://www.n0nb.us
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Tlf scoring for Stew Perry?
Hi Mike, et. al. Hamlib can be used from a Python, Perl, or TCL script and call the functions used for calculating azimuth and distance using several different location formats. Ervin mentioned below about some changes he submitted to the non-C language bindings. Those changes are only available in the development branch of Hamlib at this time (we're working to get the next version "out the door"). An example of how Python can be used for these functions can be found in the latter part of the following script: https://github.com/N0NB/hamlib/blob/master/bindings/pytest.py A daily snapshot of the development branch is available at: http://n0nb.users.sourceforge.net Compiling is not too difficult although certain dependencies exist, particularly for compiling the language bindings. Most of all the information is detailed in the INSTALL and README.betatester files in the source archive. Admittedly, getting started learning the Hamlib functions is not as easy as it should be due to a lack of good documentation. I started on a manual earlier this year and really need to get back to working on it. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Tlf scoring for Stew Perry?
* On 2013 13 Dec 15:44 -0600, Mike Waters wrote: > That was it! Thanks, Nate! :-) > > I should have caught that from the error, but I was fixated on another part > of the compiler message. I understand completely. I have found that when solving compiler errors, fix the first thing and sometimes all the others, or at least many of the others, go away. It's as though once it gets out of sync, the rest is undefined! > > Just as info, sudo is not required to run gcc in your home directory. > > > > You're right. I thought it did the last time I ran gcc. Thanks. It depends on where you are in the file system. Perhaps you were compiling some kernel source or a kernel module of some such which is often unpacked outside of one's home directory. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Few modifications in Tlf core
* On 2013 31 Dec 06:07 -0600, Thomas Beierlein wrote: > The single rig backends are normally implemented by different OMs. So > we have a situation where different rigs show different behaviour quite > often. One of the things I would like to see addressed in Hamlib is this difference between backends. In some ways it is not easy or may not be possible due to differences between the radios themselves. The backends have been added in an ad hoc manner and have not been guided by a single "best of" approach or policy. This adversely affects TLF et. al. and is supposed to be one of the benefits of Hamlib for applications. Part of my ongoing work is to improve the Hamlib documentation as a needed first step. Reading this list helps me to better understand those issues which I hope to address in the documentation. I know several on this list have contributed to Hamlib and for that you have my thanks. Don't be afraid to suggest changes and fixes. Happy New Year! 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Few modifications in Tlf core
* On 2014 02 Jan 12:34 -0600, Hegedüs Ervin wrote: > If that function got 0 as 'width', then that set the filter the > lower value... :( > > That mean the using of RIG_PASSBAND_NORMAL is not that what the > author wanted. > > > I don't know, what should be the solution. At first glance, I will say the Yaesu backend is likely doing things "correctly" only because it was written first. ;) As I see it, the backends should handle RIG_PASSBAND_NORMAL through the function rather than in some arbitrary method. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] CQ 160-Meter CW Contest this weekend
The latest cty.dat file is always available from: http://country-files.com/ 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Fw: WARC bands
* On 2014 22 Jan 23:56 -0600, Thomas Beierlein wrote: > The whole initialization code is very complex and not easily to change. > It is on my todo list already but changign needs a lot of care. Maybe > we should write it completely from scratch. Here is a hare-brained idea from the peanut gallery. ;-) If (and I say "if") a rewrite of some sort is desirable, then it may be desirable to separate certain parts of TLF into a library so that core functions such as duping, country lookup, scoring, managing the log file, etc. would be separate from the UI. Then other UIs could be written to take advantage of the library so that a TR compatible UI would share the same core as one written for CT users or a general logger, for example. As I see it, every logger out there does mostly the same things and each one reinvents all of these similar functions. The real differences are the UI and, up until such a libary would exist, varying degrees of completeness of the common parts. No matter the UI, a callsign given to the country lookup routine would return the same answer based on the cty.dat installed. Log file format would be separate from the UI. Perhaps mutliple log format backends could be incorporated as some users may prefer a flat file and others an SQL DB and so on. A common interface would allow easily reading a log file generated from one UI in another UI. Each UI would have access to consistent Cabrillo and ADIF export and import. A C library can be used with just about any other language so these core routines wouldn't limit UIs to be written in C. Thoughts? 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Fw: WARC bands
* On 2014 24 Jan 00:33 -0600, Thomas Beierlein wrote: > While I was talking about scoring and contest handling in my mail, you > are quite right. It would be good to write a completely new tlf. > Question is have we time and man power to do it? Anyway - I am in for > it. While it is a large task, it will be manageable when broken down into prioritized smaller tasks. I would say pick a module and break it out first then move on to another. > At the moment I would favor a tab separated list for the log format > with a header line documenting the order and contents of the columns. > That can be easily parsed, extended and even read and written without a > special program. It can also be handled with any scripting language > without problems. This is where I think multiple storage "backends" could be useful. Perhaps I am a bit naive here, but an SQLite backend, for example, would put the work of parsing on the SQLite engine. Maybe this is a part better done by each UI? OTOH, once the library is used to setup the event parameters, it would also be easy to write an SQL query based on call per band, or call per event, or call per mode, or call per band/mode, etc. > Besides the above comments one major step forward would be an unified > handling of the mass of contest rules around. Ervin did already wrote > about that in his answer to your mail. I would like to add a little bit > here: > > If we look over to other contest programs we see that most of them have > the different contests hard coded and can simply choose which one to > use. Easy for the user - hard for maintenance (it requires a lot of man > power for development). N1MM seems to be an exception - he has a > contest rule generator for simple cases. > > Tlf tried another way: Some hard coded contests and some configuration > keywords to roll your own rule file. At present the chosen keywords > normally solve only special problems. It is not easy to know which one > to use without looking into the code and often we miss a keyword and > hurry to add just anther special one (Sounds familiar?) > > As I see it the following could be a good way: > > - Have some very general keywords to roll your own simple contest. The > MY_COUNTRY/MY_CONTINENT_/DX_ POINTS may be a good idea for point > scoring. > - Have some simple general configurable rules for multiplier counting: > What to look at (call, exchange,...), what qualifies as a multi, once > per band or once per contest, > e.g. COUNTRY, DXCC, PER_BAND or CALL, PREFIX, PER_CONTEST > - Allow more than one rule and allow to specify how to combine them, > e.g. DXCC and WPX-PREFIX added > > - What can not be done these simple way (different points per band, > special station bonus points, ...) have to be hard coded. These > should be doable by the normal ham without a knowledge of the inner > working of the program and without a need to compile code for the > program. > > As Ervin told there are two ways. I too would prefer the second one - > using a scripting language for that and I too think python is the way > to go. It is easy to learn and program, the scripts can be debugged > and tested independent of tlf and can be easily integrated into tlf. > (I even did some thinking if we can not write the whole program in > python...) In general, I agree, but maybe too much effort is being put into calculating the score? I know it is something the contest loggers have always done and it seems to be expected, but it seems like the final score calculated by the contest sponsor was never the same as that which I submitted (that could be a "here" thing, though). IMO, at best a raw score is only good for posting to 3830 and at worst requires a lot of coding and debugging effort. I honestly think that not calculating a score in real time relieves much of the complexity of writing an event definition (personally, I found the displayed score to be a distraction over the years). A module that parses the log and then does a score calculation after the event may have its uses. That paragraph may have ruffled a few feathers! Ideally, writing a contest definition should not require knowing or learning a scripting language. Most of what is needed seems to fit into the key:value paradigm and there are various ways to represent that. Among the easiest for non-programmers to understand would be the GKeyFile: https://developer.gnome.org/glib/stable/glib-Key-value-file-parser.html which has a syntax similar to .ini files found on Windows but is extended in several respects. It is easy to read and would be easy for people with a list of keywords and possible values either in an example file or manual page to understand and submit a new event file to the developers. (Note that I am considering these arguments for extending Hamlib at some future time as well so this point has been rattling around in my brain for some time). Scripting could be useful, but may be a bit over rated?
Re: [Tlf-devel] Fw: WARC bands
* On 2014 24 Jan 15:16 -0600, Ervin Hegedüs - HA2OS wrote: > I didn't hear about Xdx before - could you make some comparison > of the configuration method with Tlf and Xdx? Hi Ervin. This is off-topic, but I hope Tom will be understanding. :-) Xdx is a GUI DX Cluster client originally written by Joop, PG4I. He stopped maintenance on it several years ago and with his blessing I picked it up a couple of weeks ago. right now I'm hoping to receive some language translation updates before releasing a stable update. More info at: https://github.com/N0NB/xdx At one time it was a companion project of Xlog also by Joop. Xlog has had a new maintainer for some time. The only things Xdx and Tlf have in common, other than written in C, are that both connect to a DX Cluster and both use the cty.dat country file. 73, de Nate >> > ps: I know I'm the last one who connected to this project. I > really don't want to "clever" - but when you wrote your idea > about the rewrite from scratch, I felt completely my > own - sorry :) I hope I didn't leave the impression that I wanted to rewrite anything from scratch. Rather, if a rework of the structure of Tlf is desirable, and some of that will involve code modification, then it may be useful to build some parts that already exist in Tlf into a separate library so that other programs can use the same functions. -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] hamlib in v1.2.0
* On 2014 16 Mar 10:04 -0500, Ervin Hegedüs wrote: > Hello Fred, > > On Sun, Mar 16, 2014 at 02:29:35PM +0100, dh...@freenet.de wrote: > > I compiled now from the github master, this works as usual. > > which source had compiled from github master? Hamlib or Tlf? > > As I know the hamlib on github isn't an official version, Nate > uses the sourceforge: > > http://sourceforge.net/p/hamlib/code/ci/master/tree/ True, the SourceForge repository is "official", but I see to it that both are in sync. I prefer interacting with the GitHub website which is why I often link to it. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Wiki
* On 2015 05 Jan 08:33 -0600, Thomas Beierlein wrote: > The wiki seems to be a different problem. Github wiki requires a github > account and seems to be not so flexible. Other choices may be > sourceforge or the fedora one Ed mentioned. I would not bother with SourceForge as they provide a MarkDown Wiki by default unless a project wants to go it alone with another Wiki package. We're discussing that a bit on the Hamlib list as SF.net took away MediaWiki last summer as a hosted app. All of our content was in MediaWiki and would need to be transitioned to something else. Not fun. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Where to get newest callmaster data file?
* On 2015 17 Oct 17:42 -0500, Mike Waters wrote: > Thanks, but I already have the latest cty.dat file. The "callmaster" file > contains only callsigns, one per line. And I didn't see anything like that > there. Did I miss something? It's likely based on the Super Check Partial database: http://supercheckpartial.com/ 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Setting up ARRL 160m rules file
It's probably my unfamiliarity with Tlf. I am setting up a rules file for the upcoming ARRL 160m contest as a USA entrant. For stations in W/VE (any ARRL/RAC section) the scoring is two points for working stations in another ARRL/RAC section (including 'DX' such as KH6, KL7, KP4, KV4, etc.) and five points for other DXCC entities. Now, the real time scoring isn't all that important, I suppose, as ARRL will score the log based on what is in the Cabrillo file. I do want to be sure that Tlf honors any entity that appears in CTY.DAT that I record a section abbreviation as one that is a section mult and not a DX mult. I am still poking around in the source, but so far have set my rules file as: # # ARRL 160m CONTEST (Stateside) # # # CONTEST=arrl160m_usa LOGFILE=arrl160m.log CONTEST_MODE CABRILLO=UNIVERSAL # MULT_LIST=arrlsections DX_&_SECTIONS RECALL_MULTS # 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Cw keyer via hamlib
* On 2015 02 Dec 15:38 -0600, Tomasz Pabich wrote: > Hello. > > Arevthey possibility to addnthis functionality ?? > Hamlib do this quite well, only what isnneeded is sending hamlib command > insted cqwdaemon or winkeyer. As far as I know there is some provision for telling the radio to send Morse. It would depend on which radio you're wanting to use as to how this could be done. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Cw keyer via hamlib
* On 2015 02 Dec 16:04 -0600, Tomasz Pabich wrote: > I use KX3, i wan to use internal keyer, because they work like winkeyer, > and I dont need any additional hardware or cable. You are correct. I just tested it on my K3 with rigctl and it sent just fine. I've been poking around the Tlf source. I'm not certain how soon I can understand the flow to include an option for Hamlib send_morse, but it would be a good idea to include that as an option. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Tlf with ARRL 160m, some thoughts
This is the first I have used Tlf since Tom released the 1.2 series. Congratulations, Tom, this is the best experience I have had with Tlf. Well done. I am adjusting my habits to the TR--Enter Sends Message (ESM) in N1MM parlance--key sequencing and it works well. I just have to remember to switch between CQ and S&P modes. Once I do that, the operation is very slick. As the exchange in ARRL 160m is quite simple, so long as the exchange field is empty, pressing sends my call rather than reaching up to press F6. I like! Operation is just as smooth in CQ mode. I've operated about four hours or so between last night and this morning and put 115 Qs in the log, mostly S&P, although I did manage a short run this morning. Band isn't great and my 100W from a short wire struggles to be heard it seems. Granted, a lot of ops may be dealing with local noise while I have a very quiet location. Now a few things I'll put on my TODO list. Editing keys. Once characters are in the call field the left arrow enters edit mode. I'd like the key to do the same while jumping the cursor to the first character in the field. Often a person only copies the suffix of the call and being able to jump to the front of the string with one key press rather than several is probably expected behavior. As with above, the key should exit edit mode and position the cursor after the last character. This will likely be a synonym of in this case and is an intuitive key press for many users. Sort out the cases where some cty.dat entities are ARRL sections or entities. For the most part this would affect ARRL 160, ARRL FD, and ARRL SS where all US territories are counted as an ARRL section. For other events such as ARRL DX they are entities rather than sections, as I recall, so there may need to be an addition rules file keyword and some logic added. I do have a rules file for ARRL 160m USA in my repository and it is in a pending pull request to Tom. Also in that pull request is a fix for the MULT_LIST rules parameter where the file will be loaded from the installed files if it doesn't exist in the local working directory. This will avoid having to copy a file such as arrlsections into the working directory each time when a distributed mults file is used. For keying the CW I am using the updated winkeydaemon.pl from Wilbert, PE7T, with my HamGadgets MK-1. I did patch it to enable the debug command line switch. It too has been working flawlessly. I can create and push the code to a repository on GitHub if anyone is interested. Control of my K3 with Hamlib has worked flawlessly as well. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Tlf with ARRL 160m, some thoughts
* On 2015 06 Dec 09:53 -0600, Thomas Beierlein wrote: > Hi Nate and others, > > let me first congrats to your 160m results. Well done. Thanks, Tom. I was a bit disappointed to not make a complete QSO with C6AUM early this morning. He couldn't quite pull me out this year so I never had a chance to see Tlf count a 5 point QSO. I did have one dupe call me this AM and Tlf correctly scored it at zero points. I opened an issue against my repository this morning where I worked the ONE (Ontario East) section and Tlf counted it as NE (Nebraska). When I did work an NE station later, no additional mult was counted. I need to go through the logic on that one. > Am Sat, 5 Dec 2015 08:31:39 -0600 > schrieb Nate Bargmann : > > Sort out the cases where some cty.dat entities are ARRL sections or > > entities. For the most part this would affect ARRL 160, ARRL FD, and > > ARRL SS where all US territories are counted as an ARRL section. For > > other events such as ARRL DX they are entities rather than sections, > > as I recall, so there may need to be an addition rules file keyword > > and some logic added. > > > What kind of support do you have in mind? Some new scoring keywords? Right now as I incompletely understand the logic, the issue appears a bit tricky and I don't have a solution handy at the moment. What I did was a trick offered on this list a year ago and I simply deleted the conflicting entities from a local copy of cty.dat placed in the working directory. Since I didn't actually get a chance to try this in the contest since the only one of those entities I heard, KP2 in VI, did not hear me, I can only go by my tests before the contest. In those tests with an unmodified cty.dat, with the DX_&_SECTIONS keyword in the rules file Tlf chose to apply the mult for the entity rather than the section even though it took my entry in the exchange field. More testing is needed. Perhaps the solution is to include two section files in the distribution, one with all the sections and the other with just the mainland sections for ARRL DX. I think the logic would still need to be looked at in the case where a US entity appears in cty.dat, did the op enter a section abbreviation for the exchange, if so, then count it as a section, etc. As the next event where this will be an issue is over six months away, there is some time for me to study this more. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Problem to compile TLF.
* On 2015 06 Dec 10:05 -0600, David Quental wrote: > Hi Thomas, > > tks for your email. > > I removed the tlf directory, then installed it again. > > In fact the 2 lines are here when I type './configure'. However, it does not > compile yet: > > keyer.c:31:19: fatal error: panel.h: No such file or directory > #include >^ > compilation terminated. > Makefile:547: recipe for target 'keyer.o' failed > make[2]: *** [keyer.o] Error 1 David, if you use the command: locate panel.h do you get anything? I have the mlocate Debian package installed that provides a handy database to find files quickly using the 'locate' command. Here is what I get: $ locate panel.h /usr/include/panel.h /usr/include/ncursesw/panel.h /usr/share/doc/python2.7/html/library/curses.panel.html /usr/src/linux-headers-3.16.0-4-amd64/include/config/input/apanel.h /usr/src/linux-headers-3.16.0-4-common/include/drm/drm_panel.h The first two are the ones used by the C preprocessor. Perhaps you need an additional package installed that provides panel.h? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Problem to compile TLF.
* On 2015 06 Dec 11:07 -0600, Thomas Beierlein wrote: > Hi David and Nate, > > I just checked in a OpenSUSE vm. There is no /usr/include/panel.h just > a /usr/include/ncurses/panel.h in OpenSUSE. As an additionla problem > there is also no *.pc file which you could consult. > > So you need to tell 'configure' about that additional search path. > Please do it as follows: > > CFLAGS=-I/usr/include/ncurses ./configure > make clean > make > > That should fix the problem. I think we should consider a check for the panel.h using AC_CHECK_HEADER (I think, I need to revisit the docs) in configure.ac. We can then use the values that *should* appear in config.h to find the proper panel.h file. I've got a pretty good handle on the Autotools, so I can open an issue and assign to myself to fix. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Tlf with ARRL 160m, some thoughts
* On 2015 06 Dec 11:30 -0600, Ed wrote: > > Dumb question, but here goes anyhow. Did you update the arrlsections > file ? I'm working from the Tlf Git master branch so there was no need to update as the version in the master branch has all current 83 sections. However, looking through the file, the same issue may appear with SF and SFL, SD and SDG, and OR and ORG. I did have OR counted correctly but never worked an ORG this weekend. NTX was counted correctly but it appears in the file before NT. As NE appears in the list before ONE, it's probably case of accepting a bit too generous of a match when parsing the array. In other words, the length of the string typed in the exchange field should match the length of the string in the array exactly. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Problem to compile TLF.
David, I have committed a patch to the build system that uses two GNU macros to find the needed files. If you can clone my repository: https://github.com/N0NB/tlf.git and switch to the search-for-panel branch and test the build on your system with the symlink you created for panel.h removed (back to OpenSuSE default), I would be grateful to see how it works. Please let us know. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Problem to compile TLF.
* On 2015 06 Dec 14:06 -0600, David Quental wrote: > Hi Nate, > > tks for your email and patch. > > Well, it did not work out: > > keyer.c:31:19: fatal error: panel.h: No such file or directory > #include >^ > compilation terminated. > Makefile:547: recipe for target 'keyer.o' failed > make[2]: *** [keyer.o] Error 1 No problem, I expected that. Please send me the config.h file from the build directory. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Problem to compile TLF.
* On 2015 06 Dec 17:44 -0600, David Quental wrote: > Hi Nate, > > tks for your email. > > Ok, I will send file right now. This doesn't look like the version generated in the search-for-panel branch. Be sure you do: git checkout search-for-panel after you do a new clone of my repository: https://github.com/N0NB/tlf.git Regardless, I will probably need to do a bit more work before it compiles, I just want to see what configure from the search-for-panel branch finds on your system before I go on. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Problem to compile TLF.
* On 2015 06 Dec 18:38 -0600, David Quental wrote: > Well, I did not do command git checkout search-for-panel. Instead I did a > mkdir N0NB command, then I did git clone https://github.com/N0NB/tlf.git > inside of the new directory. > > Where do I perform command git checkout search-for-panel ? Inside the tlf > directory ? Yes, that is where it needs to be done. Of course I am assuming that you have Git installed. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Problem to compile TLF.
David, I will send you a source tarball that doesn't require Git to your Gmail address if that is okay. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Problem to compile TLF.
This has been resolved by a patch set just applied by Tom and previously tested by David. The build system should detect when the ncurses header files are installed in /usr/include or /usr/include/ncurses or in a location passed by use of the CPPFLAGS variable when running the configure script. Thanks to David for being patient and testing things for me even though I found a bug in another package I used, which has now been submitted and accepted upstream. This is the way the collaborative software community weeks--Tlf benefits and others benefit as well. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] RAC contests: Scoring for special calls
* On 2015 18 Dec 17:13 -0600, Ervin Hegedüs wrote: > I hope we can solve these special rules in next year, and Tlf > will be the best logger on the world :). I know I'll be digging through the code and offering suggestions. :-) The Kansas QSO Party features a bonus station, although in six years I've yet to work it. :-( There's always a first time! Implementation thoughts. Probably will require a couple of new keywords. Perhaps one like BONUS_STATION which could be a space separated list in quotes. Then BONUS_STATION_POINTS would be the value for the station(s) in the list. That part was easy. Figuring out the scoring code will be a bit more tricky. Hopefully Tom can shed some insight into that. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Improved keyboard handling
After much study and searching and playing around, writing and testing code, and learning just how much difference there is between terminal emulators (and I've hardly scratched the surface), I am attaching two files for your testing pleasure. ;-) The idea is to enable Ncurses keypad mode and utilize the constants that keyname() recognizes as much as possible. The new-onechar.c file is essentially a reworked copy of ui_utils.c that can be compiled with the following command: gcc -o new-onechar -lncurses new-onechar.c When the program runs it will print the decimal ordinal of the pressed key and its name as returned by keyname(). Use Ctl-D exit. In the main() function ncurses is initialized as closely as possible to Tlf to avoid such differences. Of note is the use of the set_escdelay() function to lower the time getch() will wait from the default of 1000 mS to 25 mS. On my machines this is fast enough to process Alt-keys and other keys that have codes beginning with a value of 27 (^[ or Escape). The downside is that someone that must use Escape in place of Alt will not be able to. The small value was chosen to call stoptx() as soon as possible while allowing sufficient time to receive multi value escaped keys. A look at the new onechar() function show several test sections. I found this necessary to assign various Alt-key combinations into the constants that keyname() will return as M-key--M-a, M-b, etc. Also some keys are terminal specific. Thus far I have tested this on Xfce Terminal, Gnome Terminal, Xterm, and the Linux console as found in Debian 8. Other peculiarities likely lurk out there. I was surprised just how much variation there is just between the ones I tested. To determine the sent codes I used 'showkey -a' in each terminal. One oddity I found is that on the Linux console on my ThinkPad T410 laptop is that Shift-F9 through Shift-F12 produced no keystrokes. At this time all keys among the terminals are processed into a definition as found in the other attached file, names.txt. Implementing this will require a fair amount of care and I have not yet begun the process of doing so. For the most part, the work will consist of replacing one numeric constant with another in various places. Sometimes a named constant like KEY_HOME or KEY_BACKSPACE may be substituted. Before that I would like to hear back from others who will test this on various terminals and report back any unrecognized keys and their key codes as shown by 'showkey -a'. Have fun! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us Ordinal: 0 Name: ^@ Ordinal: 1 Name: ^A Ordinal: 2 Name: ^B Ordinal: 3 Name: ^C Ordinal: 4 Name: ^D Ordinal: 5 Name: ^E Ordinal: 6 Name: ^F Ordinal: 7 Name: ^G Ordinal: 8 Name: ^H Ordinal: 9 Name: ^I Ordinal: 10 Name: ^J Ordinal: 11 Name: ^K Ordinal: 12 Name: ^L Ordinal: 13 Name: ^M Ordinal: 14 Name: ^N Ordinal: 15 Name: ^O Ordinal: 16 Name: ^P Ordinal: 17 Name: ^Q Ordinal: 18 Name: ^R Ordinal: 19 Name: ^S Ordinal: 20 Name: ^T Ordinal: 21 Name: ^U Ordinal: 22 Name: ^V Ordinal: 23 Name: ^W Ordinal: 24 Name: ^X Ordinal: 25 Name: ^Y Ordinal: 26 Name: ^Z Ordinal: 27 Name: ^[ Ordinal: 28 Name: ^\ Ordinal: 29 Name: ^] Ordinal: 30 Name: ^^ Ordinal: 31 Name: ^_ Ordinal: 32 Name: Ordinal: 33 Name: ! Ordinal: 34 Name: " Ordinal: 35 Name: # Ordinal: 36 Name: $ Ordinal: 37 Name: % Ordinal: 38 Name: & Ordinal: 39 Name: ' Ordinal: 40 Name: ( Ordinal: 41 Name: ) Ordinal: 42 Name: * Ordinal: 43 Name: + Ordinal: 44 Name: , Ordinal: 45 Name: - Ordinal: 46 Name: . Ordinal: 47 Name: / Ordinal: 48 Name: 0 Ordinal: 49 Name: 1 Ordinal: 50 Name: 2 Ordinal: 51 Name: 3 Ordinal: 52 Name: 4 Ordinal: 53 Name: 5 Ordinal: 54 Name: 6 Ordinal: 55 Name: 7 Ordinal: 56 Name: 8 Ordinal: 57 Name: 9 Ordinal: 58 Name: : Ordinal: 59 Name: ; Ordinal: 60 Name: < Ordinal: 61 Name: = Ordinal: 62 Name: > Ordinal: 63 Name: ? Ordinal: 64 Name: @ Ordinal: 65 Name: A Ordinal: 66 Name: B Ordinal: 67 Name: C Ordinal: 68 Name: D Ordinal: 69 Name: E Ordinal: 70 Name: F Ordinal: 71 Name: G Ordinal: 72 Name: H Ordinal: 73 Name: I Ordinal: 74 Name: J Ordinal: 75 Name: K Ordinal: 76 Name: L Ordinal: 77 Name: M Ordinal: 78 Name: N Ordinal: 79 Name: O Ordinal: 80 Name: P Ordinal: 81 Name: Q Ordinal: 82 Name: R Ordinal: 83 Name: S Ordinal: 84 Name: T Ordinal: 85 Name: U Ordinal: 86 Name: V Ordinal: 87 Name: W Ordinal: 88 Name: X Ordinal: 89 Name: Y Ordinal: 90 Name: Z Ordinal: 91 Name: [ Ordinal: 92 Name: \ Ordinal: 93 Name: ] Ordinal: 94 Na
Re: [Tlf-devel] Improved keyboard handling
* On 2016 04 Jan 10:40 -0600, Ervin Hegedüs wrote: > Hi Nate, Happy New Year, Ervin. :-) > thanks for your test :), You're quite welcome! > just a short remark: I can compile it with this command: > > gcc -L/usr/lib/x86_64-linux-gnu -o new-onechar new-onechar.c -lncurses > > so, the necessary library must be the last argument in case of my > GCC (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)) Of course, this is not an issue for the Tlf build system as all will be found. This is just to compile the file I submitted earlier (note to the lurkers coming across this in the future). > here are some results from my Linux Mint: > > rxvt-unicode > > a 97 0141 0x61 > A 65 0101 0x41 > ^A 1 0001 0x01# CTRL+a > ^[a27 0033 0x1b# left ALT+a >97 0141 0x61 > ä 195 0303 0xc3# right ALT+a > 164 0244 0xa4 > > Escape delay time is: 25 mS > Ordinal: 97 Name: a > Ordinal: 65 Name: A > Ordinal: 1 Name: ^A > Ordinal: 225Name: M-a > Ordinal: 228Name: M-d > > > Mate terminal > = > a 97 0141 0x61 > A 65 0101 0x41 > ^A 1 0001 0x01 > ^[a27 0033 0x1b >97 0141 0x61 > ä 195 0303 0xc3 > 164 0244 0xa4 > > Escape delay time is: 25 mS > Ordinal: 97 Name: a > Ordinal: 65 Name: A > Ordinal: 1 Name: ^A > Ordinal: 225Name: M-a > Ordinal: 228Name: M-d > > > Note, that in most cases in my work, I preffer the rxvt-unicode, > but that not supports some special keys in Tlf - therefore I use > Gnome terminal or Mate for Tlf. (And as I remembe, on my > home-machine there is Lxc-terminal, or some kind of like this.) > > Now only these two "new" terminals what I have, which doesn't > exist in your list. Nice. It looks like things are being handled correctly. My goal is to get to a point where Tlf can work on the op's terminal of choice by unifying the key codes as much as possible. Along with the Alt-keys, I am also interested in keys such as F1-F12, Shift F1-Shift F12, Backspace, Insert, Delete, Home, End, Page-Up, Page-Down, and the arrow keys. On a US 101/104 (so-called Windows keyboard) keyboard the keys between the main keys and the numeric pad as well as the keys when Num Lock is off are of interest to me. > Hope this helps to you, Most certainly! I think I am on my way to help making the Tlf UI more consistent. I'm also learning a lot about Ncurses, which has been a goal of mine for years. :-) 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Improved keyboard handling
* On 2016 04 Jan 13:03 -0600, Pierre Fogal wrote: > Hi Nate, Hi Pierre. > Attached is the output from Konsole (KDE terminal) running under Mate on > Arch. > > If key combos don't show, they are mapped to something. And I discovered a > few mappings that, er, surprised me! Indeed! I kind of presumed (wrongly as it turns out) that there was quite a bit of similarity between terminals. > For some combinations there are notes enclosed in ( ) to the right of the > new-onechar output. At this time I think we're going to have to avoid Alt-F1-F12 and Ctl-F1-F12 as they are quite often captured by the various desktops and even the Linux console (Alt-F keys). The Shift-F1-12 keys seem safe although Tlf doesn't currently use them but the original onechar function does look for them so I carried that through. Depending on the terminal Alt-0 to Alt-9 may not be available. In Xfce Terminal with multiple tabs Alt-1 will jump to the left most tab, Alt-2 to the one to the right of that and so on. A quick work-around was a new tabless Xfce Terminal window and then those keys were passed through to the program. These sorts of issues are more a matter of documentation on our part than coding. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Improved keyboard handling
* On 2016 04 Jan 12:58 -0600, Thomas Beierlein wrote: > Hi Nate, hi Ervin, Happy New Year, Tom! > having some common key handling is a great goal - but not so even to > reach. I'd be thrilled will 95% coverage of Tlf's keys across most all terminals. I understand this is likely an effort that will never be entirely perfect and I expect the function to grow a bit more to cover a few more corner cases. since the tests are fairly well defined I don't expect speed issues for the most part. > Thanks for the work Nate. I did some similar stuff some time ago, but > got distracted by some more urgent problems in tlf. I will try to find > the old branch and push it to github for reference. > > I had a similar handling for the ESCDELAY and an activated keypad. Main > difference - I did only handle the alt-keys by adding the +128. In some cases a different value needs to be used (see the Xterm section) to assign the value into the range known by keyname() and define_key() as listed in the names.txt file. > If I remember correctly by doing so I was able to map nearly all used > key combinations in tlf to the new ncurses keys. The only ones which > did not work where the Ctrl-PgUp and Ctrl-PgDn keys which are not > handled by ncurses for the xfce terminal. Those are going to be a problem in some cases. The Gnome Terminal I installed had a handy configuration selection to disable all shortcuts which enabled nearly all the keys. Alt-Space was still caught by Xfce for the window menu. I also found that Xfce Terminal gives the same key code for Alt-A as with Alt-Shift-A while Gnome Terminal and Xterm gave separate codes for each. > I had hoped that with ncurses doing the key decoding that we could drop > the different handling for different terminal emulations. But that > seems to be not so. The good thing is that we can limit the custom coding to just a few corner cases which is a good thing. I'm surprised that the current batch of corner cases is already this large, but results from Ervin and Pierre have been encouraging. > Let me add two more terminal settings which we should check - that is > plain linux console and screen and/or tmux. I did a quick check on plain Linux Console on my T410 laptop but need to do so with a 101 key keyboard. I do use tmux (right now to access Mutt remotely) so it is also an easy test. In fact I did some tests this morning from a computer running Windows 7 and Putty and found that setting the keyboard entry to use Xterm gave me the F1-F4 keys. I'd been scratching my head over that for a long time which was a headache for using Midnight Commander remotely. Nice to know this exercise helped me fix that. > Maybe it is time to sort it out and get a solid solution. Nate it would > be nice if you could lead that work. Ervin and me we are willing to test > and give hints and support. would that be ok for you? Absolutely. I'll probably get a bit more done over the next couple of weeks and get a branch pushed out for wider testing. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Improved keyboard handling
* On 2016 04 Jan 14:35 -0600, Ervin Hegedüs wrote: > just a short info - now I checked my home-desktop (which I use > for Tlf, near the RIG), and here is the Gnome-terminal - Tlf only > works the this one. > > Here is the test result as above: > > Gnome-terminal > == > a 97 0141 0x61 > A 65 0101 0x41 > ^A 1 0001 0x01 > ^[ 27 0033 0x1b > a 97 0141 0x61 > ä 195 0303 0xc3 > 164 0244 0xa4 > > > Escape delay time is: 25 mS > Ordinal: 97 Name: a > Ordinal: 65 Name: A > Ordinal: 1 Name: ^A > Ordinal: 225Name: M-a > Ordinal: 228Name: M-d > > As you can see, in showkey cmd, the Alt-a sequence represents as > different mode - hope this is helpful... :) It is reporting a bit differently than Xterm although the prefix byte is the same. Ewww, yuck! I missed exactly what you were noting earlier. Solution: Just don't use the right Alt-key. ;-) In that terminal what is $TERM set to ($ echo $TERM)? I know there are some tests in main.c for $TERM and the original onechar() function takes at least the value of use_xterm into account. I will need to revisit that. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Improved keyboard handling
* On 2016 04 Jan 15:19 -0600, David Quental wrote: > Hi Nate and all from the list, > > to all a nice HNY 2016. > > Just to tell that I can not compile the new-onechar.c file: > > gcc -o new-onechar -lncurses new-onechar.c > /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: > /tmp/cc8JFHNd.o: undefined reference to symbol 'keypad' > /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/libtinfo.so: error > adding symbols: DSO missing from command line > collect2: error: ld returned 1 exit status > ct1drb@new-host:~/reserva/ct1drb/tlf/src> > > I have OpenSuSE leap 42.1 64bits. Hi David, es HNY! As I recall you'll need to change the line #include to #include As there is no build system a bit of manual work is required. ;-) 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Improved keyboard handling
* On 2016 04 Jan 15:19 -0600, David Quental wrote: > Hi Nate and all from the list, > > to all a nice HNY 2016. > > Just to tell that I can not compile the new-onechar.c file: > > gcc -o new-onechar -lncurses new-onechar.c > /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: > /tmp/cc8JFHNd.o: undefined reference to symbol 'keypad' > /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/libtinfo.so: error > adding symbols: DSO missing from command line > collect2: error: ld returned 1 exit status > ct1drb@new-host:~/reserva/ct1drb/tlf/src> > > I have OpenSuSE leap 42.1 64bits. Oh, please disregard my previous post. This is a linker error and not a compiler error. You will need to add the path where libnurses.so lives with the -L option, Ervin's first post has an example. HTH, 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Improved keyboard handling
* On 2016 04 Jan 15:14 -0600, Ervin Hegedüs wrote: > > In that terminal what is $TERM set to ($ echo $TERM)? > > Gnome-term/MATE terminal: xterm > rxvt-unicode: rxvt-unicode Everything here except the Linux console reports 'xterm' and still there are differences. :-/ I guess the next question is how best to handle this? Could it be the way your keyboard is configured? Is your right Alt setup as a 'Compose' key? There is also the 'xev' command that should report how the key is recognized. Here I get: KeyPress event, serial 38, synthetic NO, window 0x722, root 0x136, subw 0x0, time 3366418307, (-154,42), root:(597,503), state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 38, synthetic NO, window 0x722, root 0x136, subw 0x0, time 3366420183, (-154,42), root:(597,503), state 0x10, keycode 108 (keysym 0xffea, Alt_R), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False (each key press will also generate a KeyRelease event, but I did not copy those stanzas as they're the same) Note that each key is named as Alt_L and Alt_R. > Here are some screenshots about the different terminal types when > Tlf runs in: > > https://www.dropbox.com/sh/o66fidr21uryjwe/AADu-dKIta7PxYbCSiNLYmqPa That looks more like color theme differences. For example, Ubuntu has a very different color scheme for Xfce Terminal than Debian. At this time the keyboard is my focus. > If I can help you anything (eg. check the keys in different > terminals), just let me know! Certainly, keep testing and playing. It's how we learn this stuff. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Improved keyboard handling
* On 2016 04 Jan 12:58 -0600, Thomas Beierlein wrote: > If I remember correctly by doing so I was able to map nearly all used > key combinations in tlf to the new ncurses keys. The only ones which > did not work where the Ctrl-PgUp and Ctrl-PgDn keys which are not > handled by ncurses for the xfce terminal. It seems that Xfce catches these keys even when they're sent to a terminal window with no tabs. However, Gnome Terminal and Xterm give them the following codes: Ordinal: 519Name: kDC5 Ordinal: 523Name: kDN3 Ordinal: 525Name: kDN5 Ordinal: 528Name: kEND3 Ordinal: 530Name: kEND5 Ordinal: 533Name: kHOM3 Ordinal: 535Name: kHOM5 Ordinal: 543Name: kLFT3 Ordinal: 545Name: kLFT5 Ordinal: 548Name: kNXT3 Ordinal: 550Name: kNXT5 Ordinal: 553Name: kPRV3 Ordinal: 555Name: kPRV5 Ordinal: 558Name: kRIT3 Ordinal: 560Name: kRIT5 Ordinal: 564Name: kUP3 Ordinal: 566Name: kUP5 These keys aren't known to Ncurses but are defined by the Xterm terminfo database entry from what I found. Still keyname() generated the names for those keys. As I recall the keys with the suffix of '3' are Ctl-key combinations and the ones with the suffix of '5' are Alt-key combinations. In order the keys are: Delete Down Arrow End Home Left Arrow Page Down Page Up Right Arrow Up Arrow I'll add these to my names.txt file (probably should rename it to keynames.txt) as a future reference. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Improved keyboard handling
* On 2016 05 Jan 08:57 -0600, Nate Bargmann wrote: > As I recall the keys with the suffix of '3' are Ctl-key > combinations and the ones with the suffix of '5' are Alt-key > combinations. It's exactly the reverse (I should test rather than rely on memory), corrected version follows: keys with the suffix of '3' are Alt-key combinations. Keys with the suffix of '5' are Ctl-key combinations. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Improved keyboard handling
* On 2016 05 Jan 10:39 -0600, Thomas Beierlein wrote: > Here just a test with your program for the PgUp and PgDn on three > terminals: > > > xfce terminal xterm rxvt > Ctrl-PgUp -- 550 kPRV5 530 kPRV5 > Ctrl-PgDn -- 545 kNXT5 528 kNXT5 > Alt-PgUp548 kPRV3 548 kPRV5 338 KEY_NPAGE > Alt-PgDn543 kNXT3 543 kNXT5 339 KEY_PPAGE Ahh, RXVT, I recall why I dumped it years ago. ;-) > By the way there is a very easy way to check the plain keycodes from a > terminal. Just type > > $ cat > > and then you will get all key sequences for any key you press (minus > the ones that your terminal strips out - e.g. for Ctrl-PgUp/PgDn in > xfce terminal). I was never very good at interpreting line noise. ;-) ^[[5;5~^[[6;5~^C That's Ctl-PgUp Ctl-PgDn Ctl-C. Which is why discovering 'showkey -a' was so helpful to me: ^[[5;5~ 27 0033 0x1b 91 0133 0x5b 53 0065 0x35 59 0073 0x3b 53 0065 0x35 126 0176 0x7e ^[[6;5~ 27 0033 0x1b 91 0133 0x5b 54 0066 0x36 59 0073 0x3b 53 0065 0x35 126 0176 0x7e The numeric values are very easy to test in C code and the same character representation is given. I also have Qterm installed and it seems to follow the other desktop terminals for key codes. So far Gnome Terminal as found in Debian Jessie may be my choice of terminal since the shortcuts can be easily disabled. Now if I can convince it to start on X Display 1 instead of 0 I'll be happy. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TIME_OFFSET in logcfg.dat
* On 2016 05 Jan 19:57 -0600, Pierre Fogal wrote: > So, what's the purpose of this? I just discovered my RAC Winter contest > log is 5 hours off because I put TIME_OFFSET=5 into my logcfg.dat after I > came across it in the logcfg.dat example. It has a helpful comment of > > # > # # > # Time offset from UTC # > # # > # > > so I figured ... what the heck. > > Eastern standard time is 5 hours from UT. > > Clearly it was not the right thing to do. Probably reasonably easy to fix with Perl or AWK/Sed. Do back up your log file first! This is the upside of a plain text log file. Ahh well, you'll remember that detail next time. ;-) Good luck! 73, Nate P.S. you're not the first who has gained 'experience' in a like manner! -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Test branch use_keypad pushed to my GitHub
Here is my first crack at Tlf with the keypad() function. So far it 'Works For Me' (TM) in Gnome Terminal (the one X11 terminal that seems to honor the most keystrokes). So far, so good. :-D I have it at: https://github.com/N0NB/tlf/tree/use_keypad Beat on it. If it's reasonably acceptable, then I will issue a pull request, Tom. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Test branch use_keypad pushed to my GitHub
* On 2016 14 Jan 11:07 -0600, Thomas Beierlein wrote: > Hi Nate, > > just a quick feedback. > > I can do a serious check from my side not before the weekend. > Besides this I will try to prepare a tlf-1.2.3 to get our work from > the last weeks packaged. > > The new key handling and Ervins bandmap improvements are planned for > the next version (1.2.4) afterwards. That sounds fair. There is no rush as I can use my local builds. :-) 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.2.3 maintenance and bug-fix release
Good to see, Tom. Thanks! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Possible memory leak
I may have found a memory leak in Tlf. I have noticed that since enabling the cluster for testing that if I left Tlf run overnight that by morning the Hamlib TRX line would be reporting 0.0 and there would be no more spots in the bandmap. I chose to run Tlf under valgrind last night and this is what it reported: ==31899== Memcheck, a memory error detector ==31899== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==31899== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==31899== Command: /home/nate/local/bin/tlf ==31899== ==31899== Thread 2: ==31899== Source and destination overlap in memcpy(0xb9ce2a0, 0xb9ce39f, 256) ==31899==at 0x4C2D75D: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==31899==by 0x43958B: recvline (sockserv.c:415) ==31899==by 0x43CD4F: receive_packet (splitscreen.c:1221) ==31899==by 0x4098DE: background_process (background_process.c:100) ==31899==by 0x65E20A3: start_thread (pthread_create.c:309) ==31899==by 0x68DD04C: clone (clone.S:111) ==31899== ==31899== Thread 1: ==31899== Source and destination overlap in memcpy(0xb9ce2a0, 0xb9ce39f, 256) ==31899==at 0x4C2D75D: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==31899==by 0x43958B: recvline (sockserv.c:415) ==31899==by 0x43C936: packet (splitscreen.c:1099) ==31899==by 0x410014: changepars (changepars.c:777) ==31899==by 0x40D42B: callinput (callinput.c:572) ==31899==by 0x41E014: logit (logit.c:92) ==31899==by 0x41F73E: main (main.c:945) The code in question is: memcpy(sockbuf[ifds].buf, sockbuf[ifds].buf + len, sockbuf[ifds].buflen - len); Looking over the Glibc documentation it advises that if the source and destination locations overlap, then memmove() is the safe function to use. I modified the call to memmove() and ran Tlf for several hours through the night and it was functioning normally until I closed it to work K5P using CQRlog. I've attached a patch and will commit this to the master branch later. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us diff --git a/src/sockserv.c b/src/sockserv.c index 4386c2a..ced42f5 100644 --- a/src/sockserv.c +++ b/src/sockserv.c @@ -412,7 +412,7 @@ int recvline(int *fd, char *buf, int buflen) len = sockbuf[ifds].buflen; memcpy(buf, sockbuf[ifds].buf, len); if (sockbuf[ifds].buflen > len) - memcpy(sockbuf[ifds].buf, sockbuf[ifds].buf + len, + memmove(sockbuf[ifds].buf, sockbuf[ifds].buf + len, sockbuf[ifds].buflen - len); sockbuf[ifds].buflen -= len; *fd = ifds; ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] CQ 160m rules, anyone written one?
I thought I'd ask before I go reinventing wheels. The CQ 160m WW CW 'test is this coming weekend and it kind of snuck up on me! Has anyone done a rules file for this contest for a W/VE station? While I've doing quite a bit of hacking on the Tlf source, I'm still green on its rules subtleties. The rules seem straightforward: IV. Exchange: RS(T) and state for U.S., province for Canada, and CQ Zone for DX. Note: Zones are location indicators only and do not count for multipliers. This just seems to beg for a regex option for the rules file. ;-) V. Multiplier: U.S. States: (48 contiguous states); U.S. District of Columbia (DC) (1) Canadian Provinces: (14) VO1, VO2, NB, NS, PEI (VY2), VE2, VE3, VE4, VE5, VE6, VE7, VE8 (NWT), VY1 (YUK), VYØ. Note VO1 and VO2 are separate due to tradition. DXCC plus WAE countries: WAE: IT, GM (Shetland Islands), JW (Bear island), TA1 (European Turkey), 4U1VIC, Z6 Kosova. It looks like for W/VE the same list is used in ARRL DX: MULT_LIST=arrldx_mults SECTION_MULT WAE, I'm thoroughly unfamiliar with, although it's not likely that I'll work any. VI. Points: Contacts with stations in own country: 2 points. Contacts with other countries on same continent: 5 points. Contacts with other continents: 10 points Maritime mobile contacts count 5 points. There is no multiplier value for a maritime mobile contact. Do these choices looks sane? MY_COUNTRY_POINTS=2 MY_CONTINENT_POINTS=5 DX_POINTS=10 VII. SCORING: All stations—the final score is the result of the total QSO points multiplied by the sum of all multipliers (states, VE provinces, DX countries). Given the rules options above, I'll have to test the scoring this week. In reality with my antenna setup and running the K3 barefoot, odds are that the only DXCC countries I can expect to work are XE and a few Caribbean entities. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Radio change mode problem
* On 2016 26 Jan 09:43 -0600, Ervin Hegedüs wrote: > Note, that I'm not sure, there is a right way to do that - > I'm afraid, there isn't any reliable method to detect, which is > your _logmode_ (not RIG mode!), I mean, if you want to work in > AFSK, you'll select the LSB mode on your RIG, but choose DIGI > mode in Tlf. That was a bug I noticed the other evening looking at something else, that only LSB is available for digi modes. As I plan to expand to interfacing with Fldigi I am going to have to fix this one since I need to use PKTUSB with the K3 for PSK31 and PKTLSB for RTTY. Others may need to use the RTTY mode as well. A quick thought is to add a key word to the logcfg.dat vocabulary such as 'RIG_DIGIMODE=' and then the op could select whichever is needed for his setup and Tlf would set the rig mode to RIG_DIGIMODE, etc. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] CQ 160m rules, anyone written one?
It looks like this rules file will do the job for me in the upcoming CQ WW 160m CW 'test. Of course, bugs will show under contest conditions! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us # TEMPLATE containing most parameters # # for defining rules for a contest# # CONTEST=cqww160 LOGFILE=cqww160-2016 CONTEST_MODE CABRILLO=UNIVERSAL # ## ## # Messages F1= to F12= # # Message CQ_TU_MSG=# # Message S&P_TU_MSG= # ## # % = call # # @ = hiscall # # # = serial# # [ = RST # # + = increase cw speed # # - = decrease cw speed # ## ## # F1=CQ TEST % F2=@ DE % F3=@ 5NN KS F4=TU 73 F5= @ F6=% F7=@ SRI QSO B4 GL F8=AGN F9= ? F10= QRZ? F11= PSE K F12=+TEST- % % # CQ_TU_MSG=TU % S&P_TU_MSG=TU 5NN KS # #ALT_0= #ALT_1= #ALT_2= #ALT_3= #ALT_4= #ALT_5= #ALT_6= #ALT_7= #ALT_8= #ALT_9= # #SHORT_SERIAL #LONG_SERIAL # #SEND_DE # # # # # CONTEST PARAMETERS # #(roll your own... )# # # #CALLUPDATE # #MIXED # #--- # Can exchange be recycled? # e.g. impossible if it is a serial # number... # #RECALL_MULTS # # format serial number: (001) # #SERIAL_EXCHANGE # #--- # Multiplier type: # #WYSIWYG_MULTIBAND # (makes its own multiplier list #on the go...) # #WYSIWYG_ONCE # (same, but mults do not count #per band..) # # MULT_LIST=arrldx_mults #MULT_LIST=us_canada_states #SERIAL_SECTIONS DX_&_SECTIONS #SECTION_MULT #POWERMULT_5 #POWERMULT_2 # #PORTABLE_MULT_2 # # # # # POINTS LIST # # # # # # How may points per qso? # #ONE_POINT #TWO_POINTS #THREE_POINTS #2EU3DX_POINTS # #USE_COUNTRYLIST_ONLY #COUNTRYLIST=SP_DX:SP,HA #COUNTRY_LIST_POINTS=10 MY_COUNTRY_POINTS=2 MY_CONTINENT_POINTS=5 DX_POINTS=10 # # ### END #___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] CQ 160m rules, anyone written one?
* On 2016 29 Jan 12:02 -0600, Mike Waters wrote: > Thanks, Nate! I have an older version of tlf (not sure how to determine the > version) perhaps 3 years old. Any chance this rules file won't work? Hi Mike. There is always a chance, of course. Admittedly, I don't know as it would depend on when certain keywords were introduced, as I've not been heavily involved in Tlf development until recently. Easy way to tell is to set up a test directory and run with the new rules file from there and do some improvised contacts and see what happens. That's what I did last night. There is also the -v option which provides verbose startup. I will be running the same experimental version that Tom posted a link to a few days ago, although with a few extra features that I've not pushed out yet. So far I've had it running for hours on end without issue. GL in the 'test! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] CQ 160m rules, anyone written one?
* On 2016 30 Jan 18:43 -0600, Mike Waters wrote: > Nate, > > I found out yesterday that your CQWW 160 CW rules file is more-or-less the > same as the one I had! The uncommented lines were just in different places > in yours and my rules files. :-) I'll likely push mine out to Tom so there is a CQ 160 file available. > BTW, conditions on 160m both last night and tonight are the best that I > have seen in several years. I regret not working it last night. I was too worn out from installing cameras in the calving barn yesterday. I couldn't have concentrated at all. On the plus side, I did work HI for an new state/entity Saturday morning. Assuming it gets confirmed, I'll have 49 states on 160m. Now someone will tell me AK was easily workable this morning. Sigh... 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] IARU HF Championship
If anyone has a rules file for the upcoming IARU HF Championship, please share. Sure beats reinventing wheels! :-) 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] IARU HF Championship
I have a rudimentary rules file which beyond the edited parameters from the generic contest rules file I added: # # Scoring rules# # # ITUMULT MIXED RECALL_MULTS Perhaps I shouldn't really care about the scoring since it seems to be logging OK. For mults it is only counting the numeric zone. Per the IARU HFC rules, each HQ station should also count as a mult. Right now the only way to determine that is to assume that letter groups constitute an HQ station and therefore a mult, e.g. ARRL, RAC, DARC, etc. Finally, the scoring is, as expected, unique. Here is an extract from the scoring and multiplier rules on the ARRL Web site: 7. QSO Points: 7.1. Contacts within your own ITU zone, as well as QSOs with any IARU-member society HQ station or IARU official (counting as the special multiplier), count one point each. 7.1.1. Contacts with a station in the same ITU zone but on a different continent count one point. 7.2. Contacts within your continent (but different ITU zone) count three points. 7.3. Contacts with a different continent and IARU zone count five points. 8. Multipliers: The total number of ITU zones plus IARU member society HQ stations worked on each band (not mode). IARU officials represent a maximum of four multipliers per band (AC, R1, R2 and R3). 8.1. IARU member society HQ stations and officials do not count for zone multipliers. 8.2. To qualify as the special multiplier, Administrative Council and Regional Executive Committee stations must only be operated by the individual station licensee as a single operator entry or as a multi operator, single transmitter entry with significant participation by the licensee. I guess it's time to start hacking again. ;-) 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] short confirmation
We conspired. Ha! I should have issued the PR long ago. One thing I am starting to tackle is using CAT PTT via Hamlib. I hope to get something working by this weekend's HF Championship to see how it works. I have modified the vk_play script locally to use aplay instead of play as I'm using ALSA with PulseAudio. To direct the sound to the right adapter I use the GUI PA Volume Control program. I should probably do a bit more work to determine the correct command line options and include them in the script to make it a bit more bomb proof. I seem to recall that the recording feature of Tlf depends on the OSS drivers. Perhaps we should look into adding ALSA support since it is ubiquitous on Linux these days. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] short confirmation
* On 2016 04 Jul 00:19 -0500, Thomas Beierlein wrote: > Am Sat, 2 Jul 2016 14:13:01 -0500 > schrieb Nate Bargmann : > > > We conspired. Ha! > > I guessed so. Feel free to do again... Naw, it was just luck of the draw. Really! > > I seem to recall that the recording feature of Tlf depends on the OSS > > drivers. Perhaps we should look into adding ALSA support since it is > > ubiquitous on Linux these days. > > > Not quite. The recording of the voice keyer messages gets done by the > external 'rec' command from the sox package. Contest recording itself > uses also an external script (scripts/soundlog) atm also based on rec. > Finally playback is handled by 'play'. (see audio.c for details). > > What still is done with OSS and needs a rewrite to ALSA is the whole > suite of scanning functions (in same file). But I am not sure if that > functions are really needed or should better be done by an external > program. I think that utilizing debugged external programs is a wise thing to do, especially given that there are a few choices in this arena. Some people still prefer OSS over ALSA. Some people will have nothing to do with PulseAudio, etc. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Counties to state mult
I am getting ready for the KS QSO Party next weekend and so far I think Tlf will work just fine. As an in-state participant I have a total of 64 mults available to me--50 US states including Kansas where I reside, 13 Canadian provinces, and DX. Out of state participants have 105 Kansas counties as their multipliers. For them life would be rather simple using WYSIWYG_ONCE. For me it is not so simple as even when we in-state stations work each other, we give the three letter county abbreviation as the exchange, e.g. I give "599 MSH" and may receive "599 JOH". No matter, these exchanges only count for one mult, KS. However, Tlf treats them as additional mults as it has no way of being told to consider them as one mult. So this is an enhancement request. As I see it, perhaps an additional file option can be added where from either the file name or the first non comment line in the file the multiplier for which all of the strings that follow should be counted. As an example, the file format could be as follows: # Mult for which these strings count KS # County abbreviations ALL AND ATC BAR . . . Also, does the exchange input field call a validation function for the entered string when a mult file is given in the rules file? It seems to me that it doesn't. It may be a nice feature if it did and if no mult file is given, then the exchange field becomes free form and no validation is done. Thoughts? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.3.0 major release
* On 2017 08 Feb 00:02 -0600, Thomas Beierlein wrote: > After a lot of work by all people contributing to TLF I would like to > announce the release of the new TLF-1.3.0 version. > > You can find it at > > http://www.hs-mittweida.de/tb/tlf-1.3.0.tar.gz Tom, is this a permanent location that will be valid through future releases? I ask because I am working on a Slackware build script for Tlf and the script must know the download link. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.3.0 major release
* On 2017 12 Mar 10:41 -0500, Ervin Hegedüs wrote: > if yes, probably it would be good to enable the directory > listing. I've made the Debian package, but I had to remove the > watch file (which helps to checks the version checker the new > release of an upstream source), because it needs to read all > available versions. It would be nice if the nongnu site could be used since there is a project page there already to host the release tarballs. I wonder if the administrators would allow Tom to take over from Rein as administrator for the Savannah page. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.3.0 major release
Excellent news, Tom! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us signature.asc Description: Digital signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.3.0 major release
Good work, Tom. As for Git, I would use both sites and keep them in sync by pushing commits to each. I've had times when SourceForge was unavailable and had to rely solely on GitHub. It's matter of adding a remote and the doing a push to origin and to the the additional remote. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.3.0 major release
* On 2017 06 Apr 01:19 -0500, Thomas Beierlein wrote: > Nate suggested to use it as a backup copy. That seems to be a good > idea. So we can keep the main development at github, but host the code > also on savannah. You're welcome, Tom. These days I'm wearing several hats from upstream developer/maintainer, to downstream packager for Slackware, to contributor, to user, so I try to share what I've learned along the way. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us signature.asc Description: Digital signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] code indenting?
* On 2018 24 Jan 23:34 -0600, Thomas Beierlein wrote: > > GNU indent is a powerful tool for C source formatting and present in > > any modern Linux distro. We could define a common style simply by > > setting up an .indent.pro file. > > see http://www.gnu.org/software/indent/manual/indent.html#SEC4 > > > For a similar way you can look up the hamlib mailing list. They use > astyle now. I recommend astyle only for the fact that it can do some things GNU indent does not. It works well for getting the variety of coding styles found in the Hamlib code base somewhat close to what I want. I still go through and hand massage the files a bit more. > - I further had a look into the Travis CI which integrates neatly with > the github working flow. Maybe we should use it to do common checks > on the code automatically. I'd not heard of this. More info, Tom? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us signature.asc Description: Digital signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] code indenting?
* On 2018 25 Jan 09:29 -0600, Thomas Beierlein wrote: > Copy it to a file with name '.astylerc' and test with > > $ astyle --option=.astylerc < infile > outfile If the file is ~/.astylerc then '--option=' is not necessary. I actually have my own astylerc in my home directory and use '--option=' to use the file in the Hamlib scripts/ directory when formatting Hamlib files, which I've not done for a while... > I used 'meld' for comparison of old and new. There are mostly > whitespace changes. You can filter out these differences in the meld > preferences box and leave only the main structural ones. Some times I use the file comparison feature of Midnight Commander and other times I use the Magit package in Emacs. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us signature.asc Description: Digital signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] winkeydaemon updated to v1.0.5
As an FYI, for those who may use it, winkeydaemon has been updated to version 1.0.5 thanks to patches from Wilbert, PE7T. Here is the commit message: This patch adds the '-e' and '-m' switches. Using '-e' turns on 'paddle echo' on the winkeyer3. Also, it makes the daemon retransmit the received echo characters as UDP datagrams to the host and port of your choice (default: localhost:6790). Using the '-m' switch turns off the (annoying) side tone. Tested and and found to be working with WK3SMT 3.0.9. Works supposedly on WK2, too. On suggestion of Wilbert, README and INSTALL have been edited to remove some references that were no longer valid. The code is hosted at GitHub: https://github.com/N0NB/winkeydaemon and the release may be downloaded from: https://github.com/N0NB/winkeydaemon/archive/v1.0.5.tar.gz 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us signature.asc Description: Digital signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Recommended code formatting settings for Emacs?
Well, it's been some time since I hacked on Tlf and I'm getting back to it. As I've converted to using Emacs over the past year, the Tlf source uses a mixture of four space indents and, presumably, eight space tabs to align certain blocks of the code. When I was using Geany, it was able to use the correct character depending on the indent level. As I'm just looking at the code again, I'm curious if anyone else is using Emacs and what their settings are. I presently have Emacs configured for four spaces for each indent level that we're using in Hamlib. I could probably come up with a proper Tlf configuration with some help. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Handling multiplier aliases?
One of the limitations I have had with Tlf in the past is aliasing a list of multiplier strings to a single multiplier. To wit, like many US QSO Parties, the Kansas QSO Party has a different set of multipliers for in-state and out of state stations. For out of state stations the situation is straight forward, the 105 counties in Kansas which are three characters in length. For in-state stations, such as myself, it is a bit more complicated as our multipliers are the other 49 states using the USPS two-letter state abbreviations and the 14 Canadian provinces, also by a two letter abbreviation, and DX for the rest of the world. When an in-state works another in-state we exchange the three letter county abbreviation, however, only the first exchange counts for Kansas, so we have a total of 64 multipliers! In its current iteration, Tlf treats the three letter county abbreviations as a new multiplier for each, but this is clearly wrong per our rules. To provide an accurate log summary I use a custom Python script to process the log after the event. It would be nice to have Tlf count the multipliers properly and verify the entered exchange against the list to avoid typing errors. How best can we accomplish this? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
* On 2018 05 Jun 22:21 -0500, Thomas Beierlein wrote: > Hi Nate, > > ltns, hope you are well. Oh, I am doing fine. Been working on Hamlib documentation after getting 3.2 out into the wild, doing some FT-8 lately, fixing a noisy DG-5 for my TS-520SE, looking at a friend's FT-890 and hooking up my FT-890 for a radio to check into nets while the K3 does FT-8 duty. Just small stuff. :-) > We will look into it, but it would be nice to have some more > information. > > Can you please provide us with your logcfg.dat, a sample log with > marked errors/problems and maybe your python script as a starter? I'll attach the 2017 log, logcfg.dat, rules file, my mults file, and the Perl script (thought I'd done it in Python, but this is in the directory. You can play with the scoring and adding new QSOs with the KS counties to see what Tlf does. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB # General contest mode # # CONTEST=ksqp LOGFILE=ksqp_2017.log CONTEST_MODE CABRILLO=UNIVERSAL # ## ## # Messages F1= to F12= # # Message CQ_TU_MSG=# # Message S&P_TU_MSG= # ## # % = call # # @ = hiscall # # # = serial# # [ = RST # # + = increase cw speed # # - = decrease cw speed # ## ## # F1=CQ KQP % F2=@ DE % F3=@ 5NN MSH F4= TU F5=@ F6=% F7=@ SRI QSO B4 GL F8=AGN F9=? F10=QRZ? F11=PSE K F12=CQ KQP % # CQ_TU_MSG=TU % S&P_TU_MSG=TU 5NN MSH # #ALT_0= #ALT_1= #ALT_2= #ALT_3= #ALT_4= #ALT_5= #ALT_6= #ALT_7= #ALT_8= #ALT_9= # #SEND_DE # # # # # Voice Keyer Files# #(F1 to F12)# # # VKM1=/home/nate/logs/wav/N0N/kqp/F1.wav VKM2=/home/nate/logs/wav/N0N/kqp/F2.wav VKM3=/home/nate/logs/wav/N0N/kqp/F3.wav VKM4=/home/nate/logs/wav/N0N/kqp/F4.wav #VKM5= VKM6=/home/nate/logs/wav/N0N/kqp/F6.wav #VKM7= VKM8=/home/nate/logs/wav/N0N/kqp/F8.wav #VKM9= VKM10=/home/nate/logs/wav/N0N/kqp/F10.wav VKM11=/home/nate/logs/wav/N0N/kqp/F11.wav VKM12=/home/nate/logs/wav/N0N/kqp/F12.wav VKSPM=/home/nate/logs/wav/N0N/kqp/SPM.wav VKCQM=/home/nate/logs/wav/N0N/kqp/CQM.wav # # # # Scoring rules# # # MIXED RECALL_MULTS SSBPOINTS=2 CWPOINTS=3 WYSIWYG_ONCE MULT_LIST=ksqp.txt ### END # # DX DX # Canada provinces AB BC MB NB NL NT NS NU ON PE QC SK YT # US states (50) AL AK AZ AR CA CO CT DE FL GA HI ID IL IN IA KS KY LA ME MD MA MI MN MS MO MT NE NV NH NJ NM NY NC ND OH OK OR PA RI SC SD TN TX UT VT VA WA WV WI WY # KS counties (105) ALL AND ATC BAR BRT BOU BRO BUT CHS CHT CHE CHY CLK CLY CLO COF COM COW CRA DEC DIC DON DOU EDW ELK ELL ELS FIN FOR FRA GEA GOV GRM GRT GRY GLY GRE HAM HPR HVY HAS HOG JAC JEF JEW JOH KEA KIN KIO LAB LAN LEA LCN LIN LOG LYO MRN MSH MCP MEA MIA MIT MGY MOR MTN NEM NEO NES NOR OSA OSB OTT PAW PHI POT PRA RAW REN REP RIC RIL ROO RUS RSL SAL SCO SED SEW SHA SHE SMN SMI STA STN STE SUM THO TRE WAB WAL WAS WIC WIL WOO WYA 20CW 26-Aug-17 14:00 0001 K3MB 599 599 PA 3 14042.2 20CW 26-Aug-17 14:03 0002 KN4Y 599 599 FL 3 14042.2 20CW 26-Aug-17 14:05 0003 N8II 599 599 WV 3 14042.2 20CW 26-Aug-17 14:09 0004 K0PV 599 599 CO 3 14042.2 20CW 26-Aug-17 14:11 0005 K4XI 599 599 FL 3 14042.2 20CW 26-Aug-17 14:12 0006 K4ZGB 599 599 AL 3 14042.2 20CW 26-Aug-17 14:18 0007 VE3AYR 599 599 ON 3 14042.2 20CW 26-Aug-17 14:20 0008 WB2PJH 599 599 NJ 3 14042.2 20CW 26-Aug-17 14:20 0009 N6MU 599 599 CA 3 14042.2 20CW 26-Aug-17 14:21 0010 KD8DEU 599 599 MI 3 14042.2 20CW 26-Aug-17 14:21 0011 AE1T 599 599 NH 3 14042.2 20CW 26-Aug-17 14:22 0012 K3TN 599 599 MD 3 14042.2 20CW 26-Aug-17 14:26 0013 VE4EA 599 599 MB 3 14042.2 20CW 26-Aug-17 14:28 0014 WA2FZB 599 599 NJ 3 14042.2 20CW 26-Aug-17 14:28 0015 N4UP 599 599 VA 3 14042.2 20CW 26-Aug-17 14:29 0016 K2HVN 599 599 DE 3 14042.2 20CW 26-Aug-17 14:30 0017 N4NQ 599 599 GA 3 14042.2 20CW 26-Aug-17 14:30 0018
Re: [Tlf-devel] Handling multiplier aliases?
One thought I had would be to create a parallel mults file definition using GKeyFile as the means for setting groups for mults, alias, and alias_mults. I am thinking along the lines of: [Mults] AL AK AZ . . . WV WY [Alias] KS [AliasMults] (County abbreviations) Then the code could look for the Mults group and if found process it and if not, then revert to the current mults file style. In this format, any AliasMult entered would be applied as the Alias. Thoughts? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
* On 2018 11 Jun 12:07 -0500, Ervin Hegedüs wrote: Hi Ervin! > and you should pass this file to Tlf through parse_logcfg.c? > > brrr > > :) It's been a while since I followed the logic. Maybe that's why I sent the email first. ;-) > I think the codebase of Tlf is already very complex. I agree. I use 'git grep' a lot to find my way around. I do this with Hamlib and I've been developing on it for 15 years or so! > How many contest could we use this feature? I think it would be useful for a lot of US QSO parties. Not every state has its own party so there are far less than 50 as some states do one party as a group. Also, this probably only affects in-state participants. How many Tlf users would this impact immediately, well, me, for one. :-D > Once upon I proposed that we sould start to a new direction in > config file/rules parsing. I'm still thinking that the best way > would be implement some external scripting language, as module, > eg. Python and/or Lua. With one of those, everyone can make a > more sophisticate rule for every contests. > > Here is my original opinion: > > http://lists.nongnu.org/archive/html/tlf-devel/2014-01/msg00101.html Thanks for the pointer back into that thread. I tossed a number of lofty ideas out there! This post from Tom is apropos to this thread: http://lists.nongnu.org/archive/html/tlf-devel/2014-01/msg00104.html 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
Let me start over on this as I think there are a few misunderstandings. * On 2018 11 Jun 12:07 -0500, Ervin Hegedüs wrote: > Hi all, > > On Mon, Jun 11, 2018 at 08:18:11AM -0500, Nate Bargmann wrote: > > One thought I had would be to create a parallel mults file definition > > using GKeyFile as the means for setting groups for mults, alias, and > > alias_mults. I am thinking along the lines of: > > > > [Mults] > > AL > > AK > > AZ > > . > > . > > . > > WV > > WY > > > > [Alias] > > KS > > > > [AliasMults] > > (County abbreviations) > > > > > > Then the code could look for the Mults group and if found process it and > > if not, then revert to the current mults file style. > > > > In this format, any AliasMult entered would be applied as the Alias. > > > > Thoughts? > > and you should pass this file to Tlf through parse_logcfg.c? No. This is in the mults file and should be handled in the same code area as the present mults file is read. Correct me if I'm wrong, but I didn't think parse_logcfg.c handled the mults file processing. Here is my outline of the logic flow (based on my likely misunderstanding of the process). The open mults file function is called. The GKeyFile functions are used to open the mults file and test if the group "[Mults]" is present. If so, the Mults, Alias, and AliasMults are loaded into their respective data structures. If not, the present mults processing code is used and the file is loaded into the mults data structure. During logging operations the exchange validator can process the mults structures as follows. Any string appearing in [Mults] is subject to the rules for mults defined elsewhere, either internally or in the rules file. Any string appearing in [AliasMults] is applied to the [Alias] value which is then subject to the mults rules. In the case of the Kansas QSO Party, here is how it would work. An in-state participant has 64 mults available--50 US states, 13 Canadian provinces, and "DX". When an in-state op works another in-state op we exchange the county abbreviations ([AliasMults]) and the first one counts as the KS mult and any subsequent counties are not counted toward the mults. The current implementation of Tlf does not allow for the 105 Kansas counties to only count toward KS one time. In order to validate the exchange I included the 105 counties in the mults file (attached in a previous mail) so Tlf treats it as 169 mults! Therefore I have a custom script to calculate my raw score. It's not a big deal, it's just a nice to have feature. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
* On 2018 12 Jun 00:29 -0500, Thomas Beierlein wrote: > Hi Nate, hi Ervin, > > sorry to jump in late in the discussion. Our local field day kept me > busy the last days. Hope you had fun. > For me there are two distinct points in that discussion: > > a) How to present the multis and their alias (e.g. by the GKey format > as proposed) > b) How to present and score it internally. > > Wrt b) I had some time to think about and there are some first ideas. > > Regarding the format I am 100% for the GKeyFile format - at least in > the long run. At the moment we would introduce a new concept to > TLF's users. So I am not sure if something like the following could do > also: > > # plain multis > AL > AK > AZ > . > . > . > WV > WY > # aliased multi with aliases > KS:ALL,AND,ATC,... > # additional entries > KS:WAB,WAL,WAS, ... > > The format is also easy to write (and to parse). > > Any comments? It occurred to me later that GKeyFile expects entries to be key=value pairs. My list would seem to be breaking that as it would, at best, merely be a list of keys. I *think* that would be workable, but maybe not. I like your method of defining the alias mult and its aliases. In fact, for those parties that require it, multiple mults and aliases could be easily defined. for the 7 Land QSO Party it could be: NV:...,...,..., ... WY:...,...,..., ... etc. That is actually quite clever. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
