hamlib-developer — hamlib developers forum

[Hamlib-developer] [Hamlib/Hamlib] 65be24: Don't re-compute (twice!) the length of the verify...

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 65be240130abab7d095cc1d2e31043d66d775f79
      https://github.com/Hamlib/Hamlib/commit/65be240130abab7d095cc1d2e31043d66d775f79
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-11-08 (Sat, 08 Nov 2025)

  Changed paths:
    M rigs/kenwood/ic10.c
    M rigs/kenwood/kenwood.c
    M rigs/kenwood/kenwood.h
    M rigs/kenwood/thd72.c
    M rigs/kenwood/thd74.c

  Log Message:
  -----------
  Don't re-compute (twice!) the length of the verify command every time through
kenwood_transaction(), when it doesn't change after kenwood_open().

Remove redundant memset()


  Commit: acd4e6031eb5ee61c99dc56e9d914b4e1d3ccc37
      https://github.com/Hamlib/Hamlib/commit/acd4e6031eb5ee61c99dc56e9d914b4e1d3ccc37
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-11-08 (Sat, 08 Nov 2025)

  Changed paths:
    M rigs/barrett/4100.c

  Log Message:
  -----------
  Remove (infinite) recursive call to rig_close()


  Commit: 0bf9d6255bda68ebef4914c58baa15d0dd7a9021
      https://github.com/Hamlib/Hamlib/commit/0bf9d6255bda68ebef4914c58baa15d0dd7a9021
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-11-09 (Sun, 09 Nov 2025)

  Changed paths:
    M rigs/barrett/4100.c
    M rigs/mds/9710.c

  Log Message:
  -----------
  Fix some typos

Use the correct VFO param instead of modes
Gets rid of a couple of very weird VFO entries.


  Commit: 6a89902b3501a788263b6133245582ce5609fe18
      https://github.com/Hamlib/Hamlib/commit/6a89902b3501a788263b6133245582ce5609fe18
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-11-10 (Mon, 10 Nov 2025)

  Changed paths:
    M rigs/icom/ic820h.c

  Log Message:
  -----------
  Fix vfo name for IC-820H

Dunno about the FIXME: on the next line, but the IC-820H definitely
  doesn't have a VFO C.


Compare: https://github.com/Hamlib/Hamlib/compare/55feb026fa0d...6a89902b3501

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

[Hamlib-developer] wsjtx bricht mit rig control error immer ab

[Dieter S. <die...@gm...>]

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virenfrei.www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [Hamlib-developer] IC-706MKIIG and PTT

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

Try

  -C rts_state=OFF

73


vk4tux

On 12/11/25 23:22, Pino Zollo wrote:
> Please help !
>
> Sending the command:
>
> /usr/local/bin/rigctld  -m 3011 -c 0x58 -s 9600  -r /dev/ttyS0 -p 
> /dev/ttyS0    -vvvv
>
> the PTT is activated ....it is on RTS on the same ttyS0.
>
> Is there a way to avoid it ?
>
> I have tested with   -P NONE....   -P RTS but no change
>
> Thanks
>
> Pino ZP4KFX
>
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] IC-706MKIIG and PTT

[Pino Z. <pin...@gm...>]

Please help !

Sending the command:

/usr/local/bin/rigctld  -m 3011 -c 0x58 -s 9600  -r /dev/ttyS0 -p 
/dev/ttyS0    -vvvv

the PTT is activated ....it is on RTS on the same ttyS0.

Is there a way to avoid it ?

I have tested with   -P NONE....   -P RTS but no change

Thanks

Pino ZP4KFX

Re: [Hamlib-developer] Rig Control Error

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

Well, theoretically yes. At the time, I programmed the “Diagnostic mode” 
in a way that it simply automates all the steps that would otherwise 
have to be performed manually, i.e., writing a wsjtx_log_config.ini file 
with the correct content, copying it to the right location, and so on. 
It is also programmed so that this file is automatically reset to its 
default content afterwards, as many OMs forgot to do this when 
performing the manual procedure, which then quickly led to huge amounts 
of data accumulating on the hard drive.

What we could possibly do is query and log the available COM ports and 
audio sources/sinks in the second debug log file (i.e., in 
wsjtx_syslog.log).

The question is always how user-friendly (or perhaps better, how 
foolproof) we want to make our programs. Joe's concept for WSJT-X (or 
QMAP or MAP65) has always been that it's all intended for experts. 
Specifically, that OMs (or YLs) should be encouraged to take the time to 
learn how it all works, because that's the only way operators can truly 
understand what they're doing. And basically, I agree with Joe. However, 
experience has shown that many users are not even capable of operating 
their computers properly. Frankly, I have never understood why even OMs 
who have spent a lot of money and time on highly complex equipment for 
EME operation sometimes have difficulty installing a new version of 
WSJT-X (Improved). But that's just the way it is. I think this may also 
be due to the fact that many OMs have now reached a certain God-blessed age.

That's why I had already incorporated a whole host of features into my 
“improved PLUS edition” that make everything more user-friendly. I will 
continue along this path. But everything has its limits. A basic 
understanding of hardware and software is essential if someone wants to 
engage in digital modes. I mean, fishing is also a nice hobby, hi. 
However, FT8 has now become something of a mass market. This has also 
attracted many “plug-in radio amateurs” (= "Steckdosen-Amateure") as we 
say here in DL.

But what often makes things very difficult for users are those annoying 
Windows updates. There, serious changes (drivers no longer accepted, 
etc.) are often made without informing the user accordingly. But let's 
be honest, it's not much better with Linux and macOS. Just think of the 
new hurdles that Tahoe has brought. And on my various Linux systems, 
I've often had to completely restore the system because yet another 
update had messed something.

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


Am 11.11.2025 um 17:10 schrieb Michael Morgan:
> Hey Uwe - would it make sense for the diagnostic mode when it starts 
> to maybe iterate the available serial ports.  So instances like this 
> would be easy for us to know what ports are available?
>
> 73,  Michael, AA5SH
>
> On Tue, Nov 11, 2025 at 9:35 AM Dave Baxter via Hamlib-developer 
> <ham...@li...> wrote:
>
>     Just a thought.
>
>     Does COM3 actually exist, and is it actually the rig?
>
>     (Windows can re-enumerate ports as things are connected/removed,
>     or when coming out of a sleep state, so sometimes what was on
>     "COMx" is now on "COMy" !   There are ways to nail things down to
>     stop that, but you then have to be very careful to reconnect
>     things to the same physical USB port on the PC.   Put a Hub in the
>     mix, and it gets very complicated very fast!)
>
>     Is the rig connected by native USB, or via a common USB-Serial /
>     CI-V adapter?   Many of such will have their drivers blocked by
>     Windows, as there are hoards of fake chipsets out there used for
>     such things, even FTDI look-alikes!
>
>     If a native USB connection, what does Windows Device Manager say
>     about it?
>
>     Does any other software (Icom specific for the rig for example?)
>     work OK with the radio?   If not, are the correct drivers installed?
>
>     Also, does the rig have CI-V "Trancieve" enabled?   If so, try
>     with that disabled.  (Though I think later Hamlib instances would
>     disable that automagically if it was detected.)
>
>     Just idle thoughts, based on experiences with that OS and COM
>     ports in the past work life, where we often had multiple USB and
>     serial connected instrumentation "things" at the same time. 
>      Sometimes, Windows going to sleep, and then coming out of that,
>     the Universe would implode, as various pieces of software suddenly
>     lost sight of what they expected.
>
>     That was true from Windows XP through Windows 10.   Glad I have
>     nothing to do with that OS any more!.
>
>     73.
>
>     Dave G8KBV.
>
>
>     On 11/11/2025 14:09, prb...@gm... wrote:
>>
>>     Hi Uwe
>>
>>     Thanks for your help, I apologise if I appear to be making it
>>     complicated.
>>
>>     I have downloaded V3.0 as you said and this time the Hamlib
>>     update button worked, but still the same error with no comms to
>>     the rig.
>>
>>     I have set the diagnose mode and shut the program, then restarted
>>     it and closed it again.
>>
>>     I have found the attached 2 log files from the desktop, is this
>>     what you required ?
>>
>>     Thanks again
>>
>>     Regards
>>
>>     Peter
>>
>>     73
>>
>>     M7PTS
>>
>>     *From:*Uwe, DG2YCB <dg...@gm...> <mailto:dg...@gm...>
>>     *Sent:* 10 November 2025 13:49
>>     *To:* Peter Bearne <prb...@gm...>
>>     <mailto:prb...@gm...>; Hamlib Developers
>>     <ham...@li...>
>>     <mailto:ham...@li...>
>>     *Subject:* Re: [Hamlib-developer] Rig Control Error
>>
>>     Sorry, I meant, of course: Follow the instructions (= restart
>>     *the program*, reproduce the error for a few seconds and close
>>     the program again)
>>
>>
>>     73 de DG2YCB,
>>     Uwe
>>     ________________________________________
>>     German Amateur Radio Station DG2YCB
>>     Dr. Uwe Risse
>>     eMail: dg...@gm...
>>     Info: www.qrz.com/db/DG2YCB <http://www.qrz.com/db/DG2YCB>
>>
>>     Am 10.11.2025 um 14:45 schrieb Uwe, DG2YCB via Hamlib-developer:
>>
>>         Follow the instructions (= restart your computer, reproduce
>>         the error for a few seconds and close the program again)
>>
>>
>>
>>     _______________________________________________
>>     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
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Rig Control Error

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

The RigControl log shows no communication with the rig, which probably 
means a config error.

Do you have the "official" Icom USB driver installed in the PC? Make 
sure to follow the installation instructions carefully; Windows is 
finicky about that.

Look at the device manager list before and after connecting the cable to 
see what materializes. That name may change, depending on a lot of factors.

73 n3gb


On 11/11/25 9:09 AM, prb...@gm... wrote:
>
> Hi Uwe
>
> Thanks for your help, I apologise if I appear to be making it complicated.
>
> I have downloaded V3.0 as you said and this time the Hamlib update 
> button worked, but still the same error with no comms to the rig.
>
> I have set the diagnose mode and shut the program, then restarted it 
> and closed it again.
>
> I have found the attached 2 log files from the desktop, is this what 
> you required ?
>
> Thanks again
>
> Regards
>
> Peter
>
> 73
>
> M7PTS
>
> *From:*Uwe, DG2YCB <dg...@gm...>
> *Sent:* 10 November 2025 13:49
> *To:* Peter Bearne <prb...@gm...>; Hamlib Developers 
> <ham...@li...>
> *Subject:* Re: [Hamlib-developer] Rig Control Error
>
> Sorry, I meant, of course: Follow the instructions (= restart *the 
> program*, reproduce the error for a few seconds and close the program 
> again)
>
>
> 73 de DG2YCB,
> Uwe
> ________________________________________
> German Amateur Radio Station DG2YCB
> Dr. Uwe Risse
> eMail: dg...@gm...
> Info: www.qrz.com/db/DG2YCB <http://www.qrz.com/db/DG2YCB>
>
> Am 10.11.2025 um 14:45 schrieb Uwe, DG2YCB via Hamlib-developer:
>
>     Follow the instructions (= restart your computer, reproduce the
>     error for a few seconds and close the program again)
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Rig Control Error

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

Hey Uwe - would it make sense for the diagnostic mode when it starts to
maybe iterate the available serial ports.  So instances like this would be
easy for us to know what ports are available?

73,  Michael, AA5SH

On Tue, Nov 11, 2025 at 9:35 AM Dave Baxter via Hamlib-developer <
ham...@li...> wrote:

> Just a thought.
>
> Does COM3 actually exist, and is it actually the rig?
>
> (Windows can re-enumerate ports as things are connected/removed, or when
> coming out of a sleep state, so sometimes what was on "COMx" is now on
> "COMy" !   There are ways to nail things down to stop that, but you then
> have to be very careful to reconnect things to the same physical USB port
> on the PC.   Put a Hub in the mix, and it gets very complicated very fast!)
>
> Is the rig connected by native USB, or via a common USB-Serial / CI-V
> adapter?   Many of such will have their drivers blocked by Windows, as
> there are hoards of fake chipsets out there used for such things, even FTDI
> look-alikes!
>
> If a native USB connection, what does Windows Device Manager say about it?
>
> Does any other software (Icom specific for the rig for example?) work OK
> with the radio?   If not, are the correct drivers installed?
>
> Also, does the rig have CI-V "Trancieve" enabled?   If so, try with that
> disabled.  (Though I think later Hamlib instances would disable that
> automagically if it was detected.)
>
> Just idle thoughts, based on experiences with that OS and COM ports in the
> past work life, where we often had multiple USB and serial connected
> instrumentation "things" at the same time.   Sometimes, Windows going to
> sleep, and then coming out of that, the Universe would implode, as various
> pieces of software suddenly lost sight of what they expected.
>
> That was true from Windows XP through Windows 10.   Glad I have nothing to
> do with that OS any more!.
>
> 73.
>
> Dave G8KBV.
>
>
> On 11/11/2025 14:09, prb...@gm... wrote:
>
> Hi Uwe
>
>
>
> Thanks for your help, I apologise if I appear to be making it complicated.
>
>
>
> I have downloaded V3.0 as you said and this time the Hamlib update button
> worked, but still the same error with no comms to the rig.
>
>
>
> I have set the diagnose mode and shut the program, then restarted it and
> closed it again.
>
>
>
> I have found the attached 2 log files from the desktop, is this what you
> required ?
>
>
>
> Thanks again
>
>
>
> Regards
>
>
>
> Peter
>
>
>
> 73
>
>
>
> M7PTS
>
>
>
> *From:* Uwe, DG2YCB <dg...@gm...> <dg...@gm...>
> *Sent:* 10 November 2025 13:49
> *To:* Peter Bearne <prb...@gm...> <prb...@gm...>; Hamlib
> Developers <ham...@li...>
> <ham...@li...>
> *Subject:* Re: [Hamlib-developer] Rig Control Error
>
>
>
> Sorry, I meant, of course: Follow the instructions (= restart *the
> program*, reproduce the error for a few seconds and close the program
> again)
>
>
> 73 de DG2YCB,
> Uwe
> ________________________________________
> German Amateur Radio Station DG2YCB
> Dr. Uwe Risse
> eMail: dg...@gm...
> Info: www.qrz.com/db/DG2YCB
>
> Am 10.11.2025 um 14:45 schrieb Uwe, DG2YCB via Hamlib-developer:
>
> Follow the instructions (= restart your computer, reproduce the error for
> a few seconds and close the program again)
>
>
>
> _______________________________________________
> Hamlib-developer mailing lis...@li...://lists.sourceforge.net/lists/listinfo/hamlib-developer
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>

Re: [Hamlib-developer] Rig Control Error

[Dave B. <g8k...@go...>]

Just a thought.

Does COM3 actually exist, and is it actually the rig?

(Windows can re-enumerate ports as things are connected/removed, or when 
coming out of a sleep state, so sometimes what was on "COMx" is now on 
"COMy" !   There are ways to nail things down to stop that, but you then 
have to be very careful to reconnect things to the same physical USB 
port on the PC.   Put a Hub in the mix, and it gets very complicated 
very fast!)

Is the rig connected by native USB, or via a common USB-Serial / CI-V 
adapter?   Many of such will have their drivers blocked by Windows, as 
there are hoards of fake chipsets out there used for such things, even 
FTDI look-alikes!

If a native USB connection, what does Windows Device Manager say about it?

Does any other software (Icom specific for the rig for example?) work OK 
with the radio?   If not, are the correct drivers installed?

Also, does the rig have CI-V "Trancieve" enabled?   If so, try with that 
disabled.  (Though I think later Hamlib instances would disable that 
automagically if it was detected.)

Just idle thoughts, based on experiences with that OS and COM ports in 
the past work life, where we often had multiple USB and serial connected 
instrumentation "things" at the same time.  Sometimes, Windows going to 
sleep, and then coming out of that, the Universe would implode, as 
various pieces of software suddenly lost sight of what they expected.

That was true from Windows XP through Windows 10.   Glad I have nothing 
to do with that OS any more!.

73.

Dave G8KBV.


On 11/11/2025 14:09, prb...@gm... wrote:
>
> Hi Uwe
>
> Thanks for your help, I apologise if I appear to be making it complicated.
>
> I have downloaded V3.0 as you said and this time the Hamlib update 
> button worked, but still the same error with no comms to the rig.
>
> I have set the diagnose mode and shut the program, then restarted it 
> and closed it again.
>
> I have found the attached 2 log files from the desktop, is this what 
> you required ?
>
> Thanks again
>
> Regards
>
> Peter
>
> 73
>
> M7PTS
>
> *From:*Uwe, DG2YCB <dg...@gm...>
> *Sent:* 10 November 2025 13:49
> *To:* Peter Bearne <prb...@gm...>; Hamlib Developers 
> <ham...@li...>
> *Subject:* Re: [Hamlib-developer] Rig Control Error
>
> Sorry, I meant, of course: Follow the instructions (= restart *the 
> program*, reproduce the error for a few seconds and close the program 
> again)
>
>
> 73 de DG2YCB,
> Uwe
> ________________________________________
> German Amateur Radio Station DG2YCB
> Dr. Uwe Risse
> eMail: dg...@gm...
> Info: www.qrz.com/db/DG2YCB <http://www.qrz.com/db/DG2YCB>
>
> Am 10.11.2025 um 14:45 schrieb Uwe, DG2YCB via Hamlib-developer:
>
>     Follow the instructions (= restart your computer, reproduce the
>     error for a few seconds and close the program again)
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Rig Control Error

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

Hi Peter,

Thanks for the two files. This helps a lot!

As you/we can see from the file "WSJT-X_rigControl.log", there are 
numerous "Communication timed out" errors. Looks to me as if the program 
cannot connect to your rig at all. This can only be due to either a 
hardware defect (defective USB cable, loose plug, etc.) or incorrect 
settings for the COM port, baud rate, etc., or that the COM port in 
question is already occupied by another program, or that your firewall 
is blocking the connection.

Very unlikely that it's due to the Hamlib driver, because there is no 
connection at all. Can you connect to your rig in other ways? For 
example, via OmniRig?

As far as I remember, Windows asks once for each new program version 
whether you want to allow network communication. Did you perhaps 
accidentally click “No”? If so, you will need to correct this in the 
Windows Firewall settings.

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


Am 11.11.2025 um 15:09 schrieb prb...@gm...:
>
> Hi Uwe
>
> Thanks for your help, I apologise if I appear to be making it complicated.
>
> I have downloaded V3.0 as you said and this time the Hamlib update 
> button worked, but still the same error with no comms to the rig.
>
> I have set the diagnose mode and shut the program, then restarted it 
> and closed it again.
>
> I have found the attached 2 log files from the desktop, is this what 
> you required ?
>
> Thanks again
>
> Regards
>
> Peter
>
> 73
>
> M7PTS
>
> *From:*Uwe, DG2YCB <dg...@gm...>
> *Sent:* 10 November 2025 13:49
> *To:* Peter Bearne <prb...@gm...>; Hamlib Developers 
> <ham...@li...>
> *Subject:* Re: [Hamlib-developer] Rig Control Error
>
> Sorry, I meant, of course: Follow the instructions (= restart *the 
> program*, reproduce the error for a few seconds and close the program 
> again)
>
>
> 73 de DG2YCB,
> Uwe
> ________________________________________
> German Amateur Radio Station DG2YCB
> Dr. Uwe Risse
> eMail: dg...@gm...
> Info: www.qrz.com/db/DG2YCB <http://www.qrz.com/db/DG2YCB>
>
> Am 10.11.2025 um 14:45 schrieb Uwe, DG2YCB via Hamlib-developer:
>
>     Follow the instructions (= restart your computer, reproduce the
>     error for a few seconds and close the program again)
>

Re: [Hamlib-developer] Rig Control Error

[<prb...@gm...>]

Hi Uwe

 

Thanks for your help, I apologise if I appear to be making it complicated.

 

I have downloaded V3.0 as you said and this time the Hamlib update button worked, but still the same error with no comms to the rig.

 

I have set the diagnose mode and shut the program, then restarted it and closed it again.

 

I have found the attached 2 log files from the desktop, is this what you required ?

 

Thanks again

 

Regards

 

Peter

 

73

 

M7PTS

 

From: Uwe, DG2YCB <dg...@gm...> 
Sent: 10 November 2025 13:49
To: Peter Bearne <prb...@gm...>; Hamlib Developers <ham...@li...>
Subject: Re: [Hamlib-developer] Rig Control Error

 

Sorry, I meant, of course: Follow the instructions (= restart the program, reproduce the error for a few seconds and close the program again) 


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



Am 10.11.2025 um 14:45 schrieb Uwe, DG2YCB via Hamlib-developer:

Follow the instructions (= restart your computer, reproduce the error for a few seconds and close the program again) 

Re: [Hamlib-developer] Rig Control Error

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

Thank you, Uwe, for taking the time to reply.

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] Rig Control Error

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

Sorry, I meant, of course: Follow the instructions (= restart *the 
program*, reproduce the error for a few seconds and close the program 
again)

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


Am 10.11.2025 um 14:45 schrieb Uwe, DG2YCB via Hamlib-developer:
> Follow the instructions (= restart your computer, reproduce the error 
> for a few seconds and close the program again)

Re: [Hamlib-developer] Rig Control Error

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

Hi Pete,

Why do you make everything so complicated? Simply install v3.0.0 251101 
<https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v3.0.0/wsjtx-3.0.0-win64_improved_PLUS_251101.exe/download>of 
WSJT-X (Improved) and use the “Diagnostic mode” which you can activate 
from the Save menu. Follow the instructions (= restart your computer, 
reproduce the error for a few seconds and close the program again). This 
will automatically create two debug log files in a new "logs" folder, 
which will be created on the desktop of your computer. Send them to me 
or to all of us. The most important file is “WSJT-X_RigControl.log,” 
because it logs all communication between WSJT-X (Improved) and your 
rig, so that we can immediately see any errors in Hamlib or elsewhere. 
Note that the “Diagnostic mode” is not available with earlier versions 
of WSJT-X. By the way: The “Update Hamlib” function is also working 
again in the current version 3.0.0 251101 
<https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v3.0.0/wsjtx-3.0.0-win64_improved_PLUS_251101.exe/download>. 


In addition, all of our 3.0.0 versions contain the necessary SSL/TLS 
files, so you no longer need to install OpenSSL yourself on Windows, as 
was the case with all previous versions of WSJT-X. This is now only 
necessary if you already have incompatible OpenSSL versions installed on 
your PC. You're mixing up several things here that have nothing to do 
with each other.

I am happy to provide you with the following information about the 
general status of the WSJT-X project:
Keep in mind that Joe is now over 84 years old. A few years ago, Joe was 
no longer able to keep the old Princeton URL for the WSJT-X download 
page. That's why we moved to SourceForge again. (I created the new 
homepage for him). In addition, for years now, both WSJT-X and the more 
up-to-date “WSJT-X Improved” version of the source code and all 
installers have no longer been created by him, but by other people in 
the core WSJT Develop group. Most of the maintenance work of WSJT-X is 
nowadays done by me. I also create all Linux and Windows installation 
packages. And because we younger members of the core WSJT Development 
group have been responsible for most of the innovations for years now, I 
am releasing with “WSJT-X Improved” a state-of-the-art edition of 
“WSJT-X,” where all new features are tested and optimized, and bugs are 
fixed promptly.

IMPORTANT FOR YOU:
You must always distinguish between the program itself (i.e., WSJT-X or 
WSJT-X Improved) and Hamlib. If you have rig control errors, there can 
be various reasons for this. Often it is because the user has 
accidentally set some settings incorrectly (COM port, baud rate, etc.) 
or there is a hardware problem (USB cable, etc.).
If you can rule all of that out, then it could be caused by the Hamlib 
driver. For Windows users, the entire Hamlib driver database is 
contained in a single DLL file: “libhamlib-4.dll”, which is located in 
the “bin” folder of your installation (usually 
c:\WSJT\wsjtx\bin\libhamlib-4.dll). This file is replaced when you use 
the “Update Hamlib” function. In theory, however, this can also be done 
manually by the user at any time. As mentioned, you only need to reset 
the “libhamlib-4.dll” file that came with WSJT-X v2.5.4, and you will 
then have the same Hamlib version (i.e., also with v3.0.0 251101"). By 
the way, you can also find this file here 
<https://sourceforge.net/projects/wsjt-x-improved/files/Additional%20Files/Hamlib/libhamlib-4_WSJTX_v2.5.4_64-bit.dll/download>. 
If your rig control error persists, then it is obviously due to 
something else.
But again: you just need to use the built-in “Diagnostic mode” in WSJT-X 
(Improved) and send us the two files in question, then we can say more 
about it.

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


Am 10.11.2025 um 13:05 schrieb Peter Bearne:
> Is there anyway you can talk me through how to get the data you need?
> Ive also rolled back to 2.5.4
> Is it advisable to put 2.7 back on first?
> Is diagnostic mode built into the program, or do you mean Windows 
> diagnostic?
> Regards
>
> Pete
>
> On Mon, 10 Nov 2025, 10:51 Peter Bearne, <prb...@gm...> wrote:
>
>     Hi Nate,
>
>     Im not sure how to get the Rigctl data you need?
>
>     Thanks for trying to help me out.
>
>     Regards
>
>     Peter
>
>     On Mon, 10 Nov 2025, 00:35 Nate Bargmann, <n0...@n0...> wrote:
>
>         * On 2025 09 Nov 13:33 -0600, prb...@gm... wrote:
>         > Hi Nate,
>         >
>         > Thanks for coming back to me.
>         > I'm sorry, I'm not very good with the technical side, I have
>         spent 2 days
>         > trying to repair and am about to give up and sell my rig.
>         > I have attached the document I have found, it appears to
>         relate to Version
>         > 2.7 which has the button to update Hamlib.
>
>         I suspect that 2.7 has the old URL either hard coded or in a
>         configuration variable.  The old link has gone away and isn't
>         coming
>         back.  It was not my decision to break that.
>
>         > All my set up was working a year ago, before I decided to
>         try to update the
>         > software to V3.0
>         > I have even completely reset my IC705, but it's made no
>         difference.
>         > I have just rolled back to 2.5.4 but its just the same,
>         although I don't
>         > have the hamlib update buttons, but it still comes up with
>         >
>         > Hamlib error: Communication timed out
>         > serial.c(884):ser_close return(0)
>         > iofunc.c(361):port_close return(0)
>         > rig.c(1083):rig_open return(-5) Communication timed out
>         > serial.c(884):ser_close return(0)
>         > iofunc.c(361):port_close return(0)
>         > iofunc.c(361):port_close return(0)  while opening connection
>         to rig
>         >
>         > Timestamp: 2025-11-09T19:27:53.170Z
>
>         As I stated earlier, the output from rigctl will be
>         considerably more
>         helpful to us.  This output is like an outline while the
>         output I am
>         asking for is the entire term paper!
>
>         > I notice the download web page has changed from princetown
>         to a different
>         > one?
>
>         I don't know as I don't get the software from there.  I use
>         the package
>         provided by the Debian project.
>
>         > I don't really use the rig for voice, so its useless for me now.
>         >
>         > And in response to your question about when I try to press
>         the update hamlib
>         > button, yes, it fails to update, with the error straight away?
>         >
>         > Should I not stay on 2.5.4? I just don't know what to do now
>
>         You can ask on the WSJT-X support forum (wherever that is) for
>         guidance
>         on manually installing the updated .DLL but I don't think that
>         is where
>         the problem is, but I cannot guess from the sparse output
>         above.  Sorry.
>
>         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

Re: [Hamlib-developer] Rig Control Error

[Peter B. <prb...@gm...>]

Is there anyway you can talk me through how to get the data you need?
Ive also rolled back to 2.5.4
Is it advisable to put 2.7 back on first?
Is diagnostic mode built into the program, or do you mean Windows
diagnostic?
Regards

Pete

On Mon, 10 Nov 2025, 10:51 Peter Bearne, <prb...@gm...> wrote:

> Hi Nate,
>
> Im not sure how to get the Rigctl data you need?
>
> Thanks for trying to help me out.
>
> Regards
>
> Peter
>
> On Mon, 10 Nov 2025, 00:35 Nate Bargmann, <n0...@n0...> wrote:
>
>> * On 2025 09 Nov 13:33 -0600, prb...@gm... wrote:
>> > Hi Nate,
>> >
>> > Thanks for coming back to me.
>> > I'm sorry, I'm not very good with the technical side, I have spent 2
>> days
>> > trying to repair and am about to give up and sell my rig.
>> > I have attached the document I have found, it appears to relate to
>> Version
>> > 2.7 which has the button to update Hamlib.
>>
>> I suspect that 2.7 has the old URL either hard coded or in a
>> configuration variable.  The old link has gone away and isn't coming
>> back.  It was not my decision to break that.
>>
>> > All my set up was working a year ago, before I decided to try to update
>> the
>> > software to V3.0
>> > I have even completely reset my IC705, but it's made no difference.
>> > I have just rolled back to 2.5.4 but its just the same, although I don't
>> > have the hamlib update buttons, but it still comes up with
>> >
>> > Hamlib error: Communication timed out
>> > serial.c(884):ser_close return(0)
>> > iofunc.c(361):port_close return(0)
>> > rig.c(1083):rig_open return(-5) Communication timed out
>> > serial.c(884):ser_close return(0)
>> > iofunc.c(361):port_close return(0)
>> > iofunc.c(361):port_close return(0)  while opening connection to rig
>> >
>> > Timestamp: 2025-11-09T19:27:53.170Z
>>
>> As I stated earlier, the output from rigctl will be considerably more
>> helpful to us.  This output is like an outline while the output I am
>> asking for is the entire term paper!
>>
>> > I notice the download web page has changed from princetown to a
>> different
>> > one?
>>
>> I don't know as I don't get the software from there.  I use the package
>> provided by the Debian project.
>>
>> > I don't really use the rig for voice, so its useless for me now.
>> >
>> > And in response to your question about when I try to press the update
>> hamlib
>> > button, yes, it fails to update, with the error straight away?
>> >
>> > Should I not stay on 2.5.4? I just don't know what to do now
>>
>> You can ask on the WSJT-X support forum (wherever that is) for guidance
>> on manually installing the updated .DLL but I don't think that is where
>> the problem is, but I cannot guess from the sparse output above.  Sorry.
>>
>> 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] Rig Control Error

[Peter B. <prb...@gm...>]

Hi Nate,

Im not sure how to get the Rigctl data you need?

Thanks for trying to help me out.

Regards

Peter

On Mon, 10 Nov 2025, 00:35 Nate Bargmann, <n0...@n0...> wrote:

> * On 2025 09 Nov 13:33 -0600, prb...@gm... wrote:
> > Hi Nate,
> >
> > Thanks for coming back to me.
> > I'm sorry, I'm not very good with the technical side, I have spent 2 days
> > trying to repair and am about to give up and sell my rig.
> > I have attached the document I have found, it appears to relate to
> Version
> > 2.7 which has the button to update Hamlib.
>
> I suspect that 2.7 has the old URL either hard coded or in a
> configuration variable.  The old link has gone away and isn't coming
> back.  It was not my decision to break that.
>
> > All my set up was working a year ago, before I decided to try to update
> the
> > software to V3.0
> > I have even completely reset my IC705, but it's made no difference.
> > I have just rolled back to 2.5.4 but its just the same, although I don't
> > have the hamlib update buttons, but it still comes up with
> >
> > Hamlib error: Communication timed out
> > serial.c(884):ser_close return(0)
> > iofunc.c(361):port_close return(0)
> > rig.c(1083):rig_open return(-5) Communication timed out
> > serial.c(884):ser_close return(0)
> > iofunc.c(361):port_close return(0)
> > iofunc.c(361):port_close return(0)  while opening connection to rig
> >
> > Timestamp: 2025-11-09T19:27:53.170Z
>
> As I stated earlier, the output from rigctl will be considerably more
> helpful to us.  This output is like an outline while the output I am
> asking for is the entire term paper!
>
> > I notice the download web page has changed from princetown to a different
> > one?
>
> I don't know as I don't get the software from there.  I use the package
> provided by the Debian project.
>
> > I don't really use the rig for voice, so its useless for me now.
> >
> > And in response to your question about when I try to press the update
> hamlib
> > button, yes, it fails to update, with the error straight away?
> >
> > Should I not stay on 2.5.4? I just don't know what to do now
>
> You can ask on the WSJT-X support forum (wherever that is) for guidance
> on manually installing the updated .DLL but I don't think that is where
> the problem is, but I cannot guess from the sparse output above.  Sorry.
>
> 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] Rig Control Error

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

* On 2025 09 Nov 13:33 -0600, prb...@gm... wrote:
> Hi Nate,
> 
> Thanks for coming back to me.
> I'm sorry, I'm not very good with the technical side, I have spent 2 days
> trying to repair and am about to give up and sell my rig.
> I have attached the document I have found, it appears to relate to Version
> 2.7 which has the button to update Hamlib.

I suspect that 2.7 has the old URL either hard coded or in a
configuration variable.  The old link has gone away and isn't coming
back.  It was not my decision to break that.

> All my set up was working a year ago, before I decided to try to update the
> software to V3.0
> I have even completely reset my IC705, but it's made no difference.
> I have just rolled back to 2.5.4 but its just the same, although I don't
> have the hamlib update buttons, but it still comes up with 
> 
> Hamlib error: Communication timed out
> serial.c(884):ser_close return(0) 
> iofunc.c(361):port_close return(0) 
> rig.c(1083):rig_open return(-5) Communication timed out
> serial.c(884):ser_close return(0) 
> iofunc.c(361):port_close return(0) 
> iofunc.c(361):port_close return(0)  while opening connection to rig
> 
> Timestamp: 2025-11-09T19:27:53.170Z

As I stated earlier, the output from rigctl will be considerably more
helpful to us.  This output is like an outline while the output I am
asking for is the entire term paper!

> I notice the download web page has changed from princetown to a different
> one?

I don't know as I don't get the software from there.  I use the package
provided by the Debian project.

> I don't really use the rig for voice, so its useless for me now.
> 
> And in response to your question about when I try to press the update hamlib
> button, yes, it fails to update, with the error straight away?
> 
> Should I not stay on 2.5.4? I just don't know what to do now

You can ask on the WSJT-X support forum (wherever that is) for guidance
on manually installing the updated .DLL but I don't think that is where
the problem is, but I cannot guess from the sparse output above.  Sorry.

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] Rig Control Error

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

* On 2025 09 Nov 12:05 -0600, prb...@gm... wrote:
> I'm not very good at technical things, I have your document "How to deal
> with Rig control errors" but get a bit lost.

Hi Peter.

I'm not sure that is a document provided by Hamlib.  It doesn't sound at
all familiar to me.

> Number 3. says update Hamlib to the latest version, but I get an error when
> I try,  "error loading Hamlib-4.dll  TLS Initialization failed"?

That is strange.  Is that an error you're getting when trying to
download from the Internet?  If so, the link name had to change due to
the elimination of personal Web space hosting by SourceForge.net.  The
main page is now https://hamlib.sourceforge.net/snapshots/ and the
.DLLs are at:

https://hamlib.sourceforge.net/snapshots/dll32/libhamlib-4.dll
https://hamlib.sourceforge.net/snapshots/dll64/libhamlib-4.dll

The former is for 32 bit Windows and the latter for 64 bit.

> Number 4 says click to save menu on diagnostics mode? Which I don't
> understand?

Neither do I!

> The error I get from the main screen is shown below.
> 
>  
> 
> If there is anyway you could assist me, that would be great.

We have a utility, rigctl, that we much prefer to see diagnostics from.
I think WSJT-X includes it but I'm not sure as I don't use that software
on Windows.

You can start reading this section of our README.betatester file:

https://github.com/Hamlib/Hamlib/blob/55feb026fa0de001cd4306f90691f0b00214f04e/README.betatester#L209

The key difference is that you will use something like "COM8" for the
-r option.  The -vvvvv option is very important from our perspective as
that is the maximum amount of debugging output that Hamlib will
generate.  Post all of that output here, please.

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] Rig Control Error

[<prb...@gm...>]

Hi,

 

I hope you can help.

 

I only ever use my IC705 on WSJT-X and have been off air for over a year.

 

I can back to my radio / PC and saw a new version 3.0 available.

 

I downloaded this and found it was a developers version, but it also didn't
seem to work, so I tried to install 2.5.4 version again which now wouldnt
work also?

 

I have uninstalled this and now installed 2.7.0

 

I have an IC705 and am running a Windows 10 PC

 

The Audio into the PC seems to work, I can see stations calling but I have
no CAT control?

 

I have all of the settings back as they were when it worked last. The same
PC, the same antenna, the Same USB lead (Tried others and still the same)

 

I'm not very good at technical things, I have your document "How to deal
with Rig control errors" but get a bit lost.

 

Number 3. says update Hamlib to the latest version, but I get an error when
I try,  "error loading Hamlib-4.dll  TLS Initialization failed"?

Number 4 says click to save menu on diagnostics mode? Which I don't
understand?

 

The error I get from the main screen is shown below.

 

If there is anyway you could assist me, that would be great.

 

Regards

 

Peter M7PTS

 

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

 

Hamlib error: 

Communication timed out

 

****4:frame.c(556):icom_transaction returning(-5) Communication timed out

 

***3:icom.c(833):icom_get_usb_echo_off returning(-5) Communication timed out

 

icom_rig_open: echo status result=-5

icom_rig_open: Unable to determine Icom echo status -- is rig on and
connected?

**2:icom.c(1193):icom_rig_open returning(-5) Communication timed out

 

**2:rig.c(8484):async_data_handler_stop entered

**2:rig.c(8515):async_data_handler_stop returning(0) 

**2:rig.c(8525):morse_data_handler_stop entered

**2:rig.c(8571):morse_data_handler_stop returning(0) 

ser_close: restoring options

rig.c(1476):rig_open returning2(-5) Communication timed out

 

Communication timed out

Communication timed out

while opening connection to rig

 

Timestamp: 2025-11-09T17:05:33.500Z

Re: [Hamlib-developer] Windows installer script / code

[Martin C. <mfn...@gm...>]

Hi Nate,

Thanks for both the explanations and the code. Very helpful, and much
appreciated.

Martin.
KD6YAM

On Thu, Nov 6, 2025 at 4:48 AM Nate Bargmann <n0...@n0...> wrote:

> * On 2025 05 Nov 12:05 -0600, Martin Cooper wrote:
> > Hi Nate,
> >
> > I can understand reducing dependencies, for sure.
> >
> > At issue for me, as I mentioned, is knowing exactly what the installer
> > does. A Windows user has a choice - download the installer exe and run
> it,
> > or download the zip file and unzip it. What's the difference? Why would
> the
> > user choose one over the other? Are there additional things that the
> > installer does (e.g. modifying the Windows registry or making other
> system
> > changes) that the user doesn't get if they simply unzip the zip file?
> What
> > exactly is the installer doing to my system?
>
> I've attached both nsis config files.
>
> No registry modification is done as none is needed for Hamlib.  As I see
> it, the advantage is with the installer as different components can be
> installed or omitted with DLLs being a required component.
>
> > Also, if I'm building an application that might call upon Hamlib for some
> > functionality, how do I decide whether I should tell my users to install
> > Hamlib using the installer exe or simply download and unzip the zip file?
> > What would I miss if I told them to just unzip the zip file?
>
> Nothing will be missed, however with the installer I suspect you could
> have your users uncheck all of the optional components and set the path.
>
> > Without either documentation or source code for the installer, neither an
> > end user nor an application developer has a way to know which path to
> > follow and why. Admittedly, making the source code available isn't going
> to
> > help most end users, so perhaps the preferable path would be to fully
> > document the two alternatives and the reasons that someone would choose
> one
> > over the other. Me, I'm used to reading source code to find undocumented
> > information, which is why I went looking for it. :-)
>
> Just an oversight.  Those files will be added to the repository.
>
> Thanks!
>
> 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
>

[Hamlib-developer] [Hamlib/Hamlib] 55feb0: Add Noise Reduction to FT450

[Check y. g. s. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 55feb026fa0de001cd4306f90691f0b00214f04e
      https://github.com/Hamlib/Hamlib/commit/55feb026fa0de001cd4306f90691f0b00214f04e
  Author: telewizoor <not...@gi...>
  Date:   2025-11-08 (Sat, 08 Nov 2025)

  Changed paths:
    M rigs/yaesu/ft450.h

  Log Message:
  -----------
  Add Noise Reduction to FT450

Closes GitHub issue #1937.



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

Re: [Hamlib-developer] [SPAM] Re: rig-multicast?

[Chris R. <chr...@ch...>]

I wasn't aware that Log4OM uses rigctld but indeed it does, I can 
connect to my rig using Log4OM and connect WSJT-X to it using the 
"Hamlib NET rigctl" option.  I can also see rigctld in the background 
process list.

I've had a lot of experience with connecting hardware to multiple 
software applications both in my day job, where it was electron 
microscopes and for amateur astronomy using the ASCOM platform.  What 
made it challenging was unhelpful applications which will poll the 
hardware as fast as they can which can overwhelm the hardware or put the 
hardware control in their UI process so when the hardware takes time to 
respond the UI gets unresponsive.  Hardware that's slow to respond - and 
if you are using a 9600 baud serial port - response times can be in the 
10s of milliseconds was also a problem.  It also doesn't help when a 
command doesn't send any response, how do you know when it's safe to 
send the next command?

I found that the best way was to set up a separate serial control 
process with a concurrent queue of transactions. Each App control 
instance would put a transaction on the queue and block until the serial 
control process had processed the transaction.  The serial control 
process would read the queue at a rate that suited the hardware. Status 
properties would use a throttled control process where the previous 
value would be returned until it was more than a reasonable age to keep 
polling commands at a reasonable rate.

I'm sure that Hamlib will have the same issues.  I was using C# and .NET 
to handle this but I'm sure there are similar solutions in Linux.

Hope this helps,

Chris, G5CTH

On 04/11/2025 22:39, David Balharrie wrote:
>
> Log4OM uses rigctld, it does not use the api library.
>
> This is its config panel
>
> 73 de David M0DGB/G8FKH
>
> *From:*Michael Morgan <cmo...@gm...>
> *Sent:* 04 November 2025 20:22
> *To:* Uwe, DG2YCB <dg...@gm...>
> *Cc:* ham...@li...
> *Subject:* [Hamlib-developer] [SPAM] Re: rig-multicast?
>
> It just passes through the capabilities of the rig so if PWR and SWR 
> is available it still would be available.
>
> I could try and type up some notes on how to launch it.  And it should 
> work with any application that works with HamLib - so Log4OM would be 
> good.
>
> Michael
>
>
>
>     On Nov 4, 2025, at 10:45 AM, Uwe, DG2YCB <dg...@gm...> wrote:
>
>     Hi Michael and George,
>
>     Thanks for your replies. Would this approach also work with
>     Log4OM? And an additional question: Is the Read PWR and SWR
>     feature supported by rigctld? Because there were actually a few
>     requests about this some time ago (especially from OMs who use
>     Log4OM but would like to continue using the Read PWR and SWR
>     feature, which is not possible with OmniRig).
>
>     If the approach with rigctld would solve this problem for and with
>     Log4OM and WSJT-X (Improved): Could one of you two perhaps be so
>     kind as to briefly explain the setup in a PDF (preferably with a
>     few screenshots)? Then we could make it available to these OMs (or
>     I could put it on my SourceForge page). Thanks.
>
>
>     73 de DG2YCB,
>     Uwe
>     ________________________________________
>     German Amateur Radio Station DG2YCB
>     Dr. Uwe Risse
>     eMail: dg...@gm...
>     Info: www.qrz.com/db/DG2YCB <http://www.qrz.com/db/DG2YCB>
>
>     Am 04.11.2025 um 16:58 schrieb George Baltz:
>
>         As AA5SH wrote, the current way to handle multiple users is to
>         use rigctld.  My setup is to have cqrlog configured to start
>         rigctld, and then I tell cqrlog(via ctrl-J) to fire up WSJT-X
>         (Improved), configured to use 'Hamlib dummy' as the rig on
>         127.0.0.1:4532
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Windows installer script / code

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

Fat fingered and didn't attach the files.  🙄

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] Windows installer script / code

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

* On 2025 05 Nov 12:05 -0600, Martin Cooper wrote:
> Hi Nate,
> 
> I can understand reducing dependencies, for sure.
> 
> At issue for me, as I mentioned, is knowing exactly what the installer
> does. A Windows user has a choice - download the installer exe and run it,
> or download the zip file and unzip it. What's the difference? Why would the
> user choose one over the other? Are there additional things that the
> installer does (e.g. modifying the Windows registry or making other system
> changes) that the user doesn't get if they simply unzip the zip file? What
> exactly is the installer doing to my system?

I've attached both nsis config files.

No registry modification is done as none is needed for Hamlib.  As I see
it, the advantage is with the installer as different components can be
installed or omitted with DLLs being a required component.

> Also, if I'm building an application that might call upon Hamlib for some
> functionality, how do I decide whether I should tell my users to install
> Hamlib using the installer exe or simply download and unzip the zip file?
> What would I miss if I told them to just unzip the zip file?

Nothing will be missed, however with the installer I suspect you could
have your users uncheck all of the optional components and set the path.

> Without either documentation or source code for the installer, neither an
> end user nor an application developer has a way to know which path to
> follow and why. Admittedly, making the source code available isn't going to
> help most end users, so perhaps the preferable path would be to fully
> document the two alternatives and the reasons that someone would choose one
> over the other. Me, I'm used to reading source code to find undocumented
> information, which is why I went looking for it. :-)

Just an oversight.  Those files will be added to the repository.

Thanks!

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] Windows installer script / code

[Martin C. <mfn...@gm...>]

On Wed, Nov 5, 2025 at 8:11 AM Nate Bargmann <n0...@n0...> wrote:

> * On 2025 04 Nov 10:33 -0600, Martin Cooper wrote:
> > Apologies in advance if I'm missing something obvious.
> >
> > When looking at how Hamlib is built for Windows, the scripts (e.g.
> > build-w64.sh) and associated docs take me through the process to the
> point
> > of creating a zip file. However, the release artifacts on GitHub also
> > include a .exe installer. I've been unable to find the script / code that
> > creates that installer, and / or documentation for how it's created. I'm
> > interested in looking at this because I want to see *exactly* what it's
> > doing, if anything, that's different from just unzipping a zip file (e.g.
> > different locations, setting up paths, etc.).
> >
> > Where can I find the source for this?
>
> Nowhere public at the moment.
>
> That is simply because I didn't appreciate that they would be useful.
> The build* scripts you see are actually called by another script that is
> in turn called by cron in the VM.  They do things like archive the
> source snapshot on the host machine and handle the uploads to
> SourceForge.net.  I also have variations for releases.  The nsis
> configuration file is separate from them (I kept the nsis stuff out of
> the build* scripts to lessen the dependency count by one, I could be
> convinced to place it in those scripts contingent on whether nsis is
> found).
>

Hi Nate,

I can understand reducing dependencies, for sure.

At issue for me, as I mentioned, is knowing exactly what the installer
does. A Windows user has a choice - download the installer exe and run it,
or download the zip file and unzip it. What's the difference? Why would the
user choose one over the other? Are there additional things that the
installer does (e.g. modifying the Windows registry or making other system
changes) that the user doesn't get if they simply unzip the zip file? What
exactly is the installer doing to my system?

Also, if I'm building an application that might call upon Hamlib for some
functionality, how do I decide whether I should tell my users to install
Hamlib using the installer exe or simply download and unzip the zip file?
What would I miss if I told them to just unzip the zip file?

Without either documentation or source code for the installer, neither an
end user nor an application developer has a way to know which path to
follow and why. Admittedly, making the source code available isn't going to
help most end users, so perhaps the preferable path would be to fully
document the two alternatives and the reasons that someone would choose one
over the other. Me, I'm used to reading source code to find undocumented
information, which is why I went looking for it. :-)

Thanks,

Martin.
KD6YAM


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

Re: [Hamlib-developer] Windows installer script / code

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

* On 2025 04 Nov 10:33 -0600, Martin Cooper wrote:
> Apologies in advance if I'm missing something obvious.
> 
> When looking at how Hamlib is built for Windows, the scripts (e.g.
> build-w64.sh) and associated docs take me through the process to the point
> of creating a zip file. However, the release artifacts on GitHub also
> include a .exe installer. I've been unable to find the script / code that
> creates that installer, and / or documentation for how it's created. I'm
> interested in looking at this because I want to see *exactly* what it's
> doing, if anything, that's different from just unzipping a zip file (e.g.
> different locations, setting up paths, etc.).
> 
> Where can I find the source for this?

Nowhere public at the moment.

That is simply because I didn't appreciate that they would be useful.
The build* scripts you see are actually called by another script that is
in turn called by cron in the VM.  They do things like archive the
source snapshot on the host machine and handle the uploads to
SourceForge.net.  I also have variations for releases.  The nsis
configuration file is separate from them (I kept the nsis stuff out of
the build* scripts to lessen the dependency count by one, I could be
convinced to place it in those scripts contingent on whether nsis is
found).

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