hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Greg T. <gd...@le...>]

I too fall into the camp that LLM output is a derived work of its
training inputs, and that LLMs trained on code without permission are
basically copyright infringement at scale.

+1 to require Signed-off-by: asserting that the person has the right to
license the code under the project's license -- which means it is not
from an LLM.


Separately from licensing, I am seeing discussion in multiple projects
where people are submitting code that is LLM-generated.  It's buggy and
project maintainers end up spending time dealing with it (review, fix).
I recently saw a "new project" with pretty big claims, and then a human
commented fairly extensively and quite reasonably (technically sensible
and polite).  That resulted in an LLM-generated reply to the comments,
at which point the human called the LLM-sock-puppet on their behavior
and the converation ended.

For unison, a non-ham project I maintain, I decided that LLM code was
not ok for both of these reasons, and CONTRIBUTING.md reads:

  ## LLM usage

  LLMs essentially always use training input without copyright
  permission, and the unison maintainer considers the output from LLMs
  to be a derived work of the training data.  Thus *LLM-generated code
  is simply not acceptable for submission to the project*.  This is
  implied by the previous requirement that the submitter has permission
  to license the code under the project's license, but stated explicitly
  because that seems to be necessary.

  It is ethically unacceptable to ask humans to review and deal with
  code generated by LLMs.  Even if there were no licensing issues,
  LLM-generated code would still be unwelcome.

(I, a human, am the sole author of that text and you are welcome to take
it!)

At least for now, I strongly recommend hamlib take a "no LLM output is
acceptable within the project" stance.

73 de n1dam

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[<gm...@bt...>]

I accepted a free trial of CoPilot and I was quite impressed.

It DID save a lot of typing for churning out boiler-plate code. At one point it generated an adequate ADIF parser just from a short prompt in comment. Almost as if it were reading my mind.

If I was typing in comment about what I wanted a method to achieve, it would start suggesting additional lines of "specification" for the code, and I could think, "yes, OK I'll have that" or just ignore it.

In the end though I didn't think I could justify spending $10 a month for what is in effect a pasttime, but I can see it being very useful for those for whom coding is an income.

When it produced the ADIF parser, I did wonder where it got that algorithm from. And did think probably other code on github.

In the end I tended to use it as a glorified "auto-complete" tool. Where, instead of just suggesting variable names etc, it went on to complete the method. I never got to the point that I trusted the code it generated. I would always go over it and review what it generated.

In that process, it was difficult to see which of the code assistants was helping me. Was it just the existing non-LLM tools such as "Intellisense" in VS Code or was it LLM "Copilot"? And where do you draw the line?

Just my two-pennyworth.

Phil GM3ZZA
________________________________
From: Mikael Nousiainen <mik...@fa...>
Sent: 23 December 2025 8:45 AM
To: ham...@li... <ham...@li...>
Subject: Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

Hi all!

Regarding the AI / LLM code generation discussion, Nate summarized my thoughts well here:

> I do think the licensing aspect is an important consideration. I do trust that you and Terrell are taking the time to test the LLM code against an actual radio and working out any bugs. Perhaps, other than generic programming concepts, Hamlib code is so specialized that an LLM can only train on Hamlib and thus is just spitting Hamlib code right back to you and if so, there wouldn't be a licensing issue.

I really do not think licensing is an issue because of the very specific area of expertise required for Hamlib development. Using AI agents is very close to just Google searches and Stack Overflow usage for generic constructs, like Nate mentioned.

However, what I'd like to emphasize is that I'd encourage all Hamlib developers to actively review and **clean up** any code generated by AI agents. IMO we should strive for code that looks like a human wrote it, making it readable. This also means we should document the code where it needs to and, more importantly, remove any excess comments, inconsistencies and historical details (about code what _used to be_ there) that many AI agents tend to write.

We saw some examples of this phenomenon in PR #1961 - but now it's more or less all cleaned up. 👍

I think the goal in any software development should be to produce the least amount of code and documentation to allow other developers to easily understand the purpose and internal logic of a piece of code. This is why the clean-up phase after using AI agents is essential.

Nate and others: Maybe we could incorporate some of this into HAMLIB.developer file instead of an "absolute ban" of AI agents?

73,
Mikael OH3BHX

On Mon, Dec 22, 2025, at 18:52, Nate Bargmann wrote:
> Jeremy Box posted this to GitHub pull requests 1826 and 1961:
>
> ----- Forwarded message from Jeremy <not...@gi...> -----
>
> Date: Mon, 22 Dec 2025 07:14:40 -0800
> From: Jeremy <not...@gi...>
> To: Hamlib/Hamlib <Ha...@no...>
> Subject: Re: [Hamlib/Hamlib] Added Yaesu FTX-1 Support (PR #1961)
>
> jeremybox left a comment (Hamlib/Hamlib#1961)
>
> Just returning from vacation and seeing the flurry of activity here.  I
> don't know what the appropriate forum for this question is, so if this
> isn't it, please redirect me, but I was just rereading the
> https://github.com/Hamlib/Hamlib/blob/2805dc5ed66412f80e008650169d5d78f2a94cb1/README.developer
> file again and I came across the LLM section starting here
> https://github.com/Hamlib/Hamlib/blob/2805dc5ed66412f80e008650169d5d78f2a94cb1/README.developer#L517
>
> My initial commit for the ftx-1 code started with taking the existing
> 991A code, and trying to iteratively get the functions to work on my
> FTX-1.  When coding I do use a LLM tool in my IDE to assist while
> writing my code, and so some of the code that I contributed was assisted
> with a LLM with the intent of staying as close to the existing
> format/style of hamlib code as I could, but it was not 100% hand written
> by me.  This new PR similarly looks extremely LLM driven, and I don't
> know where that leaves us on actually wanting to use either my or this
> code at all based on the current wording and intent of the README.  As
> it is mentioned that we are using the 'honor system' for this, I don't
> know what the appropriate path foward is, but wanted to raise it before
> further work was done either by myself or Terrell that is not acceptable
> for this project.
>
> This is in no way intended to detract from either of our respective
> contributions, as we were both I'm sure just eager to try to get FTX-1
> capability into hamlib for anyone who hjas this radio, but I again am
> not clear on the proper process here or what the 'right' thing to do is.
> I find using a LLM assistant extremely valuable in speeding up my coding
> output, and handling boring 'chores' in coding, but I do understand the
> reasoning behind, and respect that the project has specifically asked
> not to use them.  Now that I am aware of this, I will be pasting this
> same comment into both my existing accepted PR and Terrell's outstanding
> one, and encourage discission on the more active PR
> https://github.com/Hamlib/Hamlib/pull/1961 unless there's a better place
> to bring this up.  Perhaps the 'right' way to solve this is to roll back
> my PR entirely, and then work together to commit (by hand) working code
> for this radio?  I don't really know.
>
> ----- End forwarded message -----
>
> Here is the section of README.developer that I added a few months back:
>
> 1.5. A word about AI
>
> Over the past several years the latest rage is so-called Artificial
> Intelligence, a.k.a. Large-language Learning Models (LLM).  Companies are
> pushing using AI for development.  GitHub (owned by Microsoft) seems to be
> pushing "Copilot" at every turn.  Many thoughts about this technology exist
> among Free Software developers.
>
> Perhaps the most questionable aspect of LLM generated code is licensing--can
> such code be licensed under the GPL/LGPL?  It's not an easy question to answer.
> Code that is written by a developer is copyrighted by that developer, presuming
> it is original work.  That does not change even when code is collaboratively
> developed and held in a common repository.  Ostensibly, the developer has
> written the code and not plagiarized that of someone else without due credit
> (certainly, it is fine to "borrow" code from compatibly licensed projects, just
> credit the project/authors and disclaim it is your original work).
>
> The question leads to another question, did the LLM have access to sources that
> were licensed under an incompatible license?  Could this lead to a copyright
> infringement issue?  At this time LLMs don't seem to reveal their learning
> sources and Copilot likely has access to closed sources that are hosted at
> GitHub.
>
> The Hamlib project accepts contributions on the "honor system".  It is implied
> that contributions are the original works of their respective authors and
> offered under the license terms of the GPL 2.0 or LGPL 2.1.  Use of LLM
> generated code breaks this model.  The contributors of such code cannot claim it
> as their own original work.
>
> Finally, Hamlib is a hobby project for hobbyists and as such all contributors
> should take pride in having their original work included for the benefit of many
> other radio hobbyists.  Against that backdrop, using LLM generated code seems
> like cheating.
>
> --------------------------
>
> I added the following reply to GitHub PR 1961:
>
> Jeremy,
>
> Those are my thoughts and my thoughts alone. I am certainly willing to
> revise them if other contributors think I am being to rigid. I
> understand the speed and ease LLMs provide to developers. Maybe I'm
> stuck a bit in the "hard way" mold. Perhaps this brave new world is just
> beyond my comfort zone.
>
> I do think the licensing aspect is an important consideration. I do
> trust that you and Terrell are taking the time to test the LLM code
> against an actual radio and working out any bugs. Perhaps, other than
> generic programming concepts, Hamlib code is so specialized that an LLM
> can only train on Hamlib and thus is just spitting Hamlib code right
> back to you and if so, there wouldn't be a licensing issue.
>
> I'd be lying if I tried to state that I've not used search engines over
> the years to get a lead on something I seek to accomplish. Often times
> this led to a manual excerpt or code snippet from another project that
> sparked an idea. I think we all do that. LLMs seem to be that capability
> on steroids!
>
> ---------------------------
>
>
> I want to add that I don't want to stifle development.  I'm stuck in a
> quandary of how to proceed with PR 1961 and would appreciate guidance.
>
> 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
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>
> Attachments:
> * signature.asc


_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Daniele F. <iu...@gm...>]

TL;DR I'm not against LLM but I'm worried that they could produce code
identical to projects with incompatible licenses or projects with
compatible licences but that require attribution and it is missing. In
one word: plagiarism.

I think that the thing to address is the licensing part because we
aren't writing software only for ourselves, but we are also giving it
to other people saying that all the authors have licensed their
contributions under GPL/LGPL. This affects distros and possibly
commercial users.

If children contributed code to Hamlib I believe that we would need to
ask their parents to license the code, the same for
employees/employers. Is this even possible with LLM's? I believe that
Github had an AI assistant which allowed users to choose the license
of its data.

For some Hamlib is a hobby project and for some is a commodity. One
goal for Nate IMHO is to make maintenance easier for everybody.

To make it easier for downstreams that want to update the 4.x releases
already in use, I hope that we can clearly show that all of the
contributions are properly licensed whatever was their source.

For the future should we ask contributors to add a note to their
commit messages like the Signed-off-by tag required to contribute to
the Linux kernel?
It just tells that the person has the right to submit that code:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
it's an annoyance but it works for them that have tens or hundreds of
new contributors each year that have to learn this additional step,
will it work for Hamlib too? Would it make any difference? Probably
for some downstream users, yes.

BTW, Gmail has suggested several corrections while I was writing this
email, I accepted some and refused others and some it did
automatically, was it AI or just a spelling and grammar checker?
-- 
73 de IU5HKX Daniele

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Mikael N. <mik...@fa...>]

Hi all!

Regarding the AI / LLM code generation discussion, Nate summarized my thoughts well here:

> I do think the licensing aspect is an important consideration. I do trust that you and Terrell are taking the time to test the LLM code against an actual radio and working out any bugs. Perhaps, other than generic programming concepts, Hamlib code is so specialized that an LLM can only train on Hamlib and thus is just spitting Hamlib code right back to you and if so, there wouldn't be a licensing issue.

I really do not think licensing is an issue because of the very specific area of expertise required for Hamlib development. Using AI agents is very close to just Google searches and Stack Overflow usage for generic constructs, like Nate mentioned.

However, what I'd like to emphasize is that I'd encourage all Hamlib developers to actively review and **clean up** any code generated by AI agents. IMO we should strive for code that looks like a human wrote it, making it readable. This also means we should document the code where it needs to and, more importantly, remove any excess comments, inconsistencies and historical details (about code what _used to be_ there) that many AI agents tend to write.

We saw some examples of this phenomenon in PR #1961 - but now it's more or less all cleaned up. 👍 

I think the goal in any software development should be to produce the least amount of code and documentation to allow other developers to easily understand the purpose and internal logic of a piece of code. This is why the clean-up phase after using AI agents is essential.

Nate and others: Maybe we could incorporate some of this into HAMLIB.developer file instead of an "absolute ban" of AI agents?

73,
Mikael OH3BHX

On Mon, Dec 22, 2025, at 18:52, Nate Bargmann wrote:
> Jeremy Box posted this to GitHub pull requests 1826 and 1961:
>
> ----- Forwarded message from Jeremy <not...@gi...> -----
>
> Date: Mon, 22 Dec 2025 07:14:40 -0800
> From: Jeremy <not...@gi...>
> To: Hamlib/Hamlib <Ha...@no...>
> Subject: Re: [Hamlib/Hamlib] Added Yaesu FTX-1 Support (PR #1961)
>
> jeremybox left a comment (Hamlib/Hamlib#1961)
>
> Just returning from vacation and seeing the flurry of activity here.  I
> don't know what the appropriate forum for this question is, so if this
> isn't it, please redirect me, but I was just rereading the
> https://github.com/Hamlib/Hamlib/blob/2805dc5ed66412f80e008650169d5d78f2a94cb1/README.developer
> file again and I came across the LLM section starting here
> https://github.com/Hamlib/Hamlib/blob/2805dc5ed66412f80e008650169d5d78f2a94cb1/README.developer#L517
>
> My initial commit for the ftx-1 code started with taking the existing
> 991A code, and trying to iteratively get the functions to work on my
> FTX-1.  When coding I do use a LLM tool in my IDE to assist while
> writing my code, and so some of the code that I contributed was assisted
> with a LLM with the intent of staying as close to the existing
> format/style of hamlib code as I could, but it was not 100% hand written
> by me.  This new PR similarly looks extremely LLM driven, and I don't
> know where that leaves us on actually wanting to use either my or this
> code at all based on the current wording and intent of the README.  As
> it is mentioned that we are using the 'honor system' for this, I don't
> know what the appropriate path foward is, but wanted to raise it before
> further work was done either by myself or Terrell that is not acceptable
> for this project.
>
> This is in no way intended to detract from either of our respective
> contributions, as we were both I'm sure just eager to try to get FTX-1
> capability into hamlib for anyone who hjas this radio, but I again am
> not clear on the proper process here or what the 'right' thing to do is.
> I find using a LLM assistant extremely valuable in speeding up my coding
> output, and handling boring 'chores' in coding, but I do understand the
> reasoning behind, and respect that the project has specifically asked
> not to use them.  Now that I am aware of this, I will be pasting this
> same comment into both my existing accepted PR and Terrell's outstanding
> one, and encourage discission on the more active PR
> https://github.com/Hamlib/Hamlib/pull/1961 unless there's a better place
> to bring this up.  Perhaps the 'right' way to solve this is to roll back
> my PR entirely, and then work together to commit (by hand) working code
> for this radio?  I don't really know.
>
> ----- End forwarded message -----
>
> Here is the section of README.developer that I added a few months back:
>
> 1.5. A word about AI
>
> Over the past several years the latest rage is so-called Artificial
> Intelligence, a.k.a. Large-language Learning Models (LLM).  Companies are
> pushing using AI for development.  GitHub (owned by Microsoft) seems to be
> pushing "Copilot" at every turn.  Many thoughts about this technology exist
> among Free Software developers.
>
> Perhaps the most questionable aspect of LLM generated code is licensing--can
> such code be licensed under the GPL/LGPL?  It's not an easy question to answer.
> Code that is written by a developer is copyrighted by that developer, presuming
> it is original work.  That does not change even when code is collaboratively
> developed and held in a common repository.  Ostensibly, the developer has
> written the code and not plagiarized that of someone else without due credit
> (certainly, it is fine to "borrow" code from compatibly licensed projects, just
> credit the project/authors and disclaim it is your original work).
>
> The question leads to another question, did the LLM have access to sources that
> were licensed under an incompatible license?  Could this lead to a copyright
> infringement issue?  At this time LLMs don't seem to reveal their learning
> sources and Copilot likely has access to closed sources that are hosted at
> GitHub.
>
> The Hamlib project accepts contributions on the "honor system".  It is implied
> that contributions are the original works of their respective authors and
> offered under the license terms of the GPL 2.0 or LGPL 2.1.  Use of LLM
> generated code breaks this model.  The contributors of such code cannot claim it
> as their own original work.
>
> Finally, Hamlib is a hobby project for hobbyists and as such all contributors
> should take pride in having their original work included for the benefit of many
> other radio hobbyists.  Against that backdrop, using LLM generated code seems
> like cheating.
>
> --------------------------
>
> I added the following reply to GitHub PR 1961:
>
> Jeremy,
>
> Those are my thoughts and my thoughts alone. I am certainly willing to
> revise them if other contributors think I am being to rigid. I
> understand the speed and ease LLMs provide to developers. Maybe I'm
> stuck a bit in the "hard way" mold. Perhaps this brave new world is just
> beyond my comfort zone.
>
> I do think the licensing aspect is an important consideration. I do
> trust that you and Terrell are taking the time to test the LLM code
> against an actual radio and working out any bugs. Perhaps, other than
> generic programming concepts, Hamlib code is so specialized that an LLM
> can only train on Hamlib and thus is just spitting Hamlib code right
> back to you and if so, there wouldn't be a licensing issue.
>
> I'd be lying if I tried to state that I've not used search engines over
> the years to get a lead on something I seek to accomplish. Often times
> this led to a manual excerpt or code snippet from another project that
> sparked an idea. I think we all do that. LLMs seem to be that capability
> on steroids!
>
> ---------------------------
>
>
> I want to add that I don't want to stifle development.  I'm stuck in a
> quandary of how to proceed with PR 1961 and would appreciate guidance.
>
> 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
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>
> Attachments:
> * signature.asc

[Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Nate B. <n0...@n0...>]

Jeremy Box posted this to GitHub pull requests 1826 and 1961:

----- Forwarded message from Jeremy <not...@gi...> -----

Date: Mon, 22 Dec 2025 07:14:40 -0800
From: Jeremy <not...@gi...>
To: Hamlib/Hamlib <Ha...@no...>
Subject: Re: [Hamlib/Hamlib] Added Yaesu FTX-1 Support (PR #1961)

jeremybox left a comment (Hamlib/Hamlib#1961)

Just returning from vacation and seeing the flurry of activity here.  I
don't know what the appropriate forum for this question is, so if this
isn't it, please redirect me, but I was just rereading the
https://github.com/Hamlib/Hamlib/blob/2805dc5ed66412f80e008650169d5d78f2a94cb1/README.developer
file again and I came across the LLM section starting here
https://github.com/Hamlib/Hamlib/blob/2805dc5ed66412f80e008650169d5d78f2a94cb1/README.developer#L517

My initial commit for the ftx-1 code started with taking the existing
991A code, and trying to iteratively get the functions to work on my
FTX-1.  When coding I do use a LLM tool in my IDE to assist while
writing my code, and so some of the code that I contributed was assisted
with a LLM with the intent of staying as close to the existing
format/style of hamlib code as I could, but it was not 100% hand written
by me.  This new PR similarly looks extremely LLM driven, and I don't
know where that leaves us on actually wanting to use either my or this
code at all based on the current wording and intent of the README.  As
it is mentioned that we are using the 'honor system' for this, I don't
know what the appropriate path foward is, but wanted to raise it before
further work was done either by myself or Terrell that is not acceptable
for this project.

This is in no way intended to detract from either of our respective
contributions, as we were both I'm sure just eager to try to get FTX-1
capability into hamlib for anyone who hjas this radio, but I again am
not clear on the proper process here or what the 'right' thing to do is.
I find using a LLM assistant extremely valuable in speeding up my coding
output, and handling boring 'chores' in coding, but I do understand the
reasoning behind, and respect that the project has specifically asked
not to use them.  Now that I am aware of this, I will be pasting this
same comment into both my existing accepted PR and Terrell's outstanding
one, and encourage discission on the more active PR
https://github.com/Hamlib/Hamlib/pull/1961 unless there's a better place
to bring this up.  Perhaps the 'right' way to solve this is to roll back
my PR entirely, and then work together to commit (by hand) working code
for this radio?  I don't really know.

----- End forwarded message -----

Here is the section of README.developer that I added a few months back:

1.5. A word about AI

Over the past several years the latest rage is so-called Artificial
Intelligence, a.k.a. Large-language Learning Models (LLM).  Companies are
pushing using AI for development.  GitHub (owned by Microsoft) seems to be
pushing "Copilot" at every turn.  Many thoughts about this technology exist
among Free Software developers.

Perhaps the most questionable aspect of LLM generated code is licensing--can
such code be licensed under the GPL/LGPL?  It's not an easy question to answer.
Code that is written by a developer is copyrighted by that developer, presuming
it is original work.  That does not change even when code is collaboratively
developed and held in a common repository.  Ostensibly, the developer has
written the code and not plagiarized that of someone else without due credit
(certainly, it is fine to "borrow" code from compatibly licensed projects, just
credit the project/authors and disclaim it is your original work).

The question leads to another question, did the LLM have access to sources that
were licensed under an incompatible license?  Could this lead to a copyright
infringement issue?  At this time LLMs don't seem to reveal their learning
sources and Copilot likely has access to closed sources that are hosted at
GitHub.

The Hamlib project accepts contributions on the "honor system".  It is implied
that contributions are the original works of their respective authors and
offered under the license terms of the GPL 2.0 or LGPL 2.1.  Use of LLM
generated code breaks this model.  The contributors of such code cannot claim it
as their own original work.

Finally, Hamlib is a hobby project for hobbyists and as such all contributors
should take pride in having their original work included for the benefit of many
other radio hobbyists.  Against that backdrop, using LLM generated code seems
like cheating.

--------------------------

I added the following reply to GitHub PR 1961:

Jeremy,

Those are my thoughts and my thoughts alone. I am certainly willing to
revise them if other contributors think I am being to rigid. I
understand the speed and ease LLMs provide to developers. Maybe I'm
stuck a bit in the "hard way" mold. Perhaps this brave new world is just
beyond my comfort zone.

I do think the licensing aspect is an important consideration. I do
trust that you and Terrell are taking the time to test the LLM code
against an actual radio and working out any bugs. Perhaps, other than
generic programming concepts, Hamlib code is so specialized that an LLM
can only train on Hamlib and thus is just spitting Hamlib code right
back to you and if so, there wouldn't be a licensing issue.

I'd be lying if I tried to state that I've not used search engines over
the years to get a lead on something I seek to accomplish. Often times
this led to a manual excerpt or code snippet from another project that
sparked an idea. I think we all do that. LLMs seem to be that capability
on steroids!

---------------------------


I want to add that I don't want to stifle development.  I'm stuck in a
quandary of how to proceed with PR 1961 and would appreciate guidance.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Re: [Hamlib-developer] Hamlib backend file structure for large backends

[Mikael N. <mik...@fa...>]

Hi George,

Thanks for your input, please see my comments below!

On Sun, Dec 21, 2025, at 20:55, George Baltz wrote:
> [Sorry, personal/ham time is in short supply this time of year, so this 
> is a bit rushed. More may follow]
>
> On 12/20/25 12:07 PM, Mikael Nousiainen wrote:
>> Hello Hamlib developers!
>>
>> There's been some recent discussion in Hamlib PR #1961 (see https://github.com/Hamlib/Hamlib/pull/1961) about the device backend file structure. Some backend, such as the new Yaesu FTX-1 backend have grown rather complex and with the upcoming addition of Icom network protocol support and full-featured FlexRadio backend (with audio and I/Q data streaming!) are only likely to make the backend sizes larger (these will be part of the ARDC Hamlib improvement project, also announced recently on this mailing list and in the GitHub PRs).
>>
>> Traditionally, most of the backends (for a single device type - or its variants) has been placed in a single source file. However, as these files grow up to several thousand lines long - or possibly even larger, to over 10k lines - it can be argued that managing the source code becomes more difficult. Additionally, splitting backend code into logical parts might make sharing common code across similar backends easier.
> Missing one very important detail - backends for most rigs are made up 
> of *two* files; one specifically for the rig and one for the 
> vendor(e.g., rigs/icom/icom.c, rigs/yaesu/newcat.c, etc) that is shared 
> by all rigs from that manufacturer. AFAICT the previous development 
> would start with the common file and add replacements for any of the 
> common routines necessary to handle the new rig. Checking if a similar 
> function existed in another rig file may not have happened.

Agreed - though there are some significant inconsistencies here: in some cases the "common routines" simply contain huge if-else blocks to handle each specific rig, which is not really optimal regarding what I think a clean backend implementation would be. In an optimal case, the "common routines" would only contain code that can be directly re-used by the individual backends (or somehow parameterized, e.g. with custom subcommand numbers as parameters - like a Yaesu EX-menu command could work) - and it wouldn't handle any specific model, maybe unless there are only a handful of variations to a command.

>> As potential alternatives to single-file backends, there is already one proposal in the FTX-1 backend PR and I personally added another one.
>>
>> Here are all of the 3 options that have been discussed so far:
>>
>> 1) Traditional, single-file backend - no matter the size of the file
>>
>> 2) The current PR # structure (files split in two directories): main backend files (ftx1.c and ftx1.h) + README are in rigs/yaesu directory and the rest of the files are in rigs/yaesu/ftx1 directory
>>
>> 3) Similar multi-file backend as in PR #1961, but all of the files (including ftx1.c, ftx1.h and README) are placed in a backend-specific subdirectory, e,.g. rigs/yaesu/ftx1.
>>
>> Personally, I'd prefer option 3 - but *only* for multi-file backends.
> Personally, I'd prefer option 1.  Putting these files into a 
> subdirectory means the chances of reusing them (or even looking at them) 
> drops to about zero.
>>
>> For a single-file backend, we could still use the current convention (of not having a separate subdirectory for the backend). So as a summary, this is a question of adding subdirectory for multi-file backend. And IMO there's definitely no point in starting to convert any of the existing backends - unless changes are being made to them and they grow significantly larger.
>>
>> Since there's already the FTX-1 backend PR under review that would benefit from this discussion, I think everyone would appreciate if we can make a decision reasonably quickly :)
>>
>> Please share your thoughts!
> You asked for it :-)
>
> Part of the problem with the size of backends is that although Hamlib 
> has data structures to describe the capabilities of the rig, there is no 
> table-driven description of the command structure/syntax to actually do 
> anything.  So it all is done by individual code paths.  Tie together the 
> Hamlib function, the rig model and the command, and a lot of that code 
> could go away.

True - there's a lot of simple refactoring that could be done.

>
> Case in point: PR #1952.  Replaces almost all of the logic that computes 
> which command to send with preset templates ready to apply the function 
> values to and ship out to the rig; uses data already in the rig 
> capabilities to define those templates.  And I noticed (after the fact) 
> that 3 of the 4 voice_mem() functions in the Elecraft backend can now be 
> removed by adding a few more lines to kenwood_init() and using the 
> common code in kenwood.c.

Exactly. There is indeed a lot of cleanup to be done.

However, what I'm after with my file structure proposal (option 3) is that, even WITH your points considered (clear separation between common and model-specific code + refactoring of repetitive code constructs done), more complex transceivers end up having complex backends with usually plenty of model-specific code (no manufacturer seems to case about consistency, there will be lots of exceptions to "rules"). In this case, I think having multiple files for a single backend will help maintainability and readability.

I'm already seeing this is the case with FTX-1 - lots of the commands are FTX-1-specific (although some smaller parts of the FTX-1 backend could probably made more generic, e.g. the EX menu command routines).

What I'm after here is to establish a guideline for larger backends: what's the convention we should follow with more complex backends. Most backends would do just fine with a single file!

Additionally, we could document some of the backend development process rules where what you've stated in your message are top priority: making sure the "common routines" are used to full extent and that the code doesn't use repetitive constructs (that are also prone to bugs).

We could certainly extend the existing developer docs with these guidelines: https://github.com/Hamlib/Hamlib/blob/master/README.developer

73,
Mikael OH3BHX

Re: [Hamlib-developer] Hamlib backend file structure for large backends

[Nate B. <n0...@n0...>]

I am comfortable with option 1 or 3, whichever the primary developer
prefers.  Option 2 just seems cumbersome.

I strive to keep contributing as a low of a friction process as possible
though there are things that have to be done a certain way at this time.
That said, I don't want to have a conflict of styles drive development
away.  OTOH, I don't want a free for all either.  Somewhere in between
those extremes is a place where I hope the project can thrive.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Re: [Hamlib-developer] possible changes to how data from FLRig is handled

[Peter S. <vk...@gm...>]

Hi Phil,
Yes its definitely family time now but do really appreciate any
investigation you can do after the holidays. I have a usable workaround by
using old versions of hamlib on the shack pc but at some point there will
be a tipping point where i will be left in the wilderness if i stay on an
old version (hamlib 5 might be that point).

Seasons greetings to you and the extended hamlib community

Regards, Peter vk5pj.

On Sun, 21 Dec 2025, 23:39 gm...@bt..., <gm...@bt...>
wrote:

>
>
> ------------------------------
> *From:* Peter Sumner <vk...@gm...>
> *Sent:* 21 December 2025 10:18 AM
> *To:* gm...@bt... <gm...@bt...>
> *Subject:* Re: [Hamlib-developer] possible changes to how data from FLRig
> is handled
>
> Hello Phil,
>  "wsjt-X" and "wsjt-X Improved" are pretty well the same code base since
> the release of version 3 where the code was merged from what I understand,
> Uwe could give a better answer than me on that.
>
> I did load FLRig onto my Raspberry Pi 4 and can see the same affliction is
> _not_ there under lInux (Rasp OS) when flrig is in the equation.  Would
> seem my problem is a windows affliction, maybe I need to load up Linux Mint
> on my shack PC :-)
>
> Would still love to find an answer to this situation as not quite ready to
> give up on Windows yet, as too many utilities I use are windows only
> (Log4OM contact logging being the big one)
>
> Can anyone comment on what the best way for me to request a feature change
> in HAMLIB?
>
> I've put the hamlib-developer list back on the e-mail trail. I must have
> forgot to Reply-all at one stage. I am not sure where the problem lies as I
> have been unable to reproduce it with my set up. I would need to take this
> laptop upto the shack and connect it up under Windows to try and do so, but
> it's definitely family time this week, so it'll be a couple of days.
>
> 73 Phil.
>
>
>
> Regards,
> Peter, vk5pj
>
>
> On Sun, Dec 21, 2025 at 8:19 PM gm...@bt... <
> gm...@bt...> wrote:
>
> Hi Peter,
>
> Sorry I don't have WSJT-X (Improved) here, just WSJT-X. Have you discussed
> this with the WSJT-X (Improved) team?
>
> Phil GM3ZZA.
> ------------------------------
> *From:* Peter Sumner <vk...@gm...>
> *Sent:* 21 December 2025 3:12 AM
> *To:* gm...@bt... <gm...@bt...>
> *Subject:* Re: [Hamlib-developer] possible changes to how data from FLRig
> is handled
>
> Hello Phil,
>   I will have to grab one of my Raspberry PI's and try FLRIG on it with a
> recent HAMLIB to see what it looks like there but at present I am in the
> windows world for day to day operations.
>
> My Windows setup of WSJT-X (Improved) has multiple configurations for the
> different Modes (FT8, WSPR, Q65 and Q65 EME). Starting WSJT-X for the first
> time or swapping between configs is when I see the rig control error and
> have to select FLRig from the list.
>
> Regards,
> Peter, vk5pj
>
> On Sun, Dec 21, 2025 at 7:08 AM gm...@bt... <
> gm...@bt...> wrote:
>
> Hi Peter,
>
> I can only see what happens on Linux and I do not see the effect you write
> about.
>
> I use FlRig all the time and have never seen it treated like this.
>
> But I do have separate configurations for each rig (in WSJT-X).
>
> 73 Phil GM3ZZA
> ------------------------------
> *From:* Peter Sumner <vk...@gm...>
> *Sent:* 20 December 2025 6:59 PM
> *To:* gm...@bt... <gm...@bt...>
> *Subject:* Re: [Hamlib-developer] possible changes to how data from FLRig
> is handled
>
> Hello Phil,
>   I have been trying all newer releases of HAMLIB as they come along,
> including those shipped with WSJT-X (and improved) to check if they
> function any better for me but all releases newer than 4.5.4 exhibit the
> same trait and I am forced to copy an old "libhamlib-4.dll" into the bin
> folder of any new release of WSJT-X to make it work for me.  I even tried
> the nightly build of hamlib v5 to see what happened (same thing).
>
> Regards,
> Peter, vk5pj
>
> On Sat, Dec 20, 2025 at 11:58 PM gm...@bt... <
> gm...@bt...> wrote:
>
> Hi Peter,
>
> Are these versions you are quoting hamlib? If so these are quite out of
> date. The latest shipped with WSJT-X (3.0-rc1) is 4.7~git 20250905. There
> has been significant change to the way flrig has been handled since then.
> Even this version is not quite correct as it changed firig to W1HKJ/FLlRig
> and has now been changed back to FlRig/FlRig.
>
> I believe the latest Windows 64-bit version of hamlib is available and can
> just be copied over the hamlib .dll in the WSJT-X directory.
>
> 73 Phil GM3ZZA
>
> ------------------------------
> *From:* Peter Sumner <vk...@gm...>
> *Sent:* 20 December 2025 9:42 AM
> *To:* ham...@li... <
> ham...@li...>
> *Subject:* [Hamlib-developer] possible changes to how data from FLRig is
> handled
>
> Hello,
>   I have been an avid user of WSJT-X - HAMLIB - FLRig for some time now
> and have found that in builds after version 4.54 there were changes to
> flrig.c that allow hamlib to display the radio model connected to FLRig.
> While this seems like a minor change, it has cascaded into this extra
> information being sent to software like WSJT-X that then saves this extra
> information in its INI file.   When WSJT-X starts up and queries HAMLIB it
> gets a vanilla list of rigs that show "FLRig FLRig" as it used to be in
> version 4.5.4 but in anything after that, the extra information bleeds
> through to WSJT-X once the connection is open to FLRig.
>
> This causes WSJT-X to store the rig type as: "Rig=FLRig IC-7600(FLRig)"
> which does not match the value it sees at start up ("FLRig FLRig"), meaning
> WSJT-X shows a rig control error and the user must manually select FLRig
> from the list every time.
>
> With my limited ability I have been able to identify where I think the
> change happened (see below).   Is there any way for this behaviour to be
> changed with a setting in a JSON file or even reverted to how it was in
> v4.5.4 ? unless there is a pressing need to have this extra information
> from FLRig?
>
> /ver 4.6.5 flrig.c
>
>     RIG_MODEL(RIG_MODEL_FLRIG),
>     .model_name = "",
>     .mfg_name = "FLRig",
>     .version = "20250107.0",
>
> then down quite a bit around line 870 this happens (which is not in 4.5.4)
>
>  char model_name[256];
>     snprintf(model_name,sizeof(model_name), "%.248s(%s)", value, "FLRig");
>     rig->caps->model_name = strdup(model_name);
>     STATE(rig)->model_name = strdup(model_name);
>
>
> //ver 4.5.4 flrig.c
>
>     RIG_MODEL(RIG_MODEL_FLRIG),
>     .model_name = "FLRig",
>     .mfg_name = "FLRig",
>     .version = "20221109.0",
>
> I have asked George Blatz about this but he told me he had no experience
> with FLRig and doubted he could be of assistance.
>
> O/S windows 10 X64, I have no compilers and lack the experience to try and
> compile a private version of HAMLIB.
>
> hoping one of the members here can help
>
> Regards,
> Peter, vk5pj
>
>

Re: [Hamlib-developer] Hamlib backend file structure for large backends

[George B. <geo...@gm...>]

[Sorry, personal/ham time is in short supply this time of year, so this 
is a bit rushed. More may follow]

On 12/20/25 12:07 PM, Mikael Nousiainen wrote:
> Hello Hamlib developers!
>
> There's been some recent discussion in Hamlib PR #1961 (see https://github.com/Hamlib/Hamlib/pull/1961) about the device backend file structure. Some backend, such as the new Yaesu FTX-1 backend have grown rather complex and with the upcoming addition of Icom network protocol support and full-featured FlexRadio backend (with audio and I/Q data streaming!) are only likely to make the backend sizes larger (these will be part of the ARDC Hamlib improvement project, also announced recently on this mailing list and in the GitHub PRs).
>
> Traditionally, most of the backends (for a single device type - or its variants) has been placed in a single source file. However, as these files grow up to several thousand lines long - or possibly even larger, to over 10k lines - it can be argued that managing the source code becomes more difficult. Additionally, splitting backend code into logical parts might make sharing common code across similar backends easier.
Missing one very important detail - backends for most rigs are made up 
of *two* files; one specifically for the rig and one for the 
vendor(e.g., rigs/icom/icom.c, rigs/yaesu/newcat.c, etc) that is shared 
by all rigs from that manufacturer. AFAICT the previous development 
would start with the common file and add replacements for any of the 
common routines necessary to handle the new rig. Checking if a similar 
function existed in another rig file may not have happened.
> As potential alternatives to single-file backends, there is already one proposal in the FTX-1 backend PR and I personally added another one.
>
> Here are all of the 3 options that have been discussed so far:
>
> 1) Traditional, single-file backend - no matter the size of the file
>
> 2) The current PR # structure (files split in two directories): main backend files (ftx1.c and ftx1.h) + README are in rigs/yaesu directory and the rest of the files are in rigs/yaesu/ftx1 directory
>
> 3) Similar multi-file backend as in PR #1961, but all of the files (including ftx1.c, ftx1.h and README) are placed in a backend-specific subdirectory, e,.g. rigs/yaesu/ftx1.
>
> Personally, I'd prefer option 3 - but *only* for multi-file backends.
Personally, I'd prefer option 1.  Putting these files into a 
subdirectory means the chances of reusing them (or even looking at them) 
drops to about zero.
>
> For a single-file backend, we could still use the current convention (of not having a separate subdirectory for the backend). So as a summary, this is a question of adding subdirectory for multi-file backend. And IMO there's definitely no point in starting to convert any of the existing backends - unless changes are being made to them and they grow significantly larger.
>
> Since there's already the FTX-1 backend PR under review that would benefit from this discussion, I think everyone would appreciate if we can make a decision reasonably quickly :)
>
> Please share your thoughts!
You asked for it :-)

Part of the problem with the size of backends is that although Hamlib 
has data structures to describe the capabilities of the rig, there is no 
table-driven description of the command structure/syntax to actually do 
anything.  So it all is done by individual code paths.  Tie together the 
Hamlib function, the rig model and the command, and a lot of that code 
could go away.

Case in point: PR #1952.  Replaces almost all of the logic that computes 
which command to send with preset templates ready to apply the function 
values to and ship out to the rig; uses data already in the rig 
capabilities to define those templates.  And I noticed (after the fact) 
that 3 of the 4 voice_mem() functions in the Elecraft backend can now be 
removed by adding a few more lines to kenwood_init() and using the 
common code in kenwood.c.

>
> 73,
> Mikael OH3BHX
>
73 n3gb

Re: [Hamlib-developer] possible changes to how data from FLRig is handled

[<gm...@bt...>]

________________________________
From: Peter Sumner <vk...@gm...>
Sent: 21 December 2025 10:18 AM
To: gm...@bt... <gm...@bt...>
Subject: Re: [Hamlib-developer] possible changes to how data from FLRig is handled

Hello Phil,
 "wsjt-X" and "wsjt-X Improved" are pretty well the same code base since the release of version 3 where the code was merged from what I understand, Uwe could give a better answer than me on that.

I did load FLRig onto my Raspberry Pi 4 and can see the same affliction is _not_ there under lInux (Rasp OS) when flrig is in the equation.  Would seem my problem is a windows affliction, maybe I need to load up Linux Mint on my shack PC :-)

Would still love to find an answer to this situation as not quite ready to give up on Windows yet, as too many utilities I use are windows only (Log4OM contact logging being the big one)

Can anyone comment on what the best way for me to request a feature change in HAMLIB?

I've put the hamlib-developer list back on the e-mail trail. I must have forgot to Reply-all at one stage. I am not sure where the problem lies as I have been unable to reproduce it with my set up. I would need to take this laptop upto the shack and connect it up under Windows to try and do so, but it's definitely family time this week, so it'll be a couple of days.

73 Phil.



Regards,
Peter, vk5pj


On Sun, Dec 21, 2025 at 8:19 PM gm...@bt...<mailto:gm...@bt...> <gm...@bt...<mailto:gm...@bt...>> wrote:
Hi Peter,

Sorry I don't have WSJT-X (Improved) here, just WSJT-X. Have you discussed this with the WSJT-X (Improved) team?

Phil GM3ZZA.
________________________________
From: Peter Sumner <vk...@gm...<mailto:vk...@gm...>>
Sent: 21 December 2025 3:12 AM
To: gm...@bt...<mailto:gm...@bt...> <gm...@bt...<mailto:gm...@bt...>>
Subject: Re: [Hamlib-developer] possible changes to how data from FLRig is handled

Hello Phil,
  I will have to grab one of my Raspberry PI's and try FLRIG on it with a recent HAMLIB to see what it looks like there but at present I am in the windows world for day to day operations.

My Windows setup of WSJT-X (Improved) has multiple configurations for the different Modes (FT8, WSPR, Q65 and Q65 EME). Starting WSJT-X for the first time or swapping between configs is when I see the rig control error and have to select FLRig from the list.

Regards,
Peter, vk5pj

On Sun, Dec 21, 2025 at 7:08 AM gm...@bt...<mailto:gm...@bt...> <gm...@bt...<mailto:gm...@bt...>> wrote:
Hi Peter,

I can only see what happens on Linux and I do not see the effect you write about.

I use FlRig all the time and have never seen it treated like this.

But I do have separate configurations for each rig (in WSJT-X).

73 Phil GM3ZZA
________________________________
From: Peter Sumner <vk...@gm...<mailto:vk...@gm...>>
Sent: 20 December 2025 6:59 PM
To: gm...@bt...<mailto:gm...@bt...> <gm...@bt...<mailto:gm...@bt...>>
Subject: Re: [Hamlib-developer] possible changes to how data from FLRig is handled

Hello Phil,
  I have been trying all newer releases of HAMLIB as they come along, including those shipped with WSJT-X (and improved) to check if they function any better for me but all releases newer than 4.5.4 exhibit the same trait and I am forced to copy an old "libhamlib-4.dll" into the bin folder of any new release of WSJT-X to make it work for me.  I even tried the nightly build of hamlib v5 to see what happened (same thing).

Regards,
Peter, vk5pj

On Sat, Dec 20, 2025 at 11:58 PM gm...@bt...<mailto:gm...@bt...> <gm...@bt...<mailto:gm...@bt...>> wrote:
Hi Peter,

Are these versions you are quoting hamlib? If so these are quite out of date. The latest shipped with WSJT-X (3.0-rc1) is 4.7~git 20250905. There has been significant change to the way flrig has been handled since then. Even this version is not quite correct as it changed firig to W1HKJ/FLlRig and has now been changed back to FlRig/FlRig.

I believe the latest Windows 64-bit version of hamlib is available and can just be copied over the hamlib .dll in the WSJT-X directory.

73 Phil GM3ZZA

________________________________
From: Peter Sumner <vk...@gm...<mailto:vk...@gm...>>
Sent: 20 December 2025 9:42 AM
To: ham...@li...<mailto:ham...@li...> <ham...@li...<mailto:ham...@li...>>
Subject: [Hamlib-developer] possible changes to how data from FLRig is handled

Hello,
  I have been an avid user of WSJT-X - HAMLIB - FLRig for some time now and have found that in builds after version 4.54 there were changes to flrig.c that allow hamlib to display the radio model connected to FLRig.  While this seems like a minor change, it has cascaded into this extra information being sent to software like WSJT-X that then saves this extra information in its INI file.   When WSJT-X starts up and queries HAMLIB it gets a vanilla list of rigs that show "FLRig FLRig" as it used to be in version 4.5.4 but in anything after that, the extra information bleeds through to WSJT-X once the connection is open to FLRig.

This causes WSJT-X to store the rig type as: "Rig=FLRig IC-7600(FLRig)" which does not match the value it sees at start up ("FLRig FLRig"), meaning WSJT-X shows a rig control error and the user must manually select FLRig from the list every time.

With my limited ability I have been able to identify where I think the change happened (see below).   Is there any way for this behaviour to be changed with a setting in a JSON file or even reverted to how it was in v4.5.4 ? unless there is a pressing need to have this extra information from FLRig?

/ver 4.6.5 flrig.c

    RIG_MODEL(RIG_MODEL_FLRIG),
    .model_name = "",
    .mfg_name = "FLRig",
    .version = "20250107.0",

then down quite a bit around line 870 this happens (which is not in 4.5.4)

 char model_name[256];
    snprintf(model_name,sizeof(model_name), "%.248s(%s)", value, "FLRig");
    rig->caps->model_name = strdup(model_name);
    STATE(rig)->model_name = strdup(model_name);


//ver 4.5.4 flrig.c

    RIG_MODEL(RIG_MODEL_FLRIG),
    .model_name = "FLRig",
    .mfg_name = "FLRig",
    .version = "20221109.0",

I have asked George Blatz about this but he told me he had no experience with FLRig and doubted he could be of assistance.

O/S windows 10 X64, I have no compilers and lack the experience to try and compile a private version of HAMLIB.

hoping one of the members here can help

Regards,
Peter, vk5pj

Re: [Hamlib-developer] Hamlib Error

[Daniele F. <iu...@gm...>]

Hello Heino,

> Kenwood TS-590S – CAT control HAM Office – OK; CAT control WSJT-X – not OK

> What can I do to be able to operate the Kenwood with the latest version?

I don't know this radio but from the log it seems that it is in memory
mode, does it work if you manually put it in VFO mode?

-- 
73 de IU5HKX Daniele

[Hamlib-developer] Hamlib backend file structure for large backends

[Mikael N. <mik...@fa...>]

Hello Hamlib developers!

There's been some recent discussion in Hamlib PR #1961 (see https://github.com/Hamlib/Hamlib/pull/1961) about the device backend file structure. Some backend, such as the new Yaesu FTX-1 backend have grown rather complex and with the upcoming addition of Icom network protocol support and full-featured FlexRadio backend (with audio and I/Q data streaming!) are only likely to make the backend sizes larger (these will be part of the ARDC Hamlib improvement project, also announced recently on this mailing list and in the GitHub PRs).

Traditionally, most of the backends (for a single device type - or its variants) has been placed in a single source file. However, as these files grow up to several thousand lines long - or possibly even larger, to over 10k lines - it can be argued that managing the source code becomes more difficult. Additionally, splitting backend code into logical parts might make sharing common code across similar backends easier.

As potential alternatives to single-file backends, there is already one proposal in the FTX-1 backend PR and I personally added another one.

Here are all of the 3 options that have been discussed so far:

1) Traditional, single-file backend - no matter the size of the file

2) The current PR # structure (files split in two directories): main backend files (ftx1.c and ftx1.h) + README are in rigs/yaesu directory and the rest of the files are in rigs/yaesu/ftx1 directory

3) Similar multi-file backend as in PR #1961, but all of the files (including ftx1.c, ftx1.h and README) are placed in a backend-specific subdirectory, e,.g. rigs/yaesu/ftx1.

Personally, I'd prefer option 3 - but *only* for multi-file backends.

For a single-file backend, we could still use the current convention (of not having a separate subdirectory for the backend). So as a summary, this is a question of adding subdirectory for multi-file backend. And IMO there's definitely no point in starting to convert any of the existing backends - unless changes are being made to them and they grow significantly larger.

Since there's already the FTX-1 backend PR under review that would benefit from this discussion, I think everyone would appreciate if we can make a decision reasonably quickly :)

Please share your thoughts!

73,
Mikael OH3BHX

Re: [Hamlib-developer] possible changes to how data from FLRig is handled

[<gm...@bt...>]

Hi Peter,

Are these versions you are quoting hamlib? If so these are quite out of date. The latest shipped with WSJT-X (3.0-rc1) is 4.7~git 20250905. There has been significant change to the way flrig has been handled since then. Even this version is not quite correct as it changed firig to W1HKJ/FLlRig and has now been changed back to FlRig/FlRig.

I believe the latest Windows 64-bit version of hamlib is available and can just be copied over the hamlib .dll in the WSJT-X directory.

73 Phil GM3ZZA

________________________________
From: Peter Sumner <vk...@gm...>
Sent: 20 December 2025 9:42 AM
To: ham...@li... <ham...@li...>
Subject: [Hamlib-developer] possible changes to how data from FLRig is handled

Hello,
  I have been an avid user of WSJT-X - HAMLIB - FLRig for some time now and have found that in builds after version 4.54 there were changes to flrig.c that allow hamlib to display the radio model connected to FLRig.  While this seems like a minor change, it has cascaded into this extra information being sent to software like WSJT-X that then saves this extra information in its INI file.   When WSJT-X starts up and queries HAMLIB it gets a vanilla list of rigs that show "FLRig FLRig" as it used to be in version 4.5.4 but in anything after that, the extra information bleeds through to WSJT-X once the connection is open to FLRig.

This causes WSJT-X to store the rig type as: "Rig=FLRig IC-7600(FLRig)" which does not match the value it sees at start up ("FLRig FLRig"), meaning WSJT-X shows a rig control error and the user must manually select FLRig from the list every time.

With my limited ability I have been able to identify where I think the change happened (see below).   Is there any way for this behaviour to be changed with a setting in a JSON file or even reverted to how it was in v4.5.4 ? unless there is a pressing need to have this extra information from FLRig?

/ver 4.6.5 flrig.c

    RIG_MODEL(RIG_MODEL_FLRIG),
    .model_name = "",
    .mfg_name = "FLRig",
    .version = "20250107.0",

then down quite a bit around line 870 this happens (which is not in 4.5.4)

 char model_name[256];
    snprintf(model_name,sizeof(model_name), "%.248s(%s)", value, "FLRig");
    rig->caps->model_name = strdup(model_name);
    STATE(rig)->model_name = strdup(model_name);


//ver 4.5.4 flrig.c

    RIG_MODEL(RIG_MODEL_FLRIG),
    .model_name = "FLRig",
    .mfg_name = "FLRig",
    .version = "20221109.0",

I have asked George Blatz about this but he told me he had no experience with FLRig and doubted he could be of assistance.

O/S windows 10 X64, I have no compilers and lack the experience to try and compile a private version of HAMLIB.

hoping one of the members here can help

Regards,
Peter, vk5pj

[Hamlib-developer] possible changes to how data from FLRig is handled

[Peter S. <vk...@gm...>]

Hello,
  I have been an avid user of WSJT-X - HAMLIB - FLRig for some time now and
have found that in builds after version 4.54 there were changes to flrig.c
that allow hamlib to display the radio model connected to FLRig.  While
this seems like a minor change, it has cascaded into this extra
information being sent to software like WSJT-X that then saves this extra
information in its INI file.   When WSJT-X starts up and queries HAMLIB it
gets a vanilla list of rigs that show "FLRig FLRig" as it used to be in
version 4.5.4 but in anything after that, the extra information bleeds
through to WSJT-X once the connection is open to FLRig.

This causes WSJT-X to store the rig type as: "Rig=FLRig IC-7600(FLRig)"
which does not match the value it sees at start up ("FLRig FLRig"), meaning
WSJT-X shows a rig control error and the user must manually select FLRig
from the list every time.

With my limited ability I have been able to identify where I think the
change happened (see below).   Is there any way for this behaviour to be
changed with a setting in a JSON file or even reverted to how it was in
v4.5.4 ? unless there is a pressing need to have this extra information
from FLRig?

/ver 4.6.5 flrig.c

    RIG_MODEL(RIG_MODEL_FLRIG),
    .model_name = "",
    .mfg_name = "FLRig",
    .version = "20250107.0",

then down quite a bit around line 870 this happens (which is not in 4.5.4)

 char model_name[256];
    snprintf(model_name,sizeof(model_name), "%.248s(%s)", value, "FLRig");
    rig->caps->model_name = strdup(model_name);
    STATE(rig)->model_name = strdup(model_name);


//ver 4.5.4 flrig.c

    RIG_MODEL(RIG_MODEL_FLRIG),
    .model_name = "FLRig",
    .mfg_name = "FLRig",
    .version = "20221109.0",

I have asked George Blatz about this but he told me he had no experience
with FLRig and doubted he could be of assistance.

O/S windows 10 X64, I have no compilers and lack the experience to try and
compile a private version of HAMLIB.

hoping one of the members here can help

Regards,
Peter, vk5pj

[Hamlib-developer] WSJT-X band changes crash SmartSDR

[Dr.Alexander H. <dh...@da...>]

Hi all, merry XMAS!

I've had a problem with WSJT-X using libhamlib4.dll updated to the 
newest version.

My setup:
- Windows 11 pro
- FlexRadio Flex-6500 with SmartSDR 4.1.5
- DAX and CAT 4.1.5
- MiniDeluxe to get port 7809 for HamRadioDeluxe: 
https://github.com/rickerw4pc/MiniDeluxe?tab=readme-ov-file
- WSJT-X improved 3.0.0: wsjtx-3.0.0-win64_improved_AL_PLUS_251212.exe 
<https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v3.0.0/wsjtx-3.0.0-win64_improved_AL_PLUS_251212.exe/download>
- WSJT-X setup to HamRadioDeluxe

Changing bands from WSJT-X crashes SmartSDR and the Flex-6500.
I have feedback from other OM, who have the same crash, telling me that
it was caused by a "CAT storm" and hamlib.
BTW using the specific Flex-6XXX setting and a network server causes the 
same problem.

Vy 73, Alex - DH2ID

-- 
Dr.Alexander H.Hahn
Marie-Baum-Strasse 8
76137 Karlsruhe
Mail:dh...@da...
Tel: 0721 848801
Mob: 01716242717

[Hamlib-developer] WSJT-X bandchanges crash SmartSDR

[Dr.Alexander H. <dh...@da...>]

Hi all, merry XMAS!

I've had a problem with WSJT-X using libhamlib4.dll updated to the 
newest version.

My setup:
- Windows 11 pro
- FlexRadio Flex-6500 with SmartSDR 4.1.5
- DAX and CAT 4.1.5
- MiniDeluxe to get port 7809 for HamRadioDeluxe: 
https://github.com/rickerw4pc/MiniDeluxe?tab=readme-ov-file
- WSJT-X improved 3.0.0: wsjtx-3.0.0-win64_improved_AL_PLUS_251212.exe 
<https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v3.0.0/wsjtx-3.0.0-win64_improved_AL_PLUS_251212.exe/download>
- WSJT-X setup to HamRadioDeluxe

Changing bands from WSJT-X crashes SmartSDR and the Flex-6500.
I have feedback from other OM, who have the same crash, telling me that
it was caused by a "CAT storm" and hamlib.
BTW using the specific Flex-6XXX setting and a network server causes the 
same problem.

Vy 73, Alex - DH2ID

-- 
Dr.Alexander H.Hahn
Marie-Baum-Strasse 8
76137 Karlsruhe
Mail:dh...@da...
Tel: 0721 848801
Mob: 01716242717

[Hamlib-developer] Hamlib Error

[<hi...@gm...>]

Hallo liebes WSJTX Team,

ich habe in meinem shack folgendes Gerätesetup:

 

Windows 11, WSJT-X 3.0.0-win64_improved_PLUS_251212

 

YAESU FTDX101MP – CAT Steuerung HAM Office, CAT Steuerung WSJT-X – alles OK

 

ICOM IC-9700 – CAT Steuerung HAM Office, CAT Steuerung WSJT-X – alles OK

 

Kenwood TS-590S – CAT Steuerung HAM Office – OK; CAT Steuerung WSJT-X –
nicht OK

 

Ich bekome die CAT Steuerung des TS590S an WSJT-X auf Verderb nicht hin. Die
Schnittstellen (USB und RS232 nativ) sind OK.

Mit beiden Schnittstellen kann ich z.B. die CAT Steuerung an HAM Office
bedienen.

WSJT-X gibt immer wieder eine Hamlib Error Meldung aus. Siehe Anhang.

Ich habe dann alle WSJT-X Versionen deinstalliert, und habe die WSJT-X
Version 2.7.0 installiert.

Hier konnte ich den TS590S mit der CAT Steuerung einbinden und alles
funktioniert. Ab Version 2.8.0 bekomme ich die Hamlib Error Fehlermeldungen.

Ich könnte natürlich mit der Version 2.7 arbeiten, allerdings vermisse ich
sehr die Buttons für die Bandwahl.

Was kann ich tun, um den Kenwood mit der neuesten Version betreiben zu
können?

 

English Version:

 

Hello dear WSJTX team,

I have the following device setup in my shack:

 

Windows 11, WSJT-X 3.0.0-win64_improved_PLUS_251212

 

YAESU FTDX101MP – CAT control HAM Office, CAT control WSJT-X – everything OK

 

ICOM IC-9700 – CAT control HAM Office, CAT control WSJT-X – everything OK

 

Kenwood TS-590S – CAT control HAM Office – OK; CAT control WSJT-X – not OK

 

I can't get the CAT control of the TS590S to work with WSJT-X. The
interfaces (USB and RS232 native) are OK.

I can use both interfaces to operate the CAT control on HAM Office, for
example.

WSJT-X keeps displaying a Hamlib error message. See attachment.

I then uninstalled all WSJT-X versions and installed WSJT-X version 2.7.0.

Here I was able to integrate the TS590S with the CAT control and everything
works. From version 2.8.0 onwards, I get the Hamlib error messages.

I could of course work with version 2.7, but I really miss the buttons for
band selection.

What can I do to be able to operate the Kenwood with the latest version?

 

Mit freundlichen Grüßen

Heino Tiedemann, DL2HT

Re: [Hamlib-developer] (No Subject)

[Uwe, D. <dg...@gm...>]

Hi Dave,

I can assure you that all 3.0.0 builds of WSJT-X and WSJT-X Improved 
work perfectly with the Icom IC-7300. The Hamlib driver for it also 
works without any problems.

I recommend that you revert to the latest version, which is *3.0.0 
251212* 
<https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v3.0.0/>, 
and then systematically search for the cause of the error.

As Michael already mentioned, it could be because you selected the wrong 
COM port, or because it is already blocked by another application.

Another OM who had a similar problem found that a Windows update had 
swapped the two COM port numbers for the IC-7300, so that he now had to 
select COM4 instead of COM3. Maybe you could try that too. Check the 
Windows Device Manager to see which (virtual) COM ports are created for 
your IC-7300 when you connect it via USB. Then try both in WSJT-X.

Notes:
1. The Test CAT function does not always work reliably. The best thing 
to do is to try setting both COM ports, click OK, and then restart 
WSJT-X. It is best to simply set one of the two COM ports, click “OK,” 
and restart WSJT-X. If COM3 does not work, repeat the same process with 
COM4, or whichever two ports your IC-7300 uses. One of them should work 
if you have selected the correct settings on your rig.

2. The Diagnostic Mode feature is only available for versions higher 
than 2.7. All 2.8 and 3.0 versions have this.

73 de DG2YCB,
Uwe
________________________________________
German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg...@gm...
Info: www.qrz.com/db/DG2YCB


Am 18.12.2025 um 02:31 schrieb Michael Morgan:
> That error message is saying that COM3 is already open. Do you have 
> another application connecting to your rig? And is COM3 the correct 
> serial port?
>
> On Wed, Dec 17, 2025 at 7:16 PM Amateur Radio AA4TE via 
> Hamlib-developer <ham...@li...> wrote:
>
>     Good Day,
>
>     I am following the directions found at
>     How_to_deal_with_rig_control_errors.pdf
>     <https://wsjt-x-improved.sourceforge.io/How_to_deal_with_rig_control_errors.pdf>
>
>
>     image.pngon Sourceforge.io which specically state I should alert
>     you if there's a hamlib problem. I've got my Rig set to IC-7300.
>
>     I reinstalled WSJT-X 3.0 since I couldn't uninstall it. Win11
>     didn't like it. Here's the previous Update lib error message.
>
>     image.png
>
>     The .pdf instructions state I should revert back to a file that
>     worked. Unfortunately, I have not gotten WSJT-X to work for a very
>     long time.
>
>
>     I tried to configure after reinstalling over the top of the old
>     V2.7 and am still stumped by ham lib.
>
>     Here's the error message I get when I "Test CAT"
>
>     image.png
>
>
>
>     The .pdf above stated I need to attach some .log files, but I
>     can't find any.
>
>
>
>     Dave Dahlberg AA4TE
>     Secretary, Kershaw Co. Amateur Radio Club
>     _______________________________________________
>     Hamlib-developer mailing list
>     Ham...@li...
>     https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] (No Subject)

[Michael M. <cmo...@gm...>]

That error message is saying that COM3 is already open. Do you have another
application connecting to your rig?  And is COM3 the correct serial port?

On Wed, Dec 17, 2025 at 7:16 PM Amateur Radio AA4TE via Hamlib-developer <
ham...@li...> wrote:

> Good Day,
>
> I am following the directions found at
> How_to_deal_with_rig_control_errors.pdf
> <https://wsjt-x-improved.sourceforge.io/How_to_deal_with_rig_control_errors.pdf>
>
>
> [image: image.png]on Sourceforge.io which specically state I should alert
> you if there's a hamlib problem. I've got my Rig set to IC-7300.
>
> I reinstalled WSJT-X 3.0 since I couldn't uninstall it. Win11 didn't like
> it. Here's the previous Update lib error message.
>
> [image: image.png]
>
> The .pdf instructions state I should revert back to a file that worked.
> Unfortunately, I have not gotten WSJT-X to work for a very long time.
>
>
> I tried to configure after reinstalling over the top of the old V2.7 and
> am still stumped by ham lib.
>
> Here's the error message I get when I "Test CAT"
>
> [image: image.png]
>
>
>
> The .pdf above stated I need to attach some .log files, but I can't find
> any.
>
>
>
> Dave Dahlberg AA4TE
> Secretary, Kershaw Co. Amateur Radio Club
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>

[Hamlib-developer] (No Subject)

[Amateur R. A. <aa...@aa...>]

Good Day,

I am following the directions found at [How_to_deal_with_rig_control_errors.pdf](https://wsjt-x-improved.sourceforge.io/How_to_deal_with_rig_control_errors.pdf)

[image.png]on Sourceforge.io which specically state I should alert you if there's a hamlib problem. I've got my Rig set to IC-7300.

I reinstalled WSJT-X 3.0 since I couldn't uninstall it. Win11 didn't like it. Here's the previous Update lib error message.

[image.png]

The .pdf instructions state I should revert back to a file that worked. Unfortunately, I have not gotten WSJT-X to work for a very long time.

I tried to configure after reinstalling over the top of the old V2.7 and am still stumped by ham lib.

Here's the error message I get when I "Test CAT"

[image.png]

The .pdf above stated I need to attach some .log files, but I can't find any.

Dave Dahlberg AA4TE
Secretary, Kershaw Co. Amateur Radio Club

[Hamlib-developer] [Hamlib/Hamlib] b80cfd: Update NEWS for memory leak fixes

[Nate B. <no...@gi...>]

  Branch: refs/heads/Hamlib-4.7
  Home:   https://github.com/Hamlib/Hamlib
  Commit: b80cfd34204e1034cdd6b6b4bc577f1371d4c37d
      https://github.com/Hamlib/Hamlib/commit/b80cfd34204e1034cdd6b6b4bc577f1371d4c37d
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-12-13 (Sat, 13 Dec 2025)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  Update NEWS for memory leak fixes



To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

[Hamlib-developer] [Hamlib/Hamlib] 813f21: Fix memory leak in rigctld

[GeoBaltz <no...@gi...>]

  Branch: refs/heads/Hamlib-4.7
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 813f210979ef6cf4f8ce0a33a2b37c77d10d0756
      https://github.com/Hamlib/Hamlib/commit/813f210979ef6cf4f8ce0a33a2b37c77d10d0756
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-12-13 (Sat, 13 Dec 2025)

  Changed paths:
    M tests/rigctl_parse.c
    M tests/rigctld.c

  Log Message:
  -----------
  Fix memory leak in rigctld

Just started playing with valgrind, and already We have a Winner!
rigctld was leaking ~100 bytes every 5 seconds; rearrange code so
  arg is not allocated until it is needed and will be passed to the
  routine that will free() it.
Also fix uninitialized variable warning.

(cherry picked from commit 08a013b87b07272ceadf6f4bd37251d26c7ef22a)


  Commit: b7790198465d9aad7ac90d64eeb8cb27dea9c60b
      https://github.com/Hamlib/Hamlib/commit/b7790198465d9aad7ac90d64eeb8cb27dea9c60b
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-12-13 (Sat, 13 Dec 2025)

  Changed paths:
    M tests/rigctltcp.c

  Log Message:
  -----------
  Fix the same leak in rigctltcp.c

(cherry picked from commit 018c86997b264ee0abc997f3b049105a5b8bc9a1)

Missed one

(cherry picked from commit 1cf8d03e130ebeb6553f4943a6508849911e0615)


Compare: https://github.com/Hamlib/Hamlib/compare/8488fa21ac58...b7790198465d

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

[Hamlib-developer] [Hamlib/Hamlib] 08a013: Fix memory leak in rigctld

[GeoBaltz <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 08a013b87b07272ceadf6f4bd37251d26c7ef22a
      https://github.com/Hamlib/Hamlib/commit/08a013b87b07272ceadf6f4bd37251d26c7ef22a
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-12-10 (Wed, 10 Dec 2025)

  Changed paths:
    M tests/rigctl_parse.c
    M tests/rigctld.c

  Log Message:
  -----------
  Fix memory leak in rigctld

Just started playing with valgrind, and already We have a Winner!
rigctld was leaking ~100 bytes every 5 seconds; rearrange code so
  arg is not allocated until it is needed and will be passed to the
  routine that will free() it.
Also fix uninitialized variable warning.


  Commit: 018c86997b264ee0abc997f3b049105a5b8bc9a1
      https://github.com/Hamlib/Hamlib/commit/018c86997b264ee0abc997f3b049105a5b8bc9a1
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-12-10 (Wed, 10 Dec 2025)

  Changed paths:
    M tests/rigctltcp.c

  Log Message:
  -----------
  Fix the same leak in rigctltcp.c


  Commit: 1cf8d03e130ebeb6553f4943a6508849911e0615
      https://github.com/Hamlib/Hamlib/commit/1cf8d03e130ebeb6553f4943a6508849911e0615
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-12-12 (Fri, 12 Dec 2025)

  Changed paths:
    M tests/rigctltcp.c

  Log Message:
  -----------
  Missed one


Compare: https://github.com/Hamlib/Hamlib/compare/bb39a8f73d07...1cf8d03e130e

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

[Hamlib-developer] [Hamlib/Hamlib] ed36f0: add Icom ID-52A/E Plus

[Nate B. <no...@gi...>]

  Branch: refs/heads/Hamlib-4.7
  Home:   https://github.com/Hamlib/Hamlib
  Commit: ed36f02455418bdbbbdd8cc45c3cc528ebadf3f5
      https://github.com/Hamlib/Hamlib/commit/ed36f02455418bdbbbdd8cc45c3cc528ebadf3f5
  Author: Martin <ma...@ma...>
  Date:   2025-12-10 (Wed, 10 Dec 2025)

  Changed paths:
    M include/hamlib/riglist.h
    M rigs/icom/Makefile.am
    M rigs/icom/icom.c
    M rigs/icom/icom.h
    A rigs/icom/id52plus.c

  Log Message:
  -----------
  add Icom ID-52A/E Plus

(cherry picked from commit d997bbd7b1f9057ad44fe99631f708ed15c352d6)


  Commit: 2c9257025eb33613613fe32b46f96565b886798c
      https://github.com/Hamlib/Hamlib/commit/2c9257025eb33613613fe32b46f96565b886798c
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-12-10 (Wed, 10 Dec 2025)

  Changed paths:
    M bindings/python/test_Hamlib_class.py

  Log Message:
  -----------
  Add ID52+ to Python test class

(cherry picked from commit bb39a8f73d07766925dd61b6628146983a31a3a7)


  Commit: 8488fa21ac58fd263f15c5878dc948e070928bfc
      https://github.com/Hamlib/Hamlib/commit/8488fa21ac58fd263f15c5878dc948e070928bfc
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-12-10 (Wed, 10 Dec 2025)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  Update NEWS for new ID-52A/E model


Compare: https://github.com/Hamlib/Hamlib/compare/81aff30954e7...8488fa21ac58

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

[Hamlib-developer] [Hamlib/Hamlib] d997bb: add Icom ID-52A/E Plus

[Nate B. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: d997bbd7b1f9057ad44fe99631f708ed15c352d6
      https://github.com/Hamlib/Hamlib/commit/d997bbd7b1f9057ad44fe99631f708ed15c352d6
  Author: Martin <ma...@ma...>
  Date:   2025-12-08 (Mon, 08 Dec 2025)

  Changed paths:
    M include/hamlib/riglist.h
    M rigs/icom/Makefile.am
    M rigs/icom/icom.c
    M rigs/icom/icom.h
    A rigs/icom/id52plus.c

  Log Message:
  -----------
  add Icom ID-52A/E Plus


  Commit: cb3fbbb8b859f469a7e167e575a8b6466b1d9960
      https://github.com/Hamlib/Hamlib/commit/cb3fbbb8b859f469a7e167e575a8b6466b1d9960
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-12-10 (Wed, 10 Dec 2025)

  Changed paths:
    M include/hamlib/riglist.h
    M rigs/icom/Makefile.am
    M rigs/icom/icom.c
    M rigs/icom/icom.h
    A rigs/icom/id52plus.c

  Log Message:
  -----------
  Merge GitHub PR #1960


  Commit: bb39a8f73d07766925dd61b6628146983a31a3a7
      https://github.com/Hamlib/Hamlib/commit/bb39a8f73d07766925dd61b6628146983a31a3a7
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-12-10 (Wed, 10 Dec 2025)

  Changed paths:
    M bindings/python/test_Hamlib_class.py

  Log Message:
  -----------
  Add ID52+ to Python test class


Compare: https://github.com/Hamlib/Hamlib/compare/1d7f7591d9d8...bb39a8f73d07

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications