hamlib-developer — hamlib developers forum

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

[David B. <da...@ba...>]

Log4OM uses rigctld, it does not use the api library.

This is its config panel

[cid:image001.png@01DC4DDB.F27E1CC0]


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...<mailto: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...<mailto: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] [SPAM] Re: rig-multicast?

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

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... <mailto: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
> 

Re: [Hamlib-developer] rig-multicast?

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

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


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

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

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?

Thanks,

Martin.
KD6YAM

Re: [Hamlib-developer] Daily snapshot

[jarmo <oh...@ni...>]

Tue, 4 Nov 2025 06:00:05 -0600
Nate Bargmann <n0...@n0...> kirjoitti:


> Hi Jarmo.
> 
> That is correct as there have been no commits since that date.
> Whenever the next commit is applied, the version string will reflect
> that date.
> 
> We will get back to development soon.
> 
> 73, Nate
> 

Thanks, explain all

Jarmo

Re: [Hamlib-developer] rig-multicast?

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

It's still there, but right now it's on hold.  This and a couple of 
other features need some problems solved first.  The major holdups are:

1. Thread safety - Internally there is very little consideration of 
conflicts between threads.  The locking now is at the entry/exit level.

2. Error handling and recovery - Some of the error handling code affects 
state and data far outside of its scope.

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

We may get back to the multicast and/or REST interfaces to Hamlib next 
year, but it will require some real design work (including some security 
concerns) before they can be generally used.

HTH

73 n3gb

On 11/4/25 7:53 AM, Uwe, DG2YCB via Hamlib-developer wrote:
> Hi Nate and all,
>
> What actually became of Mike's approach to making a 
> rig-multicast-capable Hamlib version? Was that lost with Mike's 
> passing, or could something like that still become a reality someday? 
> If I remember correctly, reading already worked, but writing (and thus 
> synchronization) did not yet.
>
> I ask this because one of Hamlib's major weaknesses is that only one 
> rig can be connected to a COM port at a time. If, for example, someone 
> runs Log4OM next to WSJT-X, Hamlib is automatically ruled out for many 
> OMs. The same applies if I want to connect multiple WSJT-X (Improved) 
> instances to one rig. That's why I really welcomed Mike's approach at 
> the time, even though I considered it somewhat ambitious. 
> Unfortunately, I can't help you much with the implementation myself, 
> but I would of course be available for any alpha tests.
>
> 73 de DG2YCB,
> Uwe
> ________________________________________
> German Amateur Radio Station DG2YCB
> Dr. Uwe Risse
> eMail: dg...@gm...
> Info: www.qrz.com/db/DG2YCB
>
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] rig-multicast?

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

Uwe,
There is a somewhat simpler approach that you could consider.  I had done a quick proof of concept in QLog. But you could add two options for a checkbox and spinwheel for port selection then take the rig control information you have in WSJT and launch an instance of rigctld.  I know for MacOS it is already packaged, then have this copy of WSJT connect to the rigctld instance.  Then the other apps and instances can connect to the rigctld process.  It is already a proven and tested solution.  I quite often when I use a rig that needs it launch a rigctld instance manually then have all of the other apps connect to it.  But it can be automated in WSJT or Log4OM or wherever to ease the process for other applications.

73

Michael, AA5SH


> On Nov 4, 2025, at 6:53 AM, Uwe, DG2YCB via Hamlib-developer <ham...@li...> wrote:
> 
> Hi Nate and all,
> 
> What actually became of Mike's approach to making a rig-multicast-capable Hamlib version? Was that lost with Mike's passing, or could something like that still become a reality someday? If I remember correctly, reading already worked, but writing (and thus synchronization) did not yet.
> 
> I ask this because one of Hamlib's major weaknesses is that only one rig can be connected to a COM port at a time. If, for example, someone runs Log4OM next to WSJT-X, Hamlib is automatically ruled out for many OMs. The same applies if I want to connect multiple WSJT-X (Improved) instances to one rig. That's why I really welcomed Mike's approach at the time, even though I considered it somewhat ambitious. Unfortunately, I can't help you much with the implementation myself, but I would of course be available for any alpha tests.
> 
> 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>
> 
> 
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] rig-multicast?

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

Hi Nate and all,

