Re: ToDo item: switch logfile to database
* On 2023 28 Dec 13:07 -0600, Christoph Berg wrote: > But sqlite is not a networking database. If you want that, use > PostgreSQL. I've been using the WeeWX weather station processing software for nearly nine years and it prefers to use SQLite for its DB. It also supports Mysql/Mariadb. Recently a contributor has begun writing support for Postgresql. He has noted that the SQL dialects of SQLite and Mysql are similar but quite different from Postgresql which he states adheres closely to the SQL standard. Those familiar with both can better respond on this, but I would say that it appears that supporting both SQLite and Postgresql could require a lot of duplicate work. I don't know this for certain so this would be an area the project would need to examine carefully. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: ToDo item: switch logfile to database
* On 2023 28 Dec 08:57 -0600, Alan Dove wrote: > Hey, folks: > > I'm opposed to having TLF rely on a database. It adds complexity and > failure points, and shouldn't be necessary for any forseeable contest > log. I think this is a good point particularly in the logging space where Tlf is mostly used as a logger for single operator efforts. > Users who want a tool to collect QSOs from multiple contests for > analysis, DXCC tracking, and so forth should use a separate > application. CQRLog does all that and more, and also exemplifies the > kinds of support problems a database can add - just browse through the > CQRLog forums for tales of woe from users who can't get the database > connection working properly. CQRlog was also my first thought and I do use it though I do not aggregate my contest event log data into it. However, CQRlog is X11 GUI only and is not a solution for anyone working only in the console (that's not an argument toward having Tlf depend on a DB). There are also online log repositories but one has to constantly upload to them and rely on the services offered to make use of the data. The somewhat misnamed Logbook of The World does not import a considerable amount of uploaded ADIF data as it is only intended to retain data needed for ARRL and CQ WAZ award tracking. The list of compromises with these services goes on. CQRlog depends on Mysql/Mariadb and can use it in two modes. The first is the usual where the server process is running on localhost or a remote host and the second where it acts a bit like SQLite by starting a private server that saves the DB in the user's home directory hierarchy. I use the second method as it avoids having to become a DB administrator. For those unfamiliar, SQLite is an embedded DB. It saves the database to a single file that can be specified at run time. Like the current log file the SQLite database file would be written in the working directory for a given event. While SQLite supports transactions internally, the single file is still subject to anything that affects the file system in use. Backups are relatively easy by simply copying the file though care should be take to ensure a write is not in progress. How much that differs from copying the present log file merits investigation. An advantage to SQLite would be the ability to quite easily construct queries in the SQL syntax that would require custom C code with a flat text file. That said, text has the advantage that many tools can work with it from the shell prompt or with higher level scripting languages (editing log data at runtime would likely require custom code whereas now it can be piped to a favorite editor). An application accesses the SQLite DB through library calls. A certain amount of access at the shell prompt is available via the sqlite utility. > Networking should definitely be a higher priority. Thinking of a networked multi-position station setup, each position's computer having Tlf using an SQLite DB could be less error prone with the potential for multiple entries from the other positions arriving nearly simultaneously and the local station wanting to read the log for previously worked callsigns, etc. SQLite appears to be able to manage that with ease whereas keeping a flat file in sync internally could be a problem. I don't have any empirical data to back this up, but my thought is that once a log file were to exceed a few thousand entries that SQLite would probably have the performance edge even if the log is kept in a single flat table. Food for thought. 73, Nate, N0NB -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Updated ARRL Sections list
For anyone wanting to work the ARRL 160m or certain future ARRL contests, I have updated the arrlsections file: https://raw.githubusercontent.com/N0NB/tlf/update_arrl_sections/share/arrlsections My apologies for not catching this until ARRL November Sweepstakes was past. I think this list also is used for ARRL Field Day and some other ARRL events. I wonder if there needs to be some accommodation for former section names. While I've kept the file somewhat current, I see no issue with having both GTA and GH in the file, except that validation would then allow both, when the former is incorrect for the present time. Off the top of my head, I wonder if the mults parser could be extended so that a syntax such as: GH:20230701 GTA:20180101:202306030 implying a start date that is current (no end date given) for GH and a start and end date for GTA (I don't think those are the actual dates, as I just guessed at dates for this discussion). It would probably take considerable research to discover the actual dates and may not even be worth the effort as I doubt logs are rescored years after the fact. Thoughts? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Remove CTCOMPATIBLE mode (RFC #2)
* On 2023 27 Aug 14:24 -0500, Csahok Zoltan wrote: > Wouldn't SPRINTMODE do this for you? (or is it broken? haven't tried it yet) > >SPRINTMODE > If set, Tlf will automatically switch its mode between LOG and > S after every QSO. Fred, have you had a chance to test this idea? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Tlf and the 2023 KS QSO Party
Thanks to the hard work of everyone, my use of Tlf for this year's KS QP was the smoothest yet. The scoring module is bang on except for the addition of 100 points for working KS0KS, but I don't think that is something I ever mentioned for inclusion. ESC to kill sending of Morse and voice files worked quite well. There were some instances of my only having a couple of letters typed in and while transmitting a Morse message that hitting ESC wiped the call field. I don't really recall the exact circumstances but it may have been the case where it was split second timing between the end of the message and my hitting ESC. This was much less annoying than losing an entire exchange as before! Because I use full break-in (QSK) in CW mode, I often need to end a transmission before a message is completely sent when I hear the other station begin transmitting. I don't always remember what I've typed so preserving the field contents is important to me. As I recall, CT and N1MM only use ESC to stop sending and use another key combination to wipe the fields. Now, this may be cumbersome to more proficient ops but for a lot of us, the program should retain all entered information until such time as the op deliberately wants to wipe the fields. There are too many times when out of frustration I whacked the ESC key multiple times with other programs (one stop is good, four five stops being even gooder, sort of thing), a habit I've had to unlearn with Tlf. Perhaps I need to revisit my configuration in light of recent development. Tlf scored all mults and QSO points correctly for me this year. I made sure to use the new Python scoring module and it worked perfectly as near as I could tell. Right at the end I mistyped a county abbreviation which Tlf accepted but my log processing script caught. Perhaps the scoring module should compare the entered string with the mults list in the Python rules file. It would still fail to catch an error such as MS entered for MSH, or WA for WAS, for example. For that we probably need AI (Applied Instruction). The sound recorder worked perfectly, except for when I forgot to start it yesterday morning and didn't record the first two hours of the event. D'oh! Having upgraded to Debian 12 a couple of weeks earlier and with PipeWire replacing PulseAudio as the sound server, I did have to revisit sound level settings. The pavucontrol app still works as before and still seems to save audio level settings per application which means levels can be set for both Tlf using SoX and WSJT-X using the ALSA plugin. The improvements to Tlf are noticeable. Thank you! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Remove CTCOMPATIBLE mode (RFC #2)
I just opened issue #407 to remove CTCOMPATIBLE mode and all associated code and documentation. Here is the text from the issue: I first broached this subject back in November 2019: https://lists.nongnu.org/archive/html/tlf-devel/2019-11/msg00120.html I'd found that the CT commands in Tlf were not correct but since no one had ever complained, I corrected them. No one complained about the changed behavior which led to this thread in January 2020: https://lists.nongnu.org/archive/html/tlf-devel/2020-01/msg3.html One objection was posted by Fred, DH5FS: https://lists.nongnu.org/archive/html/tlf-devel/2020-01/msg00010.html Questions were asked of Fred with no response. In May 2020 I followed up the thread with: https://lists.nongnu.org/archive/html/tlf-devel/2020-05/msg8.html Still no word from Fred. If there is no opposition, CTCOMPATIBLE will be removed. I think there is enough capability in Tlf to warrant moving on from what is now essentially a dead and gone way of logging. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: not1mm
* On 2023 16 May 09:07 -0500, Drew Arnett wrote: > In the world of open source contest loggers, just saw this posted on > reddit: https://github.com/mbridak/not1mm I do like his sense of humor, especially the Men Without Hats reference! > Cross platform for networked logging is definitely one thing I'm interested > in. He does say that if on MS Windows, run away. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Color changes
* On 2023 11 Apr 13:05 -0500, Martin Kratoska wrote: > Yes, I played a lot with Xresources but there is not a solution. For the > better visibility to my old eyes I need simply to replace the "bright" cyan > color with bright red color. That's all. I am looking into the source code > where to change this single color. Cyan sucks! Otherwise the color scheme is > excellent, ensuring low fatigue to my eyes, the cyan color is the ONLY > problem... Did you actually try the Xresources file included with TLF> https://github.com/Tlf/tlf/blob/master/doc/Xresources I've attached a screenshot of UXterm running with that very same set of colors and my white background is more gray than yours providing better contrast. I have also found that on GNOME the Xresources file isn't always read so the 'xrdb' command has to be run before starting [U]Xterm|[u]rxvt. Please compare my screenshot to yours. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Color changes
Terminals are set up in interesting ways. If you're using Xterm or rxvt, then there is an X Resources file in the TLF repository that sets the colors to mimic those of the Linux console withe a VGA color scheme. Perhaps this post will help: https://www.n0nb.us/blog/2020/02/coping-with-color-on-the-linux-console-and-xterm-and-friends/ If you're using the terminal from a desktop environment, then setting the actual colors will vary with the terminal at hand. I use Xterm (UXterm, actually for UTF-8) with the VGA color palette. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: When writing the Cabrillo file the exchange is not prompted
* On 2022 22 Nov 03:35 -0600, Csahok Zoltan wrote:
> Hi Nate,
>
> OK, the issue is in the internal definition of the ARRL-SS contest.
> For some (most likely historical) reason exchange_serial is set
> to true for this contest. The meaning of this field has probably
> drifted from "exchange has a serial number part" to "exchange is a serial
> number only", thus not matching ARRL-SS any more.
>
> The quick solution is to comment out the offending line in src/setcontest.c:
> @@ -219,7 +219,7 @@ contest_config_t config_arrldx_dx = {
> contest_config_t config_arrl_ss = {
> .id = ARRL_SS,
> .name = "ARRL_SS",
> -.exchange_serial = true,
> +//.exchange_serial = true,
> .points = {
> .type = FIXED,
> .point = 2,
>
> As exchange_serial (also controlled by SERIAL_EXCHANGE) has precedence over
> CABRILLO-EXCHANGE, the value you set as exchange was always ignored.
You're the best!
That did the trick. Also, I got an error for my format being too wide
and thought about it then went back into logcfg.dat and modified the
CABRILLO-EXCHANGE value by removing the quotes to:
CABRILLO-EXCHANGE= # A 83 KS
And it works as expected! I suspect that I am the first to use TLF in
SS for a long time so do apply this patch as I would consider that line
the culprit.
> I tested it for a generic contest so this issue didn't pop up.
Hence why I sent you everything I had just to see if the problem would
turn up for you.
73, Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
signature.asc
Description: PGP signature
Re: When writing the Cabrillo file the exchange is not prompted
* On 2022 21 Nov 07:44 -0600, Csahok Zoltan wrote: > > Is something like 'CABRILLO-EXCHANGE= # A 83 KS' supported? > Yes, exactly. > > Regarding the template: could it be that TLF doesn't use it? Due to eg. not > finding it. > It works OK for me. Still no joy here. I moved all of the Cabrillo settings into logcfg.dat and commented the setting for the template file and moved it out of the directory. I set: CABRILLO-EXCHANGE= # A 83 KS But it is not reflected in the generated file: QSO: 14325 PH 2022-11-20 0054 N0NB 0001 W7DX374 M 73 WWA I even tried quoting is as: CABRILLO-EXCHANGE="# A 83 KS" and there was no change in the output. It should be formatted per the example at the bottom of the page that ARRL provides: http://www.arrl.org/cabrillo-format-tutorial In other words, I expect to see this: QSO: 14325 PH 2022-11-20 0054 N0NB 0001 A 83 KS W7DX374 M 73 WWA 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: When writing the Cabrillo file the exchange is not prompted
* On 2022 21 Nov 06:57 -0600, Csahok Zoltan wrote: > And there is surely neither CABRILLO-EXCHANGE nor SERIAL_EXCHANGE in > the logcfg and rule file? > (stock logcfg.dat has "CABRILLO-EXCHANGE= #" on line 171) I just checked to be sure and no, that keyword does not appear in either of my local files. My logcfg.dat is from long ago and doesn't include all the CABRILLO keywords. Is something like 'CABRILLO-EXCHANGE= # A 83 KS' supported? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: When writing the Cabrillo file the exchange is not prompted
* On 2022 21 Nov 06:12 -0600, Csahok Zoltan wrote: > Try adding this line to SS_template.cbr: > > EXCHANGE: 12 ABC I added: EXCHANGE: # A 83 KS to the template and there is no change to the generated Cabrillo file. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: When writing the Cabrillo file the exchange is not prompted
* On 2022 20 Nov 22:27 -0600, Csahok Zoltan wrote: > Hi Nate, > > How are your CABRILLO* config parameters set? In the rules file there is CABRILLO=ARRL-SS and in logcfg.date there is CABRILLO-TEMPLATE=SS_template.cbr and the template file has nothing out of the ordinary. > Did TLF ask for the other fields like category info? Yes, it mostly went through everything until I added the template file and the setting for its name in logcfg.dat. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
When writing the Cabrillo file the exchange is not prompted
Hi All. I just completed working some of the ARRL SS this weekend. As the logs must be submitted within seven (7) days, I set to work on generating the Cabrillo file. The problem is that the program doesn't prompt for my sent exchange. I built TLF from the master branch on Friday, if that makes a difference. I am only seeing the serial number in the Cabrillo file, the rest of my sent exchange is not there. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: The Contest Logging SW Future
* On 2022 15 Nov 13:14 -0600, Alan Dove wrote: > Hey, folks: > > Godot is extremely hobbyist-friendly; I'd say the majority of people > using it right now are hobbyists playing around in game jams and > building passion projects. There's a huge amount of training material > online for it as well, both free and paid. I'd be interested to see what you come up with. I'm not a gamer by any stretch so I'd probably have trouble following the documentation or trying to transliterate it into a logging UI. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: TLF, open source contest logging SW, and contest logging SW future
Beware that I've been watching this space for nearly 25 years and I've developed a certain skepticism/cynicism. Unavoidable, I guess. * On 2022 15 Nov 05:59 -0600, Alan Dove wrote: > Hey, folks: > > I agree that the current state of logging software - on all platforms - > is pretty stale. This business of having bespoke platform-restricted > programs, each with its own peculiar ways of doing things, feels very > dated now. The plethora of ham logging applications in development > suggests a lot of other people feel the same. Unfortunately, almost all > of them are one-person efforts that seem to get off to a strong start, > then languish. I think the unquestioned leader these days is N1MM+. I've not looked at it for a couple of years but the breadth and depth of events it supports likely dwarfs any current project by an order of magnitude or more. Eclipsing it would be a Herculean task; equaling it would astounding. Tom has a dedicated group of developers that churn out updates at an incredible rate: https://n1mmwp.hamdocs.com/downloads/update-history/ I'll be honest and say that it will take untold hours and dedication to equal it. The only thing that N1MM+ has against it is that is locked into MS Windows and that doesn't appear to be changing any time soon. > Rather than having individual developers dive right into coding more > soon-to-be-abandoned loggers from scratch, I think what needs to happen > is for a group of code-literate hams to come together and decide on a > general approach, then pursue it together. I've been thinking about two > potential strategies, each with distinct strengths and weaknesses. > > Because I've been learning game coding recently, I've thought about > building a logger in Godot, the open source game engine ( > https://godotengine.org/ ). As a game engine, Godot has a slew of > built-in functions for displaying information, and this could produce a > logger that looks really cool and is fun to use. Cross-platform > compilation is built into the engine, so releasing packages for > Windows, Mac, Linux, Android, iOS and web should all be feasible. The > main drawback to this approach is that I suspect the number of hams who > are also into Godot is pretty small, so the developer pool might be > kind of restricted. That said, Godot is not that hard to learn, and its > internal scripting language is very much like Python. That is intriguing, how approachable is it for hobbyists? Its main Web page promises a lot. Certainly the ability to use various languages would appear to offer opportunities to various developers. Cross-platform is a definite win. > The other strategy would be to build a logger in some Javascript-based > web-like framework, either with Electron or as a progressive web app ( > https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps ). > Everybody and their mother has some relevant coding skills in the > underlying languages (HTML, CSS, Javascript), so there's a huge > potential developer pool, and these sorts of applications are > inherently cross-platform. I think the biggest challenges would > probably be things like rig interfacing and possibly performance issues > with logs containing huge numbers of QSOs. JS has historically implied the use of a browser and browsers have historically been very poor at maintaining focus of a text entry field. It is a regular annoyance of mine to be typing into a browser window, switching away to another application for whatever reason, switching back and begin typing only to look and see that my keystrokes have apparently been directed to /dev/null. This has been an ongoing issue since ever since I started using browsers! This makes them completely unacceptable for use as a contest logger which is also why I think this approach has never caught on. For efficient entry a logger needs to return focus to the field that was in use before whatever action caused it lose focus and it needs to do this every time without the operator having to intervene. Even in stand-alone apps this requires careful attention. With browsers seemingly breaking keyboard UI willy nilly over the decades, this is unacceptable. If such a JS app can be coded to run stand-alone then the goal is possible. As it is unlikely that MS will port .NET to Linux such that it will run on all distributions as well as on later versions of Windows, N1MM+ being multi-platform is a pipe dream. Of the two approaches above the Godot approach likely has the better chance of implementing a UI serious contest operators can utilize. > Until such a project gets underway, I think we'll just keep muddling > through with the current mix of applications. I think there will always be a variations of applications available due to varying operator interests. There will be operators who only want to log and dupe and submit a Cabrillo log with no external device interfacing. At the other end are those who want the logger to control every device in
Re: What is the tlf future?
Hi Martin. Are you aware of the Tr Linux port? https://www.kkn.net/trlinux/ This is the "real deal" that I think TLF was modeled after initially. I just checked the Tr mailing list archives and apparently you are aware of it. I am curious why you've popped back in here with your thoughts but have not posted them to that mailing list as well? If you want to bang on us for not developing TLF to your liking, fine, but why not bang on the developers of Tr if it's not a perfect for for you as well? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: What is the tlf future?
* On 2022 14 Oct 10:05 -0500, Alan Dove wrote: > Hey, folks: > > The biggest barrier I see to wider Linux use in the ham shack is that > the two most important pieces of software for hams, a general logger > and a contest logger, are only available in single-platform versions > that haven't drawn very large developer communities. Essentially, > there's CQRLog for general logging, and about 1.5 usable contest > loggers that all run in console windows. > > None of these applications are available on Windows or Mac, so right > away the pool of potential developers is only that tiny sliver of the > Venn diagram where ham radio operators, qualified software developers, > and Linux aficionados overlap. For CQRLog, the developer pool gets even > smaller because it's in Pascal. And don't @ me with "Pascal is elegant" > and so forth; I'm just referring to the objective fact that it's far > less popular than, say, C++, and therefore has fewer programmers > available to work on it. Alan, these are all good points and I'm not going to dispute them. I will say that all other loggers are single platform as well. N1MM+ is tied to MS Windows being written in .Net. The Mac loggers would likely be the easiest to cross-platform to Linux but so far I've not seen that effort either. So no matter what application one chooses, you're locked into the OS silo that choice runs on. > Since these applications are all Free, the developers who do work on > them generally have day jobs and other commitments. So we have a tiny > pool of people who are even qualified to work on these programs, and > they're all working part-time. Of course progress is slow. N1MM+ is available free of charge. Apparently there are enough contesters fluent in .Net to continue driving its development. Given that .Net is very much a proprietary framework of Microsoft it is a bit astonishing that N1MM+ has gained such developer mind share. > Until someone develops a cross-platform logger using a popular > framework, and manages to attract a critical mass of developers to it, > this won't change. Consider Fldigi, which runs perfectly on Linux and > gets maniacally frequent updates. That's all because it's drawn a large > group of developers and users, the overwhelming majority of whom are > using Windows in the shack. Fldigi is emblematic of many cross-platform application as it started on Linux and built out from there. There are many other examples, too many to list, actually, that became cross-platform in this manner. Meanwhile, the number of applications that started on MS Windows and became cross-platform to Linux is vanishingly small. My point here is waiting for a popular Windows application to become cross-platform to Linux has been a long wait and the world will be waiting for a long time to come. Having dabbled with porting a GTK program from GTK 2 to GTK 3 I have come to appreciate that GUI toolkits are not not for the faint of heart. Then, what I have seen of GTK 4, it is basically unsuitable for any application that needs a UI that goes beyond the relatively simple UI dictated by GNOME. So, for a general cross-platform GUI toolkit there are really just two choices that I am aware of, Qt and Fltk. Both are C++ libraries so writing code in C is pretty much out of the question (perhaps I am wrong here) and so coding must happen in C++. Is it possible for a mortal hobbyist programmer to work in C++ effectively? With its templates and other additions to its more recent standards, I decided that my time was better spent in code much more simple. For all its warts, NCurses is approachable by nearly anyone conversant in C. It is very low level and requires a fair amount of boilerplate in the code to develop an effective TUI. There are a couple of small projects out there to develop TUI libraries with widgets and so on to eliminate a lot of the boilerplate. So far they don't seem to have gotten much traction. The code in TLF is difficult to understand and follow in part because of NCurses calls scattered throughout the code. Historically TLF has not been implemented in an MVC design, as I understand MVC which may be wrong. Most programmer hams have probably taken a look at the TLF code base and been scarred for life! No, it's not that bad but it is typical of hobbyist projects where the primary object is writing code and adding features. While I have contributed to TLF I am just a small contributor compared to Tom, Zoli, and others who understand it much better than me. All that said, TLF fills a niche no GUI logger ever can. GUI loggers offer eye candy that TLF cannot. I am not active in all that many events so TLF fills my needs these days. I can say that Tom and Zoli, et. al. do consider requests and bug reports and act on them. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG
KS QP Saturday--The Good, The Bad, and The Ugly
Apologies to Sergio Leone for hijacking his movie title. ;-) This weekend is the annual Kansas QSO Party and I've been putting TLF through the paces again. I am using Git master at commit 67e2322. The Good: Escape is working well to stop a voice transmission that is in progress. The sound log files are now in a subdirectory of the working directory. The Bad: I had the first lock-up of TLF in recent memory, if ever, earlier today. I am not sure if I struck Ctrl-S (now that I think about it) but TLF in the XTerm I am using would not respond. I used 'pkill -f tlf' to dump it and restart it. I know I had intended to Alt-Tab back to the XTerm from Firefox to enter a call and that is when it happened. Operator or TLF error, I'm not sure. Related, at one point TLF was getting sluggish while the TU CW message was being sent with the callsign text not being cleared and the worked before window remaining visible until after the TU message was sent. At one point this remained for several seconds and a station was answering and I could not type and then it returned to normal. Oddly, I didn't see that again. There were only about 230 Qs in the log file at the time. The Ugly: Escape is wiping out the entered data when first pressed while a CW message is in process (I don't recall if it did the same thing on SSB). This requires a repeat request or a good short term memory (I had to ask for repeats when this happened). If there are users that want to maintain the current behavior then it should be configurable. If it already is and I missed it, that's on me. TLF seems to be inventing multipliers in the scoring window. The actual ones appearing in the log file are correct but the Mul: value seemed to increment almost without a pattern. Consequently the displayed score is nonsensical. I noticed when I restarted TLF after the pkill command that it prompted me whether to rescore the log. I answered Y and when the logging screen came up all of the CW QSOs were set to 2 points instead of 3 (in the KSQP CW score 3 points and SSB score 2 points each). For whatever reason I had SSBMODE set in log_cfg.dat. Just now I commented it out and started TLF again and did not get the rescoring prompt and my last CW contacts are still at 3 points. Thankfully, the log file was backed up each time. I suppose this brings up another question, what value is there in storing a point value in the log file? It seems to me that if points are calculated by mode that the mode column should be the determining factor. Also, mults will need to be read and calculated from each line so doing so for the mode would seem consistent. I also think it is an error in judgment to be rewriting the log file in the first place. Thankfully this bug didn't destroy my event as Cabrillo generation was not affected. I think that TLF should only append to the log file and the only time it is written is when the operator performs an editing action either in TLF or an external editor. As I see it, the log data is the most precious part of the event and I know that most of us don't back up the log file with every disk write, but perhaps we should! Anyway, these are the issues I found today. What will tomorrow bring? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: winkeydaemon
* On 2022 08 Aug 09:08 -0500, Ed wrote: > On Mon, 8 Aug 2022 03:43:16 -0500 > Nate Bargmann wrote: > > > > Hi Ed, > > > > Then the ./ is not required. In essence, the ./ tells the shell to > > run the command that is found in the current directory and to look > > nowhere else. > > > Hope that helps. > > > > 73, Nate > > I put the winkey daemon in /home/ed/bin, this is the output: > > /home/ed/bin/winkeydaemon: line 8: syntax error near unexpected token > `newline' > /home/ed/bin/winkeydaemon: line 8: `' Looks like you tried to save the page from the GitHub page as there is no `' text in that script, particularly at line 8. Try this link: https://raw.githubusercontent.com/N0NB/winkeydaemon/master/src/winkeydaemon Then save it from your browser but beware that your browser may add a '.txt' extension (Chromium does that here) which should not be added when you do a "Save As...". You will also need to set the executable bit on the file after you save it, i.e. 'chmod +x winkeydaemon' in the directory you saved it. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: winkeydaemon
* On 2022 07 Aug 13:03 -0500, Ed wrote: > Is this the correct way to start it ? > > ./winkeydaemon -n -d /dev/ttyUSB0 > > This is what I get > > bash: ./winkeydaemon: No such file or directory > > The directory it is in is in my path. Hi Ed, Then the ./ is not required. In essence, the ./ tells the shell to run the command that is found in the current directory and to look nowhere else. If, say, you have winkeydaemon in $HOME/local/bin and that directory is also in your path, then if you're in $HOME/logs/test, use of the ./ tells the shell to only run the winkeydaemon command that is found in $HOME/logs/test and ignore the path. As there is likely no executable file named winkeydaemon in $HOME/logs/test the shell reports that the command could not be found. If this is your situation, then simply do not prepend the ./ to the command line. In many cases, the user's $PATH variable will contain '.' so that the normal user account can run a command found in the current working directory. It is also customary for this to not be included in root's $PATH so the ./ is often provided in examples for root to run a command from the current working directory. As an example, here is my $PATH: $ echo $PATH /home/nate/bin:/home/nate/local/bin:.:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin In my case, the current directory will be searched before any of the system directories but after my custom 'bin' directories in my user account. Conversely, it is omitted for the root account (Debian default): # echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin Hope that helps. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Spots Posting as "DX de TLF-A"
* On 2022 01 Mar 13:04 -0600, Alan Dove wrote: > I favor the third option. An extra "Enter" isn't asking much, and would > also serve as a quick confirmation before sending a spot to the world. I agree with Alan. Option C seems a most sensible way to do it. Typing Ctl-B and then hitting Enter after looking over the proposed spot is not onerous. I've not used the cluster features much except for the Kansas QSO Party where there is no penalty for a single op doing so. In that case as an in-state participant I am more interested in having my run frequency spotted. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Documentation Updating
* On 2022 24 Feb 14:56 -0600, Alan Dove wrote: > Nate: > > I think the web interface would be the better choice for getting people > to deposit rules files. No argument from me on that, Alan! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Documentation Updating
* On 2022 24 Feb 13:32 -0600, Alan Dove wrote: > Hey, folks: > > I like the idea of using the wiki to store additional contest files. > That would keep the installed rules directory from getting out of > control, and would make it a lot easier for folks to contribute them. > Can the wiki be made editable by an established list of users, or does > that also need to be managed with forks and pull requests? The GitHub wiki will work either way. Edits can be done through the Web interface or via forks and PRs. I prefer working in a local Git working tree and pushing up my changes after viewing them through a Firefox add-on that mimics the GitHub formatting (at least that is what I do with Hamlib stuff). 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: SSB Interfacing Question
* On 2022 24 Feb 10:33 -0600, Alan Dove wrote: > Hey, folks: > > In editing the documentation, I came across this line from README.ssb: > > "For the purposes of CW and PTT control, TLF interfaces to the radio > via cwdaemon, not hamlib. Therefore if you want voice keyer facilities > cwdaemon must be running before starting TLF." > > Is that still true? I thought I saw something in the man page about > using hamlib for PTT. I don't think so as I use Hamlib keying via CAT command on my K3 with SSB. There is some work going on in the Hamlib side to facilitate CW keying via CAT command. I've not followed it closely but have seen some list and GitHub traffic on the subject. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Documentation Updating
* On 2022 23 Feb 08:21 -0600, Alan Dove wrote: > Hey, folks: > > As a recent convert to Linux-based ham radio and TLF, I'd like to help > a bit with the project if I can. My coding is rudimentary at best, but > I've worked as a technical writer for over 20 years and feel I could > probably put those skills to use on the documentation. Hi Alan! Welcome to Tlf. > I've forked the project on Github so I can edit the documentation and > submit pull requests. I'm planning to start with the /doc/README file > and work my way down from there. Please let me know if there's some > more pressing need in the docs, or some other approach the developers > would prefer I take. I don't want to step on any toes. As I replied to Nick, the use of Markdown for the HTML/PDF documentation seems a very good choice to me. The nice thing about Markdown is that the readability of the source text is not degraded, in fact it is enhanced, IMO, and it would be a good choice to convert at least the main README file into the format as GitHub will format it when viewing the main source directory online. The other nice thing about Markdown is that GitHub will convert it into HTML automatically for the main Tlf Web pages and any Wiki pages that are written. Generation of PDF would need to be done locally and PanDoc does a good job with that from what I have seen. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Documentation Updating
* On 2022 23 Feb 10:46 -0600, Nick Craig-Wood wrote: > As a new user (new to both contesting and tlf) I was thinking about helping > with the docs too. Welcome! > I think it would be good for the project to have nice looking online docs. > In another project I'm involved in (rclone) we use markdown for the docs and > convert that into man pages and the website. Forgive me! I have become somewhat of a man page purist in recent years. While I understand the utility of a single source file for all documentation, the fact is that while man pages are documentation they exist in a different problem domain than Web pages or a PDF manual. The existing man page is a pretty good reference even if it is a bit verbose, though that is a trend for many man pages these days. The HTML pages, though old, have the benefit of the screenshots of the Tlf UI. IMHO, Markdown is an ideal source format for the HTML and PDF documentation simply because it handles inline images in those formats. The way one approaches writing a manual with images seems much different than writing for the man page reference format where images cannot be used inline. > The website is the primary documentation method, but all the > information is in the man page too. I like this way of working because > there is only one source for the documentation - the markdown files - > and everything else is built from there. I could certainly help with > this if people thought it was a good idea. I'm not much of a technical > writer, but I'm a better software developer ;-) As I see it, the man page should be a reference that serves as a memory refresher for configuration and operation commands. The HTML/PDF should be a more conversational manual that makes use of the images and links. The man page can be output to HTML as well and included if desired in an HTML/PDF manual. These are just my thoughts. The rest of the project members likely have differing opinions! :-) > I just want to say thank you to all the developers of tlf - I know how > hard Open Source software is! You're welcome! I am only a hobbyist in the software realm so I don't know whether this is more difficult than closed source software or not. I do know that collaboration is fun and satisfying. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: DX Cluster Setup Help
The colors for Xterm/rxvt can be set via the Xresources file. See: https://github.com/Tlf/tlf/blob/master/doc/Xresources These settings will mimic the default Linux console colors. Adjust to suit your taste. However, due to the way Tlf handles the console versus Xterm/rxvt, its colors won't be quite the same. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: DX Cluster Setup Help
* On 2022 17 Feb 10:22 -0600, Alan Dove wrote: > Can someone provide a snippet of a known good logcfg.dat file, with > cluster configuration parameters that definitely work? I'm on Ubuntu > 20.04, by the way. Here is what I use for the Kansas QSO Party: # # # # PACKET INTERFACE # # # # # Cluster: WR3D TELNETHOST=wr3d.dxcluster.net TELNETPORT=7300 # automatic login ### CLUSTERLOGIN= # write log to disk # CLUSTER_LOG The last parameter is completely optional. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: New exchange checking in TLF
Along with the exchange changes, everyone planning on operating SS this coming weekend should be aware that a new section has been added, PE, for Prince Edward Island. You can manually add PE on a line by itself to the arrlsections file as either a copy in your working directory or to the installed file. This file should now have 84 lines in it. My apologies for not catching this before the CW weekend. Also, this new section will be available for the upcoming ARRL 160m contest next month and for Field Day 2022. There may be other events that use this file as well, so check rules, etc. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Onno's SSB keying script described in his blog
* On 2021 01 Nov 18:35 -0500, Onno VK6FLAB wrote: > As for the unhealthy obsession, I've been at this since the 6502 :-) > Amateur Radio was supposed to be a way to do technical stuff away from > computing. Little did I know a decade ago that the two are on an > increasingly narrowing road on the way to the horizon! I received my Novice on 4 Nov 1983. Less than two weeks later I had a Radio Shack Color Computer 2. It's been a narrow road since! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Onno's SSB keying script described in his blog
In my RSS feed comes this from Onno, VK6FLAB, writing about his SSB keying shim for SSB through cwdaemon: http://www.southgatearc.org/news/2021/october/foundations-of-amateur-radio-30-10-2021.htm Good article, Onno. Just one question, are you aware that Hamlib supports PTT keying via radio command when the radio supports it? I use it with my K3 and voice messages. Of course, not all radios support it so something else is required. Hamlib also supports keying the radio via an RS-232 port and such, so I'm not sure where Hamlib fell short for you. Regardless, welcome to the unhealthy obsession with software development! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Can you prevent mode switching?
* On 2021 28 Oct 01:01 -0500, Thomas Beierlein wrote: > - Add a new keyword as suggested above. > - On bandswitch record not only the old frequency but also the mode. So > TLF may start with turning the rig to CW on first start but remember > later any changes made directly at the trx. I would ask that even this setting not be performed when the new keyword is present. With the keyword present, Tlf should be "passive", only changing its logging mode but not sending any mode change to the radio. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Can you prevent mode switching?
* On 2021 27 Oct 18:23 -0500, Onno VK6FLAB wrote: > I've just removed (commented out) all rig_set_mode calls in src/gettxinfo.c > and the behaviour persists. Not sure where else to look. Hi Onno, Follow the logic from the parsing of logcfg.dat with the SSBMODE and RTTYMODE keywords. That should lead you to where the mode is set on startup, at least. > I agree with Nate, TLF should follow the mode, not set it unless > specifically instructed to do so. I'm sure some prefer the current behavior (working a single mode event, I can see this preference and would likely use it). I'd like to see a similar keyword, perhaps RIGMODE is to close to the existing RIGMODEL keyword, maybe FOLLOW_MODE would work, that could be added for Tlf following the radio mode until instructed to change mode. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Can you prevent mode switching?
IMO, Tlf should follow the rig mode and NOT set it unless the operator specifically issues a mode change command in the call field. I've intended to look into it but haven't made it that far. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: The state QSO Party thread
This weekend brings the Alabama QSO Party today 1500z through 0300z tomorrow (late evening in the US). For out state participants the rules are reasonably straight forward with the only twist being that while mults count once per the event, they do count per mode. As there are 67 counties, there are 67 mults for both CW and phone so a total available of 134 for a mixed mode entry! Going through the list of Tlf mult commands I do not see anything that counts mults per mode. This is a feature enhancement that should be addressed. QSO Party rules authors are inventive. At this time I've no files to share as I'm not sure if I'll have any operating time today. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: The state QSO Party thread [TN QP]
* On 2021 06 Sep 22:13 -0500, Doug Smith wrote: > > Please don't blame Tlf here. That is totally my doing as that is the > > data I put in for that field in my local template. > > > > Looking at the relevant Cabrillo V 3 specification[1], I see that > > Location has three categories, ARRL sections as mentioned, IOTA island > > name, and RDA number. That's it. Now, if Tlf can be faulted to any > > degree it would be that it does not validate this field against those > > lists, at a minimum ARRL sections, I would think. > > Not at all, it's not by any means TLF's fault! > Just that sometimes you have to guide the users:) I mean, that can go to an > extreme, I used N1MM for the contest yesterday & the balloon help kept > getting in the way... (I guess there's a way to turn it off but that's too > much work:) I appreciate you bringing this up as it caused me to more carefully examine that part of the Cabrillo spec that I had simply glanced over and *assumed* I knew what I was doing. > I'm not sure Colorado is using the same checking software. You may not have > a problem. Hopefully, they'll be kind enough to let me know. They may not have as many logs to go through as I found far less activity and 3830 shows far less logs than TN with a 24 hour head start. > We use W3KM Cab Evaluator. Ahh, apparently another single developer project with no obvious links to SourceForge, GitHub, or GitLab to be found. Okay, so some digging is in order. W3KM Cabrillo Evaluator[1] Explicit Contest rules[2] Cabrillo Log template[3] Which has an embedded PDF[4] where in the Notes section at the bottom number 4 states, " Cabrillo log filenames are urCall.log or urCall.cbr - where urCall is your callsign." May I humbly ask that either the software settings be checked or the author (W3KM) be made aware of the bug of only allowing *.log? Without a public facing issue tracker and access to the source, it's not possible for someone to noodle around and identify the bug for him. A *.cbr file should not be any problem given the examples he provides and the official Cabrillo specification. > (I used to use a collection of custom Perl > scripts & a SQL database but it was a big pain to update when the rules > changed, and when I wanted to push most of the work to someone else, getting > Perl and SQL installed -- on a Windows box -- was more than I wanted to > undertake...) I can understand that as Windows is generally hostile toward open standard software. Windows users even more so. ;-) That said, I have a custom Perl script that processes the resulting .cbr for the Kansas QP to generate some statistics and a summary for the 3830 site. This year the script and Tlf agreed on the score. Heh! Unfortunately, Perl is essentially a dead language, not from the standpoint of development as that continues, but it's not high on any surveys that show language popularity that I've seen. Expecting someone to pick up the Camel Book these days is probably asking a bit much, especially of a language that doesn't hide its Unix heritage at all. I don't blame you one bit for moving toward a prepackaged solution for a Windows user. > > That is generated by Tlf internally and can be changed. However, WWOF > > states either .log or .cbr is valid (bottom of the page)[2]. In that > > light it would appear the adjudication software is overly restrictive. > > > > Also, Tlf uses the .log extension for its internal log written to disk. I need to point out that the .log extension is apparently not hard coded in Tlf as the complete log file name is specified in its RULES file so could conceivably be anything the user chooses. > Again, a nit:) I would concur the adjudication software is overly > restrictive, and it has similar tendencies in other areas. It is not > exactly difficult to change a file extension:) As above, even the author's examples allow for both extensions so I'm inclined to look for a setting or consider such behavior a bug. > (it's a whole lot easier than talking an entrant through sending > something other than an ADIF file. This year, we had someone scan a > printout of his Cabrillo file & send us the JPEG!) Words fail... > I wasn't used to operating from a fixed station:), usually do this thing > mobile where I'm signing /DAVI, /CHEA, etc.. & it's obvious I'm in > Tennessee... You were signing with TNQP so that was a clue. Most ops out of state will just call TN. Taking a chance I unwittingly worked the K4A special event that was not taking part in TNQP. 73, Nate [1] https://www.qsl.net/w3km/cabrillo.htm [2] https://qsl.net/w3km/explicit-rules.htm [3] https://qsl.net/w3km/cab_template.htm [4] https://qsl.net/w3km/template.pdf -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP
Re: The state QSO Party thread [CO QP files]
* On 2021 06 Sep 14:43 -0500, Nate Bargmann wrote: > The WYSIWYG multiplier method was confused by the fact I was entering > two values in the exchange field--the other op's name and county. If I > worked another station in the same county WYSIWYG counted it as a new > mult. I may have avoided some of the pain had I taken the advice of the RULES section of the man page and did more prior testing. My outcome may have been different had I used the NO_RST option in my rules file. I shall keep that in mind for the future. I guess it pays (eventually) to edit the documentation. ;-) 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: The state QSO Party thread [TN QP]
* On 2021 06 Sep 17:41 -0500, Doug Smith wrote: > For years I was the adjudicator for the TNQP and still am the backup guy. I > haven't run Nate's log through the checking software yet but it looks > straightforward & I don't remember having significant issues with TLF output > in the past. Hi Doug. That is great to know. > One thing I did notice is the LOCATION: tag in the Cabrillo header is > "Kansas". N1MM puts one's ARRL section on this tag, and the adjudication > software we use will kick out a log that doesn't have a valid ARRL section. > (in Nate's case, "KS" -- but if you're in New York which has multiple ARRL > sections, "NY" will NOT work. It needs to be NLI or ENY or WNY or NNY.) > > The LOCATION: tag is interchangeable with the ARRL-SECTION: tag but it must > contain a valid ARRL section either way. For entrants outside the U.S. and > Canada, the appropriate entry is "DX". > > It might be a bit more trouble to fix than it's worth, but it would be > helpful both for the adjudicators and new-to-QSO-Party entrants if somehow > one could be forced (or at least guided) to enter a valid section. > > This really doesn't make a whole lot of sense, but that's the way the > third-party packages work. Please don't blame Tlf here. That is totally my doing as that is the data I put in for that field in my local template. Looking at the relevant Cabrillo V 3 specification[1], I see that Location has three categories, ARRL sections as mentioned, IOTA island name, and RDA number. That's it. Now, if Tlf can be faulted to any degree it would be that it does not validate this field against those lists, at a minimum ARRL sections, I would think. Thanks for the good info and insight, Doug. I've not seen much commentary over the years of those in your position so this kind of feedback is very helpful. I think I'll need to resubmit my CO QP log as I made the same error. > I don't see that Nate worked any of our mobiles more than once on the same > band/mode. We don't allow county-line operations in our contest. (well, > technically they're permitted but only if you can figure out how to park > your car so the radio *and* the antenna are both exactly on the border!) If > he had, the adjudication software would have accepted multiple 40CW QSOs > with W4NZ as valid if different counties had been logged. The differences in the QPs is one of the fun parts. Being used to KS QP this branching out is useful. > Final nit pick:) The file we received was N0NB.cbr. N1MM uses the .log > extension. Obviously it is not a big deal for the adjudicator to rename the > file:) (the adjudication software ignores any files without the .log > extension) That is generated by Tlf internally and can be changed. However, WWOF states either .log or .cbr is valid (bottom of the page)[2]. In that light it would appear the adjudication software is overly restrictive. Also, Tlf uses the .log extension for its internal log written to disk. > Again, none of this is serious. Nate, thanks for entering! (and thanks for > working me on 80 meters. 100 watts to a VOCF antenna 1.8m above ground > behind a fence. "VOCF"=VERY off-center fed.) You had a very good signal here, Doug, s9+ as I recall. Funny thing, I wasn't sure you were instate or not so I looked up your call before I hit F6! Then today going back through the TN QP rules there is your call in a few places. D'oh! 73, Nate [1] https://wwrof.org/cabrillo/cabrillo-v3-header/ [2] https://wwrof.org/cabrillo/cabrillo-specification-notes/ -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: The state QSO Party thread [TN QP]
Sorry this is after the fact as the Tennessee QP was yesterday. Overall, this was easy for Tlf as the exchange was signal report and county (instate) and signal report and state/province (outstate). The only difference from the KS QP was making the mults per band rather than once. As usual, my files are attached. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 # General contest mode # # CONTEST=tnqp LOGFILE=tnqp_2021.log CONTEST_MODE CABRILLO=UNIVERSAL CABRILLO-CONTEST=TN-QSO-PARTY CABRILLO-EXCHANGE=KS # Station Cabrillo template CABRILLO-TEMPLATE=tnqp-naqp.cbr # CALLMASTER=MASTER.SCP # ## ## # Messages F1= to F12= # # Message CQ_TU_MSG=# # Message S_TU_MSG= # ## # % = call # # @ = hiscall # # # = serial# # [ = RST # # + = increase cw speed # # - = decrease cw speed # ## ## # F1=CQ TQP % F2=@ DE % F3=5NN KS F4= TU F5=@ F6=% F7=@ SRI QSO B4 GL F8=AGN F9=? F10=QRZ? F11=PSE K F12=CQ TQP % # CQ_TU_MSG=TU % S_TU_MSG=TU 5NN KS # #ALT_0= ALT_1=KS #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= #VKM2= #VKM3= #VKM4= #VKM5= #VKM6= #VKM7= #VKM8= #VKM9= #VKM10= #VKM11= #VKM12= #VKSPM= #VKCQM= # # # # Scoring rules# # # MIXED RECALL_MULTS THREE_POINTS SECTION_MULT MULT_LIST=tnqp.txt ### END # RULES=tnqp # # # # # TLF-LOGCFG.DAT v. 1.1.0 # # # # Uncomment the options you# # want to enable. See tlf.doc # # for a description of the # # options. You can keep diff- # # erent versions for different # # contests. I keep separate# # configuration files for # # each contest. If you enable # # more than 1 mutually exclu- # # sive options, the last one # # will be efective.# # # # # # # #CTCOMPATIBLE # # # # # EDITOR # # # # # #EDITOR=joe EDITOR=vim #EDITOR=e3 #EDITOR=mcedit # # # # # CALL # # # # # CALL=N0NB # # # # # # Time offset from UTC # # # # # TIME_OFFSET=0 TIME_MASTER # # # # # LAN PORT # # # # # addnode only OTHER nodes !! # #ADDNODE=10.0.0.115 #ADDNODE=192.168.1.2 # THISNODE=A # LAN_DEBUG # # # # # KEYERPORT# # # # # NETKEYER NETKEYERPORT=6789 NETKEYERHOST=127.0.0.1 # # # # # KEYERPARAMETERS # # # # #---speed (6 ... 60 wpm) CWSPEED=24 #---weight (-5 ... 5 ms) WEIGHT=1 #---cq delay (in 0,5 s) CQDELAY=10 #---txdelay (ms) TXDELAY=2 #---sidetone (200...800, 0 = mute) CWTONE=800 # # # # PACKET INTERFACE # # # # # # use tnc instead of telnet # #TNCPORT=/dev/ttyS0 #TNCPORT=/dev/ttyUSB1 #TNCSPEED=2400 # # get clusterinfo from network ## #FIFO_INTERFACE # # # # # RADIO CONTROL# # (comment out if not present) # # Rigmodel = Hamlib index, here # # for ten tec OMNI VI # # # RADIO_CONTROL RIGMODEL=2029 RIGSPEED=38400 RIGPORT=/dev/rig RIGPTT # SSBMODE # #RIT_CLEAR # #SHOW_FREQUENCY # # # # # INFORMATION WINDOWS # # # #
Re: The state QSO Party thread [CO QP files]
Overall Tlf did better than propagation into CO from this location. The WYSIWYG multiplier method was confused by the fact I was entering two values in the exchange field--the other op's name and county. If I worked another station in the same county WYSIWYG counted it as a new mult. The other suspected issue was working the same station on a band/mode but in a new county which the rules allow for point credit but Tlf scored as 0 points. Neither of these were show stoppers as both introduced errors into Tlf's scoring of the event. For the good side, I created an North American QSO Party Cabrillo template (specified by the CO QP rules) that I will merge with the main template file. One bug did surface here since in the rules file the CABRILLO-EXCHANGE parameter is taken as a single string and is not split for Cabrillo output as the received exchange is. The parameter is apparently limited to 10 characters as a string any longer than that is truncated even when the field in the Cabrillo template is specified to be longer. The CO QP rules state all fields should start at the same column number as the NAQP template available online[1]. I did some manual adjustment to line things up which I probably could have avoided if CABRILLO-EXCHANGE did not truncate its input. ADIF export appears to be fine although I've not uploaded it to LoTW or eQSL yet. Tlf still has a few rough edges that I think we can work out in the future. My updated files are attached. 73, Nate [1] http://ncjweb.com/NAQP_Cabrillo_Template.txt -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 # General contest mode # # CONTEST=coqp LOGFILE=coqp-2021.log CONTEST_MODE CABRILLO=NAQP CABRILLO-CONTEST=COQP CABRILLO-EXCHANGE=NATEKS # Station Cabrillo template CABRILLO-TEMPLATE=coqp-naqp.cbr # #CABRILLO-CATEGORY-BAND=ALL #CABRILLO-CATEGORY-MODE=MIXED #CABRILLO-CATEGORY-POWER=LOW # ## ## # Messages F1= to F12= # # Message CQ_TU_MSG=# # Message S_TU_MSG= # ## # % = call # # @ = hiscall # # # = serial# # [ = RST # # + = increase cw speed # # - = decrease cw speed # ## ## # F1=CQP % F2=@ DE % F3=NATE KS F4=TU F5= @ F6=% F7=@ SRI QSO B4 GL F8=AGN F9= ? F10= QRZ? F11= PSE K F12=CQP % # CQ_TU_MSG=TU % S_TU_MSG=TU NATE KS # ALT_1=NATE ALT_2=KS #ALT_3= #ALT_4= #ALT_5= #ALT_6= #ALT_7= #ALT_8= #ALT_9= #ALT_0= # #SEND_DE # # # Scoring rules# # # MIXED RECALL_MULTS SSBPOINTS=1 CWPOINTS=2 SECTION_MULT_ONCE WYSIWYG_ONCE MULT_LIST=coqp.txt ### END # # Cabrillo format descriptions for various contests # used for North American QSO Party, Colorado QSO Party [NAQP] QSO=FREQ,5;MODE,2;DATE,10;TIME,4;MYCALL,15;EXC_S,14;HISCALL,15;EXC1,10;EXC2,3 #Cty Abb. ADA ALA ARA ARC BAC BEN BOU BRO CHA CHE CLC CON COS CRO CUS DEL DEN DOL DOU EAG ELP ELB FRE GAR GIL GRA GUN HIN HUE JAC JEF KIO KIC LAK LAP LAR LAA LIN LOG MES MIN MOF MON MOT MOR OTE OUR PAR PHI PIT PRO PUE RIB RIG ROU SAG SAJ SAM SED SUM TEL WAS WEL YUM # *Rare Counties # County Name # 1 Adams # 2 Alamosa* # 3 Arapahoe # 4 Archuleta* # 5 Baca # 6 Bent* # 7 Boulder # 8 Broomfield # 9 Chaffee # 10 Cheyenne* # 11 Clear Creek # 12 Conejos* # 13 Costilla* # 14 Crowley # 15 Custer* # 16 Delta* # 17 Denver # 18 Dolores # 19 Douglas # 20 Eagle # 21 El Paso # 22 Elbert # 23 Fremont* # 24 Garfield # 25 Gilpin # 26 Grand # 27 Gunnison* # 28 Hinsdale # 29 Huerfano # 30 Jackson* # 31 Jefferson # 32 Kiowa # 33 Kit Carson # 34 Lake* # 35 La Plata # 36 Larimer # 37 Las Animas* # 38 Lincoln # 39 Logan* # 40 Mesa # 41 Mineral # 42 Moffat # 43 Montezuma # 44 Montrose* # 45 Morgan* # 46 Otero # 47 Ouray* # 48 Park* # 49 Phillips* # 50 Pitkin* # 51 Prowers # 52 Pueblo # 53 Rio Blanco* # 54 Rio Grande* # 55 Routt* # 56 Saguache* # 57 San Juan* # 58 San Miguel* # 59 Sedgwick # 60 Summit* # 61
Re: The state QSO Party thread
* On 2021 05 Sep 09:14 -0500, Thomas Beierlein wrote: > Hi Nate, > > Am Fri, 3 Sep 2021 21:08:50 -0500 > schrieb Nate Bargmann : > > > > > For some of these events it may be necessary to simply use Tlf as a > > logger as anything resembling accurate scoring may not be possible > > given the notion that stations are usually worked once or once per > > band/mode. State QSO parties often have mobile operators that move > > from county to county and the rules allow outstate participants to > > work those mobiles again for point and multiplier credit when they > > move to a new county. Some rules also permit working such a station > > once but logging it twice when it is on a county line or at the > > junction of multiple counties. So far as I'm aware, Tlf would treat > > additional such contacts on a given band/mode as a dupe. > > > > Please have a look at IGNOREDUPES in the man page for that. I do use that in all of my events settings which then allows logging the station again but with zero point credit. Normally, this is desired behavior. In the particular case I describe such is not the correct behavior, however, it really only affects scoring not what will ultimately be written to the Cabrillo file. Case in point, last night I had one operator give me two counties for the exchange. The Colorado QP rules state that a second QSO be logged for the additional county, etc. Here Tlf incorrectly scored it as zero points but WYSIWYG did count it as a mult. I have a lot of work to do to clean up a log with just 22 QSOs in it! I am also formulating some thoughts on WYSIWYG and that aspect of Tlf and will probably open a feature request in the issue tracker in the not too distant future. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: The state QSO Party thread [CO QP files]
Attached are the files I plan to use tomorrow for the Colorado QP as an outstate participant. One possible problem will be the counting of mults by Tlf. As signal reports are not used the exchange is name + county for instate participants and name + two letter state abbreviation for me. I suspect that Tlf will count a new mult for each station in a county given a quick test I did (log file attached), even though only the county should count as the mult. All suggestions welcome. The event starts at 1300z but I know I will only operate a few hours at most. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 80SSB 04-Sep-21 02:56 0001 W0LD 59 59 LOREN BOU LOREN BO 1 3982.0 80SSB 04-Sep-21 02:56 0002 K0OJ 59 59 OJ WLDOJ WLD 1 3982.0 80SSB 04-Sep-21 02:57 0003 K0LD 59 59 LARRY BOU LARRY BO 1 3982.0 80CW 04-Sep-21 02:58 0004 W0KJ 599 599 JOE WLD JOE WLD 2 3981.3 #Cty Abb. ADA ALA ARA ARC BAC BEN BOU BRO CHA CHE CLC CON COS CRO CUS DEL DEN DOL DOU EAG ELP ELB FRE GAR GIL GRA GUN HIN HUE JAC JEF KIO KIC LAK LAP LAR LAA LIN LOG MES MIN MOF MON MOT MOR OTE OUR PAR PHI PIT PRO PUE RIB RIG ROU SAG SAJ SAM SED SUM TEL WAS WEL YUM # *Rare Counties # County Name # 1 Adams # 2 Alamosa* # 3 Arapahoe # 4 Archuleta* # 5 Baca # 6 Bent* # 7 Boulder # 8 Broomfield # 9 Chaffee # 10 Cheyenne* # 11 Clear Creek # 12 Conejos* # 13 Costilla* # 14 Crowley # 15 Custer* # 16 Delta* # 17 Denver # 18 Dolores # 19 Douglas # 20 Eagle # 21 El Paso # 22 Elbert # 23 Fremont* # 24 Garfield # 25 Gilpin # 26 Grand # 27 Gunnison* # 28 Hinsdale # 29 Huerfano # 30 Jackson* # 31 Jefferson # 32 Kiowa # 33 Kit Carson # 34 Lake* # 35 La Plata # 36 Larimer # 37 Las Animas* # 38 Lincoln # 39 Logan* # 40 Mesa # 41 Mineral # 42 Moffat # 43 Montezuma # 44 Montrose* # 45 Morgan* # 46 Otero # 47 Ouray* # 48 Park* # 49 Phillips* # 50 Pitkin* # 51 Prowers # 52 Pueblo # 53 Rio Blanco* # 54 Rio Grande* # 55 Routt* # 56 Saguache* # 57 San Juan* # 58 San Miguel* # 59 Sedgwick # 60 Summit* # 61 Teller* # 62 Washington # 63 Weld # 64 Yuma RULES=coqp # # # # # TLF-LOGCFG.DAT v. 1.1.0 # # # # Uncomment the options you# # want to enable. See tlf.doc # # for a description of the # # options. You can keep diff- # # erent versions for different # # contests. I keep separate# # configuration files for # # each contest. If you enable # # more than 1 mutually exclu- # # sive options, the last one # # will be efective.# # # # # # # #CTCOMPATIBLE # # # # # EDITOR # # # # # #EDITOR=joe EDITOR=vim #EDITOR=e3 #EDITOR=mcedit # # # # # CALL # # # # # CALL=N0NB # # # # # # Time offset from UTC # # # # # TIME_OFFSET=0 TIME_MASTER # # # # # LAN PORT # # # # # addnode only OTHER nodes !! # #ADDNODE=10.0.0.115 #ADDNODE=192.168.1.2 # THISNODE=A # LAN_DEBUG # # # # # KEYERPORT# # # # # NETKEYER NETKEYERPORT=6789 NETKEYERHOST=127.0.0.1 # # # # # KEYERPARAMETERS # # # # #---speed (6 ... 60 wpm) CWSPEED=24 #---weight (-5 ... 5 ms) WEIGHT=1 #---cq delay (in 0,5 s) CQDELAY=10 #---txdelay
Re: The state QSO Party thread [KS QP files]
As promised, here are the files I use as an instate participant in the Kansas QSO Party. Thanks to Tom for putting together the code that allows the "sections_mult" file ksqp.txt to hold the Kansas county abbreviations that all count toward the KS mult. The rest is all rather straight forward Tlf configuration. I will note that our rules allow using the cluster so it is one of the rare times I use it during an event. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 # General contest mode # # CONTEST=ksqp LOGFILE=ksqp_2021.log CONTEST_MODE CABRILLO=UNIVERSAL CALLMASTER=MASTER.SCP # ## ## # Messages F1= to F12= # # Message CQ_TU_MSG=# # Message S_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_TU_MSG=TU 5NN MSH # #ALT_0= ALT_1=DE N0N, DE N0NB OP #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 SECTION_MULT_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) KS:ALL,AND,ATC,BAR,BRT,BOU,BRO,BUT,CHS,CHT,CHE,CHY,CLK,CLY,CLO,COF,COM,COW KS:CRA,DEC,DIC,DON,DOU,EDW,ELK,ELL,ELS,FIN,FOR,FRA,GEA,GOV,GRM,GRT,GRY,GLY KS:GRE,HAM,HPR,HVY,HAS,HOG,JAC,JEF,JEW,JOH,KEA,KIN,KIO,LAB,LAN,LEA,LCN,LIN KS:LOG,LYO,MRN,MSH,MCP,MEA,MIA,MIT,MGY,MOR,MTN,NEM,NEO,NES,NOR,OSA,OSB,OTT KS:PAW,PHI,POT,PRA,RAW,REN,REP,RIC,RIL,ROO,RUS,RSL,SAL,SCO,SED,SEW,SHA,SHE KS:SMN,SMI,STA,STN,STE,SUM,THO,TRE,WAB,WAL,WAS,WIC,WIL,WOO,WYA RULES=ksqp # # # # # TLF-LOGCFG.DAT v. 1.1.0 # # # # Uncomment the options you# # want to enable. See tlf.doc # # for a description of the # # options. You can keep diff- # # erent versions for different # # contests. I keep separate# # configuration files for # # each contest. If you enable # # more than 1 mutually exclu- # # sive options, the last one # # will be efective.# # # # # # # #CTCOMPATIBLE # # # # # EDITOR # # # # # #EDITOR=joe EDITOR=vim #EDITOR=e3 #EDITOR=mcedit # # # # # CALL # # # # # CALL=N0N # # # # # # Time offset from UTC # # # # # TIME_OFFSET=0 TIME_MASTER # # # # # LAN PORT # # # # # addnode only OTHER nodes !! # #ADDNODE=10.0.0.115 #ADDNODE=192.168.1.2 # THISNODE=A # LAN_DEBUG # # # # # KEYERPORT# # # # # NETKEYER NETKEYERPORT=6789 NETKEYERHOST=127.0.0.1 # # # # # KEYERPARAMETERS
The state QSO Party thread
One of the aspects of amateur radio I've considered to get more active in are the various state QSO parties. To that end, I'm starting this thread to exchange information toward configuring Tlf for these events and discover areas where Tlf can be improved. Part of the sharing I plan is to provide my files after figuring out whether they work! Also, in the long run I hope to maintain a page on the Tlf Wiki documenting these events. Eventually a database of sorts of configuration files will exist for these events and we may even add them to the repository. For some of these events it may be necessary to simply use Tlf as a logger as anything resembling accurate scoring may not be possible given the notion that stations are usually worked once or once per band/mode. State QSO parties often have mobile operators that move from county to county and the rules allow outstate participants to work those mobiles again for point and multiplier credit when they move to a new county. Some rules also permit working such a station once but logging it twice when it is on a county line or at the junction of multiple counties. So far as I'm aware, Tlf would treat additional such contacts on a given band/mode as a dupe. In my first reply to this thread I will provide the files I use as instate participant in the recent Kansas QSO Party. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: No luck trying to pkill play_vk with escape
Removing the '&' from play_vk eliminates the auto_cq confusion, but then Escape does nothing except cancel auto_cq. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: No luck trying to pkill play_vk with escape
* On 2021 28 Aug 11:12 -0500, Thomas Beierlein wrote: > Am Sat, 28 Aug 2021 07:40:40 -0500 > schrieb Nate Bargmann : > > > Hi Tom. > > > > A quick test shows that it works to some degree but may still leave > > the radio in TX mode. I'll test further this weekend but it's a > > critical first step. > > > > 73, Nate > > > > Hi Nate, > thanks for the test. I overlooked the needed logic for PTT control. My > solution can only work if you use VOX-keying, but I fear it is not very > applicable during contest. > > Btw, if you control PTT by the PPT code you can copy the PTT-off logic > from play_file() to stoptx(). > > Anyway seems it needs quite some more work here. Quite so! I've had TX hangs and note that the auto-CQ timer appears to count at double speed on screen but for sending the actual file is fine. ATM Ive just done auto-cq and then spoke the exchange and logged with '\'. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: No luck trying to pkill play_vk with escape
Hi Tom. A quick test shows that it works to some degree but may still leave the radio in TX mode. I'll test further this weekend but it's a critical first step. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: No luck trying to pkill play_vk with escape
A thought I just had, is I wonder if threading has anything to do with this? While pgrep only returns one PID when Tlf is running, htop shows two PIDs. Oddly, I figured calling pkill via system() would as the same method is used to kill rec from the sound recorder menu. I've seen mention that this might require fork() and exec() to start the call to play_vk manually so that the PID is known and then use kill() on it. I doubt I'll get to it before tomorrow morning! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: No luck trying to pkill play_vk with escape
* On 2021 27 Aug 15:10 -0500, Zoltan Csahok wrote: > Nate, try first the companion command 'pgrep play_vk' while vk is running. > If no output is produced (which I suspect) then try 'pgrep -f play_vk'. > If it outputs the PID then just replace pgrep with pkill. > If there is still no output, then I have no idea. I've used both pgrep and pkill from another terminal session. I can get the PID of play_vk and play simply with: $ pgrep -a play 162927 /bin/sh ./play_vk /home/nate/logs/wav/N0N/kqp/F1.wav 162928 play /home/nate/logs/wav/N0N/kqp/F1.wav -q and: $ pkill -SIGTERM play_vk kills the script immediately. So all of this works manually, just not from inside Tlf (of course the PID changes with each call, etc.). 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
No luck trying to pkill play_vk with escape
One thing that has vexed me for as long as I've used the Tlf voice keyer
is the inability to cancel a message once it is fired. Invariably I
will hear a station start to call just as an auto-cq begins (Murphy's
Law and all that). I've tried this naive hack and it simply will not
kill the shell script:
$ git diff src/stoptx.c
diff --git a/src/stoptx.c b/src/stoptx.c
index 2bed5a5..6ee9d16 100644
--- a/src/stoptx.c
+++ b/src/stoptx.c
@@ -25,6 +25,7 @@
#include "clear_display.h"
#include "err_utils.h"
#include "globalvars.h"
+#include "ignore_unused.h"
#include "netkeyer.h"
#include "tlf.h"
#include "tlf_curses.h"
@@ -46,6 +47,9 @@ int stoptx(void) {
}
}
+} else if (trxmode == SSBMODE) {
+ IGNORE(system("pkill -SIGTERM play_vk"));;
+ return (0);
} else {
return (1);
}
I also tried killing the play process directly but that fails as well.
I can kill either the play_vk script or the play process with pkill from
another terminal manually but Tlf does nothing.
Looking at the case label for ESCAPE in callinput.c there is nothing
mode specific (I have local patches that separate the call to stoptx()
from clearing the input field so that the first press only stops TX).
I'd appreciate any working advice before the QSO party begins tomorrow.
73, Nate
P.S. I can push stuff out to my private repository if that helps.
P.P.S stoptx() works fine in CW.
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
signature.asc
Description: PGP signature
Re: graphical bandmap view
I don't see a Reply-to in the headers. As I use neomutt, the L commands lets me reply to a mailing list. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: graphical bandmap view
* On 2021 04 Feb 13:35 -0600, Zoltan Csahok wrote: > In case one is interested in a non-curses bandmap for Tlf: > https://github.com/zcsahok/tlf_bandmap Neat! Next up a CW skimmer! ;-) 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Trying to figure out a cppcheck warning
I've been working through the code base with the cppcheck GUI
program--remarkably few issues, actually--and have hit one in qtc_log.c
that has me a bit stumped. For reference start at line 198, the
definition of the store_qtc() function:
https://github.com/Tlf/tlf/blob/c677a3b72ba5536753b053f84634e99fa37a351a/src/qtc_log.c#L198
The cppcheck warning is:
Line 225: Either the condition 'tempi==2' is redundant or the array
'qsoflags_for_qtc[2]' is accessed at index 2, which is out of bounds.
and a pair of notes:
Line 230: Assuming that condition 'tempi==2' is not redundant
Line 225: Array index out of bounds
Here is the relevant part of the function:
214 if (direction == SEND) {
215 /* find maximum sent QTC block serial */
216 g_strlcpy(temps, loglineptr + 50, 5); // get serial of qtc block
217 tempi = atoi(temps);
218 if (tempi > nr_qtcsent) {
219 nr_qtcsent = tempi;
220 }
221
222 /* mark corresponding qso line as used for QTC */
223 g_strlcpy(temps, loglineptr + 12, 5); // qso nr in qso list
224 tempi = atoi(temps) - 1;
225 qsoflags_for_qtc[tempi] = 1;
226
227 /* find first unused QSO number for QTCs */
228 if (tempi == next_qtc_qso && tempi < MAX_QSOS) {
229 while (qsoflags_for_qtc[tempi++] == 1) {
230 if (tempi == MAX_QSOS)
231 break;
232 next_qtc_qso = tempi;
233 }
234 }
235 }
Now, it's quite possible that cppcheck is getting tripped up in some
manner. That said, I do think the array index and assignment on line
225 should be protected to assure the array index does not exceed
MAX_QSOS, i.e. tempi be tested after its assignment by atoi().
It appears that Ervin and Tom have touched that file the most so I'm
reluctant to mess with it (I don't understand the QTC you WAE guys do!).
I'll do a pull request for the other warnings to let everyone take a
look.
73, Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
signature.asc
Description: PGP signature
Re: Anyone else compiling with GCC 10.2 on Debian Testing?
* On 2021 22 Jan 15:48 -0600, Zoltan Csahok wrote: > > No, the intention is string truncation of 0 to 3 - and + characters > > prepending and appending the callsign. > > Exactly, in order to slow down if op has difficulty copying the calls. > (it's my code; adding an int to a char ptr is completely legit) It struck me while driving and doing errands this afternoon that you and Christoph are correct and that all that should be needed is to enclose the expression in square brackets to quell the warning. I see now (without testing it so far) that modifying the subscript will have the same effect as using the precision notation. It's probably just semantics, but it took me a while to see it! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Anyone else compiling with GCC 10.2 on Debian Testing?
* On 2021 22 Jan 09:43 -0600, Ervin Hegedüs wrote: > ahm, sorry, > > that was my mistake - I didn't realize the g_random_int_range()... > > Using the constant value the output will be the same. > > Sorry again :). :-) I did forget the compilation command lines I used: clang -Wall trial.c $(pkg-config --cflags --libs glib-2.0) -o trial gcc -Wall trial.c $(pkg-config --cflags --libs glib-2.0) -o trial 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Anyone else compiling with GCC 10.2 on Debian Testing?
* On 2021 22 Jan 07:42 -0600, Christoph Berg wrote:
> Re: Nate Bargmann
> > ../../tlf/src/cqww_simulator.c:155:15: warning: adding 'int' to a string
> > does not append to the string [-Wstring-plus-int]
> > "+++" + 3 - slow);
> > ~~^~~
> > ../../tlf/src/cqww_simulator.c:155:15: note: use array indexing to silence
> > this warning
> >
> > I'm going to be puzzling that one out for a bit.
>
> As it says, use array indexing: "+++"[3 - slow]
No, the intention is string truncation of 0 to 3 - and + characters
prepending and appending the callsign.
I've attached a short C program that now compiles clean with clang
and gcc with a modification to the format string and the arguments.
73, Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
#include
#include
#include
int main(void)
{
gint32 slow = g_random_int_range(0, 4);
/* See https://stackoverflow.com/a/16299867 for format explanation. */
gchar *str = g_strdup_printf("%.*s%s%.*s",
3 - slow,
"---",
"W0GCJ",
3 - slow,
"+++");
g_printf("%s%c", str, '\n');
g_free(str);
}
signature.asc
Description: PGP signature
Re: Anyone else compiling with GCC 10.2 on Debian Testing?
Thanks for the cleanup with GCC 10.2 everyone!
I just tried the compile with clang 11.0 on Debian Testing and these are
the only two warnings I see:
CC cqww_simulator.o
../../tlf/src/cqww_simulator.c:153:15: warning: adding 'int' to a string does
not append to the string [-Wstring-plus-int]
"---" + 3 - slow,
~~^~~
../../tlf/src/cqww_simulator.c:153:15: note: use array indexing to silence this
warning
"---" + 3 - slow,
^
& [ ]
../../tlf/src/cqww_simulator.c:155:15: warning: adding 'int' to a string does
not append to the string [-Wstring-plus-int]
"+++" + 3 - slow);
~~^~~
../../tlf/src/cqww_simulator.c:155:15: note: use array indexing to silence this
warning
"+++" + 3 - slow);
^
& [ ]
2 warnings generated.
These lines are part of this call:
char *str = g_strdup_printf("%s%s%s",
"---" + 3 - slow,
CALLMASTERARRAY(callnumber),
"+++" + 3 - slow);
which is creating a cwdaemon keyer string.
I'm going to be puzzling that one out for a bit.
73, Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
signature.asc
Description: PGP signature
Re: Anyone else compiling with GCC 10.2 on Debian Testing?
As Tom points out, Hamlib up to version 3.3 had rig_model_t as type int. Since 4.0 it is now of type uint32_t so this probably needs version checking for Hamlib 4.0 so Tlf users with older Hamlib versions aren't left out. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Anyone else compiling with GCC 10.2 on Debian Testing?
* On 2021 17 Jan 12:34 -0600, Thomas Beierlein wrote: > Am Sun, 17 Jan 2021 19:07:28 +0100 > schrieb Thomas Beierlein : > > > I am not sure. I had a look into the definition of rig_model_t (the > > type of myrig_model). As far as I could tell it is typedef'd to an > > int. But then I do not understand the warning. Seem I must look a > > little bit more thoroughly. > > > Found the problem. I have not only different compilers installed but > also different hamlib versions. > > rig_model_t is int in Hamlib3 and unsigned int in Hamlib4. I see that the documentation string in the Hamlib 4.0 file of riglist.h was not updated to reflect that change. :-( Perhaps this will need to be tested against the Hamlib version? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Anyone else compiling with GCC 10.2 on Debian Testing?
* On 2021 17 Jan 12:08 -0600, Thomas Beierlein wrote:
> Am Sun, 17 Jan 2021 09:59:47 -0600
> schrieb Nate Bargmann :
>
> > Is the pointer warning this one:
> >
> > In file included from ../../tlf/src/parse_logcfg.c:46:
> > ../../tlf/src/parse_logcfg.h:102:28: warning: pointer targets in
> > initialization of ‘int *’ from ‘rig_model_t *’ {aka ‘unsigned int *’}
> > differ in signedness [-Wpointer-sign] 102 |
> > (cfg_arg_t){.int_p=, .min=minval, .max=maxval} |
> > ^ ../../tlf/src/parse_logcfg.c:1121:25: note: in expansion
> > of macro ‘CFG_INT’ 1121 | {"RIGMODEL",
> > CFG_INT(myrig_model, 0, )}, | ^~~
> > ../../tlf/src/parse_logcfg.h:102:28: note: (near initialization for
> > ‘(anonymous)..int_p’) 102 |
> > (cfg_arg_t){.int_p=, .min=minval, .max=maxval} |
> > ^ ../../tlf/src/parse_logcfg.c:1121:25: note: in expansion
> > of macro ‘CFG_INT’ 1121 | {"RIGMODEL",
> > CFG_INT(myrig_model, 0, )}, | ^~~
> >
> Right. That is the one in question.
>
> > I was looking that over last night and is it a case that the macro and
> > function need to be duplicated for the unsigned int?
>
> I am not sure. I had a look into the definition of rig_model_t (the
> type of myrig_model). As far as I could tell it is typedef'd to an int.
> But then I do not understand the warning. Seem I must look a little bit
> more thoroughly.
I think the problem lies in the declaration of int_p in parse_logcfg.h,
line 61 where its type is int and rig_model_t has a type of uint32_t.
Perhaps adding another member to that union that is of type rig_model_t
and reworking the other calls will solve this?
73, Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
signature.asc
Description: PGP signature
Re: Anyone else compiling with GCC 10.2 on Debian Testing?
* On 2021 17 Jan 01:54 -0600, Thomas Beierlein wrote:
> We are aware of the warnings. They are mostly false positives about
> string operations and one about a pointer initialization.
Is the pointer warning this one:
In file included from ../../tlf/src/parse_logcfg.c:46:
../../tlf/src/parse_logcfg.h:102:28: warning: pointer targets in initialization
of ‘int *’ from ‘rig_model_t *’ {aka ‘unsigned int *’} differ in signedness
[-Wpointer-sign]
102 | (cfg_arg_t){.int_p=, .min=minval, .max=maxval}
|^
../../tlf/src/parse_logcfg.c:1121:25: note: in expansion of macro ‘CFG_INT’
1121 | {"RIGMODEL",CFG_INT(myrig_model, 0, )},
| ^~~
../../tlf/src/parse_logcfg.h:102:28: note: (near initialization for
‘(anonymous)..int_p’)
102 | (cfg_arg_t){.int_p=, .min=minval, .max=maxval}
|^
../../tlf/src/parse_logcfg.c:1121:25: note: in expansion of macro ‘CFG_INT’
1121 | {"RIGMODEL",CFG_INT(myrig_model, 0, )},
| ^~~
I was looking that over last night and is it a case that the macro and
function need to be duplicated for the unsigned int?
> Anyhow it would be good to get rid of them.
Yeah, it makes it a bit more difficult to find the warnings and errors
when trying to break things intentionally!
73, Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
signature.asc
Description: PGP signature
Anyone else compiling with GCC 10.2 on Debian Testing?
I am asking as I'm seeing a number of compiler warnings that could be harmless but should probably be looked at. It looks like GCC 10.2.1 or maybe a slightly later version will be the default in the forthcoming Debian 11. If deemed useful I can open an issue on GitHub. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: IC-7610
* On 2021 10 Jan 15:18 -0600, Juanjo EA8BGO wrote: > Dear Friends > > I have recently purchased an IC-7610 and I find the problem that when > connecting the keyer via USB with the PC, the Cwdaemon does not recognize > it. The only solution I have found is in the CQRLog using the Hamlib > option. But I see that it is not the most successful solution for the > TLFLogger > > I have seen in the forum a program written in Python (rigkeyer.py) that was > originally written for K3. > > Does anyone know how to get the TLFLogger to work with my IC-7610 without > having to use the old TTL adapter? I've no idea, but does the keyer in the radio emulate the K1EL, a.k.a. winkeyer, command set? If so, there are a couple of options including the winkeyerdaemon: https://github.com/N0NB/winkeydaem It is quite similar to cwdaemon in its set of options and can be used in place of it in Tlf. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: TLF and Hamlib 4 - things to look for
* On 2020 16 Dec 10:47 -0600, Thomas Beierlein wrote: > Yes and no. > > For the 'yes' part: > > You can point tlf to use the daemon (as Slave wrote) but it is > activated via the normal hamlib library call (with rig model number > 2). > > That means in these case it goes directly to the hamlib library and talk > to rig model 2 which results in hamlib library making a TCP connection > to rigctld (model number 2) (which talks to the hamlib library, which > talks to the radio rigctld is configured for). (Sounds like overkill > and make my head spinning). Actually, it was kind of an ingenious implementation by Stephane years back. Yes, it is fairly complex but it does allow for an application that already uses the Hamlib API to use rigctld, which at the time was very new, without being rewritten for TCP sockets. Also, such apps can then utilize a rig connected to another computer and with the proliferation of Raspberry Pis this has worked out well. > To use rigctld directly TLF has to be changed to use a direct TCP > connection to rigctld. But that is not how TLF works at the moment. At some point that might be a useful feature. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Error CAT TLFLogger 1.4.1
What does rigctl -V report? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Error CAT TLFLogger 1.4.1
* On 2020 30 May 12:48 -0500, Juanjo EA8BGO wrote: > Dear Friends. > > I have found something very curious. In old version of TLFLogger 1.3.2 if > it allows me to compile with Hamlib with ./configure --enable-hamlib > > On the contrary, in the new version 1.4.1 it does not allow it. Which version of Hamlib are you using? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: A unified color scheme?
Well, some progress has been made and my understanding has been further clarified. The behavior of A_STANDOUT and A_BOLD on the console versus a GUI terminal mostly follow the following behavior: On the console and in GUI terminals A_STANDOUT: * transposes the foreground and background colors. On the console ORing A_BOLD with A_STANDOUT: * applies the "bright" colors (8-15) to the foreground only On a GUI terminal ORing A_BOLD with A_STANDOUT: * applies the "bright" colors to the background only * increases the weight of the foreground character * does NOT apply the "bright" colors to the foreground character On the console use of the "bright" text colors can only be obtained through the A_BOLD attribute, otherwise only the basic eight colors are available for foreground and background. On a GUI terminal where the TERM value is set to some variant of *-256color "bright" colors can be applied directly as well as many more, but we'll stick with 16 internally to Tlf to keep it simple. At some point I think it will be possible to specify combinations of the 256 color palette in logcfg.dat for complete customization. At the moment the colors are rather garish as I am simply going through the source files and conditioning the use of A_STANDOUT only when not in a GUI terminal (at this time it checks the TERM environment variable for "rxvt" and "xterm" strings). I'm only partway through so the code patching isn't complete, The current progress can be viewd at: https://github.com/N0NB/tlf/commits/color_schemes I've attached a screen shot of Tlf running in URxvt, Depending on what is done at the moment, the header line color scheme is transposed or "normal". 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: A unified color scheme?
* On 2020 24 May 05:40 -0500, Koos van den Hout PE4KH wrote: > On 5/23/20 11:50 PM, jim smith wrote: > > > I don't know if this adds anything to the discussion or not, but I > > wrangled urxvt and played with the color options in tlf until I landed > > on a high contrast version that works for me, especially when I've been > > up too long and my eyes are tired. > > > > Seems to work across a couple of different versions of linux. > > Could you share your TLF/urxvt settings? I'd like to encourage everyone with customized settings to share them as they would make a good addition to a set of Wiki pages I am planning. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: A unified color scheme?
* On 2020 24 May 02:46 -0500, Thomas Beierlein wrote: > it is as soon as TLF does not know the TERM setting. Atm it recognizes > 'xterm', 'xterm-256color' and 'rxvt' (with 'rxvct-unicode' added in > next days). All other settings will respect TLFCOLORS. I'd like to think we could maintain the current palette with those TERM types but also respect TLFCOLORSn. > As handling of STANDOUT, BOLD and other attributes are inconsistent > between the emulators I could check I fear that we will not be able to > reach that goal. At the risk of being critical, as I see it, the real culprit is the general use of STANDOUT for many screen elements. Yet, I do see its value and why Rein originally chose to go this route. At that time the default VGA console screen was often not as bright as the GUI screen owing to each being different hardware, as I understand it, and especially with portable operations outdoors the use of STANDOUT gave text that was readable under such conditions. The Linux console appears to be unique in its ability to display bright text on a bright background. This has carried forward now where the framebuffer is used for the console. The problem is that the GUI terminals lack this ability with STANDOUT. I'm not sure if the reason is a technical limitation of X or a design decision. Regardless, these are the things to consider. One thing that might get close to unity is not using STANDOUT but BOLD on a normal background on GUI terminals. > Just my 2 cents. Valued, as always. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: A unified color scheme?
Hi Matthew and Jim. Thanks for sharing your screenshots and thoughts! Are either of you customizing the colors through the respective terminal settings (Konsole)/Xresources (Rxvt) or through LOGCFG.DAT? I don't want to break existing setups if at all possible. Tom made mention that TLFCOLORn only works if the TERM variable is not set, or is it only if it is "linux"? As I see it, the user should be able to set TLFCOLORn regardless of the setting of TERM. The manual page is rather light on details for this setting. At the least I should probably document the default colors available from ncurses. One of my thoughts was to encourage users, especially newcomers to Xterm/Rxvt, to start from the common VGA palette so a reasonable color scheme is the starting point. Still the ability for advanced users to customize the scheme must be preserved. Ideally, it would be possible for the user to manage all the color scheme through Tlf regardless of the setting of TERM or the terminal color palette. It remains to be seen if this ideal can be reached. Thanks for the food for thought. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: A unified color scheme?
* On 2020 23 May 10:40 -0500, Thomas Beierlein wrote: > Hi Nate, > > these are really good and valid points. From my experience in last > years I can confirm that color handling via ncurses is quite some > nightmare especially when you use a terminal emulator under X. > So thanks for the link below with some thorough discussion about the > problems. A pet sidetrack project. :-) > Right most emulators allow only bright foreground but no bright > background. I think that was the reason for using inverted color > pairs in TLF from the beginning. I'm still learning the subtleties but the console clearly can do bright text on a bright background that the emulators don't. > If you look to other programs using ncurses few uses a white/gray > background. Better combinations results from having blue as background > and using white of yellow letters. But I think that is to much to > change now. The color scheme for Xterm is quite useable to me with these "correct" colors. > The screenshots are coming through. I guess forst screen shot is from > pure Linux console, second one from xterm with your Xresource file and > the last from urxvt? > > The problem with the different shades of white in the last screenshot > may be solved by setting a pure TERM=xterm. I had similar problems in > the past with the introduction of xterm-256color not handled properly. I'll attach a shot of URxvt where I started Tlf as: TERM=xterm-256color tlf it is not much different, if at all. What I see of the UI code in Tlf is that rxvt is handled such that it tries to play the part of the Linux console. > > Instead, I think that simply unifying Xterm and URxvt and leaving > > the console alone is a better idea. > For the time being I think it may be a good decision. I did get private feedback from a user that prefers the console so I think it should be left well enough alone. As for Xterm and URxvt, I think if Tlf just treats them the same as far as colors are concerned and recommend using our Xresources, then I think we'll have a good level of consistency. Actually, I am unsure of people choosing URxvt instead of Xterm these days but some may. Plus, this has become a bit of an interesting subproject of mine. > As a reminder: If TERM is NOT set to xterm or rxvt TLF assumes you are > using plain linux console and allows you to set the colors via TLFCOLOR= Ah, that is the secret. I think I was puzzled why I couldn't get that keyword to work last winter. The reason I am promoting Xterm is due to it not consuming the key combinations that other terminals consume. Keys like F11 and Ctl-PgUp/PgDn come to mind. Xterm also supports anti-aliasing with TrueType fonts these days so it can look quite nice on the modern desktop (I'm using Gnome these days). 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Tips for working with Hamlib 4.0~git
For those wanting to experiment with building Tlf against Hamlib 4.0~git (the present development master branch) that is installed in $HOME/local, try the following commands. To find the correct hamlib.pc file: PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/$HOME/local/lib/pkgconfig ../tlf/configure --prefix=$HOME/local To verify Tlf is correctly linked to hamlib 4.0~git: LD_LIBRARY_PATH=$HOME/local/lib:$LD_LIBRARY_PATH ldd $(which tlf) | grep libhamlib Outputs: libhamlib.so.4 => /home/nate/local/lib/libhamlib.so.4 (0x7f9ba432d000) Your hex address will likely differ. Likewise to start Tlf using the local hamlib: LD_LIBRARY_PATH=$HOME/local/lib:$LD_LIBRARY_PATH tlf NOTE! A recent change to Hamlib expanded the radio model numbers. For example, the Elecraft K3 is now model 2029. Use the 'rigctl -l' command to see the complete list. With many new models and various changes, we'd like to get feedback on Hamlib 4.0~git with Tlf. Daily master branch source tarballs of Hamlib are available at: http://n0nb.users.sourceforge.net/ 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Rethinking the need for CT compatible mode
What's the thinking on this? I'd like to simplify the code page and the man page, if possible. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: so2r
* On 2020 18 Apr 05:02 -0500, m5evt wrote: > The SDR setup really lends itself well to so2r (and at low cost). I have > been thinking about implementing an OTRSP (https://www.k1xm.org/OTRSP) > listener within linhpsdr. I think I am correct in saying hamlib doesn't > have this OTRSP protocol embedded within? No, Hamlib does not have any concept of controlling multiple devices through a single instance. However, there should be no limit, aside from computer resources, on the number of Hamlib instances a program can create so long as they're each accessing a unique device on a unique port. Likewise, multiple instances of rigctld/rotctld can be run so long as each is opening a unique device on a unique port and each *ctld instance is bound to a unique TCP port. BTW, I like the rest of your ideas, even though I probably will never do SO2R! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
QSO Party Challenge
I saw that there is now a QSO party challenge: http://stateqsoparty.com/ This got me to thinking. At present Tlf is limited to one event at a time. If one of our users wants to use Tlf, quite a bit of juggling would need to take place. For example, this weekend has three QSO parties running that are a part of the challenge. It would not be easy to tune around and work the various stations by closing and opening Tlf for each QSO. A thought crossed my mind to have a sort of server/client setup where one instance of Tlf would be controlling the radio and would supply updates via UDP to one or more clients. Yeah, this is probably fraught with a number of race conditions especially when a client makes a radio control request. Another aspect is CW generation and whether cwdaemon and work-alikes can accept data from multiple clients or whether that would need to be sent to the server Tlf. Third is the sending of sound files. On the one hand Pulse Audio could be an assist here and on the other, a lot of people detest PA. At the moment I am just brain storming. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Real RST possible?
* On 2020 28 Jan 00:29 -0600, Thomas Beierlein wrote: > Hi Jim, Nate and Zoli, > > we should keep in mind to integrate it in the flow of the qso, > especially in contests. > > What I mean is running in CQ mode I need the RST of the other > station *before* answering his call and will get his RST in his reply. > Running in S I would first get my RST from him and only *afterwards* > need his RST for my reply. > > Another question is if the operator uses ESM or not. To be honest, Tom, I don't see the way I described changing the behavior of Enter or Space. It would merely modify the RST fields to be entry boxes but would be prepopulated with 59[9] as now and Enter and Space would skip them. Tab would move into each in turn from Call --> RX RST --> TX RST --> Exchange --> Call (CQWW example). Your musing of Run vs S is a good one. For the most part, I think this is a rather specific use case where the '5' is to be replaced by another numeral. Most of us probably won't use this feature. ;-) Another option is to leave all keys as-is and only modify Page-Up/Page-Dn so that they work this way: Tap Page-Dn until '1' is reached and then like an odometer the first numeral rolls down to '4', the next tap rolls the first numeral down to '3' and so on while leaving the second numeral at '1', then tap Page-Up to set the second numeral. That would require a few taps of Page-Up until the report of 459 is reached. Probably the reason this hasn't been requested before is that major contest sponsors mostly ignore the signal report for log checking. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Real RST possible?
* On 2020 26 Jan 15:45 -0600, jim smith wrote: > First, I know there is the CHANGE_RST directive, but for QRP contests > (at least in the states), many times ops send an actual RST -- 33N, > 439, etc. Is there any way to incorporate this in both the received > stations data (I imagine it would be in the exchange field, like a > serial number) and for the sending station? > > It would be helpful the above mentioned QRP contests, general ragchews > and for SOTA operations as well. I have seen other loggers handle this so that in the case of Tlf, Space would move the cursor from Call to the Exchange/Comment field and Tab would cycle through all fields, i.e., Call-->RX RST-->TX RST-->Exch-->Call, etc. As it is now, Space jumps from Call to Exch and then Tab must be used to go back to Call as Exch can contain spaces to separate exchange elements in some events. Loggers such as N1MM+ create additional field entry boxes depending on the event and Space is not allowed in any of them so it can be used as a "smart tab" that jumps over RST fields, if present, and through all the other fields. The way Tlf is structured, it would take a lot to have separate exchange fields, but it seems as though having Tab cycle through all the fields could be doable. As I see it, when Tab enters an RST field it could place the cursor under the first '9' and from there the field edited as needed. I'm afraid I don't have the time to code it for some months so maybe someone else can pick up the idea if it is thought to be a good one and add it. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Rethinking the need for CT compatible mode
* On 2020 12 Jan 16:17 -0600, Fred Siegmund wrote: > I use it for the german XMAS contest. As this is a sprint, where you have to > leave QRG after CQ, I don't like ESM (and changing between CQ and S all > the time). Hi Fred. Do you use the + and Insert keys? Their mapping was reversed from CT for a long, long time and I switched their mapping in the Git master branch (post 1.4.0). Would the following from my OP meet your needs, particularly the action of Enter? > > > > In its place I would consider adding support for the apostrophe " ' " > > > > to send the CQ_TU_MSG or S_TU_MSG. > > > > > > > > I would consider providing a :CFG keyword or keystroke combination > > > > to toggle Enter from ESM to a mode where with the call field empty > > > > Enter sends MYCALL and otherwise would only log a QSO when both the > > > > call and exchange fields are populated depending on validation. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Rethinking the need for CT compatible mode
I recently did a bit of fixup to the CT compatible mode but I find that its original choice of keystrokes to not be optimal. As I added support for some keys used in N1MM+ when ESM is disabled, the code became even more convoluted and opaque. I realized that CT compatible mode had been broken for so long that there really must not be anyone using it, so why keep it? Removing it would simplify the code in several places. In its place I would consider adding support for the apostrophe " ' " to send the CQ_TU_MSG or S_TU_MSG. I would consider providing a :CFG keyword or keystroke combination to toggle Enter from ESM to a mode where with the call field empty Enter sends MYCALL and otherwise would only log a QSO when both the call and exchange fields are populated depending on validation. Thoughts? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
winkeydaemon version 1.0.9 available
Thanks to Zoli, HA5CQZ, the winkeydaemon script has received some updates. A release tarball can be downloaded from: https://github.com/N0NB/winkeydaemon/archive/v1.0.9.tar.gz And now a short Wiki page is active: https://github.com/N0NB/winkeydaemon/wiki 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: can we benefit from N1MM's UDC files?
* On 2019 19 Dec 08:21 -0600, Drew Arnett wrote: > IIRC, N1MM is open source, no? And piggybacking is a great force > multiplier in open source. I think so, for some definition of Open Source. I don't know of a public source repository and the license text of the program installer states it is free software but doesn't reference a specific license. Looking at my installation of N1MM+ in my .wine directory I found no license document. To my knowledge N1MM+ is only distributed in binary form. As far as using the file archive is that at the most basic it would be polite to ask first. :-) 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: can we benefit from N1MM's UDC files?
* On 2019 19 Dec 03:46 -0600, Joop Stakenborg wrote: > N1MM has a large collection of so called UDC (User Defined Contest) files, > see: > > https://n1mmwp.hamdocs.com/mmfiles/categories/userdefinedcontests > > They are packed into a zip file which contains a udc file with a description > of the contest, but there are also member lists and other stuff. The udc > files contains contest and scoring information. I have looked into it > quickly and at first it seems complicated but I am sure it is well > documented and there also seems to be a dedicated editor for udc files (in > exe format of course). > > We could benefit from this large library, although I don't know what the > licensing issues might be when including them with tlf. Sounds interesting and potentially useful, Joop. I'll just say this about distribution, I think that if the library of files proves useful and we can build support in Tlf for it, then that should be sufficient and just provide a link for the user to download the files, if desired. This is kind of along the same lines as CTY.DAT and SCP files which get quickly out of date and that we should likely do a better job of pointing users toward their download sites rather than carry outdated versions in our repository. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Replacing keystroke magic numbers with symbolic names
I've made a pull request that replaces the magic numbers of the Control key combinations I could find with symbolic names. The PR can be reviewed at: https://github.com/Tlf/tlf/pull/147 Next I will start working on the Alt key combinations. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: ARRL 160m
* On 2019 08 Dec 10:07 -0600, Drew Arnett wrote: > I played for a couple of hours with the 160m contest as well from a > very noisy location, so not very many QSOs. Worked a big gun east of > the Mississippi, but no KG4 for me. :-) Didn't consult with Nate for > rules or config file. Just grabbed the distributed arrl160m_usa rules > and merged a bit from my own files from the last contest. Like I noted, this KG4 was a 2x1 in VA so no GITMO for me either. > I worked a couple of stations during auto CQ, and the rest in S > Messages and ESM both worked great. I guest operated at another > station for a bit during CQ WW. They weren't using ESM. Wasn't bad > using the function keys, but I missed ESM as someone how can touch > type. For me, using ESM in S is a bit disconcerting as when Enter is pressed after receiving the running stations exchange, the QSO is logged before my exchange is even sent, let alone confirmed. This is why I did a bit of work so that in CT mode the Enter key only logs the QSO when both fields have something it them. My S sequence was as follows: :CFG and uncomment CTCOMPATIBLE in logcfg.dat, Tlf reloads and resets the configuration. Type in the running station's call. Press F6 to send my call. Type in his exchange, if DX only a signal report is sent so type a space character in the exchange field, otherwise ARRL section is typed. Press Alt-1 which is set to "TU +5NN- KS" (I left F3 set to "@ +5NN- KS". Press Enter once he sends TU or CFM or whatever. Out of that sequence, what I would consider changing would be if the exchange field is empty that Enter sends mycall (F6), similar to ESM. I would also consider changing Insert to send the S_TU_MSG macro instead of F3. To go along with this would be enabling a notion of CQ and S in CT mode so the messages sent would be mostly the same as ESM, but with different keystrokes and with Enter logging when there are characters in each field. Also, in S, having the + key send "TU" then log was awkward as convention seems to prefer the S station to send "TU exchange" these days. > I've noticed that clear the call field behavior of the ESC key as > well. If there is an alternate behavior that makes sense and doesn't > make ESM worse, I'd love to consider it. It is slightly annoying, but > I didn't fret over it too much, as I figured it was good practice for > short term callsign memory. If getting a fill is taking time, it > might push the limits of my short term memory, though. My short term memory is working hard enough being two to three characters behind his sending! Losing the callsign just because he decided to start sending his call again a few milliseconds after I fired the exchange macro and wanting to stop it to get back in sync with him is annoying. I could imagine ESC working like this: If the callsign and exchange fields have characters in them, ESC works just as now but stopping the TX and successively clearing the fields on additional presses. If the callsign field has characters and the exchange field is empty with the cursor in either, then ESC stops TX. The second press would clear the callsign and make sure the cursor is in the callsign field. The tricky part is, what if there is no TX, I think the current behavior is to clear the fields immediately, exchange then callsign on successive presses. Since this would be new behavior, it's likely that it should be disabled by default and enabled with a keyword command as many are probably used to the current behavior. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
ARRL 160m
Well, first off, the use of cwdaemon and Tlf via Hamlib on the same serial port (real motherboard port) worked perfectly without a problem throughout my operating time. I missed Saturday evening due to having aggravated my hip yesterday and had to lay down. I was up around 0830z this AM and worked a bit over an hour and had to lay down for a while and then again from about 1140z to 1420z or thereabouts. The hip is feeling batter! My CT changes didn't get used much as I saw I had Alt-1 set for the exchange I wanted to send in S mode so that I didn't have to edit the F3 message all the time. Making sure that Enter didn't log an incomplete contact did prove useful in the wee hours... ESM mode for running worked perfectly. Combining Escape to halt the CW message and clearing the input fields is a double edged sword. When there is text in the call and exchange fields and the cursor is in the exchange field and a CW message is in progress, the first ESC stops the TX and the second clears the exchange field and the third clears the call field. This is fine so far as it goes. When the call field has characters in it and the cursor is in the call field and the exchange field is empty, a single ESC stops the TX AND clears the call field! That led to several ARGH! moments. I think that a better algorithm could be worked out. Scoring is completely wrong but ARRL 160 is difficult to score. Tlf several times counted an incorrect multiplier. For one I worked a KG4 in VA and Tlf scored it as the KG4 mult when it should have determined that the VA meant it was conus. Another time or two I fat fingered an exchange and removed the text from the mult column but even a :RES command had no apparent effect. Also, it seemed as though coming back from an :EDI command resulted in Tlf forgetting any previous dupes even though they're marked as zero points. In the end, the main thing is that the Cabrillo file is correct and ARRL will take care of the scoring. Overall, I enjoyed using Tlf again. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Replacing keystroke magic numbers with symbolic names
At the suggestion of Zoli in a since abandoned pull request, I started on an effort to replace as many "magic numbers" with symbolic names as I can find. Just for feedback I've posted four patches to: https://gist.github.com/N0NB/c22054a0160b19dae5c88efd71b3d37e At this point I will likely rebase everything together in some fashion before sending a pull request, so this is just for evaluation by the group. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Using hamlib for CW keying
I've just finished setting up for ARRL 160 and am using cwdaemon with the same port as Hamlib. In logcfg.dat I added the following line: RIGCONF=rts_state=OFF,dtr_state=OFF Then I set the K3's PTT-KEY menu to OFF-DTR and the keying was working fine with one port as I tested it. The proof will be in the 'test this weekend! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Does anyone use CTCOMPATIBLE mode?
The reason I am asking this question is because I am comparing the present behavior of Tlf's CT mode to that of my CT ver 9 manual and the two do not match. Tlf does send F5 followed by F2 as described in the CT manual, but the F2 have different definitions between the two programs. If there are no complaints, I will change the code so the correct Tlf F key macro is sent for both and '+'. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Using hamlib for CW keying
D'oh! Read the man page, Nate! RIGCONF=rig_configuration_parameters Send rig configuration parameters to Hamlib. e.g. RIGCONF=civaddr=0x40,retry=3,rig_pathname=/dev/ttyS0 I plan to try this. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Using hamlib for CW keying
That's cool, Olaf. It stands to reason that the DTR and RTS lines would explicitly need to be turned off as I think the kernel automatically enables them when an application initializes the port. This was a more or less silly idea I had and I'm glad to see it will work! I'll have to try it too. I'll have to look at the Tlf code to see if config parameters can be passed to the library without going through tigctld. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Using hamlib for CW keying
Thanks for that, Olaf. Here is a crazy idea I had that someone might like to experiment with. I thought of using a serial port multiplexer, assuming such a thing exists and I found https://github.com/danielinux/ttybus as one of the first hits, to have Hamlib and cwdaemon share the same port. For the K3 and other radios that don't use hardware handshaking, this may work well. cwdaemon keys CW via the DTR pin and the K3 can be configured to key CW via DTR or RTS. In theory, since Hamlib and cwdaemon use different pins, this should work. Another idea is to not bother with a multiplexer and just direct Hamlib and cwdaemon to the same port and see what happens! So far I've not tried this hare-brained idea myself... 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: TLF-1.4.0 release
* On 2019 25 Nov 13:17 -0600, Thomas Beierlein wrote: > Am Sat, 23 Nov 2019 18:30:01 -0600 > schrieb Nate Bargmann : > > > * On 2019 23 Nov 08:14 -0600, Drew Arnett wrote: > > > Resize is fine, but please continue to support 80x25 long term. I > > > don't see classic TUI losing value anytime soon. > > > > Do you mean that Tlf should enforce a minimum 80x25 terminal size as > > it has in the past? Personally, I've no problem with that. > > 'Enforcing' is a little bit difficult as (as far as I know) we can not > force a minimum size on any xwindow. But I will leave the warning in > place that you should have at least 25 lines in your terminal. By "enforcing" I was referring to the behavior where Tlf simply exited unless the terminal was at least 80x25. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: tlf and the nano editor
* On 2019 25 Nov 07:46 -0600, Joop Stakenborg wrote: > Hi Tom, > > > It works okay with 'nano' now, thanks! > > The weekend was, fun. Made mores than 800 Q's in the CQWWCW with tlf and > winkeydaemon using the nanokeyer. Good to hear everything worked well, Joop. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Using hamlib for CW keying
* On 2019 21 Nov 05:32 -0600, Christian Treldal wrote: > All modern rigs have keying via hamlib. I would caution, that is possible with varying degrees of support and capability. On the N1MM+ mailing list there is this recent thread that asks about a warning when CAT keying is used: https://groups.io/g/N1MMLoggerPlus/message/45927 Rich, VE3KI, weighs in later with: https://groups.io/g/N1MMLoggerPlus/message/45930 where he states: Which rig? The KY command works differently in Elecraft vs. Kenwood vs. Yaesu. The examples that have been posted in various places were for Elecraft radios. IIRC, the KY command for Kenwood radios requires a fixed-length argument (padded with blanks), which makes it essentially impossible to use substitution macros. Also as I recall, the Yaesu KY command does not send text, it selects one of the radio's own CW memories and sends that. I've not seen the code, of course, but I presume that N1MM+ is handling all of the rig control stuff internally. For Tlf and other programs using Hamlib, the rig capabilities would be queried and if rig_send_morse() is supported, it can be used, however, things like the speed up/down characters in the keying macro would need to be handled by the calling program and speed changes sent to the rig interspersed with the message text. I can see this becoming very clunky very quickly! Any given Hamlib backend will probably be coded so as to perform needed work-arounds as best as possible. Again, this is very rig specific and even Hamlib likely cannot hide certain differences. I only have access to a K3 these days. I've not seen much mention of anyone using the Hamlib send_morse function for any serious CW keying. If I could offer a wishlist item to the manufacturers, it would be for those radios incorporating a USB connector for rig control and sound card IO that a second virtual serial port be available to expose a K1EL compatible keyer. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Using hamlib for CW keying
* On 2019 23 Nov 08:26 -0600, Drew Arnett wrote: > Portable is good. So I'd ask if hamlib found it possible to support > speed changes. Yes. It is done through the set/get_level functions in rigctl with the KEYSPD token: $ rigctl -m 229 -r /dev/rig Rig command: l Level: KEYSPD Level Value: 22 Rig command: L Level: KEYSPD Level Value: 18 Rig command: l KEYSPD Level Value: 18 Rig command: b N0NB Rig command: L KEYSPD 22 Rig command: b N0NB Rig command: l Level: KEYSPD Level Value: 22 Rig command: Works on my K3. > KX3 is only 3 wire serial CAT interface, so no RTS/DTR style keying > possible. In that case, I suppose a Y cable could be fabricated that > fans out RTS/DTR to a separate key plug. That's a bit tidier perhaps. > > Another difference between rigs. Some have a jack for paddles and a > jack for key. KX3 doesn't, so I like using the external WinKeyer box > to let logging software and paddles key the rig. Using the WinKeyer > box means I'll have a common solution regardless of which rig I end up > using. (Operating at home, operating at someone else's station, FD > and other situations where the gear is an assortment from all the > participants, etc.) This is one of those "wishlist" items that understandably will not work with every radio. For those it does, it can be quite useful. > Another bonus using a WinKer (or equivalent) is that the paddle input > then pauses any sending, too. However, recently during contests, I've > been better about using CTRL-K to do fills instead of reaching for the > paddles. I'm still too green to know which method of keying for fills > I will ultimately end up preferring. All of these approaches have tradeoffs, no surprise there. Everyone has their preferred approach. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: TLF-1.4.0 release
* On 2019 23 Nov 08:14 -0600, Drew Arnett wrote: > Resize is fine, but please continue to support 80x25 long term. I > don't see classic TUI losing value anytime soon. Do you mean that Tlf should enforce a minimum 80x25 terminal size as it has in the past? Personally, I've no problem with that. > What about a 2nd application, tlf-config or easy-tlf-config, which > would have the pulldown menus etc for setting up config files. Keep > the pulldown menus out of tlf. Once you add menus, you'll add a bunch > of hotkeys. One of the nice things about TLF is that there aren't a > bunch of live keys, especially if run out of a console or terminal > rather than a windows manager. That's actually a very good idea, Drew. If such a program were to gain good enough coverage then the :SET and :CFG commands could just call it instead of an editor. As for hot keys, Tlf does have quite a few assigned already. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: tlf and the nano editor
* On 2019 23 Nov 01:18 -0600, Csahok Zoltan wrote: > My 2c: try with "export EDITOR=..." Hi Zoli, This is the setting in log_cfg.dat that I am testing with Tom's new patch to allow specifying any editor, not a shell variable. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: tlf and the nano editor
My first test with EDITOR=gedit resulted in nothing happening. I ran gedit from another terminal and it opened fine. Then I tried emacs from the terminal and it opened fine in the GUI. I then tested both emacs and gedit as Tlf editors and they worked fine. I'm not sure what was going on so it might be useful for others to test GUI editors as well. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
