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
(56) |
Jun
(31) |
Jul
(39) |
Aug
(61) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: dforsi <no...@gi...> - 2026-08-29 20:29:51
|
Branch: refs/heads/Hamlib-4.7 Home: https://github.com/Hamlib/Hamlib Commit: c7f9bc9ce6b848d87e73fd907b94abd87d0be9cf https://github.com/Hamlib/Hamlib/commit/c7f9bc9ce6b848d87e73fd907b94abd87d0be9cf Author: David Christle <dch...@us...> Date: 2026-08-29 (Sat, 29 Aug 2026) Changed paths: M rigs/yaesu/newcat.c M tests/Makefile.am A tests/testnewcatset.c Log Message: ----------- fix(yaesu): drain rejected AC command responses AC commands could return ?; before the verification reply, leaving that reply queued and desynchronizing the next CAT transaction. Send each AC command once, consume responses through a synchronization query, and cover rejection, timeout, fast-command, and model-specific behavior with a simulated-radio test. Fixes #2079 Conflicts: tests/Makefile.am (cherry picked from commit 635d11feff27a04d0a09009fed26b36d3d37c09c) Commit: 26be0909b3198a644df74eaede37da61557ac34b https://github.com/Hamlib/Hamlib/commit/26be0909b3198a644df74eaede37da61557ac34b Author: dforsi <iu...@gm...> Date: 2026-08-29 (Sat, 29 Aug 2026) Changed paths: M rigs/yaesu/newcat.c M tests/Makefile.am A tests/testnewcatset.c Log Message: ----------- Merge pull request #2186 from dforsi/Hamlib-4.7 fix(yaesu): drain rejected AC command responses Compare: https://github.com/Hamlib/Hamlib/compare/f00ca5b45a8e...26be0909b319 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: dforsi <no...@gi...> - 2026-08-29 20:19:05
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 635d11feff27a04d0a09009fed26b36d3d37c09c https://github.com/Hamlib/Hamlib/commit/635d11feff27a04d0a09009fed26b36d3d37c09c Author: David Christle <dch...@us...> Date: 2026-08-29 (Sat, 29 Aug 2026) Changed paths: M rigs/yaesu/newcat.c M tests/Makefile.am A tests/testnewcatset.c Log Message: ----------- fix(yaesu): drain rejected AC command responses AC commands could return ?; before the verification reply, leaving that reply queued and desynchronizing the next CAT transaction. Send each AC command once, consume responses through a synchronization query, and cover rejection, timeout, fast-command, and model-specific behavior with a simulated-radio test. Fixes #2079 Conflicts: tests/Makefile.am Commit: da76639d663b82589d3b2526eb7f0d68148a55f0 https://github.com/Hamlib/Hamlib/commit/da76639d663b82589d3b2526eb7f0d68148a55f0 Author: dforsi <iu...@gm...> Date: 2026-08-29 (Sat, 29 Aug 2026) Changed paths: M rigs/yaesu/newcat.c M tests/Makefile.am A tests/testnewcatset.c Log Message: ----------- Merge pull request #2132 from dchristle/fix/2079-newcat-tune-rejection fix(yaesu): drain rejected AC command responses Compare: https://github.com/Hamlib/Hamlib/compare/8cf9b1033b07...da76639d663b To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: dforsi <no...@gi...> - 2026-08-29 10:23:34
|
Branch: refs/heads/Hamlib-4.7 Home: https://github.com/Hamlib/Hamlib Commit: b1504f7e82c57c02b622a51bfd1a0e3ada1c91b8 https://github.com/Hamlib/Hamlib/commit/b1504f7e82c57c02b622a51bfd1a0e3ada1c91b8 Author: David Christle <dch...@us...> Date: 2026-08-29 (Sat, 29 Aug 2026) Changed paths: M rigs/yaesu/ft991.c M rigs/yaesu/ft991.h M rigs/yaesu/level_gran_yaesu.h M tests/Makefile.am A tests/testft991idmeter.c Log Message: ----------- fix(ft991): extend ID meter range to 25.5 A The FT-991 calibration ended at raw 107, causing larger current readings to clamp at 10 A. Map the full 8-bit meter range to amperes and advertise matching capability metadata. Fixes #2073 (cherry picked from commit 928392489c260a795b812f3ffd9766cd3b06a2d5) Conflicts: tests/Makefile.am Commit: f00ca5b45a8e1c180b5c4ce18808ab6a51fd67d7 https://github.com/Hamlib/Hamlib/commit/f00ca5b45a8e1c180b5c4ce18808ab6a51fd67d7 Author: dforsi <iu...@gm...> Date: 2026-08-29 (Sat, 29 Aug 2026) Changed paths: M rigs/yaesu/ft991.c M rigs/yaesu/ft991.h M rigs/yaesu/level_gran_yaesu.h M tests/Makefile.am A tests/testft991idmeter.c Log Message: ----------- Merge pull request #2185 from dforsi/Hamlib-4.7 fix(ft991): extend ID meter range to 25.5 A Compare: https://github.com/Hamlib/Hamlib/compare/86b69bfd214f...f00ca5b45a8e To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: dforsi <no...@gi...> - 2026-08-28 20:00:47
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 928392489c260a795b812f3ffd9766cd3b06a2d5 https://github.com/Hamlib/Hamlib/commit/928392489c260a795b812f3ffd9766cd3b06a2d5 Author: David Christle <dch...@us...> Date: 2026-08-02 (Sun, 02 Aug 2026) Changed paths: M rigs/yaesu/ft991.c M rigs/yaesu/ft991.h M rigs/yaesu/level_gran_yaesu.h M tests/Makefile.am A tests/testft991idmeter.c Log Message: ----------- fix(ft991): extend ID meter range to 25.5 A The FT-991 calibration ended at raw 107, causing larger current readings to clamp at 10 A. Map the full 8-bit meter range to amperes and advertise matching capability metadata. Fixes #2073 Commit: dff4d2636e84bbd98c2d51d159be3f81ad89e980 https://github.com/Hamlib/Hamlib/commit/dff4d2636e84bbd98c2d51d159be3f81ad89e980 Author: dforsi <iu...@gm...> Date: 2026-08-28 (Fri, 28 Aug 2026) Changed paths: M .github/codeql-analysis.yml M .github/workflows/android-ndk.yml M .github/workflows/c-cpp.yml M .github/workflows/c-cpp32.yml M .github/workflows/codeql-analysis.yml M .github/workflows/macos-latest-features.yml M .github/workflows/macos-latest-no-features.yml M .github/workflows/ubuntu-latest-features.yml M .github/workflows/ubuntu-latest-no-features.yml A .github/workflows/windows-cross-features.yml A .github/workflows/windows-cross-no-features.yml A .github/workflows/windows-latest-features.yml A .github/workflows/windows-latest-no-features.yml A HAMLIB_STREAMING.md A HAMLIB_STREAMING_BACKEND_GUIDE.md M Makefile.am M NEWS M README.developer M bindings/hamlib.swg M bindings/python/test_Hamlib_class.py M configure.ac M doc/man1/ampctl.1 M doc/man1/rigctl.1 M doc/man1/rigctld.1 M doc/man1/rotctl.1 M doc/man1/rotctld.1 M include/hamlib/rig.h M include/hamlib/rig_state.h M include/hamlib/riglist.h M lib/Makefile.am A lib/kvparse.c A lib/kvparse.h M rigs/dummy/Makefile.am M rigs/dummy/dummy.c M rigs/dummy/dummy.h M rigs/dummy/dummy_common.c M rigs/dummy/dummy_common.h A rigs/dummy/dummy_stream.c A rigs/dummy/dummy_stream.h M rigs/dummy/netrigctl.c M rigs/dummy/quisk.c M rigs/guohetec/guohetec.c M rigs/guohetec/guohetec.h M rigs/guohetec/pmr171.c M rigs/guohetec/q900.c M rigs/icom/id5100.c M rigs/kenwood/Makefile.am M rigs/kenwood/flex6xxx.c M rigs/kenwood/k3.c M rigs/kenwood/kenwood.c M rigs/kenwood/kenwood.h M rigs/kenwood/pihpsdr.c M rigs/kenwood/th.c M rigs/kenwood/thd72.c M rigs/kenwood/thd74.c A rigs/kenwood/thd7x.c A rigs/kenwood/thd7x.h M rigs/kenwood/ts2000.c M rigs/kenwood/ts590.c M rigs/kenwood/tx500.c A rigs/tci/Makefile.am A rigs/tci/README-TCI-2.0.md A rigs/tci/sunsdr2-pro.c A rigs/tci/tci.c A rigs/tci/tci2.c A rigs/tci/tci2.h M rigs/yaesu/ftx1/ftx1.c M rigs/yaesu/ftx1/ftx1_freq.c M rigs/yaesu/ftx1/ftx1_mode.c M scripts/astylerc M simulators/simid5100.c M src/Makefile.am M src/conf.c M src/iofunc.c M src/misc.c M src/register.c M src/rig.c A src/rigctl_protocol.c A src/rigctl_protocol.h A src/stream.c A src/stream.h A src/stream_account.c A src/stream_account.h A src/stream_anchor.c A src/stream_anchor.h A src/stream_codec.c A src/stream_codec.h A src/stream_convert.c A src/stream_convert.h A src/stream_net.c A src/stream_net.h A src/stream_proto.c A src/stream_proto.h A src/stream_ringbuf.c A src/stream_ringbuf.h A src/stream_time.c A src/stream_time.h M src/token.h A test/.gitignore A test/Makefile.am A test/acutest.h A test/test_debug.h A test/test_dummy_stream.c A test/test_netrigctl_stream.c A test/test_rigctld_commands.c A test/test_rigctld_stream.c A test/test_rigstreamtest.c A test/test_stream_account.c A test/test_stream_api.c A test/test_stream_codec.c A test/test_stream_convert.c A test/test_stream_ringbuf.c A test/test_stream_time.c M tests/.gitignore M tests/Makefile.am M tests/dumpcaps.c M tests/dumpcaps.h M tests/dumpstate.c M tests/rigctl.c M tests/rigctl_parse.c M tests/rigctl_parse.h M tests/rigctld.c A tests/rigctld_client.h A tests/rigctld_stream.c A tests/rigctld_stream.h A tests/rigstreamtest.c A tests/rigstreamtest.sh A tests/rigstreamtest_util.c A tests/rigstreamtest_util.h M tests/testctlparser.c M tests/testgs100.c A tests/testguohetec.c A tests/testid5100.c M tests/testnetrigctl.c A tests/testrigctlprotocol.c A tests/testthd75emu.c A tests/testthd7x.c Log Message: ----------- Merge branch 'master' into fix/2073-ft991a-id-meter-range Commit: 8cf9b1033b07f64a4a7dd4d1da6eab95e2677d69 https://github.com/Hamlib/Hamlib/commit/8cf9b1033b07f64a4a7dd4d1da6eab95e2677d69 Author: dforsi <iu...@gm...> Date: 2026-08-28 (Fri, 28 Aug 2026) Changed paths: M rigs/yaesu/ft991.c M rigs/yaesu/ft991.h M rigs/yaesu/level_gran_yaesu.h M tests/Makefile.am A tests/testft991idmeter.c Log Message: ----------- Merge pull request #2125 from dchristle/fix/2073-ft991a-id-meter-range fix(ft991): extend ID meter range to 25.5 A Compare: https://github.com/Hamlib/Hamlib/compare/a8c0a3ff6664...8cf9b1033b07 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: dforsi <no...@gi...> - 2026-08-28 14:48:05
|
Branch: refs/heads/Hamlib-4.7 Home: https://github.com/Hamlib/Hamlib Commit: 6bacdf078c7d1a46bdd314411456148bde6d55f4 https://github.com/Hamlib/Hamlib/commit/6bacdf078c7d1a46bdd314411456148bde6d55f4 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2026-08-27 (Thu, 27 Aug 2026) Changed paths: M .github/codeql-analysis.yml M .github/workflows/android-ndk.yml M .github/workflows/c-cpp.yml M .github/workflows/c-cpp32.yml M .github/workflows/codeql-analysis.yml M .github/workflows/macos-latest-features.yml M .github/workflows/macos-latest-no-features.yml M .github/workflows/ubuntu-latest-features.yml M .github/workflows/ubuntu-latest-no-features.yml Log Message: ----------- Execute the CI actions for pushes and pull requests on all branches (cherry picked from commit 1eb217ae9d3cdb3b246ebac608e3d54f64ea72c0) Conflicts: .github/workflows/windows-cross-features.yml .github/workflows/windows-cross-no-features.yml .github/workflows/windows-latest-features.yml .github/workflows/windows-latest-no-features.yml Commit: 86b69bfd214f72c28048eb5a7c16a4d6014d621f https://github.com/Hamlib/Hamlib/commit/86b69bfd214f72c28048eb5a7c16a4d6014d621f Author: dforsi <iu...@gm...> Date: 2026-08-28 (Fri, 28 Aug 2026) Changed paths: M .github/codeql-analysis.yml M .github/workflows/android-ndk.yml M .github/workflows/c-cpp.yml M .github/workflows/c-cpp32.yml M .github/workflows/codeql-analysis.yml M .github/workflows/macos-latest-features.yml M .github/workflows/macos-latest-no-features.yml M .github/workflows/ubuntu-latest-features.yml M .github/workflows/ubuntu-latest-no-features.yml Log Message: ----------- Merge pull request #2180 from dforsi/Hamlib-4.7 Execute the CI actions for pushes and pull requests on all branches Compare: https://github.com/Hamlib/Hamlib/compare/53752e576b7f...86b69bfd214f To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: dforsi <no...@gi...> - 2026-08-28 14:47:45
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 1eb217ae9d3cdb3b246ebac608e3d54f64ea72c0 https://github.com/Hamlib/Hamlib/commit/1eb217ae9d3cdb3b246ebac608e3d54f64ea72c0 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M .github/codeql-analysis.yml M .github/workflows/android-ndk.yml M .github/workflows/c-cpp.yml M .github/workflows/c-cpp32.yml M .github/workflows/codeql-analysis.yml M .github/workflows/macos-latest-features.yml M .github/workflows/macos-latest-no-features.yml M .github/workflows/ubuntu-latest-features.yml M .github/workflows/ubuntu-latest-no-features.yml M .github/workflows/windows-cross-features.yml M .github/workflows/windows-cross-no-features.yml M .github/workflows/windows-latest-features.yml M .github/workflows/windows-latest-no-features.yml Log Message: ----------- Execute the CI actions for pushes and pull requests on all branches Commit: a8c0a3ff66649d0e9a8638ab75676e29ef87b4ff https://github.com/Hamlib/Hamlib/commit/a8c0a3ff66649d0e9a8638ab75676e29ef87b4ff Author: dforsi <iu...@gm...> Date: 2026-08-28 (Fri, 28 Aug 2026) Changed paths: M .github/codeql-analysis.yml M .github/workflows/android-ndk.yml M .github/workflows/c-cpp.yml M .github/workflows/c-cpp32.yml M .github/workflows/codeql-analysis.yml M .github/workflows/macos-latest-features.yml M .github/workflows/macos-latest-no-features.yml M .github/workflows/ubuntu-latest-features.yml M .github/workflows/ubuntu-latest-no-features.yml M .github/workflows/windows-cross-features.yml M .github/workflows/windows-cross-no-features.yml M .github/workflows/windows-latest-features.yml M .github/workflows/windows-latest-no-features.yml Log Message: ----------- Merge pull request #2179 from dforsi/master Execute the CI actions for pushes and pull requests on all branches Compare: https://github.com/Hamlib/Hamlib/compare/e4c8d09a2c32...a8c0a3ff6664 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Daniele F. <iu...@gm...> - 2026-08-28 10:26:49
|
Hello Nate, Thank you for your hard work on Hamlib. I will do more commits and I welcome more committers. Also triaging issues, testing the PRs and replying to the mailing list will help a lot, and if someone has troubles with git, I can probably help or they can send the files to me. 73 de IU5HKX Daniele |
|
From: Nate B. <n0...@n0...> - 2026-08-27 17:39:57
|
CCing the mailing list to keep others in the loop. * On 2026 27 Aug 10:26 -0500, Bob McGraw wrote: > Nate: > > A bit more info. I did update my system to WSJT V3.0.2 and restarted the > computer along with the radio. No change. Still the +55 Hz initialization > frequency. I also tried a couple of the Kenwood radio settings as the > Tentec communication protocol is, as I understand, like or much like the > Kenwood code. No luck there. I then configured HRD for the Jupiter. That > controlled the radio correctly and there was no issue with frequency > control, hopping bands, etc. All good there. I'm not really familiar with Tentec, but I seem to recall that they followed the Icom CI-V implementation. There are a few others on the list far more familiar with these implementations. > Perhaps you would know. Is there a way I can access the radio configuration > description file and perhaps make modifications myself. I am not a > programmer but I've edited several other files which are mostly text files. > Saved same and the change I made do work. In particular, FLDIGI script for > the Jupiter or the Eagle. In Hamlib, no, not directly. Default parameters are contained in the C source files and compiled into the binary library that WSJT-X links to. There is a way to add delay between commands but I don't see that WSJT-X provides a way to pass configuration parameters to the library at run time. Uwe, this might be an addition worth considering in the radio configuration dialog. 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-08-27 03:08:38
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 2d19d104474491346c26950e2b13cb204735210c https://github.com/Hamlib/Hamlib/commit/2d19d104474491346c26950e2b13cb204735210c Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M rigs/dummy/netrigctl.c M tests/Makefile.am M tests/testnetrigctl.c Log Message: ----------- fix(netrigctl): make protocol output locale-independent Normalize floating-point request values without changing the process locale so network peers always receive a decimal point. Exercise every affected command through a socket pair, including a request that exceeds the former power-conversion buffer. Commit: 59f5bd7c4272fb53c624435d7e06932a34b9dbeb https://github.com/Hamlib/Hamlib/commit/59f5bd7c4272fb53c624435d7e06932a34b9dbeb Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M src/Makefile.am A src/rigctl_protocol.c A src/rigctl_protocol.h Log Message: ----------- refactor(rigctl): add locale-neutral decimal helpers Format canonical ASCII decimal values and parse complete finite tokens without changing process-global locale state. Allow callers to select strict dot-only input or an explicit dot-or-comma compatibility policy. Commit: 14f2482783eddf8072eff3afaf379576105dd8c0 https://github.com/Hamlib/Hamlib/commit/14f2482783eddf8072eff3afaf379576105dd8c0 Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M tests/rigctl_parse.c M tests/testctlparser.c Log Message: ----------- fix(rigctld): enforce canonical decimal wire values Emit ASCII-dot decimals regardless of locale and require complete finite numeric tokens. Accept decimal comma only for unambiguous scalar fields, while keeping compound clock syntax dot-only and preserving frequency precision. Commit: 55665a83ec4180b22e4c4c864758bf2c009d8988 https://github.com/Hamlib/Hamlib/commit/55665a83ec4180b22e4c4c864758bf2c009d8988 Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M rigs/dummy/dummy_common.c M rigs/dummy/dummy_common.h M rigs/dummy/netrigctl.c M rigs/dummy/quisk.c M tests/Makefile.am M tests/testnetrigctl.c A tests/testrigctlprotocol.c Log Message: ----------- fix(netrigctl): validate canonical decimal protocol data Make the NET rigctl and Quisk clients emit ASCII-dot values and reject partial, non-finite, localized, or ambiguous compound replies. Preserve legacy hexadecimal capability fields and report locale-dependent coverage as a distinct Automake result. Commit: df9dfe9ac0ebf6b91f0231e567d2e52bde75dbde https://github.com/Hamlib/Hamlib/commit/df9dfe9ac0ebf6b91f0231e567d2e52bde75dbde Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M doc/man1/rigctl.1 M doc/man1/rigctld.1 Log Message: ----------- docs(rigctl): define canonical decimal wire format Document ASCII dot as the output separator, strict finite numeric tokens, and the limited server-side decimal-comma compatibility rule. Clarify that existing command precision and freq_t representation remain intact. Commit: 70f6b26be9d0905ea4956132cd20f170a58cf0b9 https://github.com/Hamlib/Hamlib/commit/70f6b26be9d0905ea4956132cd20f170a58cf0b9 Author: Nate Bargmann <n0...@n0...> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M .github/workflows/android-ndk.yml M .github/workflows/c-cpp.yml M .github/workflows/c-cpp32.yml M .github/workflows/codeql-analysis.yml M .github/workflows/macos-latest-features.yml M .github/workflows/macos-latest-no-features.yml M .github/workflows/ubuntu-latest-features.yml M .github/workflows/ubuntu-latest-no-features.yml M .github/workflows/windows-cross-features.yml M .github/workflows/windows-cross-no-features.yml M .github/workflows/windows-latest-features.yml M .github/workflows/windows-latest-no-features.yml M NEWS M README.developer M bindings/hamlib.swg M doc/man1/ampctl.1 M doc/man1/rigctl.1 M doc/man1/rotctl.1 M doc/man1/rotctld.1 M rigs/guohetec/guohetec.c M rigs/guohetec/guohetec.h M rigs/guohetec/pmr171.c M rigs/guohetec/q900.c M rigs/icom/id5100.c M simulators/simid5100.c M src/misc.c M src/rig.c M tests/Makefile.am A tests/testguohetec.c A tests/testid5100.c Log Message: ----------- Merge branch 'master' into fix/rigctl-locale-protocol Commit: e4c8d09a2c323572e4eb7692bc1761faf6245b8c https://github.com/Hamlib/Hamlib/commit/e4c8d09a2c323572e4eb7692bc1761faf6245b8c Author: Nate Bargmann <n0...@n0...> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M NEWS Log Message: ----------- Update NEWS for locale-neutral decimal protocol in rigctl Compare: https://github.com/Hamlib/Hamlib/compare/429065b9a2ff...e4c8d09a2c32 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Bob M. <RM...@be...> - 2026-08-27 02:55:21
|
Nate: Thanks for the response. I did change the Poll from 1S to 2S and then 3S with no observed change. I did read something about WSJT V3.0.1 having the issue but 3.0.2 seems to have resolved the issue. This was a 7300 as I recall. I actually see the same occurrence on my K3S but the transition from 00 to 55 and back to 00 is very fast. Yes, I agree the initialization on my K3S is not a problem. This leads me to believe there needs to be a bit of delay entered into the initialization routine for the older and slower radios. I've also tried a slower baud rate, from 57600 to 9600. I've not found a way to set the radio to 9600. Anyway, when I set the Port 1 for the radio to 9600, everything still works and I still see the 55 Hz frequency remain on the display. At the moment I'm at a loss regarding the next steps. FYI - this computer and WSJT 3.0.1 runs correctly with my Tentec Eagle and my Elecraft K3s. Thanks -- suggestions appreciated. 73 Bob, K4TAX On 8/26/2026 5:54 PM, Nate Bargmann wrote: > * On 2026 26 Aug 17:47 -0500, Bob McGraw wrote: >> In initializing WSJT configured for the Tentec 538, it appears the >> application sends the frequency selected plus 55HZ. It seems that the >> application is confirming frequency control of VFO A. The application >> appears to be running too fast for the old Jupiter and then thus leaves the >> radio 55 HZ high in frequency as indicated on the display. Is there some >> way to add some delay or changing timing parameters such that the Tentec >> Jupiter will resolve the frequency to the correct value? > Hi Bob. > > Looking at WSJT-X Improved here, at the top right of the Radio tab in > the Settings dialog I see a spin box titled Poll Interval. Have you > tried increasing that value? > >> In using the same application with my K3S, I observe the same brief >> occurrence, but the K3S is responding faster to the application inquiry and >> resolves to the correct frequency. Not a problem. > I use a K3 and just fired up WSJT-X after not doing so for several > months mostly to check antennas for the upcoming KS QSO Party so it was > easy to take a look. > >> Windows 10 Pro 64 bit, Tentec Jupiter 538, V1.29, RS-232 cable (no USB >> conversion) between the radio and computer, Port COM 1, 57600, 8 bit, No >> Parity, stop 1 Flow Hardware. Driver Microsoft 10.0.19041.1 > Though I'm running Debian 13 here, the Radio dialog should be the same. > > 73, Nate > > |
|
From: Nate B. <no...@gi...> - 2026-08-27 01:43:33
|
Branch: refs/heads/Hamlib-4.7 Home: https://github.com/Hamlib/Hamlib Commit: bf47639499d7f38aabf25784988cf17175a10644 https://github.com/Hamlib/Hamlib/commit/bf47639499d7f38aabf25784988cf17175a10644 Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M rigs/icom/id5100.c M simulators/simid5100.c M src/misc.c M src/rig.c M tests/Makefile.am A tests/testid5100.c Log Message: ----------- fix(icom): backport ID-5100 VFO switching to 4.7 Backport the ID-5100 dualwatch and VFO targeting fix from master, adapting the regression test registration to the 4.7 build layout. Backport of aee0d590c from Hamlib/Hamlib#2129. Commit: ce03f30d61d1cb470f6d7949b8ff29f2447bf392 https://github.com/Hamlib/Hamlib/commit/ce03f30d61d1cb470f6d7949b8ff29f2447bf392 Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M tests/Makefile.am M tests/testid5100.c Log Message: ----------- fix(tests): make ID-5100 transcript portable on Windows The transcript test used POSIX socketpair and read/write APIs, so native MinGW builds could not compile it. Use loopback TCP with Winsock on Windows, preserve socketpair elsewhere, and link the platform network libraries. Commit: 172eb94e7b15a3e9509a9f54e17496aa1a51737b https://github.com/Hamlib/Hamlib/commit/172eb94e7b15a3e9509a9f54e17496aa1a51737b Author: Nate Bargmann <n0...@n0...> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M NEWS M README.developer M amplifiers/gemini/gemini.c M amplifiers/gemini/gemini.h M bindings/hamlib.swg M doc/man1/ampctl.1 M doc/man1/rigctl.1 M doc/man1/rotctl.1 M doc/man1/rotctld.1 M rigs/gomspace/gs100.c M rigs/icom/icom.c M rigs/icom/icom.h M rigs/yaesu/ftx1/ftx1.h M rigs/yaesu/ftx1/ftx1_audio.c M rigs/yaesu/ftx1/ftx1_clarifier.c M rigs/yaesu/ftx1/ftx1_ext.c M src/misc.c M tests/.gitignore M tests/Makefile.am M tests/ampctl_parse.c M tests/rigctl_parse.c M tests/rotctl_parse.c A tests/testbandmetadata.c A tests/testctlbounds.sh A tests/testctlparser.c A tests/testftx1parsers.c A tests/testgeministatus.c A tests/testgs100.c A tests/testicomfallback.c A tests/testicomts.c Log Message: ----------- Merge branch 'Hamlib-4.7' into backport/4.7-id5100-vfo-switching Commit: 53752e576b7f1864a0a4c97bdbe526f48efb0858 https://github.com/Hamlib/Hamlib/commit/53752e576b7f1864a0a4c97bdbe526f48efb0858 Author: Nate Bargmann <n0...@n0...> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M NEWS Log Message: ----------- Update NEWS for ID-5100 VFO switching backport Compare: https://github.com/Hamlib/Hamlib/compare/7fdac184c567...53752e576b7f To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2026-08-26 23:55:01
|
Branch: refs/heads/Hamlib-4.7 Home: https://github.com/Hamlib/Hamlib Commit: dbcb17c8e8be174c7f8d730ce37c33a3a8aceaeb https://github.com/Hamlib/Hamlib/commit/dbcb17c8e8be174c7f8d730ce37c33a3a8aceaeb Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M rigs/icom/icom.c M tests/Makefile.am A tests/testicomfallback.c Log Message: ----------- fix(icom): fall back from optional command rejection Old IC-7100 firmware rejects optional CI-V 0x25 and 0x26 probes. Use legacy frequency and mode commands in the same API call. Query legacy data mode and preserve unrelated protocol errors. (cherry picked from commit 3c0b14461504dd4dd44f8063f1103ad7b663618d) Commit: 81c0c36204e0b131f4e435293a80eafa63964c4a https://github.com/Hamlib/Hamlib/commit/81c0c36204e0b131f4e435293a80eafa63964c4a Author: Nate Bargmann <n0...@n0...> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M NEWS M README.developer M amplifiers/gemini/gemini.c M amplifiers/gemini/gemini.h M bindings/hamlib.swg M doc/man1/ampctl.1 M doc/man1/rigctl.1 M doc/man1/rotctl.1 M doc/man1/rotctld.1 M rigs/gomspace/gs100.c M rigs/icom/icom.c M rigs/icom/icom.h M rigs/yaesu/ftx1/ftx1.h M rigs/yaesu/ftx1/ftx1_audio.c M rigs/yaesu/ftx1/ftx1_clarifier.c M rigs/yaesu/ftx1/ftx1_ext.c M src/misc.c M tests/.gitignore M tests/Makefile.am M tests/ampctl_parse.c M tests/rigctl_parse.c M tests/rotctl_parse.c A tests/testbandmetadata.c A tests/testctlbounds.sh A tests/testctlparser.c A tests/testftx1parsers.c A tests/testgeministatus.c A tests/testgs100.c A tests/testicomts.c Log Message: ----------- Merge branch 'Hamlib-4.7' into backport/4.7-icom-optional-command-fallback Commit: 7fdac184c567d539664ef8d530cd24bbaa67b1d2 https://github.com/Hamlib/Hamlib/commit/7fdac184c567d539664ef8d530cd24bbaa67b1d2 Author: Nate Bargmann <n0...@n0...> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M NEWS Log Message: ----------- Update NEWS for Icom command fallback backport Compare: https://github.com/Hamlib/Hamlib/compare/fc8ec54ac781...7fdac184c567 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2026-08-26 23:14:17
|
Branch: refs/heads/Hamlib-4.7 Home: https://github.com/Hamlib/Hamlib Commit: 30b694d6a887667f4ca449e504403f893682a4f5 https://github.com/Hamlib/Hamlib/commit/30b694d6a887667f4ca449e504403f893682a4f5 Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M tests/ampctl_parse.c M tests/rigctl_parse.c M tests/rotctl_parse.c Log Message: ----------- fix(ctl): bound command parser inputs Reject stream read errors instead of synthesizing empty commands, validate raw hexadecimal command syntax without reading past its terminator, and keep fixed-size command and description inputs within their actual capacities. (cherry picked from commit c0adbb27bbd5178832dc135633a0e66cb83c4521) Commit: e112c04fb7cd0245fa4214c3d7fc48bc03a3ed1f https://github.com/Hamlib/Hamlib/commit/e112c04fb7cd0245fa4214c3d7fc48bc03a3ed1f Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M amplifiers/gemini/gemini.c M amplifiers/gemini/gemini.h M rigs/gomspace/gs100.c M rigs/icom/icom.c M rigs/icom/icom.h Log Message: ----------- fix(backends): validate bounded parser fields Stop Icom tuning-step lookup at each table sentinel and bound Gemini status fields without letting truncated scans cancel valid matches. Parse GS100 newline-delimited response lines until its exact non-terminated prompt while enforcing response and line-count limits. (cherry picked from commit b9b972378f9fbb1b79579d4d1671b713c3786831) Commit: 9939978040e64a3b7aeae5f02311dbdfceabfb80 https://github.com/Hamlib/Hamlib/commit/9939978040e64a3b7aeae5f02311dbdfceabfb80 Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M src/misc.c Log Message: ----------- fix(core): handle missing band metadata Check for the BANDSELECT opening delimiter before advancing into the band list in both numeric and string lookup paths. (cherry picked from commit 86dcae5fd6e852ecea3eb9710b4b7ea92ecd4c7f) Commit: cb5b9661e29a567c9880d1d485299029d2603d08 https://github.com/Hamlib/Hamlib/commit/cb5b9661e29a567c9880d1d485299029d2603d08 Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M rigs/yaesu/ftx1/ftx1.h M rigs/yaesu/ftx1/ftx1_audio.c M rigs/yaesu/ftx1/ftx1_clarifier.c M rigs/yaesu/ftx1/ftx1_ext.c Log Message: ----------- fix(ftx1): validate physical-device replies Require exact clarifier and extended-menu response structure, validate numeric conversions and terminators, and reject signed or out-of-range meter values. (cherry picked from commit d60beb2e638ada12fba55a3ef14d35ed9fb9106c) Commit: 8ee11c1075c97bd56880b41d6ccfc7966ae1b421 https://github.com/Hamlib/Hamlib/commit/8ee11c1075c97bd56880b41d6ccfc7966ae1b421 Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M tests/.gitignore M tests/Makefile.am A tests/testbandmetadata.c A tests/testctlbounds.sh A tests/testctlparser.c A tests/testftx1parsers.c A tests/testgeministatus.c A tests/testgs100.c A tests/testicomts.c Log Message: ----------- test(parsers): add boundary regressions Exercise command stream failures, hexadecimal byte formats, backend truncation and framing, metadata absence, and physical-device reply boundaries with focused valid and malformed cases. Ignore the generated test binaries and harness logs. (cherry picked from commit 5293dbb8558031f7e2a47aa49b4e4c9b23eb097d) Commit: 3ee44369155e6c3760737d5239fddcaf3529dc4b https://github.com/Hamlib/Hamlib/commit/3ee44369155e6c3760737d5239fddcaf3529dc4b Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M rigs/yaesu/ftx1/ftx1_audio.c Log Message: ----------- refactor(ftx1): simplify S-meter parsing Suppress the unused P1 conversion result while retaining the response-digit validation performed by the conversion. (cherry picked from commit 3afe2133a1ef1010478ace1d8c2bb89ff831b70a) Commit: 4e03d3813fe89c468766ceed7a555dd531e34bb3 https://github.com/Hamlib/Hamlib/commit/4e03d3813fe89c468766ceed7a555dd531e34bb3 Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M tests/ampctl_parse.c Log Message: ----------- fix(ampctl): bound escaped command parsing Stop binary command decoding at the documented escape boundary and use the conversion endpoint to advance. This avoids reading beyond a terminated command while preserving valid escaped bytes. (cherry picked from commit 560a44d844d12b5e91110102bd39df1f38086b8b) Commit: de0d2424a1d8b375f64269d5ed8b8ff33dcc3f83 https://github.com/Hamlib/Hamlib/commit/de0d2424a1d8b375f64269d5ed8b8ff33dcc3f83 Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M src/misc.c M tests/testbandmetadata.c Log Message: ----------- fix(core): return generic band for missing metadata Band-name callers treat successful lookups as printable strings. Return BANDGEN when granularity metadata has no band list instead of propagating NULL into formatting paths. (cherry picked from commit 489ca77a04e3622e57917e4061e4fa480a9cf238) Commit: da2734967d277b6e98dd8c944d48ee34157c47fe https://github.com/Hamlib/Hamlib/commit/da2734967d277b6e98dd8c944d48ee34157c47fe Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M rigs/yaesu/ftx1/ftx1.h M rigs/yaesu/ftx1/ftx1_audio.c M tests/testftx1parsers.c Log Message: ----------- fix(ftx1): validate S-meter response framing Require the response command, VFO selector, numeric payload, and terminator to match the requested S-meter frame. Reject malformed or mismatched replies without changing the output value. (cherry picked from commit 1f804d4da78954a4413c81d92ace81eec120f569) Commit: 703de001709e98a2b1f64a2284960d750afe6040 https://github.com/Hamlib/Hamlib/commit/703de001709e98a2b1f64a2284960d750afe6040 Author: David Christle <dch...@us...> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M tests/rotctl_parse.c M tests/testctlbounds.sh Log Message: ----------- fix(rotctl): bound escaped command parsing Stop parsing when an escape is missing or consumes no input, and count only successfully decoded bytes. This avoids the extra strtol call beyond the command terminator while preserving valid raw commands. (cherry picked from commit faefdac4ab8bf6d990b41469cad8692e8544f1af) Commit: c3656cee6280a33a80db208c3bd271635adf7fee https://github.com/Hamlib/Hamlib/commit/c3656cee6280a33a80db208c3bd271635adf7fee Author: Nate Bargmann <n0...@n0...> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M amplifiers/gemini/gemini.c M amplifiers/gemini/gemini.h M rigs/gomspace/gs100.c M rigs/icom/icom.c M rigs/icom/icom.h M rigs/yaesu/ftx1/ftx1.h M rigs/yaesu/ftx1/ftx1_audio.c M rigs/yaesu/ftx1/ftx1_clarifier.c M rigs/yaesu/ftx1/ftx1_ext.c M src/misc.c M tests/.gitignore M tests/Makefile.am M tests/ampctl_parse.c M tests/rigctl_parse.c M tests/rotctl_parse.c A tests/testbandmetadata.c A tests/testctlbounds.sh A tests/testctlparser.c A tests/testftx1parsers.c A tests/testgeministatus.c A tests/testgs100.c A tests/testicomts.c Log Message: ----------- Merge GitHub PR #2122 Commit: fc8ec54ac7810a1975581c1e4783815d4c59e516 https://github.com/Hamlib/Hamlib/commit/fc8ec54ac7810a1975581c1e4783815d4c59e516 Author: Nate Bargmann <n0...@n0...> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M NEWS Log Message: ----------- Update NEWS for parser bounds hardening backport Compare: https://github.com/Hamlib/Hamlib/compare/251815bbe505...fc8ec54ac781 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <n0...@n0...> - 2026-08-26 22:54:47
|
* On 2026 26 Aug 17:47 -0500, Bob McGraw wrote: > In initializing WSJT configured for the Tentec 538, it appears the > application sends the frequency selected plus 55HZ. It seems that the > application is confirming frequency control of VFO A. The application > appears to be running too fast for the old Jupiter and then thus leaves the > radio 55 HZ high in frequency as indicated on the display. Is there some > way to add some delay or changing timing parameters such that the Tentec > Jupiter will resolve the frequency to the correct value? Hi Bob. Looking at WSJT-X Improved here, at the top right of the Radio tab in the Settings dialog I see a spin box titled Poll Interval. Have you tried increasing that value? > In using the same application with my K3S, I observe the same brief > occurrence, but the K3S is responding faster to the application inquiry and > resolves to the correct frequency. Not a problem. I use a K3 and just fired up WSJT-X after not doing so for several months mostly to check antennas for the upcoming KS QSO Party so it was easy to take a look. > Windows 10 Pro 64 bit, Tentec Jupiter 538, V1.29, RS-232 cable (no USB > conversion) between the radio and computer, Port COM 1, 57600, 8 bit, No > Parity, stop 1 Flow Hardware. Driver Microsoft 10.0.19041.1 Though I'm running Debian 13 here, the Radio dialog should be the same. 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: Bob M. <RM...@be...> - 2026-08-26 20:16:09
|
In initializing WSJT configured for the Tentec 538, it appears the application sends the frequency selected plus 55HZ. It seems that the application is confirming frequency control of VFO A. The application appears to be running too fast for the old Jupiter and then thus leaves the radio 55 HZ high in frequency as indicated on the display. Is there some way to add some delay or changing timing parameters such that the Tentec Jupiter will resolve the frequency to the correct value? In using the same application with my K3S, I observe the same brief occurrence, but the K3S is responding faster to the application inquiry and resolves to the correct frequency. Not a problem. Windows 10 Pro 64 bit, Tentec Jupiter 538, V1.29, RS-232 cable (no USB conversion) between the radio and computer, Port COM 1, 57600, 8 bit, No Parity, stop 1 Flow Hardware. Driver Microsoft 10.0.19041.1 Thanks in advance 73 Bob, K4TAX |
|
From: (SV2AGW) G. R. <sv...@ya...> - 2026-08-26 16:51:37
|
Hi I was wondering if there is a ready-made/prebuilt Hamlib library available for Apple Silicon (arm64). I need to include Hamlib in the distribution package of my application, and I'd prefer to use an official or otherwise well-tested build if one is available. Could someone please point me to such a build, or let me know what the recommended approach is for distributing Hamlib with a macOS application on Apple Silicon? Thanks in advance for your help! 73 SV2AGW) George Rossopoulos Anakreontos 14 GR-54250 Thessaloniki GREECE www.sv2agw.com www.frinos.com www.agwtracker.com |
|
From: Mikael N. <mik...@fa...> - 2026-08-26 11:21:25
|
Thanks for pointing this out - there's an overwhelming amount of PR activity going on (and my giant PRs are not helping :D). I try to do _some_ PR reviews, but I'm also currently trying to wrap up the ARDC project (streaming backends + finally later the test framework, which is a huge thing... but it's coming!), so I don't have much bandwidth left for the reviews. I try to handle all feedback and further development of the ARDC project-related features though! Nate: I think I may have push rights to the repo too - at least the UI looks like it lets me merge PRs. If you're ok with it, I can try to do the full review/test cycle on some PRs (there are a couple of them waiting) and then go for a merge if the contribution looks good - just to get some of the work off your task list. What I'm also a bit worried about are security related issues in new contributed and if we could improve automated checks with GitHub actions. I will have a look at this. The new GH actions now do Windows builds automatically, so it helps a bit. They don't flag all warnings yet, which would be a great addition. Should we make the GH actions fail on code warnings - or maybe they could be set up to write comments to the PRs with the build issues noticed? It's a bit time-consuming to find all the warnings from the different builds manually. Thoughts? 73, Mikael OH3BHX On Tue, Aug 25, 2026, at 18:51, Nate Bargmann wrote: > Right now there are 34 PRs pending. It has gotten to the point that > most do not merge cleanly and I'm unsure of which way is correct to > resolve the conflict and when I don't hear from the creator of the PR, > I'm stuck. As a result, there should probably be three or four of us > working on merging things given the recent volume. In addition to > myself, Daniele has push access to the main repository, so Daniele, feel > free to start testing and merging some of the older PRs. Let's > collaborate as much as possible. I do see all comments and commits > added to PRs so I don't have to be specifically referenced to receive a > notification. > > I'd like to see a couple more volunteers, preferably from those that > have been around the project for a while. Working with the GitHub UI > isn't difficult, though I mostly do not merge from the Web UI but > locally and then push to master or 4.7, whichever branch the PR > references. I test compilation with 'make distcheck' on Debian 13 and > then cross-compile with MinGW on Debian 13 from the resulting source > archive. Once in a while I test with clang as well or do a more > intensive test with all of the bindings tests as the CI instances do. > Then I merge locally and push. > > 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 > > Attachments: > * signature.asc |
|
From: Nate B. <n0...@n0...> - 2026-08-25 15:51:25
|
Right now there are 34 PRs pending. It has gotten to the point that most do not merge cleanly and I'm unsure of which way is correct to resolve the conflict and when I don't hear from the creator of the PR, I'm stuck. As a result, there should probably be three or four of us working on merging things given the recent volume. In addition to myself, Daniele has push access to the main repository, so Daniele, feel free to start testing and merging some of the older PRs. Let's collaborate as much as possible. I do see all comments and commits added to PRs so I don't have to be specifically referenced to receive a notification. I'd like to see a couple more volunteers, preferably from those that have been around the project for a while. Working with the GitHub UI isn't difficult, though I mostly do not merge from the Web UI but locally and then push to master or 4.7, whichever branch the PR references. I test compilation with 'make distcheck' on Debian 13 and then cross-compile with MinGW on Debian 13 from the resulting source archive. Once in a while I test with clang as well or do a more intensive test with all of the bindings tests as the CI instances do. Then I merge locally and push. 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: dforsi <no...@gi...> - 2026-08-25 15:26:38
|
Branch: refs/heads/Hamlib-4.7 Home: https://github.com/Hamlib/Hamlib Commit: 40579c6213eee8e4d15b45d176deff3dcab79acd https://github.com/Hamlib/Hamlib/commit/40579c6213eee8e4d15b45d176deff3dcab79acd Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2026-08-25 (Tue, 25 Aug 2026) Changed paths: M bindings/hamlib.swg Log Message: ----------- Fix building Python bindings with SWIG 4.5 This change is compatible with SWIG 4.4. Fixes: error: implicit declaration of function 'PyInt_FromLong' SWIG commit that dropped the macros used for compatibility with Python 2: https://github.com/swig/swig/commit/79f7a2b7cb7ddc256eba09c8770133148025171d Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1145352 Commit: 251815bbe505b51677ad3828cff9f071988e473c https://github.com/Hamlib/Hamlib/commit/251815bbe505b51677ad3828cff9f071988e473c Author: dforsi <iu...@gm...> Date: 2026-08-25 (Tue, 25 Aug 2026) Changed paths: M bindings/hamlib.swg Log Message: ----------- Merge pull request #2173 from dforsi/fix/swig-4.5 Fix building Python bindings with SWIG 4.5 Compare: https://github.com/Hamlib/Hamlib/compare/e45b9b699317...251815bbe505 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: dforsi <no...@gi...> - 2026-08-25 14:44:05
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 8c008b7c34fc293f44047d2ecc0126922ba325db https://github.com/Hamlib/Hamlib/commit/8c008b7c34fc293f44047d2ecc0126922ba325db Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2026-08-25 (Tue, 25 Aug 2026) Changed paths: M bindings/hamlib.swg Log Message: ----------- Fix building Python bindings with SWIG 4.5 This change is compatible with SWIG 4.4. Fixes: error: implicit declaration of function 'PyInt_FromLong' SWIG commit that dropped the macros used for compatibility with Python 2: https://github.com/swig/swig/commit/79f7a2b7cb7ddc256eba09c8770133148025171d Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1145352 (cherry picked from commit 40579c6213eee8e4d15b45d176deff3dcab79acd) Commit: 429065b9a2ff749bba702f034fde2ddbdf77019f https://github.com/Hamlib/Hamlib/commit/429065b9a2ff749bba702f034fde2ddbdf77019f Author: dforsi <iu...@gm...> Date: 2026-08-25 (Tue, 25 Aug 2026) Changed paths: M bindings/hamlib.swg Log Message: ----------- Merge pull request #2175 from dforsi/master Fix building Python bindings with SWIG 4.5 Compare: https://github.com/Hamlib/Hamlib/compare/45755bebfbb2...429065b9a2ff To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Jon S. <jon...@gm...> - 2026-08-25 01:13:20
|
Hello first user of ATS driver :) I'll try to look into this and reproduce it on my setup, the verbose output would be appreciated. Also please do not expect quick fixes, this is a weekend project for me :( Best regards On Sun, Aug 23, 2026 at 07:21:33PM +0200, Olav Roth via Hamlib-developer wrote: > Hello, > > I found a reproducible segmentation fault in the new ATS Mini > Hamlib backend (model 44001) on macOS. > > Environment: > - macOS, 64-bit > - ATS Mini firmware 2.35 > - Hamlib 5.0.0~git 2026-08-23 > - commit 45755bebf > - /dev/cu.usbmodem14201 > - 115200 baud > > The ATS Mini returns monitor responses such as: > > 235,14074,0,0,ALL,USB,1k,3.0k,0,40,27,0,1,4.86,47 > > Frequency and mode control otherwise work. > > When using rigctld, it can eventually crash with EXC_BAD_ACCESS. > An LLDB backtrace shows: > > strtod > p_ats_update_state() at ats.c:97:38 > ats_mini_get_freq() at ats.c:383:15 > rig_get_freq() > rig_set_freq() > rigctl_set_freq() > rigctl_parse() > handle_socket() > > The immediate fault is in strtod(), apparently while parsing a > monitor response. It looks like p_ats_update_state() can pass a > NULL/invalid token to the numeric parser if the response is > incomplete or otherwise unexpected. > > I have the complete -vvvvv rigctld output and LLDB backtrace > available if useful. > > This is the best part: > > * thread #3, stop reason = EXC_BAD_ACCESS (code=1, address=0x0) > * frame #0: ... libsystem_c.dylib`fastParse64 > frame #1: ... `_ffpp_strtoencf64_l` > frame #2: ... `strtod` > frame #3: ... libhamlib.5.dylib`p_ats_update_state(rig=...) at ats.c:97:38 > frame #4: ... `ats_mini_get_freq(...)` at ats.c:383:15 > frame #5: ... `rig_get_freq(...)` at rig.c:2687:19 > frame #6: ... `rig_set_freq(...)` at rig.c:2452:23 > frame #7: ... `rigctld` ... `rigctl_set_freq(...)` > frame #8: ... `rigctld` ... `rigctl_parse(...)` > frame #9: ... `rigctld` ... `handle_socket(...)` > > vy 73, > Olav > DG3BP > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Olav R. <ol...@ol...> - 2026-08-23 17:40:31
|
Hello,
I found a reproducible segmentation fault in the new ATS Mini
Hamlib backend (model 44001) on macOS.
Environment:
- macOS, 64-bit
- ATS Mini firmware 2.35
- Hamlib 5.0.0~git 2026-08-23
- commit 45755bebf
- /dev/cu.usbmodem14201
- 115200 baud
The ATS Mini returns monitor responses such as:
235,14074,0,0,ALL,USB,1k,3.0k,0,40,27,0,1,4.86,47
Frequency and mode control otherwise work.
When using rigctld, it can eventually crash with EXC_BAD_ACCESS.
An LLDB backtrace shows:
strtod
p_ats_update_state() at ats.c:97:38
ats_mini_get_freq() at ats.c:383:15
rig_get_freq()
rig_set_freq()
rigctl_set_freq()
rigctl_parse()
handle_socket()
The immediate fault is in strtod(), apparently while parsing a
monitor response. It looks like p_ats_update_state() can pass a
NULL/invalid token to the numeric parser if the response is
incomplete or otherwise unexpected.
I have the complete -vvvvv rigctld output and LLDB backtrace
available if useful.
This is the best part:
* thread #3, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
* frame #0: ... libsystem_c.dylib`fastParse64
frame #1: ... `_ffpp_strtoencf64_l`
frame #2: ... `strtod`
frame #3: ... libhamlib.5.dylib`p_ats_update_state(rig=...) at ats.c:97:38
frame #4: ... `ats_mini_get_freq(...)` at ats.c:383:15
frame #5: ... `rig_get_freq(...)` at rig.c:2687:19
frame #6: ... `rig_set_freq(...)` at rig.c:2452:23
frame #7: ... `rigctld` ... `rigctl_set_freq(...)`
frame #8: ... `rigctld` ... `rigctl_parse(...)`
frame #9: ... `rigctld` ... `handle_socket(...)`
vy 73,
Olav
DG3BP
|
|
From: Nate B. <n0...@n0...> - 2026-08-23 16:54:54
|
----- Forwarded message from w1hkj <w1...@gm...> ----- Date: Sat, 22 Aug 2026 08:51:18 -0500 From: w1hkj <w1...@gm...> To: "Joseph A. Counsil" <jos...@gm...>, Nate Bargmann <n0...@n0...> Subject: Re: An alternative to the hamlib/xmlrpc-c++ modificatlion You found another packaging mistake. The previous file looked like a patch, but its @@ hunk headers were missing line ranges, so patch quite correctly treated it as garbage. I regenerated it as a real unified diff and verified both: patch --dry-run -p1 PASS patch -p1 PASS against the 4.7.2 flrig.c, and I also verified that the patched result is byte-for-byte identical to the supplied replacement file. Download the corrected legacy hardening v2 kit From the Hamlib 4.7.2 source root, use: patch --dry-run -p1 < 0001-flrig-legacy-http-framing-hardening-v2.patch and if that is clean: patch -p1 < 0001-flrig-legacy-http-framing-hardening-v2.patch The archive also contains a complete replacement flrig.c in case you prefer that route. One additional improvement came from rechecking Hamlib 4.7.2's I/O implementation: read_block() does return the actual number of bytes read, so using it to consume exactly the HTTP Content-Length body is consistent with the Hamlib API. This one is ready for the build/test step. TRY AGAIN. SRI David On Sat, Aug 22, 2026 at 8:36 AM w1hkj <w1...@gm...> wrote: > I directed ChatGPT to create an alternative to the proposed fix for the > latency issue with JS8Call. > > "*Yes. I think it is worth having a credible legacy-preserving > alternative ready for exactly that reason.* > > *I reviewed the 4.7.2 legacy path again, and there are three weaknesses > that stand out. First, read_transaction() reads the HTTP response > line-by-line and decides the response is complete when it happens to > encounter </methodResponse>; second, write_transaction() unconditionally > calls rig_flush() on the persistent network socket before each request; and > third, flrig_transaction() explicitly ignores the return value from > read_transaction() and continues parsing anyway.* > > *That is a fragile combination for a persistent TCP connection. Hamlib's > lower-level read_string() is itself timeout- and packet-arrival-sensitive, > and the source even contains a special FLRig-specific experiment for > </methodResponse>, suggesting response framing had already been recognized > as unusual.* > > *I prepared an experimental legacy hardening patch that keeps the existing > socket/XML implementation rather than replacing it:* > > *Download the Hamlib 4.7.2 legacy hardening experiment* > > *The proposed change does four main things:* > > - > > *reads the HTTP headers and uses Content-Length to consume exactly one > complete XML-RPC body;* > - > > *removes the unconditional rig_flush() before every request, because > once responses are consumed precisely, that flush is unnecessary and can > race late-arriving bytes;* > - > > *propagates read_transaction() timeout/I/O/protocol errors instead of > ignoring them;* > - > > *does not automatically retransmit a failed RPC, because a setter such > as PTT may already have executed.* > > *The basic model becomes:* > > *write request > ↓ > read HTTP status + headers > ↓ > parse Content-Length > ↓ > read exactly N body bytes > ↓ > validate XML-RPC terminator > ↓ > parse result* > > *rather than:* > > *flush socket > write request > read line > read line > read line > ... > hope </methodResponse> appears > ignore read error* > > *I would be careful how we present this to Nate: this is a reasoned > repair, not yet a proven fix. The xmlrpc-c++/Curl implementation has the > real FT-817 validation. This legacy patch needs the same Joe > stress/recovery test before we can claim equivalence.* > > *If it passes, however, the committee would have a very attractive choice: > retain Michael Black's original architecture, but harden its HTTP framing > and error handling; or use the already validated xmlrpc-c++ transport as > the preferred path. That would make the upstream discussion much less > binary."* > > Joe and I need to test this independently before it is ready as an > alternate path for the maintainer-list's consideration. > > The patch is attached. Joe, please apply to a fresh hamlib-4.7.2, and use > the JS8Call-improved / instrumented executable to discover any timing > issues. > > 73, David > > ----- 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: Nate B. <n0...@n0...> - 2026-08-23 16:54:27
|
----- Forwarded message from w1hkj <w1...@gm...> -----
Date: Sat, 22 Aug 2026 08:36:42 -0500
From: w1hkj <w1...@gm...>
To: "Joseph A. Counsil" <jos...@gm...>, Nate Bargmann
<n0...@n0...>
Subject: An alternative to the hamlib/xmlrpc-c++ modificatlion
I directed ChatGPT to create an alternative to the proposed fix for the
latency issue with JS8Call.
"*Yes. I think it is worth having a credible legacy-preserving alternative
ready for exactly that reason.*
*I reviewed the 4.7.2 legacy path again, and there are three weaknesses
that stand out. First, read_transaction() reads the HTTP response
line-by-line and decides the response is complete when it happens to
encounter </methodResponse>; second, write_transaction() unconditionally
calls rig_flush() on the persistent network socket before each request; and
third, flrig_transaction() explicitly ignores the return value from
read_transaction() and continues parsing anyway.*
*That is a fragile combination for a persistent TCP connection. Hamlib's
lower-level read_string() is itself timeout- and packet-arrival-sensitive,
and the source even contains a special FLRig-specific experiment for
</methodResponse>, suggesting response framing had already been recognized
as unusual.*
*I prepared an experimental legacy hardening patch that keeps the existing
socket/XML implementation rather than replacing it:*
*Download the Hamlib 4.7.2 legacy hardening experiment*
*The proposed change does four main things:*
-
*reads the HTTP headers and uses Content-Length to consume exactly one
complete XML-RPC body;*
-
*removes the unconditional rig_flush() before every request, because
once responses are consumed precisely, that flush is unnecessary and can
race late-arriving bytes;*
-
*propagates read_transaction() timeout/I/O/protocol errors instead of
ignoring them;*
-
*does not automatically retransmit a failed RPC, because a setter such
as PTT may already have executed.*
*The basic model becomes:*
*write request
↓
read HTTP status + headers
↓
parse Content-Length
↓
read exactly N body bytes
↓
validate XML-RPC terminator
↓
parse result*
*rather than:*
*flush socket
write request
read line
read line
read line
...
hope </methodResponse> appears
ignore read error*
*I would be careful how we present this to Nate: this is a reasoned repair,
not yet a proven fix. The xmlrpc-c++/Curl implementation has the real
FT-817 validation. This legacy patch needs the same Joe stress/recovery
test before we can claim equivalence.*
*If it passes, however, the committee would have a very attractive choice:
retain Michael Black's original architecture, but harden its HTTP framing
and error handling; or use the already validated xmlrpc-c++ transport as
the preferred path. That would make the upstream discussion much less
binary."*
Joe and I need to test this independently before it is ready as an
alternate path for the maintainer-list's consideration.
The patch is attached. Joe, please apply to a fresh hamlib-4.7.2, and use
the JS8Call-improved / instrumented executable to discover any timing
issues.
73, David
----- 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: Nate B. <n0...@n0...> - 2026-08-23 16:46:26
|
Trying the .tgz attachment. This was sent to me in private email attached to the message this is in reply to. 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.