What actually became of Mike's approach to making a 
rig-multicast-capable Hamlib version? Was that lost with Mike's passing, 
or could something like that still become a reality someday? If I 
remember correctly, reading already worked, but writing (and thus 
synchronization) did not yet.

I ask this because one of Hamlib's major weaknesses is that only one rig 
can be connected to a COM port at a time. If, for example, someone runs 
Log4OM next to WSJT-X, Hamlib is automatically ruled out for many OMs. 
The same applies if I want to connect multiple WSJT-X (Improved) 
instances to one rig. That's why I really welcomed Mike's approach at 
the time, even though I considered it somewhat ambitious. Unfortunately, 
I can't help you much with the implementation myself, but I would of 
course be available for any alpha tests.

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

Re: [Hamlib-developer] Daily snapshot

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

* On 2025 04 Nov 04:41 -0600, jarmo wrote:
> Hope reach right place here.
> 
> I dowloaded latest daily snapsoft
> hamlib-4.7~git-20251104-23710cf2d.tar.gz
> 
> I compiled it, but what I run it, I get version
>  rigctl -V
> rigctl Hamlib 4.7~git 2025-10-10T14:52:54Z SHA=23710cf2d 64-bit
> 
> Daystamp is from last month????

Hi Jarmo.

That is correct as there have been no commits since that date.  Whenever
the next commit is applied, the version string will reflect that date.

We will get back to development soon.

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] Daily snapshot

[jarmo <oh...@ni...>]

Hope reach right place here.

I dowloaded latest daily snapsoft
hamlib-4.7~git-20251104-23710cf2d.tar.gz

I compiled it, but what I run it, I get version
 rigctl -V
rigctl Hamlib 4.7~git 2025-10-10T14:52:54Z SHA=23710cf2d 64-bit

Daystamp is from last month????

Any ideas?

Jarmo, oh1mrr

[Hamlib-developer] Reg ID for Flex8400

[Stephen P. <st...@bi...>]

Hi,
Can anybody tell me if the Flex 8400 is supported and what the rig ID 
is. (Version 4.6.5)?

rigctld -list shows me

ID            Mfg               Model Macro

2036       FlexRadio     6xxx RIG_MODEL_F6K (So perhaps the flex 8400 is 
the same as the 6xxx series except I doubt it - the 8400 has two receivers)
23005     FlexRadio     SmartSDR     Slice A      RIG_MODEL_SMARTSDR_A
23006     FlexRadio     SmartSDR     Slice B           ditto  B..H
23007     FlexRadio     SmartSDR     Slice C
23008     FlexRadio     SmartSDR     Slice D
23009     FlexRadio     SmartSDR     Slice E
23010     FlexRadio     SmartSDR     Slice F
23011     FlexRadio     SmartSDR     Slice G
23012     FlexRadio     SmartSDR     Slice H

Thanks
Steve VK3SPX

Re: [Hamlib-developer] hamlib does now show yeasu ftm-500 or ftm 510dr

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

* On 2025 29 Oct 02:04 -0500, JOSEPH PERRY via Hamlib-developer wrote:
> hi
> when will ftm 510 yeasu hamlib commands be added to the hamlib?

Unfortunately, likely never.

I did a quick glance through the manual and didn't see anything
discussing CAT capability.  Yaesu typically only provides such
capability on radios that cover HF even if they cover VHF/UHF as well
but not V/U only radios.

> need satpc32, hrd, gpredict to connect to the radio for satellite split use.

I suspect Yaesu wants you to buy another radio model to gain that
capability...

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 does now show yeasu ftm-500 or ftm 510dr

[JOSEPH P. <joe...@ao...>]

hi
when will ftm 510 yeasu hamlib commands be added to the hamlib?
need satpc32, hrd, gpredict to connect to the radio for satellite split use.
joewb6dcousacalifornia

[Hamlib-developer] Issue with QSSTV and changing rig names

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

I pulled the latest hamlib this afternoon (Debian bookworm) and it broke QSSTV which crashed with the cryptic message "Hash Collision!!! Fatal Error!!!!".

>From experimenting it appears that it was the change from W1HKJ/FlRig to FlRig/FlRig that caused it.

This is not the first time I've had QSSTV fail like this but it's the first time I twigged the connection.

I'm just suggesting that messing with rig numbers, names and manufacturers should not be undertaken lightly. I don't think QSSTV is being actively supported.

73 Phil GM3ZZA

Re: [Hamlib-developer] Problem with G232B Timing out

[David B. <da...@ba...>]

Could you add -vvvv to the end of the command to see all the commands? Redirect to a log file.

-m 603 -r COM8 -t 8533 -s 38400 -vvvv

Also 38400 is quite high for a rotator, try 19200 or even 9600.

73 de David M0DGB/G8FKH



From: Steve Cummins <ill...@ho...>
Sent: 23 October 2025 15:49
To: ham...@li...
Subject: [Hamlib-developer] Problem with G232B Timing out
Importance: High

rotctld, Hamlib 4.5.5 Apr 05 11:43:08Z 2023 SHA=6eecd3
Report bugs to <ham...@li...<mailto:ham...@li...>>

rot_init called
initrots4_gs232a called
rot_register (601)
rot_register (609)
rot_register (610)
rot_register (602)
rot_register (603)
rot_register (611)
rot_register (612)
rot_register (604)
rot_register (605)
rot_register (606)
rot_register (607)
rot_register (608)
gs232b_rot_init called
set_conf: called
rot_open called
serial_open: COM8
serial_setup: tcgetattr
serial_setup: cfsetispeed=38400,0x000f
serial_setup: cfsetospeed=38400,0x000f
serial_setup: data_bits=8
serial_setup: parity=0
serial_setup: Handshake=None
serial_setup: tcsetattr TCSANOW
read_string_generic called, rxmax=4095 direct=1, expected_len=1
tcflush
Opened rot model 603, 'GS-232B'
Backend version: 20220109.0, Status: Stable

Good day fine people.
I'm using ROTCTLD with the following settings "-m 603 -r COM8 -t 8533 -s 38400" to control my ERC-M controller by DF9GR
The software I am using is "SkyRoof" which generally works very well, but I believe ROTCTLD drops the TCP connection on occasions and gives a time-out message.
>From the ERC-M controller I can see the rotators are turning towards their desired az & el, but the feedback from rotctld to SkyRoof is dropped. The problem exposes itself by  showing the antenna position as being static in SkyRoof, before sometimes jumping to the actual updated position if it doesn't time out.
I have tried varying baud rates, firmware updates, controller calibration all to no avail. I have even tried a different PC with the same results.
The regular PC is has W11Pro.
Are you able to give me any advice as to how I may remedy this behaviour please?
73
Steve GJ6WRI & Op GH5DX (for www.dx-world.net<http://www.dx-world.net>)

[Hamlib-developer] Problem with G232B Timing out

[Steve C. <ill...@ho...>]

rotctld, Hamlib 4.5.5 Apr 05 11:43:08Z 2023 SHA=6eecd3
Report bugs to <ham...@li...>

rot_init called
initrots4_gs232a called
rot_register (601)
rot_register (609)
rot_register (610)
rot_register (602)
rot_register (603)
rot_register (611)
rot_register (612)
rot_register (604)
rot_register (605)
rot_register (606)
rot_register (607)
rot_register (608)
gs232b_rot_init called
set_conf: called
rot_open called
serial_open: COM8
serial_setup: tcgetattr
serial_setup: cfsetispeed=38400,0x000f
serial_setup: cfsetospeed=38400,0x000f
serial_setup: data_bits=8
serial_setup: parity=0
serial_setup: Handshake=None
serial_setup: tcsetattr TCSANOW
read_string_generic called, rxmax=4095 direct=1, expected_len=1
tcflush
Opened rot model 603, 'GS-232B'
Backend version: 20220109.0, Status: Stable

Good day fine people.
I'm using ROTCTLD with the following settings "-m 603 -r COM8 -t 8533 -s 38400" to control my ERC-M controller by DF9GR
The software I am using is "SkyRoof" which generally works very well, but I believe ROTCTLD drops the TCP connection on occasions and gives a time-out message.
>From the ERC-M controller I can see the rotators are turning towards their desired az & el, but the feedback from rotctld to SkyRoof is dropped. The problem exposes itself by  showing the antenna position as being static in SkyRoof, before sometimes jumping to the actual updated position if it doesn't time out.
I have tried varying baud rates, firmware updates, controller calibration all to no avail. I have even tried a different PC with the same results.
The regular PC is has W11Pro.
Are you able to give me any advice as to how I may remedy this behaviour please?
73
Steve GJ6WRI & Op GH5DX (for www.dx-world.net)

Re: [Hamlib-developer] [wsjt-devel] Hamlib new version fails on YAESU FT-100 VFO handling

[Marco C. <PY...@ou...>]

Well,

Since my issue persists and apparently nobody provided answers, I 
abandoned Hamlib NET option and I switched to Rig=YAESU FT-100: this is 
working under every situation!

73 de Marco, PY1ZRJ



Il 13/10/25 09:55, Marco Calistri via wsjt-devel ha scritto:
> *WRONG!
> *
> The issue is till present also in the new Hamlib!
>
> I need to manually switch off  the split operation in my FT-100, then 
> click again on the new band, otherwise VFOB keeps using the previous band!
>
> I use mode Rig in my WSJTX Radio Settings.
>
> Very dumb issue which was not present on the older Hamlib!
>
> Sorry for the wrong announcement!
>
> Regards!
>
> Marco, PY1ZRJ
>
> Il 13/10/25 08:19, Marco Calistri ha scritto:
>> Hello!
>>
>> Updating to
>>
>> *rigctld Hamlib 4.7~git 2025-10-10T14:52:54Z SHA=23710cf2d 64-bit*
>>
>> Has resolved the issue I spoken about in my previous message.
>>
>> So far, so good!
>>
>> Thanks,
>>
>>
>> ---
>> *73 de Marco, PY1ZRJ (former IK5BCU)*
>> **
>>
>>
>>
>> Il 30/09/25 11:57, Marco Calistri ha scritto:
>>> Hello,
>>>
>>> Hope someone of the Hamlib group being sneaking here.
>>>
>>> So far my rigctld command to drive my YAESU FT-100 CAT port has 
>>> worked flawlessly:
>>>
>>> /usr/local/bin/rigctld -m 1021 -r /dev/FT-100_USB1 -t 4532 -s 4800 
>>> *--vfo* &
>>>
>>> This by using older Hamlib version:
>>> rigctld --version: rigctld Hamlib 4.6~git 2023-07-20T21:59:57Z 
>>> SHA=aacf06 64-bit
>>>
>>> Now, using the new Hamlib version:
>>>
>>> rigctld --version: rigctld Hamlib 4.7~git 2025-09-27T16:16:32Z 
>>> SHA=0d122f6b1 64-bit
>>>
>>> One of the VFO stays on previous frequency when I switch band.
>>>
>>> For example: I start working on 10 meters band then VFOA tunes on 
>>> 28.074 and VFOB tunes on the same frequency minus or plus the audio 
>>> shift.
>>>
>>> When I switch band, for example to 17 meters, VFOA sets on 18.100, 
>>> whereas VFOB stays on 28.074!
>>>
>>> This is a really annoying behavior!
>>>
>>> I tried also without adding the *--vfo* parameter at rigctld without 
>>> success and obtaining a worst and slower switching from TX to RX.
>>>
>>> Thanks for any inputs you could provide.
>>>
>>> Marco, PY1ZRJ
>>> ---
>>> *73 de Marco, PY1ZRJ (former IK5BCU)*
>>> **
>>
>>
>
>
> ---
> *73 de Marco, PY1ZRJ (former IK5BCU)*
> **
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**

Re: [Hamlib-developer] Hamlib new version fails on YAESU FT-100 VFO handling

[Marco C. <PY...@ou...>]

*WRONG!
*
The issue is till present also in the new Hamlib!

I need to manually switch off  the split operation in my FT-100, then 
click again on the new band, otherwise VFOB keeps using the previous band!

I use mode Rig in my WSJTX Radio Settings.

Very dumb issue which was not present on the older Hamlib!

Sorry for the wrong announcement!

Regards!

Marco, PY1ZRJ

Il 13/10/25 08:19, Marco Calistri ha scritto:
> Hello!
>
> Updating to
>
> *rigctld Hamlib 4.7~git 2025-10-10T14:52:54Z SHA=23710cf2d 64-bit*
>
> Has resolved the issue I spoken about in my previous message.
>
> So far, so good!
>
> Thanks,
>
>
> ---
> *73 de Marco, PY1ZRJ (former IK5BCU)*
> **
>
>
>
> Il 30/09/25 11:57, Marco Calistri ha scritto:
>> Hello,
>>
>> Hope someone of the Hamlib group being sneaking here.
>>
>> So far my rigctld command to drive my YAESU FT-100 CAT port has 
>> worked flawlessly:
>>
>> /usr/local/bin/rigctld -m 1021 -r /dev/FT-100_USB1 -t 4532 -s 4800 
>> *--vfo* &
>>
>> This by using older Hamlib version:
>> rigctld --version: rigctld Hamlib 4.6~git 2023-07-20T21:59:57Z 
>> SHA=aacf06 64-bit
>>
>> Now, using the new Hamlib version:
>>
>> rigctld --version: rigctld Hamlib 4.7~git 2025-09-27T16:16:32Z 
>> SHA=0d122f6b1 64-bit
>>
>> One of the VFO stays on previous frequency when I switch band.
>>
>> For example: I start working on 10 meters band then VFOA tunes on 
>> 28.074 and VFOB tunes on the same frequency minus or plus the audio 
>> shift.
>>
>> When I switch band, for example to 17 meters, VFOA sets on 18.100, 
>> whereas VFOB stays on 28.074!
>>
>> This is a really annoying behavior!
>>
>> I tried also without adding the *--vfo* parameter at rigctld without 
>> success and obtaining a worst and slower switching from TX to RX.
>>
>> Thanks for any inputs you could provide.
>>
>> Marco, PY1ZRJ
>> ---
>> *73 de Marco, PY1ZRJ (former IK5BCU)*
>> **
>
>


---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**

Re: [Hamlib-developer] Hamlib new version fails on YAESU FT-100 VFO handling

[Marco C. <PY...@ou...>]

Hello!

Updating to

*rigctld Hamlib 4.7~git 2025-10-10T14:52:54Z SHA=23710cf2d 64-bit*

Has resolved the issue I spoken about in my previous message.

So far, so good!

Thanks,


---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**



Il 30/09/25 11:57, Marco Calistri ha scritto:
> Hello,
>
> Hope someone of the Hamlib group being sneaking here.
>
> So far my rigctld command to drive my YAESU FT-100 CAT port has worked 
> flawlessly:
>
> /usr/local/bin/rigctld -m 1021 -r /dev/FT-100_USB1 -t 4532 -s 4800 
> *--vfo* &
>
> This by using older Hamlib version:
> rigctld --version: rigctld Hamlib 4.6~git 2023-07-20T21:59:57Z 
> SHA=aacf06 64-bit
>
> Now, using the new Hamlib version:
>
> rigctld --version: rigctld Hamlib 4.7~git 2025-09-27T16:16:32Z 
> SHA=0d122f6b1 64-bit
>
> One of the VFO stays on previous frequency when I switch band.
>
> For example: I start working on 10 meters band then VFOA tunes on 
> 28.074 and VFOB tunes on the same frequency minus or plus the audio shift.
>
> When I switch band, for example to 17 meters, VFOA sets on 18.100, 
> whereas VFOB stays on 28.074!
>
> This is a really annoying behavior!
>
> I tried also without adding the *--vfo* parameter at rigctld without 
> success and obtaining a worst and slower switching from TX to RX.
>
> Thanks for any inputs you could provide.
>
> Marco, PY1ZRJ
> ---
> *73 de Marco, PY1ZRJ (former IK5BCU)*
> **

[Hamlib-developer] [Hamlib/Hamlib] bc5b5b: Use auto storage instead of clobbering string lite...

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: bc5b5b6725015fb9379679f2f10de8aef3ef7291
      https://github.com/Hamlib/Hamlib/commit/bc5b5b6725015fb9379679f2f10de8aef3ef7291
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-10-06 (Mon, 06 Oct 2025)

  Changed paths:
    M tests/rigctltcp.c

  Log Message:
  -----------
  Use auto storage instead of clobbering string literal.


  Commit: 8b840d8e848de077b546825a4a33f029de2ffd6a
      https://github.com/Hamlib/Hamlib/commit/8b840d8e848de077b546825a4a33f029de2ffd6a
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-10-06 (Mon, 06 Oct 2025)

  Changed paths:
    M amplifiers/elecraft/kpa.c
    M amplifiers/gemini/gemini.c

  Log Message:
  -----------
  Always return in error case

Don't fall into normal code and get a segfault.


  Commit: fdde4d35cad736e5a93509d7e9924e9bd0e931c3
      https://github.com/Hamlib/Hamlib/commit/fdde4d35cad736e5a93509d7e9924e9bd0e931c3
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-10-06 (Mon, 06 Oct 2025)

  Changed paths:
    M rigs/dummy/trxmanager.c

  Log Message:
  -----------
  Remove funky debug writes in trxmanager.c


  Commit: 7b9372ac46fd2c93f070c0cca7c19dcc34c684c7
      https://github.com/Hamlib/Hamlib/commit/7b9372ac46fd2c93f070c0cca7c19dcc34c684c7
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-10-06 (Mon, 06 Oct 2025)

  Changed paths:
    M rigs/kenwood/k3.c

  Log Message:
  -----------
  Fold range check into existing switch statement

Cleaner code, and avoids a bogus squawk from gcc -fanalyzer.


  Commit: 48117e403ffbe8ff0c006e2ba9dcfc99f23860ee
      https://github.com/Hamlib/Hamlib/commit/48117e403ffbe8ff0c006e2ba9dcfc99f23860ee
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-10-06 (Mon, 06 Oct 2025)

  Changed paths:
    M rigs/dummy/rot_pstrotator.c

  Log Message:
  -----------
  Fix fd leak in rot_pstrotator.c

Close orphan fd in error case.
And in the normal close routine, too.


  Commit: 7349814e578a52939882ec8ab7ee1fa528328574
      https://github.com/Hamlib/Hamlib/commit/7349814e578a52939882ec8ab7ee1fa528328574
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-10-07 (Tue, 07 Oct 2025)

  Changed paths:
    M rigs/kenwood/kenwood.c

  Log Message:
  -----------
  Don't call remove_nonprint() if error occurred

The buffer may not contain a well-formed string. Use count returned by
  read_string(), and check for short response. Replace 2 strlen() calls
  with maximum of 1.
Reformat some comments to minimize wrapping.


  Commit: a72397ec607cd6926149ebc4acbf189d3eb0ade6
      https://github.com/Hamlib/Hamlib/commit/a72397ec607cd6926149ebc4acbf189d3eb0ade6
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-10-08 (Wed, 08 Oct 2025)

  Changed paths:
    M rigs/dummy/rot_pstrotator.c
    M rigs/kenwood/kenwood.c

  Log Message:
  -----------
  Use correct length when transfering result to caller.

Fix formatting.
Make trace message jibe with its surrounding.


  Commit: 23710cf2da3d8a05c7ed0b9bdecefe020404f0d1
      https://github.com/Hamlib/Hamlib/commit/23710cf2da3d8a05c7ed0b9bdecefe020404f0d1
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-10-10 (Fri, 10 Oct 2025)

  Changed paths:
    M amplifiers/elecraft/kpa.c
    M rigs/kenwood/kenwood.c

  Log Message:
  -----------
  Use return value from remove_nonprint()

Fix formatting glitch


Compare: https://github.com/Hamlib/Hamlib/compare/e992691354fb...23710cf2da3d

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

Re: [Hamlib-developer] Version 3.0.0 rc-1

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

* On 2025 11 Oct 06:25 -0500, Greg Foster wrote:
> WSJTX 3.0.0-rc1 (and release 2.7.x.x not sure the exact release)
> 
> Rig - Icom 7600
> 
> Antenna Controller - SteppIR SDA-100
> 
>  
> 
> While I was running WSJTC ver  2.6.1 whenever I changed freq/bands on WSJTX
> the Icom 7600 would move to the correct frequency and the SteppIR controller
> would follow suite. Now with WSJTX 3.0.0 rc1 when I make the frequency
> change in WSJTX the Icom 7600 follows suite but the Steppir does not, I have
> to adjust the freq. on the rig slightly for it to move to the correct
> frequency. 
> 
>  
> 
> Is there something I can do to fix this?

Hi Greg.

Hamlib does not support the SteppIR directly.  As you note, it monitors
the serial line and apparently acts on commands it recognizes.  I don't
know what version of Hamlib was included in WSJT-X 2.6.1 and what
changes have occurred since then without knowing the exact Hamlib
versions.

It seems strange to me that it fails, but I don't have Icom or SteppIR
so I cannot test.  Hopefully someone can help.

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] Version 3.0.0 rc-1

[Greg F. <gre...@sy...>]

WSJTX 3.0.0-rc1 (and release 2.7.x.x not sure the exact release)

Rig - Icom 7600

Antenna Controller - SteppIR SDA-100

 

While I was running WSJTC ver  2.6.1 whenever I changed freq/bands on WSJTX
the Icom 7600 would move to the correct frequency and the SteppIR controller
would follow suite. Now with WSJTX 3.0.0 rc1 when I make the frequency
change in WSJTX the Icom 7600 follows suite but the Steppir does not, I have
to adjust the freq. on the rig slightly for it to move to the correct
frequency. 

 

Is there something I can do to fix this?

 

Greg Foster

VE3PJ

613-328-6538

 

[Hamlib-developer] [Hamlib/Hamlib] 228347: Move FIFO_RIG from hamlib/rig.h to fifo.h where it...

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 22834737075ddbb0a7a36e179a58a8d1439415cf
      https://github.com/Hamlib/Hamlib/commit/22834737075ddbb0a7a36e179a58a8d1439415cf
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-09-27 (Sat, 27 Sep 2025)

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

  Log Message:
  -----------
  Move FIFO_RIG from hamlib/rig.h to fifo.h where it belongs.

Add header to fifo.h
Update structure pointer in rig_state


  Commit: 00020e6d9d1c7c17544fb3ce8f9ec64ae8ad0be4
      https://github.com/Hamlib/Hamlib/commit/00020e6d9d1c7c17544fb3ce8f9ec64ae8ad0be4
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-09-27 (Sat, 27 Sep 2025)

  Changed paths:
    M src/fifo.c
    M src/fifo.h
    M src/rig.c

  Log Message:
  -----------
  Add 'hl_' prefix to names of push(), pop() and peek()
  to avoid conflict with app code.

Add header to fifo.c
Drop unused structure member in rig.c


  Commit: 8bd19c4db80d22f0a710c487bfe4acc1a15e9179
      https://github.com/Hamlib/Hamlib/commit/8bd19c4db80d22f0a710c487bfe4acc1a15e9179
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-09-27 (Sat, 27 Sep 2025)

  Changed paths:
    M include/hamlib/rig_state.h
    M src/fifo.h

  Log Message:
  -----------
  Change pseudo-anonymous structure name to convention.


  Commit: d391e569ce4bb370720376363eacd6ba062f7702
      https://github.com/Hamlib/Hamlib/commit/d391e569ce4bb370720376363eacd6ba062f7702
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-09-30 (Tue, 30 Sep 2025)

  Changed paths:
    M src/rig.c

  Log Message:
  -----------
  Add rig to opened list even if skip_init is set.

Just in case someone finishes CHECK_RIG_ARG,
 or checks status from remove_opened_rig().


  Commit: 4ad91cad0a70d2a50e98317076484f420d2d4414
      https://github.com/Hamlib/Hamlib/commit/4ad91cad0a70d2a50e98317076484f420d2d4414
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-10-03 (Fri, 03 Oct 2025)

  Changed paths:
    M src/misc.c

  Log Message:
  -----------
  Add a fallback function for spaces()

This shouldn't be needed, but somebody somewhere sometime is going
to use an old rigctl with a new hamlib and get an undefined symbol.

Should go away with 5.0.


  Commit: d3769bf948a8bbe57dd982de2fc2dfbe4dea1d4d
      https://github.com/Hamlib/Hamlib/commit/d3769bf948a8bbe57dd982de2fc2dfbe4dea1d4d
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-10-03 (Fri, 03 Oct 2025)

  Changed paths:
    M bindings/python/test_Hamlib_class.py

  Log Message:
  -----------
  Don't forget the noise


  Commit: d11d7b2d0029e901e90f62e866e2a3c3e9924c50
      https://github.com/Hamlib/Hamlib/commit/d11d7b2d0029e901e90f62e866e2a3c3e9924c50
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-10-06 (Mon, 06 Oct 2025)

  Changed paths:
    M bindings/python/test_Hamlib_class.py
    M include/hamlib/rig.h
    M include/hamlib/rig_state.h
    M src/fifo.c
    M src/fifo.h
    M src/misc.c
    M src/rig.c

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


Compare: https://github.com/Hamlib/Hamlib/compare/54a5097c7e44...d11d7b2d0029

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

[Hamlib-developer] [Hamlib/Hamlib] c0717e: Remove duplicated command from --help output

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: c0717e783475e70a2a40f3d08199379f324cc1b4
      https://github.com/Hamlib/Hamlib/commit/c0717e783475e70a2a40f3d08199379f324cc1b4
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-10-04 (Sat, 04 Oct 2025)

  Changed paths:
    M tests/rigctl_parse.c

  Log Message:
  -----------
  Remove duplicated command from --help output


  Commit: 6238a5ef1b605168c06767836a882007fb5fa59c
      https://github.com/Hamlib/Hamlib/commit/6238a5ef1b605168c06767836a882007fb5fa59c
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-10-04 (Sat, 04 Oct 2025)

  Changed paths:
    M tests/rigctl_parse.c

  Log Message:
  -----------
  Reorder commands in --help output

Puts more related get/set commands side by side in the columnar output.


  Commit: 19ce6d30b0ff589d7866fa9c2457cc56d0b64d81
      https://github.com/Hamlib/Hamlib/commit/19ce6d30b0ff589d7866fa9c2457cc56d0b64d81
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-10-04 (Sat, 04 Oct 2025)

  Changed paths:
    M tests/rotctl_parse.c

  Log Message:
  -----------
  Put get_conf near set_conf


  Commit: 0546e764afe4fdca95b471d11858e74724333da8
      https://github.com/Hamlib/Hamlib/commit/0546e764afe4fdca95b471d11858e74724333da8
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-10-05 (Sun, 05 Oct 2025)

  Changed paths:
    M tests/rigctl_parse.c

  Log Message:
  -----------
  Update comments

All letters are used now, rig_set/rig_get are added and -W is
reserved by POSIX.2 for implementation extensions of get_opt,
but it doesn't apply here because this code is using strcmp()
and the W command which is implemented is not prefixed by a '-'.


  Commit: a7188c201ac552b6155fe25bfab85e44cdd76c62
      https://github.com/Hamlib/Hamlib/commit/a7188c201ac552b6155fe25bfab85e44cdd76c62
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-10-05 (Sun, 05 Oct 2025)

  Changed paths:
    M tests/rigctl_parse.c

  Log Message:
  -----------
  Put set_gpio before get_gpio

Like other set/get pairs.


  Commit: 486ec607dd84499f61e07e1d0e6a80633ab0809d
      https://github.com/Hamlib/Hamlib/commit/486ec607dd84499f61e07e1d0e6a80633ab0809d
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-10-05 (Sun, 05 Oct 2025)

  Changed paths:
    M tests/rigctl_parse.c

  Log Message:
  -----------
  Remove space for consistency with other descriptions


  Commit: bceb1a1fdf42410b876571f0a167d1fa8abefa3f
      https://github.com/Hamlib/Hamlib/commit/bceb1a1fdf42410b876571f0a167d1fa8abefa3f
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-10-05 (Sun, 05 Oct 2025)

  Changed paths:
    M tests/rigctl_parse.c

  Log Message:
  -----------
  Do not use abbreviations where there is enough space


  Commit: e992691354fb0d1966660f84314bfa31f3ee39c5
      https://github.com/Hamlib/Hamlib/commit/e992691354fb0d1966660f84314bfa31f3ee39c5
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-10-06 (Mon, 06 Oct 2025)

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

  Log Message:
  -----------
  Merge GitHub PR @1933


Compare: https://github.com/Hamlib/Hamlib/compare/d11d7b2d0029...e992691354fb

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

[Hamlib-developer] [Hamlib/Hamlib] 54a509: Use rot->caps min_az, max_az, min_el, max_el inste...

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 54a5097c7e44148dc5c02ad6194744c60fbd86f4
      https://github.com/Hamlib/Hamlib/commit/54a5097c7e44148dc5c02ad6194744c60fbd86f4
  Author: David Balharrie <da...@ba...>
  Date:   2025-10-06 (Mon, 06 Oct 2025)

  Changed paths:
    M rigs/dummy/rot_dummy.c

  Log Message:
  -----------
  Use rot->caps min_az, max_az, min_el, max_el instead of numbers. Fix not being able to move beyond 180 using move CW command.



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