hamlib-developer — hamlib developers forum

[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

Re: [Hamlib-developer] Failure of network connection of wsjtx on mac mini m4 and flex 6500

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

That's a lot of output. Looking at the final couple of pages of the 
RigControl.log, the problem that I see is that 192.168.67:2237 is not a 
well-formed IP address - it is missing an octet(neither is 127.0.0.0.1 
valid; too many.)

If this is not the problem, please send those two files with only the 
data from your new tries.

73 n3gb

On 9/28/25 8:50 AM, michael schaldenbrand wrote:
> Thanks for your help.
>
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] Failure of network connection of wsjtx on mac mini m4 and flex 6500

[michael s. <msc...@gm...>]

Thanks for your help.

[Hamlib-developer] [Hamlib/Hamlib] 744fe5: Remove redundant path from BUILT_SOURCES

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 744fe5a066e3656907ea7f59d08e9ec4545cc993
      https://github.com/Hamlib/Hamlib/commit/744fe5a066e3656907ea7f59d08e9ec4545cc993
  Author: Jan Engelhardt <ej...@in...>
  Date:   2025-09-26 (Fri, 26 Sep 2025)

  Changed paths:
    M src/Makefile.am

  Log Message:
  -----------
  Remove redundant path from BUILT_SOURCES

Re: GitHub Issue #1895

In response to a query to the automake mailing list, this reply was
received:

On Wednesday 2025-09-24 19:05, Nate Bargmann wrote:

>make[1]: don't know how to make ./hamlibdatetime.h. Stop

Something wanted to make "./hamlibdatetime.h", but you only provide
a rule for "hamlibdatetime.h":

>hamlibdatetime.h: FORCE
>       @if test -x $(top_srcdir)/.git ; then \
>               echo "/* This date time is from the last non-merge commit to Hamlib. */" > $(builddir)/$(@F).tmp ;\
>               echo "#define HAMLIBDATETIME "\"$$(TZ=UTC git --git-dir=$(top_srcdir)/.git log --no-merges
+--date='format-local:%Y-%m-%dT%H:%M:%SZ SHA=' --format='%cd' -n 1)$$(git --git-dir=$(top_srcdir)/.git log --no-merges -n 1 | head
+-n 1 | cut -c8-13)\"  >> $(builddir)/$(@F).tmp ;\

The distinction is important.

>BUILT_SOURCES = $(builddir)/hamlibdatetime.h

All targets are already relative to ${builddir},
so explicitly mentioning ${builddir} is wrong for
targets, and redundant in the recipe.

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

Removing "$(builddir)/" allows FreeBSD make to enter the rule.  GNU make
wasn't bothered by the prepending of the path when comparing to the
Makefile target.


  Commit: 34fa8d0e2fc9eeb21e1d4f86df65dfc7c1c135e4
      https://github.com/Hamlib/Hamlib/commit/34fa8d0e2fc9eeb21e1d4f86df65dfc7c1c135e4
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-09-26 (Fri, 26 Sep 2025)

  Changed paths:
    M src/Makefile.am

  Log Message:
  -----------
  Refactor hamlibdatetime.h target

Re: GitHub Issue #1895

Thanks to inspiration from Jan Engelhardt <ej...@in...> via the GNU
automake mailing list on Thu, 25 Sep 2025 20:40:21 +0200 (CEST):
https://lists.gnu.org/archive/html/automake/2025-09/msg00013.html
The 'diff' command has been wrapped inside an 'if' conditional to
hopefully hide its return value from FreeBSD make.

Also make a couple other small changes.


  Commit: 0d122f6b1a56a5ed9424dd11ac335cd37093f78f
      https://github.com/Hamlib/Hamlib/commit/0d122f6b1a56a5ed9424dd11ac335cd37093f78f
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-09-27 (Sat, 27 Sep 2025)

  Changed paths:
    M src/Makefile.am

  Log Message:
  -----------
  Restore information message from diff

Make sure tab preceeds all indented lines.


  Commit: d09f6b5dab19b6fc851b884dbcf8e637529d0a90
      https://github.com/Hamlib/Hamlib/commit/d09f6b5dab19b6fc851b884dbcf8e637529d0a90
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-09-27 (Sat, 27 Sep 2025)

  Changed paths:
    M src/Makefile.am

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


Compare: https://github.com/Hamlib/Hamlib/compare/dbea10e65524...d09f6b5dab19

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

[Hamlib-developer] [Hamlib/Hamlib] 519692: Fix command to put bandwidth control back to bandw...

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 51969202efe78345a1df22c66e469f03dcab8e9b
      https://github.com/Hamlib/Hamlib/commit/51969202efe78345a1df22c66e469f03dcab8e9b
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-09-25 (Thu, 25 Sep 2025)

  Changed paths:
    M rigs/tentec/orion.c

  Log Message:
  -----------
  Fix command to put bandwidth control back to bandwidth knob

Adds a missing *. Thanks to @peterdulowsky.

Fixes issue #1923.


  Commit: dbea10e65524a41e73017f64ceb88f6b3e6bd59a
      https://github.com/Hamlib/Hamlib/commit/dbea10e65524a41e73017f64ceb88f6b3e6bd59a
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-09-27 (Sat, 27 Sep 2025)

  Changed paths:
    M rigs/tentec/orion.c

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


Compare: https://github.com/Hamlib/Hamlib/compare/44eaded28388...dbea10e65524

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

[Hamlib-developer] [Hamlib/Hamlib] 50fc45: Remove duplicated define

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 50fc454a0b6731ffa110a8031ecc777d78d0fcba
      https://github.com/Hamlib/Hamlib/commit/50fc454a0b6731ffa110a8031ecc777d78d0fcba
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-09-24 (Wed, 24 Sep 2025)

  Changed paths:
    M include/hamlib/rotlist.h

  Log Message:
  -----------
  Remove duplicated define

Fixes:
../include/hamlib/rotlist.h:237: Warning 322: Redundant redeclaration of identifier 'ROT_MODEL_RT21' ignored,


  Commit: 44eaded28388f4368b938acd5332c51e41b86ff9
      https://github.com/Hamlib/Hamlib/commit/44eaded28388f4368b938acd5332c51e41b86ff9
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-09-25 (Thu, 25 Sep 2025)

  Changed paths:
    M include/hamlib/rig.h

  Log Message:
  -----------
  Fix Doxygen description


Compare: https://github.com/Hamlib/Hamlib/compare/1ecf72171490...44eaded28388

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

Re: [Hamlib-developer] [Fwd: Sunsetting SourceForge Developer Web (User Web)]

[Brian M. <bd...@fe...>]

On Tue, 23 Sep 2025 16:31:01 -0500
Nate Bargmann <n0...@n0...> wrote:

> Probably, but these browsers treat HTTPS as some sort of panacea and
> HTTP as some sort of pariah.  Does the snapshots page really require
> HTTPS?  IMO, no.

Well in the modern internet the general view is that everything should
be encrypted to defend against attacks that are simple to implement and
to encourage the use of certificates provided by organisations such as
LetsEncrypt. I suppose that anything that hides potentially
sensitive information is "a good thing"[tm].

Currently Firefox does permit an http:// link to be followed after
clicking through a warning, but there will probably come a time when it
will no longer do so. I don't know when this will happen, but it's
bound to be on the horizon.

-- 

Brian  G8SEZ

Re: [Hamlib-developer] [Fwd: Sunsetting SourceForge Developer Web (User Web)]

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

* On 2025 23 Sep 15:20 -0500, Dave Baxter via Hamlib-developer wrote:
> The https://hamlib.org/  address is failing from here in the Uk (for me
> anyway)
> 
> FireFox 143.0.1 says the page is not secure, and just sits there with a
> blank page.

http://hamlib.org does redirect to https://hamlib.github.io/

> If I attempt with www.hamlib.org,  I end up at https://hamlib.github.io/ 
> (That also has a link back to SourceForge!)

Which is correct.  There is an immediate redirect from
hamlib.sourceforge.net to hamlib.github.io.

> Something needs tweaking I think.

Probably, but these browsers treat HTTPS as some sort of panacea and
HTTP as some sort of pariah.  Does the snapshots page really require
HTTPS?  IMO, no.

I took over the hamlib.org domain from Martin Ewing years back and set
it to point to one of the sites and then things changed so I stuck the
redirect at SourceForge to have one landing page.

I don't claim to be any expert...

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] [Fwd: Sunsetting SourceForge Developer Web (User Web)]

[D. R. E. <doc...@gm...>]

Dave Baxter via Hamlib-developer wrote on 9/23/25 14:11:
> The https://hamlib.org/  address is failing from here in the Uk (for me
> anyway)
> 

Also here in Colorado, but with different message:
   Firefox can’t establish a connection to the server at hamlib.org.

> FireFox 143.0.1 says the page is not secure, and just sits there with a
> blank page.
> 
> If I attempt with www.hamlib.org,  I end up at
> https://hamlib.github.io/  (That also has a link back to SourceForge!)

Yep, same here.

   Doc  N7DR

-- 
Web:  http://enginehousebooks.com/drevans

Re: [Hamlib-developer] [Fwd: Sunsetting SourceForge Developer Web (User Web)]

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

The https://hamlib.org/  address is failing from here in the Uk (for me 
anyway)

FireFox 143.0.1 says the page is not secure, and just sits there with a 
blank page.

If I attempt with www.hamlib.org,  I end up at 
https://hamlib.github.io/  (That also has a link back to SourceForge!)

Something needs tweaking I think.

73.

Dave.


On 23/09/2025 20:11, Nate Bargmann wrote:
> I have completed moving the daily snapshots page to:
>
> https://hamlib.sourceforge.net/snapshots/
>
> Visitors to the old page will see a page that points to the new link and
> their browser will be redirected after 30 seconds.
>
> I have updated all links in the Hamlib repository, the main GitHub page,
> thehttps://hamlib.org landing page, and the Wiki pages.
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer