hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] Hamlib 4.6.4 release

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

* On 2025 18 Jul 16:48 -0500, gm3zza--- via Hamlib-developer wrote:
> Has anyone got the latest incarnation to create a .dll for MSVC x64? I
> now remember why I hardly ever update my Windows version of hamlib!

Some seem to have the recipe but apparently I don't have it either...

> I've got it somewhere in my notes, but....

"A cluttered desk is the sign of a cluttered mind."


"What's an empty desk a sign of?"

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 4.6.4 release

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

Has anyone got the latest incarnation to create a .dll for MSVC x64? I now remember why I hardly ever update my Windows version of hamlib!

I've got it somewhere in my notes, but....

73 Phil GM3ZZA
________________________________
From: Nate Bargmann <n0...@n0...>
Sent: 18 July 2025 8:15 PM
To: ham...@li... <ham...@li...>
Subject: Re: [Hamlib-developer] Hamlib 4.6.4 release

I forgot to include the download links.  D'oh!

https://sourceforge.net/projects/hamlib/files/hamlib/4.6.4/

https://github.com/Hamlib/Hamlib/releases/tag/4.6.4

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 4.6.4 release

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

<div dir='auto'><div>I've found my notes. It's a job now for tomorrow. I've also got an action to test "Mike Black's update for the above"?</div><div dir="auto"><br></div><div dir="auto">Phil.<br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On 18 Jul 2025 22:27, gm...@bt... wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div style="font-family:'aptos' , 'aptos_embeddedfont' , 'aptos_msfontservice' , 'calibri' , 'helvetica' , sans-serif;font-size:12pt;color:rgb( 0 , 0 , 0 )">
Has anyone got the latest incarnation to create a .dll for MSVC x64? I now remember why I hardly ever update my Windows version of hamlib!</div>
<div style="font-family:'aptos' , 'aptos_embeddedfont' , 'aptos_msfontservice' , 'calibri' , 'helvetica' , sans-serif;font-size:12pt;color:rgb( 0 , 0 , 0 )">
<br>
</div>
<div style="font-family:'aptos' , 'aptos_embeddedfont' , 'aptos_msfontservice' , 'calibri' , 'helvetica' , sans-serif;font-size:12pt;color:rgb( 0 , 0 , 0 )">
I've got it somewhere in my notes, but....</div>
<div style="font-family:'aptos' , 'aptos_embeddedfont' , 'aptos_msfontservice' , 'calibri' , 'helvetica' , sans-serif;font-size:12pt;color:rgb( 0 , 0 , 0 )">
<br>
</div>
<div style="font-family:'aptos' , 'aptos_embeddedfont' , 'aptos_msfontservice' , 'calibri' , 'helvetica' , sans-serif;font-size:12pt;color:rgb( 0 , 0 , 0 )">
73 Phil GM3ZZA</div>
<div></div>
<hr style="display:inline-block;width:98%">
<div dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Nate Bargmann &lt;n0...@n0...&gt;<br>
<b>Sent:</b> 18 July 2025 8:15 PM<br>
<b>To:</b> ham...@li... &lt;ham...@li...&gt;<br>
<b>Subject:</b> Re: [Hamlib-developer] Hamlib 4.6.4 release</font>
<div>&nbsp;</div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>I forgot to include the download links.&nbsp; D'oh!<br>
<br>
<a href="https://sourceforge.net/projects/hamlib/files/hamlib/4.6.4/">https://sourceforge.net/projects/hamlib/files/hamlib/4.6.4/</a><br>
<br>
<a href="https://github.com/Hamlib/Hamlib/releases/tag/4.6.4">https://github.com/Hamlib/Hamlib/releases/tag/4.6.4</a><br>
<br>
73, Nate<br>
<br>
-- <br>
"The optimist proclaims that we live in the best of all<br>
possible worlds.&nbsp; The pessimist fears this is true."<br>
Web: <a href="https://www.n0nb.us">https://www.n0nb.us</a><br>
Projects: <a href="https://github.com/N0NB">https://github.com/N0NB</a><br>
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819<br>
<br>
</div>
</span></font></div>
</div>
</blockquote></div><br></div></div></div>

Re: [Hamlib-developer] Hamlib 4.6.4 release

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

I forgot to include the download links.  D'oh!

https://sourceforge.net/projects/hamlib/files/hamlib/4.6.4/

https://github.com/Hamlib/Hamlib/releases/tag/4.6.4

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] Hamlib 4.6.4 release

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

Hi All.

Realizing that today is Hamlib's 25th birthday, I thought it would be
nice to just release 4.6.4 as a present to everyone!

This is a bug fix release with no new device support.

Changes are:

Version 4.6.4
        * 2025-07-18--Hamlib's 25th birthday!!!
        * Fix handling of unprintable characters in kenwood.c that broke radios
          such as the TM-D710/TM-V71 that use EOM_TH (\r) as the command terminator.
          (TNX, Lars Kellogg-Stedman and George Baltz).
        * Fixed jrc_set_chan. (TNX Mark Fine).
        * Fix memory leak in rigctl_parse.c and use unique separator character
          for each rigctld connection--closes GitHub #1748. (TNX George Baltz).
        * Fix powerstat check for Icom R75 which rejects the command.  (TNX Mark Fine).
        * Restore TS-590S/SG RIG_LEVEL_RFPOWER_METER, Fix rotctl \dump_caps output
          (TNX, George Baltz).
        * Add CW sending capability to Flex SmartSDR.  (TNX Michael Morgan)
        * Handle spaces correctly for Fles SmartSDR.  (TNX Michael Morgan)

There may be a few more bugs that can be squashed in this branch leading
to 4.6.5, but right now that seems some time off.  Otherwise development
is moving toward the 4.7.0 release later this year.

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] [Hamlib/Hamlib]

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

  Branch: refs/tags/4.6.4
  Home:   https://github.com/Hamlib/Hamlib

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

[Hamlib-developer] [Hamlib/Hamlib] 59e3d1: Advance to Hamlib 4.6.4

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

  Branch: refs/heads/Hamlib-4.6.3
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 59e3d1b307504440837c3a5c24a15d7038e59f69
      https://github.com/Hamlib/Hamlib/commit/59e3d1b307504440837c3a5c24a15d7038e59f69
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-07-18 (Fri, 18 Jul 2025)

  Changed paths:
    M NEWS
    M configure.ac

  Log Message:
  -----------
  Advance to Hamlib 4.6.4



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

Re: [Hamlib-developer] Fwd: [WSJTX] OOB and frequency shifted on display #CAT #Cat_RigControl #frequency

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

* On 2025 14 Jul 08:29 -0500, Adrian wrote:
> Nate, However I also have this from Reino after the previous;

Still, the output from:

rigctl -m 1001 -vvvvv 

would help us immensely.

Looking at the history of ft847.c there are seven commits since the
release of 4.5.5 and 4.6.0.  It appears there are two made by Mike a
couple of weeks after 4.5.5's release that may be the culprits here:

https://github.com/Hamlib/Hamlib/commit/1f98f0d34770fd94aabc58100295bb1b525402fc
This one links to GitHub issue 1286:
https://github.com/Hamlib/Hamlib/issues/1286#issuecomment-1545971701

https://github.com/Hamlib/Hamlib/commit/1f98f0d34770fd94aabc58100295bb1b525402fc
which also links to GitHub issue 1286.

I don't have this radio to test.  There may be a real problem if there
is a serial number break that requires this "fixed" code to work
properly.  We have the situation where one that worked now doesn't and
where that didn't now apparently does.

If Reino can run the command above and get the output to the list, we
can likely get this fixed but it may be more difficult as we may need to
get the reporter of GitHub issue 1286 involved as well.

73, Nate

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

[Hamlib-developer] Happy 25th birthday, Hamlib!

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

It so happened that I looked and see that today, 18 July, is Hamlib's
official birthday.  Frank Singleton made the first commit on 2000-07-18
at 20:55 +0000.

The project has certainly evolved over that time and continues to grow
and change as needs and practices dictate.

My thanks to all contributors and testers.  This project only continues
because of your interest and effort.  Thank you!

BTW, this project is of, by, and for radio hobbyists and even amateur
astronomers who find it useful.  Here's to many more years of Hamlib
development.

73, Nate

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

Re: [Hamlib-developer] Extra functions vs. extra CHECKBUTTON levels

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

> I'm not sure if they were present on Day One from Frank or added later
> by Stephane.  The complete commit history has been preserved from the
> very first commit 25 years ago today!  You can browse it.
Wow!  Happy Birthday, Hamlib!

Re: [Hamlib-developer] Extra functions vs. extra CHECKBUTTON levels

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

* On 2025 17 Jul 13:25 -0500, Stefan Jansen wrote:
> Hi George,
> 
> Thanks for your reply. Well, I understand the concept of extra
> functions/levels/parameters in general and I see that it is a great
> possibility to access additional controls of a rig.
> 
> My question was more related especially to the CHECKBUTTON levels. As
> the type CHECKBUTTON suggests to me, these levels are more like
> something you turn on and off. So I was asking myself why CHECKBUTTON
> levels should not better be modeled as extra functions. Functions also
> have an on/off mental model behind.
> 
> And maybe as an additional question: What is the conceptual idea
> bhindd parameters? What makes them different from levels and why
> weren’t they just built into hamlib as levels?

As George notes, these are historical.

I'm not sure if they were present on Day One from Frank or added later
by Stephane.  The complete commit history has been preserved from the
very first commit 25 years ago today!  You can browse it.

There are also the mailing list archives via GMANE as noted at
https://hamlib.github.io/#mailing-list  The SourceForge archives aren't
the easiest to navigate, IMO, but exist at
https://sourceforge.net/p/hamlib/mailman/hamlib-developer/

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] Extra functions vs. extra CHECKBUTTON levels

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

Hello, Stefan

On 7/17/25 2:24 PM, Stefan Jansen wrote:
> Hi George,
>
> Thanks for your reply. Well, I understand the concept of extra 
> functions/levels/parameters in general and I see that it is a great 
> possibility to access additional controls of a rig.
>
> My question was more related especially to the CHECKBUTTON levels. As 
> the type CHECKBUTTON suggests to me, these levels are more like 
> something you turn on and off. So I was asking myself why CHECKBUTTON 
> levels should not better be modeled as extra functions. Functions also 
> have an on/off mental model behind.
>
> And maybe as an additional question: What is the conceptual idea 
> bhindd parameters? What makes them different from levels and why 
> weren’t they just built into hamlib as levels?
>
>
That question I can't answer; they were in Hamlib long before I even 
knew it existed.  If I had to guess, the answer would be flexibility 
again.  If a backend is setting only off/on values, it can model 
everything as a function.  If it is setting levels, it can model an 
oddball on/off value as a CHECKBOX level.

Remember, these operations are for tweaking unique features - they need 
as much wiggle room as the manufacturers have in designing them.

73 n3gb

> Vy 73 de Stefan, DK7STJ
>
> --
> Stefan Jansen    ***    E-Mail: DK...@da...
>
>> Am 16.07.2025 um 03:34 schrieb George Baltz <geo...@gm...>:
>>
>> Why?  Flexibility. The dummy rig has examples of the types of 
>> controls that can be implemented by any backend(i.e., the rig handler 
>> itself) for whatever reason it may have.  Those extra 
>> controls/functions/levels are meant to be as general as possible so 
>> any type of data can be passed, for whatever needs that may arise.  
>> They may be unique to a single model, or to a set of models, but they 
>> are not generally available.
>>
>> 73
>>
>> n3gb
>>
>> On 7/15/25 5:10 PM, Stefan Jansen wrote:
>>> Hi dear hamlib project team,
>>>
>>> When reviewing the output of —dump-caps of some rigs, also the dummy 
>>> rig has this, I saw that there are sometimes extra levels of type 
>>> CHECKBUTTON. Thosr can, as far as I understand, have just values 0 
>>> and 1.
>>>
>>> If the above is true, then I do not understand why someone would 
>>> implement such a 0-1-level, as there are already extra functions 
>>> that have exactly that states, namely 0 or 1, off and on.
>>>
>>> Could you please explain the idea behind having those kind of 
>>> CHECKBUTTON extra levels and not implementing them just as extra 
>>> functions?
>>>
>>>
>>> Vy 73 de Stefan, DK7STJ
>>>
>>> --
>>> Stefan Jansen    ***    E-Mail: DK...@da...
>>>
>>>
>>>
>>> _______________________________________________
>>> 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] Extra functions vs. extra CHECKBUTTON levels

[Stefan J. <DK...@da...>]

Hi George,

Thanks for your reply. Well, I understand the concept of extra functions/levels/parameters in general and I see that it is a great possibility to access additional controls of a rig.

My question was more related especially to the CHECKBUTTON levels. As the type CHECKBUTTON suggests to me, these levels are more like something you turn on and off. So I was asking myself why CHECKBUTTON levels should not better be modeled as extra functions. Functions also have an on/off mental model behind.

And maybe as an additional question: What is the conceptual idea bhindd parameters? What makes them different from levels and why weren’t they just built into hamlib as levels?


Vy 73 de Stefan, DK7STJ

--
Stefan Jansen    ***    E-Mail: DK...@da...

> Am 16.07.2025 um 03:34 schrieb George Baltz <geo...@gm...>:
> 
> Why?  Flexibility. The dummy rig has examples of the types of controls that can be implemented by any backend(i.e., the rig handler itself) for whatever reason it may have.  Those extra controls/functions/levels are meant to be as general as possible so any type of data can be passed, for whatever needs that may arise.  They may be unique to a single model, or to a set of models, but they are not generally available.
> 
> 73
> 
> n3gb
> 
> On 7/15/25 5:10 PM, Stefan Jansen wrote:
>> Hi dear hamlib project team,
>> 
>> When reviewing the output of —dump-caps of some rigs, also the dummy rig has this, I saw that there are sometimes extra levels of type CHECKBUTTON. Thosr can, as far as I understand, have just values 0 and 1.
>> 
>> If the above is true, then I do not understand why someone would implement such a 0-1-level, as there are already extra functions that have exactly that states, namely 0 or 1, off and on.
>> 
>> Could you please explain the idea behind having those kind of CHECKBUTTON extra levels and not implementing them just as extra functions?
>> 
>> 
>> Vy 73 de Stefan, DK7STJ
>> 
>> --
>> Stefan Jansen    ***    E-Mail: DK...@da...
>> 
>> 
>> 
>> _______________________________________________
>> 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] Extra functions vs. extra CHECKBUTTON levels

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

Why?  Flexibility. The dummy rig has examples of the types of controls 
that can be implemented by any backend(i.e., the rig handler itself) for 
whatever reason it may have.  Those extra controls/functions/levels are 
meant to be as general as possible so any type of data can be passed, 
for whatever needs that may arise.  They may be unique to a single 
model, or to a set of models, but they are not generally available.

73

n3gb

On 7/15/25 5:10 PM, Stefan Jansen wrote:
> Hi dear hamlib project team,
>
> When reviewing the output of —dump-caps of some rigs, also the dummy rig has this, I saw that there are sometimes extra levels of type CHECKBUTTON. Thosr can, as far as I understand, have just values 0 and 1.
>
> If the above is true, then I do not understand why someone would implement such a 0-1-level, as there are already extra functions that have exactly that states, namely 0 or 1, off and on.
>
> Could you please explain the idea behind having those kind of CHECKBUTTON extra levels and not implementing them just as extra functions?
>
>
> Vy 73 de Stefan, DK7STJ
>
> --
> Stefan Jansen    ***    E-Mail: DK...@da...
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] Extra functions vs. extra CHECKBUTTON levels

[Stefan J. <DK...@da...>]

Hi dear hamlib project team,

When reviewing the output of —dump-caps of some rigs, also the dummy rig has this, I saw that there are sometimes extra levels of type CHECKBUTTON. Thosr can, as far as I understand, have just values 0 and 1. 

If the above is true, then I do not understand why someone would implement such a 0-1-level, as there are already extra functions that have exactly that states, namely 0 or 1, off and on. 

Could you please explain the idea behind having those kind of CHECKBUTTON extra levels and not implementing them just as extra functions?


Vy 73 de Stefan, DK7STJ

--
Stefan Jansen    ***    E-Mail: DK...@da...

[Hamlib-developer] [Hamlib/Hamlib] 5c06f6: Update gs232.c

[Michael M. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 5c06f66aa831c586bf4504007289675cb5e148ff
      https://github.com/Hamlib/Hamlib/commit/5c06f66aa831c586bf4504007289675cb5e148ff
  Author: Michael Morgan <844...@us...>
  Date:   2025-07-15 (Tue, 15 Jul 2025)

  Changed paths:
    M rotators/gs232a/gs232.c

  Log Message:
  -----------
  Update gs232.c

I don't use that so I added a line to void it to suppress the warning.  Hope that is ok.



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

Re: [Hamlib-developer] Fwd: [WSJTX] OOB and frequency shifted on display #CAT #Cat_RigControl #frequency

[Adrian <vk...@gm...>]

Nate, However I also have this from Reino after the previous;

_
Reino 
Talarmo_<https://wsjtx.groups.io/g/main/topic/oob_and_frequency_shifted_on/113834442?page=2#>
Jul 11#56511 // <https://wsjtx.groups.io/g/main/message/56511>

I answer myself: a bit more information about the system, where the 
hamlib to version 4.5.5.5 is working, but Hamlib Version 4.6.1 is 
generating the OOB after some time. Setup consists of a Yaesu FT-847 and 
a Mag Loop Controller by TF3LJ / VE2LJX using USB serial CAT with CAT 
pass-through. OS either Windows 10 or 11 and WSJT-X v2.7.0 as far as I know.


73


vk4tux


On 14/7/25 22:17, Nate Bargmann wrote:
> * On 2025 07 Jul 05:35 -0500, Adrian wrote:
>> Developers, FYI concerning an issue with FT-847 selection in wsjtx, which is
>> problematic, vs fine operation in MSHV, which does not use hamlib.
> So far no one has shown a bug we can fix.  I'll hold off on 4.6.4 one
> more day and if no reply I am going to release it.
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Fwd: [WSJTX] OOB and frequency shifted on display #CAT #Cat_RigControl #frequency

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

* On 2025 07 Jul 05:35 -0500, Adrian wrote:
> Developers, FYI concerning an issue with FT-847 selection in wsjtx, which is
> problematic, vs fine operation in MSHV, which does not use hamlib.

So far no one has shown a bug we can fix.  I'll hold off on 4.6.4 one
more day and if no reply I am going to release it.

73, Nate

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

[Hamlib-developer] [Hamlib/Hamlib] 02179e: Basic infrastructure for moving internal structure...

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 02179e0a93d7eeea9214ed7dcbdb52d7e94364d3
      https://github.com/Hamlib/Hamlib/commit/02179e0a93d7eeea9214ed7dcbdb52d7e94364d3
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-07-10 (Thu, 10 Jul 2025)

  Changed paths:
    M include/Makefile.am
    A include/hamlib/amp_state.h
    A include/hamlib/port.h
    A include/hamlib/rig_state.h
    A include/hamlib/rot_state.h

  Log Message:
  -----------
  Basic infrastructure for moving internal structures out of rig.h

Create breakout files, add them to Makefile.am manifest.


  Commit: 0148378ed9adb70c9342542e11c0bb03370298e5
      https://github.com/Hamlib/Hamlib/commit/0148378ed9adb70c9342542e11c0bb03370298e5
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-07-10 (Thu, 10 Jul 2025)

  Changed paths:
    M src/amp_conf.c
    M src/amp_settings.c
    M src/amplifier.c
    M src/cache.c
    M src/conf.c
    M src/event.c
    M src/mem.c
    M src/misc.c
    M src/multicast.c
    M src/network.c
    M src/rig.c
    M src/rot_conf.c
    M src/rot_settings.c
    M src/rotator.c
    M src/serial.c
    M src/settings.c
    M src/snapshot_data.c
    M src/tones.c

  Log Message:
  -----------
  Add needed new includes in src/*.c


  Commit: 1efaacb5ab5a8856fe56ad0cc197504906beebd9
      https://github.com/Hamlib/Hamlib/commit/1efaacb5ab5a8856fe56ad0cc197504906beebd9
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-07-10 (Thu, 10 Jul 2025)

  Changed paths:
    M include/hamlib/port.h
    M include/hamlib/rig.h
    M tests/example.c

  Log Message:
  -----------
  Move port definition(s) to include/hamlib/port.h

Add some ghost structs and typedefs
Make example.c compile on gcc15 and with new includes


  Commit: f03fefe1cd1028310bb63d482e538808ddd40938
      https://github.com/Hamlib/Hamlib/commit/f03fefe1cd1028310bb63d482e538808ddd40938
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-07-10 (Thu, 10 Jul 2025)

  Changed paths:
    M include/hamlib/rig.h
    M include/hamlib/rig_state.h

  Log Message:
  -----------
  Move rig_state definition(s) from rig.h to include/hamlib/rig_state.h

Compiling with NO_OLD_INCLUDES still won't work until the state
  structure(s) are moved out of rig_struct, but at least I get the
  right compiler errors.


  Commit: cc4b1ce7db096309d36f0381d93152f35901e8f0
      https://github.com/Hamlib/Hamlib/commit/cc4b1ce7db096309d36f0381d93152f35901e8f0
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-07-10 (Thu, 10 Jul 2025)

  Changed paths:
    M include/hamlib/amp_state.h
    M include/hamlib/amplifier.h
    M include/hamlib/rig.h

  Log Message:
  -----------
  Move amp_state definition to include/hamlib/amp_state.h


  Commit: 9991f46e58b937e6034f26245d6d1ab60cb7eff5
      https://github.com/Hamlib/Hamlib/commit/9991f46e58b937e6034f26245d6d1ab60cb7eff5
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-07-10 (Thu, 10 Jul 2025)

  Changed paths:
    M include/hamlib/rig.h
    M include/hamlib/rot_state.h
    M include/hamlib/rotator.h

  Log Message:
  -----------
  Move rotator state definition to include/hamlib/rot_state.h


  Commit: 213e7751bf751d69111fe6bdc722f9ec73a93a71
      https://github.com/Hamlib/Hamlib/commit/213e7751bf751d69111fe6bdc722f9ec73a93a71
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-07-10 (Thu, 10 Jul 2025)

  Changed paths:
    M rotators/amsat/if100.c
    M rotators/androidsensor/androidsensor.cpp
    M rotators/apex/apex.c
    M rotators/apex/sharedloop.c
    M rotators/ars/ars.c
    M rotators/celestron/celestron.c
    M rotators/easycomm/easycomm.c
    M rotators/ether6/ether6.c
    M rotators/flir/flir.c
    M rotators/fodtrack/fodtrack.c
    M rotators/grbltrk/grbltrk.c
    M rotators/gs232a/gs232.c
    M rotators/gs232a/gs232a.c
    M rotators/gs232a/gs232b.c
    M rotators/heathkit/hd1780.c
    M rotators/ioptron/rot_ioptron.c
    M rotators/m2/rc2800.c
    M rotators/meade/meade.c
    M rotators/prosistel/prosistel.c
    M rotators/radant/radant.c
    M rotators/rotorez/rotorez.c
    M rotators/saebrtrack/saebrtrack.c
    M rotators/sartek/sartek.c
    M rotators/satel/satel.c
    M rotators/skywatcher/skywatcher.c
    M rotators/spid/spid.c
    M rotators/ts7400/ts7400.c

  Log Message:
  -----------
  Add needed includes of new files to rotators/*/*


  Commit: e90cc5fb0ecf2bdbf3b5468e3bad73e7546e2b12
      https://github.com/Hamlib/Hamlib/commit/e90cc5fb0ecf2bdbf3b5468e3bad73e7546e2b12
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-07-10 (Thu, 10 Jul 2025)

  Changed paths:
    M amplifiers/elecraft/kpa.c
    M amplifiers/elecraft/kpa1500.c
    M amplifiers/expert/expert.c
    M amplifiers/gemini/dx1200.c
    M amplifiers/gemini/gemini.c

  Log Message:
  -----------
  Add includes to amplifiers/*/*.c


  Commit: 80cfadadb0e63555dd4ace00a4b6326da86976db
      https://github.com/Hamlib/Hamlib/commit/80cfadadb0e63555dd4ace00a4b6326da86976db
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-07-10 (Thu, 10 Jul 2025)

  Changed paths:
    M include/hamlib/amp_state.h
    M include/hamlib/port.h
    M include/hamlib/rig_state.h
    M include/hamlib/rot_state.h

  Log Message:
  -----------
  Update copyright lines


  Commit: f3e9a859ed22c7e5362eccb4fe93ef971ea15a02
      https://github.com/Hamlib/Hamlib/commit/f3e9a859ed22c7e5362eccb4fe93ef971ea15a02
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-07-10 (Thu, 10 Jul 2025)

  Changed paths:
    M amplifiers/elecraft/kpa1500.c
    M amplifiers/gemini/dx1200.c
    M include/hamlib/port.h
    M include/hamlib/rig.h
    M rotators/amsat/if100.c
    M rotators/apex/apex.c
    M rotators/apex/sharedloop.c
    M rotators/ars/ars.c
    M rotators/easycomm/easycomm.c
    M rotators/ether6/ether6.c
    M rotators/fodtrack/fodtrack.c
    M rotators/ioptron/rot_ioptron.c
    M rotators/radant/radant.c
    M rotators/saebrtrack/saebrtrack.c
    M rotators/satel/satel.c
    M src/gpio.c
    M src/iofunc.c
    M src/network.c
    M src/parallel.c
    M src/usb_port.c

  Log Message:
  -----------
  Move ???PORT() macro definitions back to rig.h

Many (most?) of the uses of the port structures in Hamlib are to pass through
  to the basic I/O routines (rig_flush(), write_block(), read_string()),
  without referencing any of the structure data.  Don't bother including
  port.h if it won't be used.

The ???PORT macros are independent of actual hamlib_port_t data use.


  Commit: 3952f030d4e3f0c394a47b0214777ef4ed4cd266
      https://github.com/Hamlib/Hamlib/commit/3952f030d4e3f0c394a47b0214777ef4ed4cd266
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-07-11 (Fri, 11 Jul 2025)

  Changed paths:
    M include/hamlib/amp_state.h
    M include/hamlib/port.h
    M include/hamlib/rig_state.h
    M include/hamlib/rot_state.h
    M simulators/simts890.c

  Log Message:
  -----------
  More copyright updates


  Commit: b8c1d80626bc2cc0a8537d748aa490adff3a61bf
      https://github.com/Hamlib/Hamlib/commit/b8c1d80626bc2cc0a8537d748aa490adff3a61bf
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-07-11 (Fri, 11 Jul 2025)

  Changed paths:
    M bindings/python/test_Hamlib_class.py

  Log Message:
  -----------
  Add required noise


  Commit: 3f7c18eb52bb2cdcbf4a1ef5abbdf73ddeae96bd
      https://github.com/Hamlib/Hamlib/commit/3f7c18eb52bb2cdcbf4a1ef5abbdf73ddeae96bd
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-07-14 (Mon, 14 Jul 2025)

  Changed paths:
    M amplifiers/elecraft/kpa.c
    M amplifiers/expert/expert.c
    M amplifiers/gemini/dx1200.c
    M amplifiers/gemini/gemini.c
    M bindings/python/test_Hamlib_class.py
    M include/Makefile.am
    A include/hamlib/amp_state.h
    M include/hamlib/amplifier.h
    A include/hamlib/port.h
    M include/hamlib/rig.h
    A include/hamlib/rig_state.h
    A include/hamlib/rot_state.h
    M include/hamlib/rotator.h
    M rotators/amsat/if100.c
    M rotators/androidsensor/androidsensor.cpp
    M rotators/ars/ars.c
    M rotators/celestron/celestron.c
    M rotators/easycomm/easycomm.c
    M rotators/ether6/ether6.c
    M rotators/flir/flir.c
    M rotators/fodtrack/fodtrack.c
    M rotators/grbltrk/grbltrk.c
    M rotators/gs232a/gs232.c
    M rotators/gs232a/gs232a.c
    M rotators/gs232a/gs232b.c
    M rotators/heathkit/hd1780.c
    M rotators/m2/rc2800.c
    M rotators/meade/meade.c
    M rotators/prosistel/prosistel.c
    M rotators/rotorez/rotorez.c
    M rotators/sartek/sartek.c
    M rotators/skywatcher/skywatcher.c
    M rotators/spid/spid.c
    M rotators/ts7400/ts7400.c
    M simulators/simts890.c
    M src/amp_conf.c
    M src/amp_settings.c
    M src/amplifier.c
    M src/cache.c
    M src/conf.c
    M src/event.c
    M src/gpio.c
    M src/iofunc.c
    M src/mem.c
    M src/misc.c
    M src/multicast.c
    M src/network.c
    M src/parallel.c
    M src/rig.c
    M src/rot_conf.c
    M src/rot_settings.c
    M src/rotator.c
    M src/serial.c
    M src/settings.c
    M src/snapshot_data.c
    M src/tones.c
    M src/usb_port.c
    M tests/example.c

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


Compare: https://github.com/Hamlib/Hamlib/compare/79c812ff4db8...3f7c18eb52bb

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

[Hamlib-developer] [Hamlib/Hamlib] 69d203: Add FTX-1 radio support to Hamlib

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 69d203fd1c2e209cda74a000977cc0b7464dc43a
      https://github.com/Hamlib/Hamlib/commit/69d203fd1c2e209cda74a000977cc0b7464dc43a
  Author: jeremybox <gi...@je...>
  Date:   2025-07-11 (Fri, 11 Jul 2025)

  Changed paths:
    M include/hamlib/riglist.h
    M rigs/yaesu/Makefile.am
    A rigs/yaesu/ftx1.c
    A rigs/yaesu/ftx1.h
    M rigs/yaesu/newcat.c
    M rigs/yaesu/yaesu.c
    M rigs/yaesu/yaesu.h

  Log Message:
  -----------
  Add FTX-1 radio support to Hamlib

- Add FTX-1 rig model (ID 840) to riglist.h
- Create ftx1.c and ftx1.h with FTX-1 implementation
- Add FTX-1 to Yaesu Makefile.am
- Integrate FTX-1 into newcat.c command validation system
- Update yaesu.c and yaesu.h for FTX-1 support
- Based on FT-991A CAT protocol compatibility


  Commit: 7ce9d60aa68af334bc680a42a28ca5194d71ecde
      https://github.com/Hamlib/Hamlib/commit/7ce9d60aa68af334bc680a42a28ca5194d71ecde
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-07-14 (Mon, 14 Jul 2025)

  Changed paths:
    M include/hamlib/riglist.h
    M rigs/yaesu/Makefile.am
    A rigs/yaesu/ftx1.c
    A rigs/yaesu/ftx1.h
    M rigs/yaesu/newcat.c
    M rigs/yaesu/yaesu.c
    M rigs/yaesu/yaesu.h

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


  Commit: 79c812ff4db84d44eca7414aa4f2f5f81f7ce3e1
      https://github.com/Hamlib/Hamlib/commit/79c812ff4db84d44eca7414aa4f2f5f81f7ce3e1
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-07-14 (Mon, 14 Jul 2025)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  Update NEWS for FTX-1 new model support


Compare: https://github.com/Hamlib/Hamlib/compare/0db57035d508...79c812ff4db8

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

Re: [Hamlib-developer] hamlib and THD74

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

Yes, it is currently broken in hamlib-4.6.3.  You can use the current 
daily build of Hamlib, or wait until 4.6.4 is released. See 
https://github.com/Hamlib/Hamlib/issues/1767

On 7/12/25 7:14 PM, Daniel Boggiano via Hamlib-developer wrote:
> Hello, I am trying to use hamlib and a THD74 and a microsoft surface 
> computer. Bluetooth and the computer works fine with the 74 but not 
> when i use hamlib with the command line. Winlink and yaac work fine as 
> well as hamlib and fldigi. When I use hamlib from the command line it 
> connects bluetooth mementarilly and then quits immediately.
>
> I ran in -vvvv modeto get this information and am passing it to you. 
> If there is anything else I can do to help, please let me know.
>
> FYI, I am an appliance operator so you'd need to speak to me in very 
> simple language.
>
> Thank you
> Danny
>
>
> Report bugs to <ham...@li...>.
>
> c:\Program Files\hamlib-w64-4.6.3\bin>rigctl -m 2042 -r COM9 -vvvv
> rigctl.c(532) Startup: rigctl -m 2042 -r COM9 -vvvv
> rigctl Hamlib 4.6.3 2025-06-10T00:52:44Z SHA=371db9 64-bit
> Report bugs to <ham...@li...>
>
> rig_test_2038: MSVCRT 2038 test = 0xf0000000:Mon Aug 05 05:04:00 2097
> rig_init: 2038 time test passed
> rig_init: rig_model=Kenwood TH-D74 20250515.3
> rig_init: rig has VFO_A
> rig_init: rig has VFO_B
> kenwood_init called, version 20250515/20250515.3
> kenwood.c(899):kenwood_init returning2(0)
> rig_set_conf called
> rig_confparam_lookup called for rig_pathname
> rig_set_conf: rig_pathname='COM9'
> rig.c(970):rig_open entered
> serial_open: serial port COM9 is OK
> serial_open: COM9
> rig_open: 00000000027d744c rs->comm_state==1?=1
> *1:kenwood.c(921):kenwood_open entered
> **2:kenwood.c(1206):kenwood_get_id entered
> kenwood_transaction called cmd=ID
> kenwood_transaction: Command is not correctly terminated 'ID TH-D74'
> kenwood.c(713):kenwood_transaction returning2(-8) Protocol error
>
> **2:kenwood.c(1213):kenwood_get_id returning(-8) Protocol error
>
> **2:kenwood.c(1206):kenwood_get_id entered
> kenwood_transaction called cmd=ID
> kenwood_transaction: Command is not correctly terminated 'ID TH-D74'
> kenwood.c(713):kenwood_transaction returning2(-8) Protocol error
>
> **2:kenwood.c(1213):kenwood_get_id returning(-8) Protocol error
>
> kenwood_open: no response to get_id from rig...continuing anyway
> kenwood_open: cannot get identification
> *1:kenwood.c(1051):kenwood_open returning(-8) Protocol error
>
> ser_close: restoring options
> rig.c(1479):rig_open returning2(-8) Protocol error
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] hamlib and THD74

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

Daniel wrote:

> Hello, I am trying to use hamlib and a THD74 and a microsoft surface computer. Bluetooth and the computer works fine with the 74
> but not when i use hamlib with the command line. Winlink and yaac work fine as well as hamlib and fldigi.

what are the Hamlib versions used by the software that work?
I mean the version of libhamlib-4.dll that can be found from the
Properties of the file in the Details page

--
73 de IU5HKX Daniele

[Hamlib-developer] hamlib and THD74

[Daniel B. <kd...@ic...>]

Hello, I am trying to use hamlib and a THD74 and a microsoft surface computer. Bluetooth and the computer works fine with the 74 but not when i use hamlib with the command line. Winlink and yaac work fine as well as hamlib and fldigi. When I use hamlib from the command line it connects bluetooth mementarilly and then quits immediately. I ran in -vvvv modeto get this information and am passing it to you. If there is anything else I can do to help, please let me know. FYI, I am an appliance operator so you'd need to speak to me in very simple language. Thank you Danny Report bugs to < ham...@li... >. c:\Program Files\hamlib-w64-4.6.3\bin>rigctl -m 2042 -r COM9 -vvvv rigctl.c(532) Startup: rigctl -m 2042 -r COM9 -vvvv rigctl Hamlib 4.6.3 2025-06-10T00:52:44Z SHA=371db9 64-bit Report bugs to < ham...@li... > rig_test_2038: MSVCRT 2038 test = 0xf0000000:Mon Aug 05 05:04:00 2097 rig_init: 2038 time test passed rig_init: rig_model=Kenwood TH-D74 20250515.3 rig_init: rig has VFO_A rig_init: rig has VFO_B kenwood_init called, version 20250515/20250515.3 kenwood.c(899):kenwood_init returning2(0) rig_set_conf called rig_confparam_lookup called for rig_pathname rig_set_conf: rig_pathname='COM9' rig.c(970):rig_open entered serial_open: serial port COM9 is OK serial_open: COM9 rig_open: 00000000027d744c rs->comm_state==1?=1 *1:kenwood.c(921):kenwood_open entered **2:kenwood.c(1206):kenwood_get_id entered kenwood_transaction called cmd=ID kenwood_transaction: Command is not correctly terminated 'ID TH-D74' kenwood.c(713):kenwood_transaction returning2(-8) Protocol error **2:kenwood.c(1213):kenwood_get_id returning(-8) Protocol error **2:kenwood.c(1206):kenwood_get_id entered kenwood_transaction called cmd=ID kenwood_transaction: Command is not correctly terminated 'ID TH-D74' kenwood.c(713):kenwood_transaction returning2(-8) Protocol error **2:kenwood.c(1213):kenwood_get_id returning(-8) Protocol error kenwood_open: no response to get_id from rig...continuing anyway kenwood_open: cannot get identification *1:kenwood.c(1051):kenwood_open returning(-8) Protocol error ser_close: restoring options rig.c(1479):rig_open returning2(-8) Protocol error

Re: [Hamlib-developer] Who's copyright on new files?

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

I agree with the general ideas stated by NAte, however the LICENSE
file differs because it says:
"The 'AUTHORS' file lists contributors known as the The Hamlib Group."

"The frontend library source code files and associated backend library
source code files are licensed and released under the Lesser GNU Public
License (LGPL)"

"Various other supplied program source files and example source files are
licensed and released under the GNU Public License (GPL)"

Since the simulators aren't frontend code I think that they are under the GPL.
This doesn't prevent individual files or directories from having
different licenses.

I think that the examples being under the GPL is strange because the
LGPL allows linking to closed source software, while I think that the
GPL is appropriate for rigctl and similar.

The tests that I have written are so basic that I didn't think of
adding a license, but I think that they are part of the backend so
they may fall under the LGPL.

-- 
73 de IU5HKX Daniele

[Hamlib-developer] [Hamlib/Hamlib] 0db570: Update NEWS for AF6SA WRC rotator backend

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 0db57035d50880893305d45ef5adbd538f0c401e
      https://github.com/Hamlib/Hamlib/commit/0db57035d50880893305d45ef5adbd538f0c401e
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-07-09 (Wed, 09 Jul 2025)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  Update NEWS for AF6SA WRC rotator backend



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