hamlib-developer Mailing List for Ham Radio Control Libraries
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer — hamlib developers forum
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(24) |
Oct
(16) |
Nov
(8) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(49) |
Feb
(17) |
Mar
(3) |
Apr
(7) |
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
(8) |
Sep
(18) |
Oct
(15) |
Nov
(15) |
Dec
(26) |
| 2002 |
Jan
(46) |
Feb
(14) |
Mar
(44) |
Apr
(3) |
May
(6) |
Jun
(47) |
Jul
(40) |
Aug
(14) |
Sep
(59) |
Oct
(39) |
Nov
(58) |
Dec
(76) |
| 2003 |
Jan
(82) |
Feb
(66) |
Mar
(37) |
Apr
(56) |
May
(34) |
Jun
(19) |
Jul
(23) |
Aug
(55) |
Sep
(31) |
Oct
(40) |
Nov
(21) |
Dec
(60) |
| 2004 |
Jan
(57) |
Feb
(110) |
Mar
(41) |
Apr
(17) |
May
(18) |
Jun
(19) |
Jul
(18) |
Aug
(5) |
Sep
(31) |
Oct
(16) |
Nov
(26) |
Dec
(36) |
| 2005 |
Jan
(69) |
Feb
(26) |
Mar
(62) |
Apr
(120) |
May
(31) |
Jun
(47) |
Jul
(7) |
Aug
(27) |
Sep
(4) |
Oct
(9) |
Nov
(26) |
Dec
(21) |
| 2006 |
Jan
(13) |
Feb
(26) |
Mar
(38) |
Apr
(31) |
May
(17) |
Jun
(6) |
Jul
(23) |
Aug
(6) |
Sep
(38) |
Oct
(87) |
Nov
(49) |
Dec
(49) |
| 2007 |
Jan
(52) |
Feb
(19) |
Mar
(20) |
Apr
(5) |
May
(25) |
Jun
(15) |
Jul
(49) |
Aug
(43) |
Sep
(21) |
Oct
(21) |
Nov
(27) |
Dec
(10) |
| 2008 |
Jan
(23) |
Feb
(20) |
Mar
(25) |
Apr
(39) |
May
(36) |
Jun
(17) |
Jul
(10) |
Aug
(18) |
Sep
(44) |
Oct
(88) |
Nov
(60) |
Dec
(65) |
| 2009 |
Jan
(99) |
Feb
(91) |
Mar
(49) |
Apr
(34) |
May
(52) |
Jun
(9) |
Jul
(11) |
Aug
(4) |
Sep
(41) |
Oct
(16) |
Nov
(51) |
Dec
(71) |
| 2010 |
Jan
(43) |
Feb
(79) |
Mar
(59) |
Apr
(55) |
May
(51) |
Jun
(38) |
Jul
(38) |
Aug
(61) |
Sep
(53) |
Oct
(46) |
Nov
(43) |
Dec
(41) |
| 2011 |
Jan
(74) |
Feb
(96) |
Mar
(41) |
Apr
(42) |
May
(61) |
Jun
(66) |
Jul
(50) |
Aug
(40) |
Sep
(11) |
Oct
(30) |
Nov
(21) |
Dec
(45) |
| 2012 |
Jan
(59) |
Feb
(4) |
Mar
(52) |
Apr
(19) |
May
(62) |
Jun
(46) |
Jul
(61) |
Aug
(18) |
Sep
(21) |
Oct
(25) |
Nov
(66) |
Dec
(41) |
| 2013 |
Jan
(36) |
Feb
(64) |
Mar
(37) |
Apr
(24) |
May
(74) |
Jun
(40) |
Jul
(43) |
Aug
(34) |
Sep
(65) |
Oct
(52) |
Nov
(23) |
Dec
(20) |
| 2014 |
Jan
(18) |
Feb
(29) |
Mar
(13) |
Apr
(41) |
May
(10) |
Jun
(12) |
Jul
(16) |
Aug
(25) |
Sep
(20) |
Oct
(56) |
Nov
(43) |
Dec
(61) |
| 2015 |
Jan
(36) |
Feb
(38) |
Mar
(92) |
Apr
(42) |
May
(13) |
Jun
(19) |
Jul
(18) |
Aug
(22) |
Sep
(21) |
Oct
(2) |
Nov
(49) |
Dec
(22) |
| 2016 |
Jan
(55) |
Feb
(144) |
Mar
(40) |
Apr
(98) |
May
(61) |
Jun
(36) |
Jul
(16) |
Aug
(33) |
Sep
(59) |
Oct
(16) |
Nov
(37) |
Dec
(32) |
| 2017 |
Jan
(70) |
Feb
(71) |
Mar
(14) |
Apr
(43) |
May
(31) |
Jun
(24) |
Jul
(38) |
Aug
(54) |
Sep
(24) |
Oct
(15) |
Nov
(26) |
Dec
(27) |
| 2018 |
Jan
(22) |
Feb
(24) |
Mar
(109) |
Apr
(12) |
May
(46) |
Jun
(23) |
Jul
(39) |
Aug
(34) |
Sep
(22) |
Oct
(43) |
Nov
(26) |
Dec
(157) |
| 2019 |
Jan
(102) |
Feb
(51) |
Mar
(63) |
Apr
(60) |
May
(91) |
Jun
(55) |
Jul
(27) |
Aug
(76) |
Sep
(52) |
Oct
(95) |
Nov
(67) |
Dec
(204) |
| 2020 |
Jan
(311) |
Feb
(148) |
Mar
(230) |
Apr
(122) |
May
(204) |
Jun
(204) |
Jul
(114) |
Aug
(36) |
Sep
(120) |
Oct
(186) |
Nov
(60) |
Dec
(151) |
| 2021 |
Jan
(182) |
Feb
(171) |
Mar
(202) |
Apr
(153) |
May
(110) |
Jun
(50) |
Jul
(58) |
Aug
(142) |
Sep
(112) |
Oct
(120) |
Nov
(97) |
Dec
(125) |
| 2022 |
Jan
(175) |
Feb
(147) |
Mar
(54) |
Apr
(73) |
May
(127) |
Jun
(95) |
Jul
(88) |
Aug
(85) |
Sep
(38) |
Oct
(40) |
Nov
(116) |
Dec
(159) |
| 2023 |
Jan
(175) |
Feb
(55) |
Mar
(83) |
Apr
(70) |
May
(165) |
Jun
(79) |
Jul
(123) |
Aug
(90) |
Sep
(40) |
Oct
(95) |
Nov
(84) |
Dec
(88) |
| 2024 |
Jan
(105) |
Feb
(60) |
Mar
(52) |
Apr
(43) |
May
(56) |
Jun
(59) |
Jul
(53) |
Aug
(47) |
Sep
(62) |
Oct
(36) |
Nov
(45) |
Dec
(100) |
| 2025 |
Jan
(52) |
Feb
(45) |
Mar
(30) |
Apr
(97) |
May
(72) |
Jun
(83) |
Jul
(124) |
Aug
(83) |
Sep
(84) |
Oct
(20) |
Nov
(49) |
Dec
(53) |
| 2026 |
Jan
(53) |
Feb
(62) |
Mar
(48) |
Apr
(73) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Nate B. <n0...@n0...> - 2026-04-29 11:09:37
|
Forgot to reply to the list... 73, Nate ----- Forwarded message from Nate Bargmann <n0...@n0...> ----- Date: Tue, 28 Apr 2026 22:09:06 -0500 From: Nate Bargmann <n0...@n0...> To: George Baltz <geo...@gm...> Subject: Re: [Hamlib-developer] SWIG & LUA versions for 5.0?? Organization: Amateur Radio! * On 2026 28 Apr 18:41 -0500, George Baltz wrote: > > How about 22.04? I don't follow the Ubuntu releases, but if that's LTS then > it may be the decider. AIUI, all even year .04 Ubuntu releases are LTS. Each is supported for five years and then an additional ten years with a support subscription which puts 12.04 almost to its entire EOL, i.e. 2012 + 5 + 10 = 2027. You are right on 22.04. For some reason my mind was jumping from 24.04 to 20.04 even though 26.04 was just released. 22.04 has one more year of standard five year LTS. A quick DDG search shows that 22.04 had Swig 4.0.2 and Lua at 5.4 as its default (this could be in error). That known, by the time we release 5.0.0, 22.04 will have only a few months of standard LTS left, so is it worth it to target a such older version of Swig? I suspect there are very few hams using 22.04 or an equivalent older release of Linux. If they are, they probably aren't concerned about later releases of Hamlib. > I think we're good as far as swig is concerned, but the comments arounnd > line 150+- in rig.h only talk about lua 5.3.5 being OK. It all depends on > which Lua version fixed 64-bit integers turning into doubles. Daniele has done quite a bit more work in that area so I hope we hear an answer. 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 ----- End forwarded message ----- -- "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 |
|
From: George B. <geo...@gm...> - 2026-04-28 23:41:04
|
On 4/28/26 6:57 PM, Nate Bargmann wrote: > * On 2026 28 Apr 11:03 -0500, George Baltz wrote: >> I've been doing a little cleanup work in rig.h, and I'd like to know if the >> problems with 32/64 bit bitmasks is still a problem with any generally >> available version of swig/lua. >> >> The earliest I have is on openSUSE 15.6 (which goes EOL this week) that >> still carries swig 4.1.1 and lua 5.1 as base versions, with swig 4.4.1 and >> lua 5.3 as optional. ISTM that even the base versions are more than enough >> to satisfy the comments in rig.h around lines 140-150 & in the RIG_MODE >> definitions around 1400+-. >> >> I don't see any minimums in the docs for these, so this might be a good time >> to define some and get rid of some of the #if/#ifndef/#endif's in this area. > At one time I attempted to list minimum versions of optional packages in > README.[betatester|developer], but had kind of given up on that, I > guess. > > Ubuntu 24.04 is still in its five year window of general LTS (another > ten yeas can be tacked on, but I think we can ignore that as that would > bring 12.04 LTS into the picture). It has Lua 5.4 and Swig 4.2. How about 22.04? I don't follow the Ubuntu releases, but if that's LTS then it may be the decider. > > Debian 12 (from 2023) has Lua 5.1, 5.2, 5.3, and 5.4 available (as does > Debian 13 from 2025; Debian 14 will add 5.5) and Swig 4.1. Debian 13 > has Swig 4.3 and Debian 14 will have 4.4.1, at least (Debian 14 will > probably be released around mid-2027). > > Debian 11 will no longer receive updates later this year. > > ISTM that even supporting Debian 12's versions is a rather long reach > backward at this point. If we can work with Swig 4.1 and Lua 5.1 as > minimum versions, then that should be adequate. > > 73, Nate > I think we're good as far as swig is concerned, but the comments arounnd line 150+- in rig.h only talk about lua 5.3.5 being OK. It all depends on which Lua version fixed 64-bit integers turning into doubles. |
|
From: Nate B. <n0...@n0...> - 2026-04-28 22:58:05
|
* On 2026 28 Apr 11:03 -0500, George Baltz wrote: > I've been doing a little cleanup work in rig.h, and I'd like to know if the > problems with 32/64 bit bitmasks is still a problem with any generally > available version of swig/lua. > > The earliest I have is on openSUSE 15.6 (which goes EOL this week) that > still carries swig 4.1.1 and lua 5.1 as base versions, with swig 4.4.1 and > lua 5.3 as optional. ISTM that even the base versions are more than enough > to satisfy the comments in rig.h around lines 140-150 & in the RIG_MODE > definitions around 1400+-. > > I don't see any minimums in the docs for these, so this might be a good time > to define some and get rid of some of the #if/#ifndef/#endif's in this area. At one time I attempted to list minimum versions of optional packages in README.[betatester|developer], but had kind of given up on that, I guess. Ubuntu 24.04 is still in its five year window of general LTS (another ten yeas can be tacked on, but I think we can ignore that as that would bring 12.04 LTS into the picture). It has Lua 5.4 and Swig 4.2. Debian 12 (from 2023) has Lua 5.1, 5.2, 5.3, and 5.4 available (as does Debian 13 from 2025; Debian 14 will add 5.5) and Swig 4.1. Debian 13 has Swig 4.3 and Debian 14 will have 4.4.1, at least (Debian 14 will probably be released around mid-2027). Debian 11 will no longer receive updates later this year. ISTM that even supporting Debian 12's versions is a rather long reach backward at this point. If we can work with Swig 4.1 and Lua 5.1 as minimum versions, then that should be adequate. 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 |
|
From: George B. <geo...@gm...> - 2026-04-28 16:02:27
|
I've been doing a little cleanup work in rig.h, and I'd like to know if the problems with 32/64 bit bitmasks is still a problem with any generally available version of swig/lua. The earliest I have is on openSUSE 15.6 (which goes EOL this week) that still carries swig 4.1.1 and lua 5.1 as base versions, with swig 4.4.1 and lua 5.3 as optional. ISTM that even the base versions are more than enough to satisfy the comments in rig.h around lines 140-150 & in the RIG_MODE definitions around 1400+-. I don't see any minimums in the docs for these, so this might be a good time to define some and get rid of some of the #if/#ifndef/#endif's in this area. Any input?? 73 n3gb |
|
From: <gm...@bt...> - 2026-04-27 06:58:23
|
Congratulations guys. 73 Phil Rose, GM3ZZA ________________________________ From: Nate Bargmann <n0...@n0...> Sent: 27 April 2026 12:36 AM To: Hamlib Developers <ham...@li...> Subject: [Hamlib-developer] Hamlib is named the winner of the 2026 Amateur Radio Software Award The Amateur Radio Software Award committee has named the Hamlib Project as the recipient of its 2026 Amateur Radio Software Award. Complete details are found at: https://arsaward.com/ All who have contributed to Hamlib in any way can consider themselves co-recipients of this award in addition to the current four core developers. Blame me for any omissions. 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 |
|
From: Nate B. <n0...@n0...> - 2026-04-26 23:36:57
|
The Amateur Radio Software Award committee has named the Hamlib Project as the recipient of its 2026 Amateur Radio Software Award. Complete details are found at: https://arsaward.com/ All who have contributed to Hamlib in any way can consider themselves co-recipients of this award in addition to the current four core developers. Blame me for any omissions. 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 |
|
From: Nate B. <no...@gi...> - 2026-04-26 17:11:56
|
Branch: refs/heads/Hamlib-4.7 Home: https://github.com/Hamlib/Hamlib Commit: 24d6d6b17fe3887875e4f4e2e80679b4a3950213 https://github.com/Hamlib/Hamlib/commit/24d6d6b17fe3887875e4f4e2e80679b4a3950213 Author: Mario Haustein <mar...@hr...> Date: 2026-04-26 (Sun, 26 Apr 2026) Changed paths: M rotators/skywatcher/skywatcher.c Log Message: ----------- Initialize motors of Skywatcher mount To use the Skywatcher rotator, both motors have to by initialized. When using the direct mode of the mounts hand control unit, this initialization is performed by the hand control. We just need to set the position. When using the motor driver directly with a simple USB-RS232-adapter, this init command must be sent before we are able to steer the mount. This allows us to use the mount without cabeling up the whole hand control unit. (cherry picked from commit 5d0d5df3cf016667429f4a1045f271e48f74479d) Commit: e134da5136154a0d409e2873e7517d3b23ce7111 https://github.com/Hamlib/Hamlib/commit/e134da5136154a0d409e2873e7517d3b23ce7111 Author: Nate Bargmann <n0...@n0...> Date: 2026-04-26 (Sun, 26 Apr 2026) Changed paths: M NEWS Log Message: ----------- Update NEWS for Skywatcher rot_open Commit: 837e1ff82e8df30057562341bbae4afef8f31894 https://github.com/Hamlib/Hamlib/commit/837e1ff82e8df30057562341bbae4afef8f31894 Author: Nate Bargmann <n0...@n0...> Date: 2026-04-26 (Sun, 26 Apr 2026) Changed paths: M simulators/simic7200.c Log Message: ----------- Merge GitHub PR #2045 Compare: https://github.com/Hamlib/Hamlib/compare/fec049932e93...837e1ff82e8d To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Mario H. <no...@gi...> - 2026-04-26 16:50:35
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 5d0d5df3cf016667429f4a1045f271e48f74479d https://github.com/Hamlib/Hamlib/commit/5d0d5df3cf016667429f4a1045f271e48f74479d Author: Mario Haustein <mar...@hr...> Date: 2026-04-26 (Sun, 26 Apr 2026) Changed paths: M rotators/skywatcher/skywatcher.c Log Message: ----------- Initialize motors of Skywatcher mount To use the Skywatcher rotator, both motors have to by initialized. When using the direct mode of the mounts hand control unit, this initialization is performed by the hand control. We just need to set the position. When using the motor driver directly with a simple USB-RS232-adapter, this init command must be sent before we are able to steer the mount. This allows us to use the mount without cabeling up the whole hand control unit. To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: dforsi <no...@gi...> - 2026-04-26 14:32:50
|
Branch: refs/heads/Hamlib-4.7 Home: https://github.com/Hamlib/Hamlib Commit: fec049932e93bd741f9145f74c2bc0ebba96b337 https://github.com/Hamlib/Hamlib/commit/fec049932e93bd741f9145f74c2bc0ebba96b337 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2026-04-26 (Sun, 26 Apr 2026) Changed paths: M simulators/simic7200.c Log Message: ----------- Remove duplicated line (cherry picked from commit f91ec06df2258a78abb58620b5097ab765065e9b) To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: dforsi <no...@gi...> - 2026-04-26 09:11:05
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: f91ec06df2258a78abb58620b5097ab765065e9b https://github.com/Hamlib/Hamlib/commit/f91ec06df2258a78abb58620b5097ab765065e9b Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2026-04-26 (Sun, 26 Apr 2026) Changed paths: M simulators/simic7200.c Log Message: ----------- Remove duplicated line Commit: ecd7d4fe463161ec7853cd91bc40c5bf4cf911e7 https://github.com/Hamlib/Hamlib/commit/ecd7d4fe463161ec7853cd91bc40c5bf4cf911e7 Author: dforsi <iu...@gm...> Date: 2026-04-26 (Sun, 26 Apr 2026) Changed paths: M simulators/simic7200.c Log Message: ----------- Merge pull request #2045 from dforsi/fix/cleanup Remove duplicated line Compare: https://github.com/Hamlib/Hamlib/compare/07bd3b365090...ecd7d4fe4631 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2026-04-24 19:17:20
|
Branch: refs/heads/Hamlib-4.7 Home: https://github.com/Hamlib/Hamlib Commit: 5bc8f19f13fa52b4fc2daf45250342287e0e5798 https://github.com/Hamlib/Hamlib/commit/5bc8f19f13fa52b4fc2daf45250342287e0e5798 Author: Leo Pizzolante <leo...@gm...> Date: 2026-04-24 (Fri, 24 Apr 2026) Changed paths: M bindings/python/test_Hamlib_class.py M include/hamlib/riglist.h M rigs/kenwood/Android.mk M rigs/kenwood/Makefile.am A rigs/kenwood/hamgeek.c A rigs/kenwood/hamgeek.h M rigs/kenwood/kenwood.c M rigs/kenwood/kenwood.h Log Message: ----------- Add Hamgeek uSDX (cherry picked from commit 2691e10cee7b5896d5a4f5dab880c2d0260e5467) Commit: eea7094ae73d6c8abaf18168cb34207eac9c7827 https://github.com/Hamlib/Hamlib/commit/eea7094ae73d6c8abaf18168cb34207eac9c7827 Author: Nate Bargmann <n0...@n0...> Date: 2026-04-24 (Fri, 24 Apr 2026) Changed paths: M rigs/kenwood/hamgeek.c Log Message: ----------- Rename macro to quell warning GCC on Debian 13 generated this warning: CC hamgeek.lo ../../../../rigs/kenwood/hamgeek.c:71:9: warning: "BACKEND_VER" redefined 71 | #define BACKEND_VER "20260423" | ^~~~~~~~~~~ In file included from ../../../../rigs/kenwood/hamgeek.c:35: ../../../../rigs/kenwood/kenwood.h:33:9: note: this is the location of the previous definition 33 | #define BACKEND_VER "20250515" | ^~~~~~~~~~~ Renamimg the macro to USDX_BACKEND_VER quelled the warning. (cherry picked from commit 07bd3b365090b37179bbcfbfaa54bfb5100b7f08) Commit: 993a2f284b68bd52b32aa9e369b17fbcf1191f64 https://github.com/Hamlib/Hamlib/commit/993a2f284b68bd52b32aa9e369b17fbcf1191f64 Author: Nate Bargmann <n0...@n0...> Date: 2026-04-24 (Fri, 24 Apr 2026) Changed paths: M NEWS Log Message: ----------- Update NEWS for new model, Hamgeek uSDX Compare: https://github.com/Hamlib/Hamlib/compare/3856ff650ae6...993a2f284b68 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2026-04-24 18:11:48
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 2691e10cee7b5896d5a4f5dab880c2d0260e5467 https://github.com/Hamlib/Hamlib/commit/2691e10cee7b5896d5a4f5dab880c2d0260e5467 Author: Leo Pizzolante <leo...@gm...> Date: 2026-04-24 (Fri, 24 Apr 2026) Changed paths: M bindings/python/test_Hamlib_class.py M include/hamlib/riglist.h M rigs/kenwood/Android.mk M rigs/kenwood/Makefile.am A rigs/kenwood/hamgeek.c A rigs/kenwood/hamgeek.h M rigs/kenwood/kenwood.c M rigs/kenwood/kenwood.h Log Message: ----------- Add Hamgeek uSDX Commit: 07bd3b365090b37179bbcfbfaa54bfb5100b7f08 https://github.com/Hamlib/Hamlib/commit/07bd3b365090b37179bbcfbfaa54bfb5100b7f08 Author: Nate Bargmann <n0...@n0...> Date: 2026-04-24 (Fri, 24 Apr 2026) Changed paths: M rigs/kenwood/hamgeek.c Log Message: ----------- Rename macro to quell warning GCC on Debian 13 generated this warning: CC hamgeek.lo ../../../../rigs/kenwood/hamgeek.c:71:9: warning: "BACKEND_VER" redefined 71 | #define BACKEND_VER "20260423" | ^~~~~~~~~~~ In file included from ../../../../rigs/kenwood/hamgeek.c:35: ../../../../rigs/kenwood/kenwood.h:33:9: note: this is the location of the previous definition 33 | #define BACKEND_VER "20250515" | ^~~~~~~~~~~ Renamimg the macro to USDX_BACKEND_VER quelled the warning. Compare: https://github.com/Hamlib/Hamlib/compare/7a64176bd06d...07bd3b365090 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2026-04-22 20:29:50
|
Branch: refs/heads/Hamlib-4.7 Home: https://github.com/Hamlib/Hamlib Commit: baee8db63cfda87341be689f480895021ec2164c https://github.com/Hamlib/Hamlib/commit/baee8db63cfda87341be689f480895021ec2164c Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-22 (Wed, 22 Apr 2026) Changed paths: M rigs/icom/ic7600.c M rigs/icom/ic7610.c Log Message: ----------- Update clock routines for IC-7600 & IC-7610 Resturns rigs/icom/ic7600.c and rigs/icom/ic7610.c to data only. (cherry picked from commit 99e63bf6414895b6d20ee70388bab44887349364) Commit: 9179a3c41c80fa36118fc93ce61c3383f6506926 https://github.com/Hamlib/Hamlib/commit/9179a3c41c80fa36118fc93ce61c3383f6506926 Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-22 (Wed, 22 Apr 2026) Changed paths: M rigs/icom/ic7700.c M rigs/icom/ic7760.c Log Message: ----------- Update the last of the Icom clocks (cherry picked from commit ee0ddd02737612e614ac2d0f44b626057a2457b3) Commit: 57f7120a783ce982c3d31ccb0869ff9e8ab151db https://github.com/Hamlib/Hamlib/commit/57f7120a783ce982c3d31ccb0869ff9e8ab151db Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-22 (Wed, 22 Apr 2026) Changed paths: M rigs/icom/ic7610.c Log Message: ----------- Fix IC-7610 clock commands Values taken from previous code were wrong - new values from IC-7610 CI-V REFERENCE GUIDE (cherry picked from commit 912cdd963df4807cb9a4736d7d9e226d157082d2) Commit: 8498864c8054e76299ae949929a31c68a92111a6 https://github.com/Hamlib/Hamlib/commit/8498864c8054e76299ae949929a31c68a92111a6 Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-22 (Wed, 22 Apr 2026) Changed paths: M rigs/icom/icom.c Log Message: ----------- Add CWR to modes eligible for dsp filtering Fix issue #2038 (cherry picked from commit 147a233ed95d494a78908edb709bc6d2b6e72d8f) Commit: 3856ff650ae64a597d41207b52c43946769af9dd https://github.com/Hamlib/Hamlib/commit/3856ff650ae64a597d41207b52c43946769af9dd Author: Nate Bargmann <n0...@n0...> Date: 2026-04-22 (Wed, 22 Apr 2026) Changed paths: M NEWS Log Message: ----------- Update NEWS for most recent patches included in 4.7.2 Compare: https://github.com/Hamlib/Hamlib/compare/bd551aad73d2...3856ff650ae6 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2026-04-22 20:07:03
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 147a233ed95d494a78908edb709bc6d2b6e72d8f https://github.com/Hamlib/Hamlib/commit/147a233ed95d494a78908edb709bc6d2b6e72d8f Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-21 (Tue, 21 Apr 2026) Changed paths: M rigs/icom/icom.c Log Message: ----------- Add CWR to modes eligible for dsp filtering Fix issue #2038 Commit: 2f3d01728b2fac145717755ccc144da97d3bd5ef https://github.com/Hamlib/Hamlib/commit/2f3d01728b2fac145717755ccc144da97d3bd5ef Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-22 (Wed, 22 Apr 2026) Changed paths: M rigs/yaesu/ft1200.c M rigs/yaesu/newcat.c M simulators/Makefile.am M simulators/sim.h R simulators/simft818.c M simulators/simftdx3000.c Log Message: ----------- Remove all traces of FTDX3000DM Per Yaesu Tech support, treat all FTDX-3000 models the same. See comments in PR #2039. While removing references to FTDX-3000DM, I happened across simft818.c. It set a new low for simulators. It is completely wrong - it uses new CAT protocol, while the rig uses the old 5-byte binary version. If you want to simulate the FT-818, start over with simft817.c as the basis, because this one is gone. Commit: 7a64176bd06d5e618d3e4bc279fc0f2f6f9c7a15 https://github.com/Hamlib/Hamlib/commit/7a64176bd06d5e618d3e4bc279fc0f2f6f9c7a15 Author: Nate Bargmann <n0...@n0...> Date: 2026-04-22 (Wed, 22 Apr 2026) Changed paths: M rigs/icom/icom.c M rigs/yaesu/ft1200.c M rigs/yaesu/newcat.c M simulators/Makefile.am M simulators/sim.h R simulators/simft818.c M simulators/simftdx3000.c Log Message: ----------- Merge GitHub PR #2041 Compare: https://github.com/Hamlib/Hamlib/compare/912cdd963df4...7a64176bd06d To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: GeoBaltz <no...@gi...> - 2026-04-22 19:34:20
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 99e63bf6414895b6d20ee70388bab44887349364 https://github.com/Hamlib/Hamlib/commit/99e63bf6414895b6d20ee70388bab44887349364 Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-21 (Tue, 21 Apr 2026) Changed paths: M rigs/icom/ic7600.c M rigs/icom/ic7610.c Log Message: ----------- Update clock routines for IC-7600 & IC-7610 Resturns rigs/icom/ic7600.c and rigs/icom/ic7610.c to data only. Commit: ee0ddd02737612e614ac2d0f44b626057a2457b3 https://github.com/Hamlib/Hamlib/commit/ee0ddd02737612e614ac2d0f44b626057a2457b3 Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-21 (Tue, 21 Apr 2026) Changed paths: M rigs/icom/ic7700.c M rigs/icom/ic7760.c Log Message: ----------- Update the last of the Icom clocks Commit: 912cdd963df4807cb9a4736d7d9e226d157082d2 https://github.com/Hamlib/Hamlib/commit/912cdd963df4807cb9a4736d7d9e226d157082d2 Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-22 (Wed, 22 Apr 2026) Changed paths: M rigs/icom/ic7610.c Log Message: ----------- Fix IC-7610 clock commands Values taken from previous code were wrong - new values from IC-7610 CI-V REFERENCE GUIDE Compare: https://github.com/Hamlib/Hamlib/compare/9a53e8629720...912cdd963df4 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: GeoBaltz <no...@gi...> - 2026-04-21 19:20:26
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 06f35bae1089163ae1e493f460b584ec32394c20 https://github.com/Hamlib/Hamlib/commit/06f35bae1089163ae1e493f460b584ec32394c20 Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/newcat.c Log Message: ----------- Use the data in valid_commands as data No need to evaluate it, the answer is right there. FWIW, this shrinks newcat.o by about 6500 bytes. Commit: c7688c776001f8ac75971f9729b8200ae9afed8f https://github.com/Hamlib/Hamlib/commit/c7688c776001f8ac75971f9729b8200ae9afed8f Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/newcat.c Log Message: ----------- Use variable instead of multiple function calls. Don't compute constants! Commit: 58829e1221bbbc1533f6d621e0ec6b4f1d6b9978 https://github.com/Hamlib/Hamlib/commit/58829e1221bbbc1533f6d621e0ec6b4f1d6b9978 Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/newcat.h Log Message: ----------- Change ncboolean to a 'bool' typedef. Now that Hamlib-5 requires C11, why settle for less than the Real Thing? Commit: 4f2b9b8a7eb1938595f4d54ece4f4a1bd9b9f6ba https://github.com/Hamlib/Hamlib/commit/4f2b9b8a7eb1938595f4d54ece4f4a1bd9b9f6ba Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/newcat.c Log Message: ----------- Remove redundant " ? TRUE : FALSE" after comparison Comparison already produces true/false boolean value. Don't (re)compute constants! Commit: 4d0d37f251ac1f223d0d1f691bd94b923a344c0d https://github.com/Hamlib/Hamlib/commit/4d0d37f251ac1f223d0d1f691bd94b923a344c0d Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/ft950.c M rigs/yaesu/newcat.c M rigs/yaesu/newcat.h Log Message: ----------- First steps toward removing those icky if() statements Define data structures for holding the rig's bandwidth capabilities. Add routine to search and return correct index. (Needs error checking) Will remove possibility of differing get&set values. No usage of this new stuff yet! Commit: 610e10af3f793dee3e6d64f290d36ad56fc720bf https://github.com/Hamlib/Hamlib/commit/610e10af3f793dee3e6d64f290d36ad56fc720bf Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/newcat.c Log Message: ----------- Get rid of static flags in rigs/yaesu/newcat.c Having static, writable storage in shared objects is usually a Bad Idea(tm). In this case they are overwritten each time a Yaesu rig is opened, so only one model can be used at any one time. This replaces the flags with macros that provide the same results. Add rig parameter to newcat_band_index() since the result depends on the rig model. Commit: 2e2c8fbc968cb7a9b390a7b5b7027c0cdcbf5c73 https://github.com/Hamlib/Hamlib/commit/2e2c8fbc968cb7a9b390a7b5b7027c0cdcbf5c73 Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/newcat.c Log Message: ----------- Remove most tests using is_ftdx3000dm The FTDX-3000 and FTDX-3000dm share the same rig_model; so is_ftdx3000dm is only necessary to differentiate those few parameters that vary between them. Commit: 1b5f492255f5f0f5d97e632a7163dd39b9b6d466 https://github.com/Hamlib/Hamlib/commit/1b5f492255f5f0f5d97e632a7163dd39b9b6d466 Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/ft710.c M rigs/yaesu/ftdx10.c M rigs/yaesu/ftdx101.c M rigs/yaesu/ftdx101mp.c M rigs/yaesu/newcat.h Log Message: ----------- Define width tables for FTDX-10, FTDX-101D, FTDX-101MP, and FT-710 Use the same shared definitions for them all. Commit: 78530515e5b55c466f226ccc2ca07862a283a7eb https://github.com/Hamlib/Hamlib/commit/78530515e5b55c466f226ccc2ca07862a283a7eb Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M simulators/simftdx101.c Log Message: ----------- Fix simftdx101.c so it is marginally useful. As usual, trying to use a simulator for debugging/development testing is not helpful. Fix ID command so it at least can say it is a FTDX-101 Get rig of includes of rig.h and misc.h Fix the SH command so it agrees with the FTDX101MP/FTDX101D CAT OpsRef TODO: Roofing filters, Main/Sub vfo commands, and lots more. Commit: d18b9c8984f9bf3e9a0b25d186a2839b5d861cbd https://github.com/Hamlib/Hamlib/commit/d18b9c8984f9bf3e9a0b25d186a2839b5d861cbd Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/newcat.c Log Message: ----------- Use new routine and data for FT-710, FTDX-{10|101D|101MP} Remove if/case statemants used to translate bandwidth<->SHcommand value. Update index routine to check for out-of-bounds inputs. Commit: 4b9908f98169ec9c24ac74ee1c571cff139beb12 https://github.com/Hamlib/Hamlib/commit/4b9908f98169ec9c24ac74ee1c571cff139beb12 Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M simulators/simft991.c Log Message: ----------- Fix up another simulator. Fix the ID command Remove includes Make the mode, width and narrow consistent. Commit: 3dec8fb59cd9910f7efe87b5c6f72c7ef516017e https://github.com/Hamlib/Hamlib/commit/3dec8fb59cd9910f7efe87b5c6f72c7ef516017e Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/ft991.c M rigs/yaesu/newcat.c Log Message: ----------- Convert FT-991/FT-991A Re-arrange some if() statements so most likely case is first. Commit: 26e598c32a476ad115284cdcc5eb8ff0420926ba https://github.com/Hamlib/Hamlib/commit/26e598c32a476ad115284cdcc5eb8ff0420926ba Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/ft891.c M rigs/yaesu/ft991.c M rigs/yaesu/newcat.c M rigs/yaesu/newcat.h Log Message: ----------- Change FT-891 to use new width structures Use the same info as the FT991. Commit: c375832f62d70467ff50454a5b6094c99cab2a14 https://github.com/Hamlib/Hamlib/commit/c375832f62d70467ff50454a5b6094c99cab2a14 Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M simulators/simftdx1200.c M simulators/simftdx3000.c Log Message: ----------- Make a couple more simulators barely functional Allow simftdx1200.c and simftdx3000.c to at least start, go through the initial setup/open, have mode and width do something. Fix field lengths, missing commands, incorrect data, etc. simftdx3000.c shows an interesting problem - the FTDX3000 CAT manual says the rig should return 0462 for the ID command - hamlib thinks that is a FTDX-3000DM, the low power version. Maybe they're backwards?? Does anybody have a real one to find out? Commit: bb451e5ce9fb60c9663db844ae69e307e66ef462 https://github.com/Hamlib/Hamlib/commit/bb451e5ce9fb60c9663db844ae69e307e66ef462 Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/ft1200.c M rigs/yaesu/ft3000.c M rigs/yaesu/newcat.c M rigs/yaesu/newcat.h Log Message: ----------- Convert FTDX-1200 and FTDX-3000 to new bandwidth code And some minor cleanups Commit: cbf6aff25a4e107a1c105af20f485ff4940da4b6 https://github.com/Hamlib/Hamlib/commit/cbf6aff25a4e107a1c105af20f485ff4940da4b6 Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M simulators/simftdx5000.c Log Message: ----------- One more simulator limps across the starting line. Just enough hacking to get it going. Commit: b84d3686d4ba60c3aabcb81ef34c68066a2008f4 https://github.com/Hamlib/Hamlib/commit/b84d3686d4ba60c3aabcb81ef34c68066a2008f4 Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/ft5000.c M rigs/yaesu/newcat.c Log Message: ----------- Convert FTDX-5000 to new bandwidth code. Commit: 7cfa437aae3f63efffa0295b0913c068d8c6b74d https://github.com/Hamlib/Hamlib/commit/7cfa437aae3f63efffa0295b0913c068d8c6b74d Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/ftx1/ftx1.c M rigs/yaesu/newcat.c Log Message: ----------- Add ftx1 to entabulated width rig list. Commit: 9a53e8629720b45c2026fd1c761697f3ffb1ee8c https://github.com/Hamlib/Hamlib/commit/9a53e8629720b45c2026fd1c761697f3ffb1ee8c Author: George Baltz N3GB <Geo...@gm...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M NEWS M ReleaseNotes_5.0.md M rigs/yaesu/newcat.h Log Message: ----------- Update newcat version, comments, NEWS and ReleaseNotes_5.0.md Compare: https://github.com/Hamlib/Hamlib/compare/8a714a44b614...9a53e8629720 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2026-04-19 17:45:38
|
Branch: refs/heads/Hamlib-4.7 Home: https://github.com/Hamlib/Hamlib Commit: 25d2db438da02eb239287fab1ed530d9280764ad https://github.com/Hamlib/Hamlib/commit/25d2db438da02eb239287fab1ed530d9280764ad Author: Nate Bargmann <n0...@n0...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M configure.ac Log Message: ----------- Advance to 4.7.2~rc Commit: c9ca4c4688349a5fcd9768c63be2ca73dfb6cd4c https://github.com/Hamlib/Hamlib/commit/c9ca4c4688349a5fcd9768c63be2ca73dfb6cd4c Author: KJ5HST <kj...@de...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/ftx1/ftx1.h M rigs/yaesu/ftx1/ftx1_ctcss.c M rigs/yaesu/ftx1/ftx1_mem.c Log Message: ----------- ftx1: rewrite set_channel using VFO-B + BM (firmware MW bug) (#2034) The FTX-1 MW (Memory Write) CAT command is firmware-broken on v1.08+ and always returns '?;' regardless of channel or parameters. The previous ftx1_set_channel built a 30-char MW command and relied on it succeeding, so rig_set_channel on an FTX-1 failed on every call -- no memory channel ever got written. Replace the MW path with the sequence the firmware actually supports: 1. MC<ch>; point the "last-selected channel" cursor at the target. The radio returns '?;' for unprogrammed slots, but the cursor still updates for the subsequent BM commit. 2. VM000; force VFO mode in case MC entered memory mode. 3. FB / MD1 / CT1 / CN10 / CN11 / OS1 program VFO-B to the target state. CT/CN/OS only function in FM, so tone and shift are only emitted for FM-family channel modes. DCS goes through CN with P2=1 because the DC command is also firmware-broken. 4. BM; copy VFO-B to the last-selected memory channel. VFO-B is used rather than VFO-A so the operator's primary RX VFO is not disturbed. VFO-B's frequency and mode are snapshotted at entry and best-effort restored on exit (including the error path), so a caller that was using VFO-B sees minimal side effects. Clarifier/RIT/XIT state is not yet programmed into the channel -- BM's handling of clarifier has not been empirically verified, and getting it wrong silently is worse than dropping it for now. Left as a potential follow-up if users report it missing. Verified end-to-end on a live FTX-1 field head + Optima/SPA-1 running firmware MAIN v1.12 at 115200 bps: rigctl -m 1051 H 1 round-trips channel 1 between 7.000 MHz LSB and 7.050 MHz LSB, and VFO-A (144.260 FM) and VFO-B (28.074 USB) are both preserved across the operation. Exposes ftx1_freq_to_tone_num() in ftx1.h (previously file-static in ftx1_ctcss.c) so ftx1_mem.c can reuse the existing CTCSS frequency lookup instead of duplicating the table. (cherry picked from commit 4024cd5d0d6ca3ae959ce7da1cf193438144c20a) Commit: 2bbd6699af0d87a75ecf251ee58fd4691baf14c2 https://github.com/Hamlib/Hamlib/commit/2bbd6699af0d87a75ecf251ee58fd4691baf14c2 Author: KJ5HST <kj...@de...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/ftx1/ftx1_mem.c Log Message: ----------- ftx1: add clarifier support and document firmware limits in set_channel Empirically verified three BM-propagation unknowns against fw v1.12: - Clarifier: the CF command series (11-char form, P3=0 for the RX/TX toggles and P3=1 for the offset) is captured by BM. MR readback shows the stored channel with the programmed clarifier offset and the RX CLAR flag. Add CF programming to the rewrite so rig_set_channel now persists chan->rit into the memory slot. - TX CLAR flag (XIT): the offset and RX flag propagate but the TX CLAR on/off toggle is silently dropped by BM. The stored channel always reads back with TX CLAR off, regardless of what CF100.3 was set to on VFO-B before the commit. We emit the command anyway for forward compatibility with a firmware fix. - DCS: CT13 (CT mode = DCS) and CN11<code> program VFO-B correctly and readback of VFO-B shows both values, but BM does not copy either to the memory channel. The stored MR response is byte-identical to a no-tone write, across DCS codes ranging from 023 to 103. DCS channels cannot be programmed via CAT on this firmware and must be set up from the front panel. We still emit CT13 + CN11 so the code path survives a later firmware fix. Also tighten the cleanup path: the function now explicitly clears VFO-B's clarifier state (and CT state for FM-family writes) on exit in addition to restoring FB/MD1 from the entry snapshot. This avoids leaking intermediate state when rig_set_channel returns. Verified end-to-end via rigctl H 1 with rit=200 Hz — channel 1 MR readback shows clar=+0200 rx=1 as expected, and both VFOs survive the round trip. (cherry picked from commit c1a259406ace8e3c4c801f2b7cb64424efc28914) Commit: 893a10f2e380034425878d85a42a1ad5daa3b632 https://github.com/Hamlib/Hamlib/commit/893a10f2e380034425878d85a42a1ad5daa3b632 Author: KJ5HST <kj...@de...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/ftx1/ftx1.h M rigs/yaesu/ftx1/ftx1_ctcss.c M rigs/yaesu/ftx1/ftx1_mem.c Log Message: ----------- ftx1: populate CTCSS/DCS fields in get_channel ftx1_get_channel has historically parsed the P8 byte from the MR response and then discarded it with a (void) cast, so rig_get_channel always returned chan->ctcss_tone == 0 regardless of what was actually programmed in the channel. An FM memory channel with a CTCSS tone or DCS code read back as "no tone" — silently misleading for callers. MR itself does not carry the tone number, only the mode (P8). Verified by byte-level comparison of MR responses across "no tone" and "CTCSS ENC tone 12" writes on fw v1.12 — only byte 23 differs. The tone number lives in CN, which is only queryable against an operating VFO. Add ftx1_read_channel_tone_state(), a static helper that: 1. Snapshots current VM and MC state via queries 2. Selects the target memory channel via MC<ch>; (enters mem mode) 3. Queries CN00 (CTCSS) or CN01 (DCS) to get the stored number 4. Populates chan->ctcss_tone / ctcss_sql / dcs_code using ftx1_tone_num_to_freq() for CTCSS 5. Restores the caller's prior state — if originally in VFO mode send VM000, if originally in memory mode on another channel send MC<original> The helper applies the MW/MR P8 swap encoding (P8=1 is TSQ, P8=2 is ENC, P8=3 is DCS) and sets ctcss_sql only for the TSQ case. Intrusiveness: get_channel now briefly switches the radio to memory mode on the target channel, which causes a momentary front-panel display change. State is restored before the function returns so the operator's net position is unchanged. The intrusion is only triggered when P8 indicates a tone is present — no-tone channels skip the CN query entirely. Also exposes ftx1_tone_num_to_freq() via ftx1.h (previously file- static in ftx1_ctcss.c) so ftx1_mem.c can reuse the existing tone table instead of duplicating it. Verified end-to-end via rigctl H/h against fw v1.12: ENC: H 1 ... 1000 0 -> h 1: CTCSS: 100.0Hz, CTCSSsql: 0.0Hz TSQ: H 1 ... 1000 1000 -> h 1: CTCSS: 100.0Hz, CTCSSsql: 100.0Hz OFF: H 1 ... 0 0 -> h 1: CTCSS: 0.0Hz, CTCSSsql: 0.0Hz After each read, VFO state and channel 1 MR response are byte-for- byte identical to the pre-test snapshot. DCS is supported in the readback path but currently unverifiable on the available hardware — the firmware does not appear to persist DCS state into memory channels via the BM write path, so no DCS channel exists to read back. The code handles P8=3 correctly should a front-panel-programmed DCS channel produce that byte value. (cherry picked from commit 130d733be2c447faabcb69f53ae3f571bba34978) Commit: 88b4efda04e2a1a9187b7531a12ab9981b216fa8 https://github.com/Hamlib/Hamlib/commit/88b4efda04e2a1a9187b7531a12ab9981b216fa8 Author: KJ5HST <kj...@de...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/ftx1/ftx1.c M rigs/yaesu/ftx1/ftx1.h M rigs/yaesu/ftx1/ftx1_ctcss.c M rigs/yaesu/ftx1/ftx1_freq.c M rigs/yaesu/ftx1/ftx1_mem.c M rigs/yaesu/ftx1/ftx1_mode.c M rigs/yaesu/newcat.h Log Message: ----------- ftx1: auto-exit Memory mode before VFO-state setters (#2034) Commands that set VFO-side state on the Main side behave poorly when the radio is in Memory mode (VM011): FA main-freq set: rejected outright with '?;' OS repeater shift: rejected outright with '?;' MD main-mode set: accepted but treated as a transient memory-tune overlay — the change does not persist when the user leaves the channel CT main-CTCSS mode: transient overlay (same pattern) CN main-tone/DCS: transient overlay (same pattern) Hamlib had no awareness of this: a caller doing rig_set_mem() followed by rig_set_freq() would silently fail (FA rejected), and rig_set_mode() would appear to succeed but the mode change would vanish on the next MC recall. Add a simple memory-mode tracking flag to the shared newcat_priv_data (ftx1_in_memory_mode), set to 1 inside ftx1_set_mem after a successful MC command. Introduce ftx1_ensure_vfo_mode() in ftx1.c that checks the flag and, if set, sends VM000; and clears the flag. Call it at the top of every VFO-state setter that is actually affected by Memory mode: ftx1_set_freq (Main-VFO branch only — FB on Sub is unaffected) ftx1_set_rptr_shift (OS) ftx1_set_ctcss_mode (CT Main) ftx1_set_ctcss_tone (CN00 Main) ftx1_set_dcs_code (CN01 Main) Sub-targeted CN commands (CN10/CN11 in set_ctcss_sql / set_dcs_sql) are deliberately left alone — the Sub side is never in Memory mode on this firmware, and an injection there would needlessly clobber a user who has intentionally parked Main in Memory mode while tuning Sub. Add a new ftx1_set_mode wrapper in ftx1_mode.c that calls ftx1_ensure_vfo_mode() and delegates to newcat_set_mode. Wire it up in rig_caps (replacing the direct newcat_set_mode pointer). Also flip priv->ftx1_in_memory_mode = 0 at the end of ftx1_set_channel because the BM commit path always ends with the Main side in VFO mode, regardless of the caller's prior position. Verified end-to-end against fw v1.12: $ rigctl -m 1051 -r ... E 1 Rig command: F 7050000 Rig command: f 7050000 (radio is now in VFO mode at 7.050 MHz — without the fix the F would have been rejected and the radio would still be in Memory mode) $ rigctl -m 1051 -r ... E 1 Rig command: M USB 2700 Rig command: m Mode: USB Passband: 2700 (VFO mode USB — without the fix the MD set would have been a transient overlay that vanished on next MC recall) The tracking flag avoids paying for a VM000 CAT round trip on every setter call; it only fires when the driver actually knows the radio entered Memory mode via set_mem. (cherry picked from commit 370dca238ac3f7eeb7c70b41110b6ab08ab2f26a) Commit: 65905f201d29aa710e01ac1fadf47cd15d382a59 https://github.com/Hamlib/Hamlib/commit/65905f201d29aa710e01ac1fadf47cd15d382a59 Author: KJ5HST <kj...@de...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/ftx1/ftx1_mem.c Log Message: ----------- ftx1: silence GCC strncpy warnings, target Sub cursor in set_channel Two fixes in preparation for resubmitting PR #2035: 1. Replace four strncpy(dst, src, sizeof(dst) - 1) calls with snprintf(dst, sizeof(dst), "%s", src). GCC on Debian 13 flagged these as -Wstringop-truncation because priv->ret_data (128 bytes) is larger than the destination and strncpy doesn't guarantee NUL termination. snprintf always NUL-terminates, which GCC recognises as safe. Clang does not emit the warning either way. Reported by N0NB. Sites: saved_fb / saved_md1 in ftx1_set_channel, and saved_vm / saved_mc in ftx1_read_channel_tone_state. 2. Change the cursor step in ftx1_set_channel from MC%06d; to MC1%05d;. Hardware probing (2026-04-18, fw v1.12) established that the MC SET command takes a VFO digit followed by a 5-digit channel: MC0NNNNN targets Main, MC1NNNNN targets Sub. Both sides maintain independent memory-mode state and can be parked in memory mode simultaneously (VM011 + VM111). BM commits VFO-B to the Sub side's last-selected memory, so the cursor-positioning step should target Sub. The previous MC%06d; form produced MC0NNNNN for channels 1..99, silently flipping Main's front-panel channel to the write target on every ftx1_set_channel call. Also rewrites the MC comment block at the top of ftx1_mem.c to document the VFO digit in both SET and READ forms, replacing the prior (incorrect) claim that the SET form is VFO-less. (cherry picked from commit 2b28d2e0ad064b717c8180da139ec0f0f8c2b8f0) Commit: bd551aad73d207d2a00a7f5ea21f710b7ca4c304 https://github.com/Hamlib/Hamlib/commit/bd551aad73d207d2a00a7f5ea21f710b7ca4c304 Author: KJ5HST <kj...@de...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/ftx1/ftx1_mem.c Log Message: ----------- ftx1: use bounded %.*s in snprintf to silence GCC -Wformat-truncation Replace "%s" with "%.*s" and explicit precision (sizeof(dst) - 1) in the four ret_data snapshot sites. Reported by N0NB on Debian 13 (GCC 14); clang and MinGW GCC did not trigger the warning. (cherry picked from commit 8a714a44b6147bdc56be5b31975a85674d4a76df) Compare: https://github.com/Hamlib/Hamlib/compare/d042479a9f80...bd551aad73d2 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2026-04-19 17:05:21
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 4024cd5d0d6ca3ae959ce7da1cf193438144c20a https://github.com/Hamlib/Hamlib/commit/4024cd5d0d6ca3ae959ce7da1cf193438144c20a Author: KJ5HST <kj...@de...> Date: 2026-04-15 (Wed, 15 Apr 2026) Changed paths: M rigs/yaesu/ftx1/ftx1.h M rigs/yaesu/ftx1/ftx1_ctcss.c M rigs/yaesu/ftx1/ftx1_mem.c Log Message: ----------- ftx1: rewrite set_channel using VFO-B + BM (firmware MW bug) (#2034) The FTX-1 MW (Memory Write) CAT command is firmware-broken on v1.08+ and always returns '?;' regardless of channel or parameters. The previous ftx1_set_channel built a 30-char MW command and relied on it succeeding, so rig_set_channel on an FTX-1 failed on every call -- no memory channel ever got written. Replace the MW path with the sequence the firmware actually supports: 1. MC<ch>; point the "last-selected channel" cursor at the target. The radio returns '?;' for unprogrammed slots, but the cursor still updates for the subsequent BM commit. 2. VM000; force VFO mode in case MC entered memory mode. 3. FB / MD1 / CT1 / CN10 / CN11 / OS1 program VFO-B to the target state. CT/CN/OS only function in FM, so tone and shift are only emitted for FM-family channel modes. DCS goes through CN with P2=1 because the DC command is also firmware-broken. 4. BM; copy VFO-B to the last-selected memory channel. VFO-B is used rather than VFO-A so the operator's primary RX VFO is not disturbed. VFO-B's frequency and mode are snapshotted at entry and best-effort restored on exit (including the error path), so a caller that was using VFO-B sees minimal side effects. Clarifier/RIT/XIT state is not yet programmed into the channel -- BM's handling of clarifier has not been empirically verified, and getting it wrong silently is worse than dropping it for now. Left as a potential follow-up if users report it missing. Verified end-to-end on a live FTX-1 field head + Optima/SPA-1 running firmware MAIN v1.12 at 115200 bps: rigctl -m 1051 H 1 round-trips channel 1 between 7.000 MHz LSB and 7.050 MHz LSB, and VFO-A (144.260 FM) and VFO-B (28.074 USB) are both preserved across the operation. Exposes ftx1_freq_to_tone_num() in ftx1.h (previously file-static in ftx1_ctcss.c) so ftx1_mem.c can reuse the existing CTCSS frequency lookup instead of duplicating the table. Commit: c1a259406ace8e3c4c801f2b7cb64424efc28914 https://github.com/Hamlib/Hamlib/commit/c1a259406ace8e3c4c801f2b7cb64424efc28914 Author: KJ5HST <kj...@de...> Date: 2026-04-15 (Wed, 15 Apr 2026) Changed paths: M rigs/yaesu/ftx1/ftx1_mem.c Log Message: ----------- ftx1: add clarifier support and document firmware limits in set_channel Empirically verified three BM-propagation unknowns against fw v1.12: - Clarifier: the CF command series (11-char form, P3=0 for the RX/TX toggles and P3=1 for the offset) is captured by BM. MR readback shows the stored channel with the programmed clarifier offset and the RX CLAR flag. Add CF programming to the rewrite so rig_set_channel now persists chan->rit into the memory slot. - TX CLAR flag (XIT): the offset and RX flag propagate but the TX CLAR on/off toggle is silently dropped by BM. The stored channel always reads back with TX CLAR off, regardless of what CF100.3 was set to on VFO-B before the commit. We emit the command anyway for forward compatibility with a firmware fix. - DCS: CT13 (CT mode = DCS) and CN11<code> program VFO-B correctly and readback of VFO-B shows both values, but BM does not copy either to the memory channel. The stored MR response is byte-identical to a no-tone write, across DCS codes ranging from 023 to 103. DCS channels cannot be programmed via CAT on this firmware and must be set up from the front panel. We still emit CT13 + CN11 so the code path survives a later firmware fix. Also tighten the cleanup path: the function now explicitly clears VFO-B's clarifier state (and CT state for FM-family writes) on exit in addition to restoring FB/MD1 from the entry snapshot. This avoids leaking intermediate state when rig_set_channel returns. Verified end-to-end via rigctl H 1 with rit=200 Hz — channel 1 MR readback shows clar=+0200 rx=1 as expected, and both VFOs survive the round trip. Commit: 130d733be2c447faabcb69f53ae3f571bba34978 https://github.com/Hamlib/Hamlib/commit/130d733be2c447faabcb69f53ae3f571bba34978 Author: KJ5HST <kj...@de...> Date: 2026-04-15 (Wed, 15 Apr 2026) Changed paths: M rigs/yaesu/ftx1/ftx1.h M rigs/yaesu/ftx1/ftx1_ctcss.c M rigs/yaesu/ftx1/ftx1_mem.c Log Message: ----------- ftx1: populate CTCSS/DCS fields in get_channel ftx1_get_channel has historically parsed the P8 byte from the MR response and then discarded it with a (void) cast, so rig_get_channel always returned chan->ctcss_tone == 0 regardless of what was actually programmed in the channel. An FM memory channel with a CTCSS tone or DCS code read back as "no tone" — silently misleading for callers. MR itself does not carry the tone number, only the mode (P8). Verified by byte-level comparison of MR responses across "no tone" and "CTCSS ENC tone 12" writes on fw v1.12 — only byte 23 differs. The tone number lives in CN, which is only queryable against an operating VFO. Add ftx1_read_channel_tone_state(), a static helper that: 1. Snapshots current VM and MC state via queries 2. Selects the target memory channel via MC<ch>; (enters mem mode) 3. Queries CN00 (CTCSS) or CN01 (DCS) to get the stored number 4. Populates chan->ctcss_tone / ctcss_sql / dcs_code using ftx1_tone_num_to_freq() for CTCSS 5. Restores the caller's prior state — if originally in VFO mode send VM000, if originally in memory mode on another channel send MC<original> The helper applies the MW/MR P8 swap encoding (P8=1 is TSQ, P8=2 is ENC, P8=3 is DCS) and sets ctcss_sql only for the TSQ case. Intrusiveness: get_channel now briefly switches the radio to memory mode on the target channel, which causes a momentary front-panel display change. State is restored before the function returns so the operator's net position is unchanged. The intrusion is only triggered when P8 indicates a tone is present — no-tone channels skip the CN query entirely. Also exposes ftx1_tone_num_to_freq() via ftx1.h (previously file- static in ftx1_ctcss.c) so ftx1_mem.c can reuse the existing tone table instead of duplicating it. Verified end-to-end via rigctl H/h against fw v1.12: ENC: H 1 ... 1000 0 -> h 1: CTCSS: 100.0Hz, CTCSSsql: 0.0Hz TSQ: H 1 ... 1000 1000 -> h 1: CTCSS: 100.0Hz, CTCSSsql: 100.0Hz OFF: H 1 ... 0 0 -> h 1: CTCSS: 0.0Hz, CTCSSsql: 0.0Hz After each read, VFO state and channel 1 MR response are byte-for- byte identical to the pre-test snapshot. DCS is supported in the readback path but currently unverifiable on the available hardware — the firmware does not appear to persist DCS state into memory channels via the BM write path, so no DCS channel exists to read back. The code handles P8=3 correctly should a front-panel-programmed DCS channel produce that byte value. Commit: 370dca238ac3f7eeb7c70b41110b6ab08ab2f26a https://github.com/Hamlib/Hamlib/commit/370dca238ac3f7eeb7c70b41110b6ab08ab2f26a Author: KJ5HST <kj...@de...> Date: 2026-04-15 (Wed, 15 Apr 2026) Changed paths: M rigs/yaesu/ftx1/ftx1.c M rigs/yaesu/ftx1/ftx1.h M rigs/yaesu/ftx1/ftx1_ctcss.c M rigs/yaesu/ftx1/ftx1_freq.c M rigs/yaesu/ftx1/ftx1_mem.c M rigs/yaesu/ftx1/ftx1_mode.c M rigs/yaesu/newcat.h Log Message: ----------- ftx1: auto-exit Memory mode before VFO-state setters (#2034) Commands that set VFO-side state on the Main side behave poorly when the radio is in Memory mode (VM011): FA main-freq set: rejected outright with '?;' OS repeater shift: rejected outright with '?;' MD main-mode set: accepted but treated as a transient memory-tune overlay — the change does not persist when the user leaves the channel CT main-CTCSS mode: transient overlay (same pattern) CN main-tone/DCS: transient overlay (same pattern) Hamlib had no awareness of this: a caller doing rig_set_mem() followed by rig_set_freq() would silently fail (FA rejected), and rig_set_mode() would appear to succeed but the mode change would vanish on the next MC recall. Add a simple memory-mode tracking flag to the shared newcat_priv_data (ftx1_in_memory_mode), set to 1 inside ftx1_set_mem after a successful MC command. Introduce ftx1_ensure_vfo_mode() in ftx1.c that checks the flag and, if set, sends VM000; and clears the flag. Call it at the top of every VFO-state setter that is actually affected by Memory mode: ftx1_set_freq (Main-VFO branch only — FB on Sub is unaffected) ftx1_set_rptr_shift (OS) ftx1_set_ctcss_mode (CT Main) ftx1_set_ctcss_tone (CN00 Main) ftx1_set_dcs_code (CN01 Main) Sub-targeted CN commands (CN10/CN11 in set_ctcss_sql / set_dcs_sql) are deliberately left alone — the Sub side is never in Memory mode on this firmware, and an injection there would needlessly clobber a user who has intentionally parked Main in Memory mode while tuning Sub. Add a new ftx1_set_mode wrapper in ftx1_mode.c that calls ftx1_ensure_vfo_mode() and delegates to newcat_set_mode. Wire it up in rig_caps (replacing the direct newcat_set_mode pointer). Also flip priv->ftx1_in_memory_mode = 0 at the end of ftx1_set_channel because the BM commit path always ends with the Main side in VFO mode, regardless of the caller's prior position. Verified end-to-end against fw v1.12: $ rigctl -m 1051 -r ... E 1 Rig command: F 7050000 Rig command: f 7050000 (radio is now in VFO mode at 7.050 MHz — without the fix the F would have been rejected and the radio would still be in Memory mode) $ rigctl -m 1051 -r ... E 1 Rig command: M USB 2700 Rig command: m Mode: USB Passband: 2700 (VFO mode USB — without the fix the MD set would have been a transient overlay that vanished on next MC recall) The tracking flag avoids paying for a VM000 CAT round trip on every setter call; it only fires when the driver actually knows the radio entered Memory mode via set_mem. Commit: 2b28d2e0ad064b717c8180da139ec0f0f8c2b8f0 https://github.com/Hamlib/Hamlib/commit/2b28d2e0ad064b717c8180da139ec0f0f8c2b8f0 Author: KJ5HST <kj...@de...> Date: 2026-04-18 (Sat, 18 Apr 2026) Changed paths: M rigs/yaesu/ftx1/ftx1_mem.c Log Message: ----------- ftx1: silence GCC strncpy warnings, target Sub cursor in set_channel Two fixes in preparation for resubmitting PR #2035: 1. Replace four strncpy(dst, src, sizeof(dst) - 1) calls with snprintf(dst, sizeof(dst), "%s", src). GCC on Debian 13 flagged these as -Wstringop-truncation because priv->ret_data (128 bytes) is larger than the destination and strncpy doesn't guarantee NUL termination. snprintf always NUL-terminates, which GCC recognises as safe. Clang does not emit the warning either way. Reported by N0NB. Sites: saved_fb / saved_md1 in ftx1_set_channel, and saved_vm / saved_mc in ftx1_read_channel_tone_state. 2. Change the cursor step in ftx1_set_channel from MC%06d; to MC1%05d;. Hardware probing (2026-04-18, fw v1.12) established that the MC SET command takes a VFO digit followed by a 5-digit channel: MC0NNNNN targets Main, MC1NNNNN targets Sub. Both sides maintain independent memory-mode state and can be parked in memory mode simultaneously (VM011 + VM111). BM commits VFO-B to the Sub side's last-selected memory, so the cursor-positioning step should target Sub. The previous MC%06d; form produced MC0NNNNN for channels 1..99, silently flipping Main's front-panel channel to the write target on every ftx1_set_channel call. Also rewrites the MC comment block at the top of ftx1_mem.c to document the VFO digit in both SET and READ forms, replacing the prior (incorrect) claim that the SET form is VFO-less. Commit: 8a714a44b6147bdc56be5b31975a85674d4a76df https://github.com/Hamlib/Hamlib/commit/8a714a44b6147bdc56be5b31975a85674d4a76df Author: KJ5HST <kj...@de...> Date: 2026-04-19 (Sun, 19 Apr 2026) Changed paths: M rigs/yaesu/ftx1/ftx1_mem.c Log Message: ----------- ftx1: use bounded %.*s in snprintf to silence GCC -Wformat-truncation Replace "%s" with "%.*s" and explicit precision (sizeof(dst) - 1) in the four ret_data snapshot sites. Reported by N0NB on Debian 13 (GCC 14); clang and MinGW GCC did not trigger the warning. Compare: https://github.com/Hamlib/Hamlib/compare/9de702a452e4...8a714a44b614 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <n0...@n0...> - 2026-04-16 02:35:04
|
The Hamlib Project is pleased to announce the release of Hamlib 4.7.1. This release includes two new radio models, many fixes and improvements to various radio models. Here is a short changelog for this release: Version 4.7.1 * 2026-04-15 * Fix unknown type compilation errors on Alpine Linux. (TNX Bradfor Boyle) * Fix rig port timeout. (TNX Matthias Moelller) * Update ReleaseNotes*.md. (TNX George Baltz) * Fix various FTX-1 meter, level and CTCSS table. (TNX KJ5HST) * Add power off capability to Flrig backend. (TNX Philip Rose) * Replace strncpy with memcpy to quell GCC 16 warning. (TNX George Baltz) * Add SWR to supported 'get levels' for K3/K4. (TNX Tom Crayner (reporter)) * Add get_split_vfo to TS-850 backend. (TNX Elisamuel Resto) * New simplecat backend. Supports Bunzee Labs DDX. (TNX Dhiru Kholia) * Fix and generalize clock handling for Icom radios. (TNX George Baltz) * Fix Yaesu attenuator levels and LVL_KEYSPD reinitialization. (TNX George Baltz) * Add new rig model Harris PRC-138. (TNX Antonio Regazzoni) * Various FT-710 fixes, especially handling SH format and RX bandwidth. Ensure FT-710 simulator rejects RF command. (TNX George Baltz) * Fix low power calculation for K3/K3S. (N0NB) * Fix FTX-1 SH bandwidth command in set/get_mode. (TNX Terrell Deppe) * Quell initializer overrides prior initialzation clang warning in ftx1.c and fix compiler warning in hd1780.c. (TNX George Baltz) Source archive and MS Windows binaries may be downloaded from: https://github.com/Hamlib/Hamlib/releases/tag/4.7.1 https://sourceforge.net/projects/hamlib/files/hamlib/4.7.1/ 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 |
|
From: Nate B. <no...@gi...> - 2026-04-15 20:34:11
|
Branch: refs/tags/4.7.1 Home: https://github.com/Hamlib/Hamlib To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2026-04-15 20:33:27
|
Branch: refs/heads/Hamlib-4.7 Home: https://github.com/Hamlib/Hamlib Commit: d042479a9f8095ba1a8e103a977c3614d7233cb2 https://github.com/Hamlib/Hamlib/commit/d042479a9f8095ba1a8e103a977c3614d7233cb2 Author: Nate Bargmann <n0...@n0...> Date: 2026-04-15 (Wed, 15 Apr 2026) Changed paths: M configure.ac Log Message: ----------- Hamlib 4.7.1 release To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: <gm...@bt...> - 2026-04-15 14:44:28
|
________________________________ From: Nate Bargmann <n0...@n0...> Sent: 15 April 2026 1:27 PM To: ham...@li... <ham...@li...> Subject: Re: [Hamlib-developer] 4.7.1~rc on W11/MSVC I have added a link on each snapshot page to the other so landing on one will give a path to the other. https://hamlib.sourceforge.net/snapshots/ https://hamlib.sourceforge.net/snapshots-4.7/ 73, Nate Thanks Phil. -- "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 |
|
From: George B. <geo...@gm...> - 2026-04-15 13:21:48
|
Which current version - current release(4.7.0), current release candidate(4.7.1-rc), or current development version(5.0.0~git)? What doesn't work - doesn't start, doesn't perform certain functions (set/get freq, set PTT, send CW, etc)? Does it produce any error messages? Help us help you. 73 n3gb On 4/14/26 22:54, Jerry via Hamlib-developer wrote: > Hi, > > The current version of Hamlib is not working with the icom 761. Older > versions of Hamlib do work whit the ic-761 > > > Regards > > Jerry > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Nate B. <n0...@n0...> - 2026-04-15 12:27:53
|
I have added a link on each snapshot page to the other so landing on one will give a path to the other. https://hamlib.sourceforge.net/snapshots/ https://hamlib.sourceforge.net/snapshots-4.7/ 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 |
|
From: Nate B. <n0...@n0...> - 2026-04-15 11:49:59
|
* On 2026 15 Apr 03:15 -0500, gm3zza--- via Hamlib-developer wrote: > I know it's last minute, but I thought I had better check it. > > I was able to create and incorporate the .lib OK on W11 this morning. > My app (ZZALOG) reported the correct hamlib version. Unfortunately, I > am not able right now to test a rig connection, maybe in a couple of > hours when I can get to the shack and turn the rig on - it doesn't > power on over WiFi! > > Snapshot: > hamlib-w64-4.7.1~rc-20260414-b234d789d.exe<https://hamlib.sourceforge.net/snapshots-4.7/hamlib-w64-4.7.1~rc-20260414-b234d789d.exe> > > HOWEVER > > It took me ages to find the daily snapshot for 4.7. All the obvious > links took me to the 5.0 snapshot. Eventually I tried > hamlib.sourceforge.net/snapshots (without a following slash) and it > took me to hamlib.github.io where the link to 4.7 snapshots worked. Sorry. I know I've posted it here a few times: https://hamlib.sourceforge.net/snapshots-4.7/ Scroll down a little way down the page and it is listed here: https://hamlib.github.io/ > The page at hamlib.sourceforge.net/snapshots/ (with the slash) is for > 5.0. Since the daily snapshots have always been of the master branch, I chose not to change that. Had I opted to break that long-standing assumption, someone else would have noted that... > The snapshots link on > https://github.com/Hamlib/Hamlib/tree/Hamlib-4.7 takes me to the 5.0 > page. I can't help that as that is a GitHub limitation. Only one link is allowed on that part of the page template and the template doesn't change depending on what branch is chosen, at least as far as I can tell. Such are the compromises when one uses something that is "free". 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 |
33 messages has been excluded from this view by a project administrator.
