hamlib-developer — hamlib developers forum

[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

[Hamlib-developer] [Hamlib/Hamlib] 11be2d: Support tuning FT-450 notch filter

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 11be2d6549a3c5f31ebbc0ccf5c586de4df4a833
      https://github.com/Hamlib/Hamlib/commit/11be2d6549a3c5f31ebbc0ccf5c586de4df4a833
  Author: telewizoor <not...@gi...>
  Date:   2025-10-06 (Mon, 06 Oct 2025)

  Changed paths:
    M rigs/yaesu/ft450.h

  Log Message:
  -----------
  Support tuning FT-450 notch filter

Per GitHub issue #1929, enable use of `L NOTCHF xxxx` command for the
Yaesu FT-450D.



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

[Hamlib-developer] RV: Hamlib not work

[Luis T. <ea5...@gm...>]

Good morning, sorry I forgot to tell you, I'm using Windows 11.
 
De: Luis Trabucco <ea5...@gm...> 
Enviado el: sábado, 4 de octubre de 2025 19:32
Para: ham...@li...
Asunto: Hamlib not work
 
Good afternoon, I'm trying to use WSJT-X with Hamlib and can't get it to
work. It works fine with: Icom IC-728 - MSHV - Log4om - GridTracker and
Hamlib w64-4.6.4, but I can't get to work with WSKT-X Improved, and it
doesn't work with JTDX either. This is the string I use:
rigctld --model=3016 --rig-file=COM5 --serial-speed=1200 --port=4532
--civaddr=56 --set-conf=stop_bits=1 --civaddr=56 f v.
Can you please tell me what's wrong?.
Thanks.

Re: [Hamlib-developer] Two version of hamlib installed

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

I have been running that way for a couple of years on openSUSE 
Tumbleweed with no problems.  The distro version of Hamlib(4.6.5) is in 
/usr, my compiled version (4.7-git) is in /usr/local, and my 
self-compiled apps are in ~/.local(cqrlog, wsjtx-improved) or in 
/usr/local(tlf, trlinux).

I just had to make sure that the paths for rigctld in the apps had 
/usr/local in them, and that /usr/local was first in /etc/ld.so.conf. YMMV.

Keeping the distro version installed is just to keep the package manager 
happy.

On 10/4/25 9:33 PM, Phil wrote:
> I want to make sure that I don't cause myself problems by having two 
> versions of hamlib installed.
>
> I have built hamlib 4.6.5 and it is installed, by default, in 
> /usr/local. I also have version 4.6.2 installed which is the Ubuntu 
> package installation.
>
> Should I just uninstall libhamlib-dev version 4.6.2 and leave 
> libhamlib-utils 4.6.2 and libhamlib-4t64 version 4.6.2? The last two 
> libraries are required by wsjt-x and fldigi. If I don't uninstall 
> these two then I think I will run into conflict problems.
>
I would uninstall the -dev package and use 4.6.5 for compilations.

73 n3gb

[Hamlib-developer] Two version of hamlib installed

[Phil <phi...@gm...>]

I want to make sure that I don't cause myself problems by having two 
versions of hamlib installed.

I have built hamlib 4.6.5 and it is installed, by default, in 
/usr/local. I also have version 4.6.2 installed which is the Ubuntu 
package installation.

Should I just uninstall libhamlib-dev version 4.6.2 and leave 
libhamlib-utils 4.6.2 and libhamlib-4t64 version 4.6.2? The last two 
libraries are required by wsjt-x and fldigi. If I don't uninstall these 
two then I think I will run into conflict problems.

-- 
Regards,
Phil

[Hamlib-developer] Hamlib not work

[Luis T. <ea5...@gm...>]

Good afternoon, I'm trying to use WSJT-X with Hamlib and can't get it to
work. It works fine with: Icom IC-728 - MSHV - Log4om - GridTracker and
Hamlib w64-4.6.4, but I can't get to work with WSKT-X Improved, and it
doesn't work with JTDX either. This is the string I use:
rigctld --model=3016 --rig-file=COM5 --serial-speed=1200 --port=4532
--civaddr=56 --set-conf=stop_bits=1 --civaddr=56 f v.
Can you please tell me what's wrong?.
Thanks.

Re: [Hamlib-developer] Rotator Dummy Issue at 180 degrees

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

That would make more sense than magic numbers. The same would go for the elevation values.

-----Original Message-----
From: George Baltz <geo...@gm...> 
Sent: 30 September 2025 19:41
To: ham...@li...
Subject: Re: [Hamlib-developer] Rotator Dummy Issue at 180 degrees

I wonder if those should just be using caps->min_az and caps->max_az?

On 9/30/25 1:01 PM, David Balharrie wrote:
> The Dummy rotator has a Min_Azimuth of -180 and Max_Azimuth of 450 degrees. Issuing set position commands with these values confirms this.
>
> It looks like the error is here
>
>      case ROT_MOVE_CCW:
>          return dummy_rot_set_position(rot, -180, priv->target_el);
>
>      case ROT_MOVE_CW:
>          return dummy_rot_set_position(rot, 180, priv->target_el);
>
> case ROT_MOVE_CW should be this...
>
>      case ROT_MOVE_CW:
>          return dummy_rot_set_position(rot, 450, priv->target_el);
>
> 73 de David M0DGB/G8FKH
>
> -----Original Message-----
> From: Nate Bargmann <n0...@n0...>
> Sent: 29 September 2025 18:18
> To: ham...@li...
> Subject: Re: [Hamlib-developer] Rotator Dummy Issue at 180 degrees
>
> * On 2025 29 Sep 09:48 -0500, David Balharrie wrote:
>> I rotated the Dummy Rotator to 180, then issued a Rotate CW (Right) 
>> from 180 and nothing happened. The command returned ok. You can do a 
>> rotate to a bearing ok. This can be demonstrated in rotctl. It is 
>> present in versions 3.6.2 through 4.7.
>>
>> I don't see the Dummy folder in rotators, otherwise I would have 
>> looked at the source. Where is Dummy Rotator located?
> It lives under rigs/dummy:
>
> https://github.com/Hamlib/Hamlib/blob/master/rigs/dummy/rot_dummy.c
>
> It probably should've been broken out under rotators, but due to historical reasons, here we are.
>
> 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 mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Rotator Dummy Issue at 180 degrees

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

I wonder if those should just be using caps->min_az and caps->max_az?

On 9/30/25 1:01 PM, David Balharrie wrote:
> The Dummy rotator has a Min_Azimuth of -180 and Max_Azimuth of 450 degrees. Issuing set position commands with these values confirms this.
>
> It looks like the error is here
>
>      case ROT_MOVE_CCW:
>          return dummy_rot_set_position(rot, -180, priv->target_el);
>
>      case ROT_MOVE_CW:
>          return dummy_rot_set_position(rot, 180, priv->target_el);
>
> case ROT_MOVE_CW should be this...
>
>      case ROT_MOVE_CW:
>          return dummy_rot_set_position(rot, 450, priv->target_el);
>
> 73 de David M0DGB/G8FKH
>
> -----Original Message-----
> From: Nate Bargmann <n0...@n0...>
> Sent: 29 September 2025 18:18
> To: ham...@li...
> Subject: Re: [Hamlib-developer] Rotator Dummy Issue at 180 degrees
>
> * On 2025 29 Sep 09:48 -0500, David Balharrie wrote:
>> I rotated the Dummy Rotator to 180, then issued a Rotate CW (Right)
>> from 180 and nothing happened. The command returned ok. You can do a
>> rotate to a bearing ok. This can be demonstrated in rotctl. It is
>> present in versions 3.6.2 through 4.7.
>>
>> I don't see the Dummy folder in rotators, otherwise I would have
>> looked at the source. Where is Dummy Rotator located?
> It lives under rigs/dummy:
>
> https://github.com/Hamlib/Hamlib/blob/master/rigs/dummy/rot_dummy.c
>
> It probably should've been broken out under rotators, but due to historical reasons, here we are.
>
> 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] Rotator Dummy Issue at 180 degrees

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

The Dummy rotator has a Min_Azimuth of -180 and Max_Azimuth of 450 degrees. Issuing set position commands with these values confirms this.

It looks like the error is here

    case ROT_MOVE_CCW:
        return dummy_rot_set_position(rot, -180, priv->target_el);

    case ROT_MOVE_CW:
        return dummy_rot_set_position(rot, 180, priv->target_el);

case ROT_MOVE_CW should be this...

    case ROT_MOVE_CW:
        return dummy_rot_set_position(rot, 450, priv->target_el);

73 de David M0DGB/G8FKH

-----Original Message-----
From: Nate Bargmann <n0...@n0...> 
Sent: 29 September 2025 18:18
To: ham...@li...
Subject: Re: [Hamlib-developer] Rotator Dummy Issue at 180 degrees

* On 2025 29 Sep 09:48 -0500, David Balharrie wrote:
> I rotated the Dummy Rotator to 180, then issued a Rotate CW (Right) 
> from 180 and nothing happened. The command returned ok. You can do a 
> rotate to a bearing ok. This can be demonstrated in rotctl. It is 
> present in versions 3.6.2 through 4.7.
> 
> I don't see the Dummy folder in rotators, otherwise I would have 
> looked at the source. Where is Dummy Rotator located?

It lives under rigs/dummy:

https://github.com/Hamlib/Hamlib/blob/master/rigs/dummy/rot_dummy.c

It probably should've been broken out under rotators, but due to historical reasons, here we are.

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 new version fails on YAESU FT-100 VFO handling

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

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] Fwd: [wsjt-devel] Hamlib new version fails on YAESU FT-100 VFO handling

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

-------- Messaggio Inoltrato --------
Oggetto: 	[wsjt-devel] Hamlib new version fails on YAESU FT-100 VFO 
handling
Data: 	Mon, 29 Sep 2025 18:13:43 -0300
Mittente: 	Marco Calistri via wsjt-devel <wsj...@li...>
Rispondi-a: 	PY...@ou..., WSJT software development 
<wsj...@li...>
Organizzazione: 	Hamradio
A: 	'WSJT software development' <wsj...@li...>
CC: 	Marco Calistri <PY...@ou...>

Re: [Hamlib-developer] Rotator Dummy Issue at 180 degrees

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

OK Thanks.. 

73 de David

-----Original Message-----
From: Nate Bargmann <n0...@n0...> 
Sent: 29 September 2025 18:18
To: ham...@li...
Subject: Re: [Hamlib-developer] Rotator Dummy Issue at 180 degrees

* On 2025 29 Sep 09:48 -0500, David Balharrie wrote:
> I rotated the Dummy Rotator to 180, then issued a Rotate CW (Right) 
> from 180 and nothing happened. The command returned ok. You can do a 
> rotate to a bearing ok. This can be demonstrated in rotctl. It is 
> present in versions 3.6.2 through 4.7.
> 
> I don't see the Dummy folder in rotators, otherwise I would have 
> looked at the source. Where is Dummy Rotator located?

It lives under rigs/dummy:

https://github.com/Hamlib/Hamlib/blob/master/rigs/dummy/rot_dummy.c

It probably should've been broken out under rotators, but due to historical reasons, here we are.

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] Rotator Dummy Issue at 180 degrees

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

* On 2025 29 Sep 09:48 -0500, David Balharrie wrote:
> I rotated the Dummy Rotator to 180, then issued a Rotate CW (Right)
> from 180 and nothing happened. The command returned ok. You can do a
> rotate to a bearing ok. This can be demonstrated in rotctl. It is
> present in versions 3.6.2 through 4.7.
> 
> I don't see the Dummy folder in rotators, otherwise I would have
> looked at the source. Where is Dummy Rotator located?

It lives under rigs/dummy:

https://github.com/Hamlib/Hamlib/blob/master/rigs/dummy/rot_dummy.c

It probably should've been broken out under rotators, but due to
historical reasons, here we are.

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] Rotator Dummy Issue at 180 degrees

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

I rotated the Dummy Rotator to 180, then issued a Rotate CW (Right) from 180 and nothing happened. The command returned ok. You can do a rotate to a bearing ok. This can be demonstrated in rotctl. It is present in versions 3.6.2 through 4.7.

I don't see the Dummy folder in rotators, otherwise I would have looked at the source. Where is Dummy Rotator located?

73 de David M0DGB/G8FKH