* 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.
* 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
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
* 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
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
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
* 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
* 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
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:
* 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
* 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
* 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
* 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
* 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
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
* 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,
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
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
* 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
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
* 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
* 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 ./
* 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
* 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
* 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
* 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
* 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
* 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
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
* 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:
#
#
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
* 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
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
* 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
* 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
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
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
* 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
* 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
* 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
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
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
* 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 scor
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
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
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
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
* 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 week
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:
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
* 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
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
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
* 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
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:
* 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
* 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
* 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]
> >
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
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
* 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
* 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
* 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:
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
* 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.
* 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
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
* 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
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 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
* 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
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
* 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
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
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:
* 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
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
* 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
* 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
* 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
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
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
* 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
* 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
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
* 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
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
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
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
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
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
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.
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
* 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
* 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
* 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:
* 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:
* 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.
* 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
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
1 - 100 of 192 matches
Mail list logo
