hamlib-developer Mailing List for Ham Radio Control Libraries (Page 65)
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
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael B. <no...@gi...> - 2024-01-22 05:34:23
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 354606f46d6695978fea45efd1ef69caaeed8367 https://github.com/Hamlib/Hamlib/commit/354606f46d6695978fea45efd1ef69caaeed8367 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-01-21 (Sun, 21 Jan 2024) Changed paths: M include/hamlib/rig.h Log Message: ----------- Comment out __TIMESIZE check as mingw64 thinks it is not 64 bits -- so we may not need this https://github.com/Hamlib/Hamlib/issues/1478 Commit: 1bb469f90fcd04d27bd3ccac683e48fda3aae48d https://github.com/Hamlib/Hamlib/commit/1bb469f90fcd04d27bd3ccac683e48fda3aae48d Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-01-21 (Sun, 21 Jan 2024) Changed paths: M rigs/winradio/g313-win.c Log Message: ----------- More token_t changes https://github.com/Hamlib/Hamlib/issues/1469 Compare: https://github.com/Hamlib/Hamlib/compare/046f3b849caa...1bb469f90fcd |
|
From: Michael B. <no...@gi...> - 2024-01-22 05:29:29
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 046f3b849caa9af7bf4828c7c569e873d4ebb22c https://github.com/Hamlib/Hamlib/commit/046f3b849caa9af7bf4828c7c569e873d4ebb22c Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-01-21 (Sun, 21 Jan 2024) Changed paths: M include/hamlib/rig.h Log Message: ----------- Fix mingw build https://github.com/Hamlib/Hamlib/issues/1478 |
|
From: Michael B. <no...@gi...> - 2024-01-22 05:13:06
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 05033171c379123b2af6e29bd9f586f77d5fdcd3 https://github.com/Hamlib/Hamlib/commit/05033171c379123b2af6e29bd9f586f77d5fdcd3 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-01-21 (Sun, 21 Jan 2024) Changed paths: M c++/ampclass.cc M c++/rigclass.cc M c++/rotclass.cc M include/hamlib/ampclass.h M include/hamlib/amplifier.h M include/hamlib/rig.h M include/hamlib/rigclass.h M include/hamlib/rotator.h M include/hamlib/rotclass.h M rigs/adat/adat.c M rigs/adat/adat.h M rigs/dummy/dummy.c M rigs/dummy/dummy_common.c M rigs/dummy/dummy_common.h M rigs/dummy/flrig.c M rigs/dummy/rot_dummy.c M rigs/elad/elad.c M rigs/elad/elad.h M rigs/flexradio/dttsp.c M rigs/gomspace/gs100.c M rigs/icmarine/icm710.c M rigs/icmarine/icm710.h M rigs/icmarine/icmarine.c M rigs/icmarine/icmarine.h M rigs/icom/ic746.c M rigs/icom/ic756.c M rigs/icom/icom.c M rigs/icom/icom.h M rigs/icom/optoscan.c M rigs/icom/optoscan.h M rigs/kenwood/k2.c M rigs/kenwood/k3.c M rigs/kenwood/kenwood.c M rigs/kenwood/kenwood.h M rigs/kenwood/tmd710.c M rigs/kenwood/ts2000.c M rigs/kenwood/ts480.c M rigs/kenwood/ts590.c M rigs/kit/dds60.c M rigs/kit/drt1.c M rigs/kit/elektor304.c M rigs/kit/elektor507.c M rigs/kit/fifisdr.c M rigs/kit/hiqsdr.c M rigs/kit/si570avrusb.c M rigs/pcr/pcr.c M rigs/pcr/pcr.h M rigs/racal/ra37xx.c M rigs/racal/ra37xx.h M rigs/racal/racal.c M rigs/racal/racal.h M rigs/tentec/rx331.c M rigs/winradio/g313-posix.c M rigs/wj/wj.c M rigs/wj/wj.h M rigs/yaesu/ft757gx.c M rigs/yaesu/newcat.c M rigs/yaesu/newcat.h M rotators/easycomm/easycomm.c M rotators/flir/flir.c M rotators/grbltrk/grbltrk.c M rotators/rotorez/rotorez.c M rotators/spid/spid.c M src/amp_conf.c M src/amp_conf.h M src/amplifier.c M src/conf.c M src/ext.c M src/extamp.c M src/rot_conf.c M src/rot_conf.h M src/rot_ext.c M src/rot_settings.c M src/settings.c M tests/ampctl.c M tests/ampctld.c M tests/rigctl.c M tests/rigctl_parse.c M tests/rigctld.c M tests/rotctl.c M tests/rotctl_parse.c M tests/rotctld.c Log Message: ----------- Change token_t to hamlib_token_t to avoid collsions with libbsm and others https://github.com/Hamlib/Hamlib/issues/1469 |
|
From: Michael B. <no...@gi...> - 2024-01-22 04:41:23
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 67aee821330f5374353b51cb1f7b0c02712a872f https://github.com/Hamlib/Hamlib/commit/67aee821330f5374353b51cb1f7b0c02712a872f Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-01-21 (Sun, 21 Jan 2024) Changed paths: M include/hamlib/rig.h Log Message: ----------- Add compile-time warning if __TIMESIZE != 64 https://github.com/Hamlib/Hamlib/issues/1478 |
|
From: Michael B. <no...@gi...> - 2024-01-21 22:41:15
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 2cc68f4773c274d146083d74ac34a8b77658808d https://github.com/Hamlib/Hamlib/commit/2cc68f4773c274d146083d74ac34a8b77658808d Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-01-21 (Sun, 21 Jan 2024) Changed paths: M src/network.c Log Message: ----------- Fix compilation for mingw DLL Commit: e62dcd0b4a6e5acd500262187192f1b78de7c57f https://github.com/Hamlib/Hamlib/commit/e62dcd0b4a6e5acd500262187192f1b78de7c57f Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-01-21 (Sun, 21 Jan 2024) Changed paths: M NEWS Log Message: ----------- Merge branch 'master' of https://github.com/Hamlib/Hamlib Compare: https://github.com/Hamlib/Hamlib/compare/c4733d9dc3fb...e62dcd0b4a6e |
|
From: Michael B. <no...@gi...> - 2024-01-21 22:13:31
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 66218e57f7179568a68b05d70fb17245f3868b6e https://github.com/Hamlib/Hamlib/commit/66218e57f7179568a68b05d70fb17245f3868b6e Author: Mikael Nousiainen <mik...@ik...> Date: 2024-01-22 (Mon, 22 Jan 2024) Changed paths: M NEWS Log Message: ----------- Update NEWS for split/VFO handling changes Commit: c4733d9dc3fb4207b62fc5e7de18793bb7a75a4b https://github.com/Hamlib/Hamlib/commit/c4733d9dc3fb4207b62fc5e7de18793bb7a75a4b Author: Michael Black <mdb...@ya...> Date: 2024-01-21 (Sun, 21 Jan 2024) Changed paths: M NEWS Log Message: ----------- Merge pull request #1482 from mikaelnousiainen/update-news-for-vfo-and-split-changes Update NEWS for split/VFO handling changes Compare: https://github.com/Hamlib/Hamlib/compare/e4e12f3ce72d...c4733d9dc3fb |
|
From: Michael B. <no...@gi...> - 2024-01-21 20:41:56
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: e4e12f3ce72d61799680b2648b9b3e4cf642e7cb https://github.com/Hamlib/Hamlib/commit/e4e12f3ce72d61799680b2648b9b3e4cf642e7cb Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-01-21 (Sun, 21 Jan 2024) Changed paths: M tests/testcache.c Log Message: ----------- Fix testcache.c for new behavior |
|
From: Michael B. <no...@gi...> - 2024-01-21 20:25:13
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 8ab8aafe4836288a1da736315b77ace5146d572c https://github.com/Hamlib/Hamlib/commit/8ab8aafe4836288a1da736315b77ace5146d572c Author: Mikael Nousiainen <mik...@ik...> Date: 2023-10-29 (Sun, 29 Oct 2023) Changed paths: M rigs/dummy/dummy.c M rigs/icom/ic7300.c M rigs/icom/ic7410.c M rigs/icom/ic7600.c M rigs/icom/ic7610.c M rigs/icom/ic785x.c M rigs/icom/ic821h.c M rigs/icom/ic9100.c M rigs/icom/icom.c M rigs/icom/icom.h M rigs/icom/icom_defs.h M rigs/icom/xiegu.c M src/cache.c M src/network.c M src/rig.c M src/sprintflst.c M tests/dumpcaps.c Log Message: ----------- Streamline VFO targeting and split functionality. Rewrite Icom backend routines to always avoid VFO swapping is the rig supports the 'targetable' commands 0x25 and 0x26. Work in progress. Commit: f89e0f0388b339ae14614ada3a6fe3e3e678bd7b https://github.com/Hamlib/Hamlib/commit/f89e0f0388b339ae14614ada3a6fe3e3e678bd7b Author: Mikael Nousiainen <mik...@ik...> Date: 2023-10-31 (Tue, 31 Oct 2023) Changed paths: M rigs/icom/icom.c M src/rig.c Log Message: ----------- Cleaning up and unifying the Icom backend Commit: 89abbfeb3ae19d18894fd80d4e108576cb784cfe https://github.com/Hamlib/Hamlib/commit/89abbfeb3ae19d18894fd80d4e108576cb784cfe Author: Mikael Nousiainen <mik...@ik...> Date: 2023-11-07 (Tue, 07 Nov 2023) Changed paths: M include/hamlib/rig.h M rigs/icom/icom.c M rigs/kenwood/flex6xxx.c M rigs/kenwood/kenwood.c M rigs/kenwood/kenwood.h M rigs/kenwood/ts590.c M rigs/yaesu/ftdx101.c M rigs/yaesu/ftdx101mp.c M rigs/yaesu/newcat.c M rigs/yaesu/newcat.h M simulators/simts450.c M simulators/simts590.c M src/conf.c M src/event.c M src/misc.c M src/network.c M src/network.h M src/rig.c M src/snapshot_data.c M src/snapshot_data.h M src/token.h M tests/Makefile.am M tests/ampctl.c M tests/ampctl_parse.c M tests/ampctld.c M tests/dumpcaps.c A tests/dumpcaps.h M tests/dumpcaps_rot.c A tests/dumpcaps_rot.h M tests/rigctl.c M tests/rigctl_parse.c M tests/rigctl_parse.h M tests/rigctlcom.c M tests/rigctld.c M tests/rigctltcp.c M tests/rotctl.c M tests/rotctl_parse.c M tests/rotctl_parse.h M tests/rotctld.c Log Message: ----------- Merge master and fix conflicts Commit: 4fa61a9a32a5666807a66135881887cd298cc9b8 https://github.com/Hamlib/Hamlib/commit/4fa61a9a32a5666807a66135881887cd298cc9b8 Author: Mikael Nousiainen <mik...@ik...> Date: 2023-11-07 (Tue, 07 Nov 2023) Changed paths: M src/snapshot_data.c Log Message: ----------- Merge branch 'master' into streamline-vfo-targeting-and-split-functionality Commit: 0ece468b49c9f5db72483fe87d366f55b557f346 https://github.com/Hamlib/Hamlib/commit/0ece468b49c9f5db72483fe87d366f55b557f346 Author: Mikael Nousiainen <mik...@ik...> Date: 2023-11-09 (Thu, 09 Nov 2023) Changed paths: M src/event.c Log Message: ----------- Merge branch 'hamlib-multicast-4' into streamline-vfo-targeting-and-split-functionality Commit: c90c675add10dd2d32c371c85b4b8b9f4ad80f3d https://github.com/Hamlib/Hamlib/commit/c90c675add10dd2d32c371c85b4b8b9f4ad80f3d Author: Mikael Nousiainen <mik...@ik...> Date: 2023-11-09 (Thu, 09 Nov 2023) Changed paths: M include/hamlib/rig.h M rigs/icom/ic7100.c M rigs/icom/ic7200.c M rigs/icom/ic7300.c M rigs/icom/ic7410.c M rigs/icom/ic746.c M rigs/icom/ic756.c M rigs/icom/ic7600.c M rigs/icom/ic7610.c M rigs/icom/ic7700.c M rigs/icom/ic7800.c M rigs/icom/ic785x.c M rigs/icom/ic821h.c M rigs/icom/ic9100.c M rigs/icom/icom.c M rigs/icom/icom.h M rigs/icom/xiegu.c M src/rig.c Log Message: ----------- Unify and streamline Icom backend logic for freq/mode and split commands. Allow use of targeted freq/mode whenever possible. Move certain Icom-specific caps to the icom_priv_caps struct to remove rig-specific conditions in generic backend code. Commit: 82f2b10275ccbea508f98d8c55d194f1cec50ada https://github.com/Hamlib/Hamlib/commit/82f2b10275ccbea508f98d8c55d194f1cec50ada Author: Mikael Nousiainen <mik...@ik...> Date: 2023-11-09 (Thu, 09 Nov 2023) Changed paths: M include/hamlib/rig.h M rigs/dummy/flrig.c M rigs/kenwood/flex6xxx.c M rigs/kenwood/kenwood.h M tests/rigctl_parse.c Log Message: ----------- Merge branch 'hamlib-multicast-4' into streamline-vfo-targeting-and-split-functionality Commit: 4a926ec503b6fc9b5148f0e7db4335393fe466e5 https://github.com/Hamlib/Hamlib/commit/4a926ec503b6fc9b5148f0e7db4335393fe466e5 Author: Mikael Nousiainen <mik...@ik...> Date: 2023-11-10 (Fri, 10 Nov 2023) Changed paths: M rigs/icom/ic7300.c M rigs/icom/icom.c M src/rig.c Log Message: ----------- Fix issues found during testing Commit: e2e723ec6098da211b907b5c1ee6c1fd11dc0b13 https://github.com/Hamlib/Hamlib/commit/e2e723ec6098da211b907b5c1ee6c1fd11dc0b13 Author: Mikael Nousiainen <mik...@ik...> Date: 2023-11-14 (Tue, 14 Nov 2023) Changed paths: M rigs/icom/icom.c M rigs/icom/icom.h M src/rig.c Log Message: ----------- Simplify/streamline split VFO handling, especially in the Icom backend. Detect reverse split automatically at startup for Icom rigs. Commit: dd974a25369a95f82316897071c5836b128908d6 https://github.com/Hamlib/Hamlib/commit/dd974a25369a95f82316897071c5836b128908d6 Author: Mikael Nousiainen <mik...@ik...> Date: 2023-11-14 (Tue, 14 Nov 2023) Changed paths: M configure.ac M rigs/dummy/flrig.c M rigs/icom/icom.h M rigs/icom/id5100.c M rigs/kenwood/kenwood.c M rigs/kenwood/kenwood.h M rigs/kenwood/ts890s.c M rigs/kenwood/ts990s.c M simulators/simft991.c M simulators/simts990.c M src/misc.c M src/rig.c M src/snapshot_data.c Log Message: ----------- Merge branch 'master' into streamline-vfo-targeting-and-split-functionality Commit: b78fa43b56855ee4b9ff913df501b5c3d5ef9c90 https://github.com/Hamlib/Hamlib/commit/b78fa43b56855ee4b9ff913df501b5c3d5ef9c90 Author: Mikael Nousiainen <mik...@ik...> Date: 2023-11-14 (Tue, 14 Nov 2023) Changed paths: M rigs/icom/ic7300.c M rigs/icom/ic7600.c M rigs/icom/ic7610.c M rigs/icom/ic7800.c M rigs/icom/ic785x.c M rigs/icom/icom.c M src/cache.c M src/misc.c M src/rig.c Log Message: ----------- Fix issues in VFO targeting. Allow IC-9700 to target Sub receiver (requires VFO swapping). Commit: 7d5f540b9c367d2c3e7e6ef2f9b154e425c5fe44 https://github.com/Hamlib/Hamlib/commit/7d5f540b9c367d2c3e7e6ef2f9b154e425c5fe44 Author: Mikael Nousiainen <mik...@ik...> Date: 2023-11-20 (Mon, 20 Nov 2023) Changed paths: M rigs/dummy/dummy.c M rigs/icom/icom.c M tests/rigctl.c M tests/rigctl_parse.c M tests/rigctld.c Log Message: ----------- Fix bugs in dummy rig. Report errors (incl. timeouts) from icom_get_powerstat(), because the timeout reason is often something else than rig being powered off. Check for power status changes in rigctld/rigctl command loops. Commit: 7b341a2ad6e9bf7488ecc75a57955c21869de73f https://github.com/Hamlib/Hamlib/commit/7b341a2ad6e9bf7488ecc75a57955c21869de73f Author: Mikael Nousiainen <mik...@ik...> Date: 2023-11-20 (Mon, 20 Nov 2023) Changed paths: M .github/workflows/c-cpp.yml M configure.ac M doc/man1/rigctl.1 M include/hamlib/rig.h M rigs/dummy/flrig.c M rigs/icom/ic7300.c M rigs/icom/ic7610.c M rigs/icom/icom.c M rigs/icom/icom.h M rigs/icom/id5100.c M rigs/kenwood/ts590.c M simulators/Makefile.am A simulators/sim.h M simulators/simft817.c A simulators/simic275.c M simulators/simts950.c M simulators/simts990.c M src/conf.c M src/misc.c M src/network.c A tests/callback.c M tests/rigctl_parse.c M tests/rigctld.c M tests/testrig.c Log Message: ----------- Merge branch 'master' into streamline-vfo-targeting-and-split-functionality Commit: 00cb0eccdc666e101b64cb393891863522ca5d9a https://github.com/Hamlib/Hamlib/commit/00cb0eccdc666e101b64cb393891863522ca5d9a Author: Mikael Nousiainen <mik...@ik...> Date: 2023-11-22 (Wed, 22 Nov 2023) Changed paths: M rigs/icom/icom.c M rigs/yaesu/newcat.c M src/iofunc.c M src/network.c Log Message: ----------- Fix multicast publisher write commands to use a mutex lock to prevent corruption in (spectrum) data written with multiple write() calls. Remove unnecessary hl_usleep() calls in Icom backend, as the frame parser will correctly detect transceive messages. Commit: 8185a3562b5d3109d2c1c15cfec57e143458c140 https://github.com/Hamlib/Hamlib/commit/8185a3562b5d3109d2c1c15cfec57e143458c140 Author: Mikael Nousiainen <mik...@ik...> Date: 2023-11-22 (Wed, 22 Nov 2023) Changed paths: M src/conf.c Log Message: ----------- Merge branch 'master' into streamline-vfo-targeting-and-split-functionality Commit: 0dea8ed8bb276e59be05708378a2ffab7df8f02a https://github.com/Hamlib/Hamlib/commit/0dea8ed8bb276e59be05708378a2ffab7df8f02a Author: Mikael Nousiainen <mik...@ik...> Date: 2023-11-24 (Fri, 24 Nov 2023) Changed paths: M src/sprintflst.c Log Message: ----------- Print integer level range Commit: 93b61d2c5e035eecd41772d010a072eb3bb71932 https://github.com/Hamlib/Hamlib/commit/93b61d2c5e035eecd41772d010a072eb3bb71932 Author: Mikael Nousiainen <mik...@ik...> Date: 2023-12-19 (Tue, 19 Dec 2023) Changed paths: M rigs/dummy/dummy.c M rigs/dummy/dummy_common.c M rigs/yaesu/newcat.c M rigs/yaesu/newcat.h Log Message: ----------- Fix dummy rig bugs. Improve FTDX101/FTDX10 ST split command logic. Commit: 3a414c3221630c0e2786b2809f340f9a222bb0e9 https://github.com/Hamlib/Hamlib/commit/3a414c3221630c0e2786b2809f340f9a222bb0e9 Author: Mikael Nousiainen <mik...@ik...> Date: 2023-12-19 (Tue, 19 Dec 2023) Changed paths: M rigs/yaesu/newcat.c M src/rig.c Log Message: ----------- Allow split passband width changes without changing the mode Commit: 1cc08d2f00a4d980e7ef120ed92ee22a9024cad4 https://github.com/Hamlib/Hamlib/commit/1cc08d2f00a4d980e7ef120ed92ee22a9024cad4 Author: Mikael Nousiainen <mik...@ik...> Date: 2023-12-19 (Tue, 19 Dec 2023) Changed paths: M NEWS M amplifiers/gemini/gemini.c R bindings/csharp/hamlibgui/MainWindow.cs R bindings/csharp/hamlibgui/MainWindow.glade R bindings/csharp/hamlibgui/Program.cs R bindings/csharp/hamlibgui/README.txt R bindings/csharp/hamlibgui/hamlibgui.csproj M doc/man1/rigctl.1 M doc/man1/rigctld.1 M extra/gnuradio/gnuradio.h M extra/gnuradio/gr.c M extra/gnuradio/graudio.c M extra/gnuradio/mc4020.c M include/hamlib/rig.h M include/hamlib/rigclass.h M lib/cJSON.c M lib/precise_time.c M rigs/adat/adat.c M rigs/adat/adat.h M rigs/adat/adt_200a.c M rigs/alinco/alinco.h M rigs/alinco/dx77.c M rigs/alinco/dxsr8.c M rigs/anytone/anytone.c M rigs/anytone/anytone.h M rigs/anytone/d578.c M rigs/aor/aor.h M rigs/aor/ar2700.c M rigs/aor/ar3000.c M rigs/aor/ar3030.c M rigs/aor/ar5000.c M rigs/aor/ar7030.c M rigs/aor/ar7030p.c M rigs/aor/ar8000.c M rigs/aor/ar8200.c M rigs/aor/ar8600.c M rigs/aor/sr2200.c M rigs/barrett/4050.c M rigs/barrett/950.c M rigs/barrett/barrett.c M rigs/barrett/barrett.h M rigs/codan/codan.c M rigs/codan/codan.h M rigs/dorji/dorji.h M rigs/dorji/dra818.c M rigs/drake/drake.h M rigs/drake/r8a.c M rigs/drake/r8b.c M rigs/dummy/aclog.c M rigs/dummy/amp_dummy.c M rigs/dummy/dummy.c M rigs/dummy/dummy.h M rigs/dummy/flrig.c M rigs/dummy/flrig.h M rigs/dummy/netrigctl.c M rigs/dummy/quisk.c M rigs/dummy/rot_dummy.c M rigs/dummy/sdrsharp.c M rigs/dummy/tci1x.c M rigs/dummy/trxmanager.c M rigs/elad/elad.c M rigs/elad/elad.h M rigs/elad/fdm_duo.c M rigs/flexradio/dttsp.c M rigs/flexradio/flexradio.h M rigs/flexradio/sdr1k.c M rigs/gomspace/gs100.c M rigs/gomspace/gs100.h M rigs/icmarine/icm700pro.c M rigs/icmarine/icm710.c M rigs/icmarine/icm710.h M rigs/icmarine/icm802.c M rigs/icmarine/icm803.c M rigs/icmarine/icmarine.c M rigs/icmarine/icmarine.h M rigs/icom/delta2.c M rigs/icom/frame.c M rigs/icom/ic1275.c M rigs/icom/ic271.c M rigs/icom/ic2730.c M rigs/icom/ic275.c M rigs/icom/ic471.c M rigs/icom/ic475.c M rigs/icom/ic7000.c M rigs/icom/ic703.c M rigs/icom/ic706.c M rigs/icom/ic707.c M rigs/icom/ic7100.c M rigs/icom/ic718.c M rigs/icom/ic7200.c M rigs/icom/ic725.c M rigs/icom/ic726.c M rigs/icom/ic728.c M rigs/icom/ic7300.c M rigs/icom/ic735.c M rigs/icom/ic736.c M rigs/icom/ic737.c M rigs/icom/ic738.c M rigs/icom/ic7410.c M rigs/icom/ic746.c M rigs/icom/ic751.c M rigs/icom/ic756.c M rigs/icom/ic7600.c M rigs/icom/ic761.c M rigs/icom/ic7610.c M rigs/icom/ic765.c M rigs/icom/ic7700.c M rigs/icom/ic775.c M rigs/icom/ic78.c M rigs/icom/ic7800.c M rigs/icom/ic781.c M rigs/icom/ic785x.c M rigs/icom/ic820h.c M rigs/icom/ic821h.c M rigs/icom/ic910.c M rigs/icom/ic9100.c M rigs/icom/ic92d.c M rigs/icom/ic970.c M rigs/icom/icf8101.c M rigs/icom/icom.c M rigs/icom/icom.h M rigs/icom/icom_defs.h M rigs/icom/icr10.c M rigs/icom/icr20.c M rigs/icom/icr30.c M rigs/icom/icr6.c M rigs/icom/icr7000.c M rigs/icom/icr71.c M rigs/icom/icr72.c M rigs/icom/icr75.c M rigs/icom/icr8500.c M rigs/icom/icr8600.c M rigs/icom/icr9000.c M rigs/icom/icr9500.c M rigs/icom/icrx7.c M rigs/icom/id1.c M rigs/icom/id31.c M rigs/icom/id4100.c M rigs/icom/id51.c M rigs/icom/id5100.c M rigs/icom/omni.c M rigs/icom/os456.c M rigs/icom/os535.c M rigs/icom/perseus.c M rigs/icom/xiegu.c M rigs/jrc/jrc.h M rigs/jrc/jst145.c M rigs/jrc/nrd525.c M rigs/jrc/nrd535.c M rigs/jrc/nrd545.c M rigs/kachina/505dsp.c M rigs/kachina/kachina.h M rigs/kenwood/elecraft.c M rigs/kenwood/flex6xxx.c M rigs/kenwood/ic10.c M rigs/kenwood/k2.c M rigs/kenwood/k3.c M rigs/kenwood/kenwood.c M rigs/kenwood/kenwood.h M rigs/kenwood/pihpsdr.c M rigs/kenwood/r5000.c M rigs/kenwood/th.c M rigs/kenwood/thd7.c M rigs/kenwood/thd72.c M rigs/kenwood/thd74.c M rigs/kenwood/thf6a.c M rigs/kenwood/thf7.c M rigs/kenwood/thg71.c M rigs/kenwood/tmd700.c M rigs/kenwood/tmd710.c M rigs/kenwood/tmv7.c M rigs/kenwood/transfox.c M rigs/kenwood/trc80.c M rigs/kenwood/ts140.c M rigs/kenwood/ts2000.c M rigs/kenwood/ts440.c M rigs/kenwood/ts450s.c M rigs/kenwood/ts480.c M rigs/kenwood/ts50s.c M rigs/kenwood/ts570.c M rigs/kenwood/ts590.c M rigs/kenwood/ts680.c M rigs/kenwood/ts690.c M rigs/kenwood/ts711.c M rigs/kenwood/ts790.c M rigs/kenwood/ts811.c M rigs/kenwood/ts850.c M rigs/kenwood/ts870s.c M rigs/kenwood/ts890s.c M rigs/kenwood/ts930.c M rigs/kenwood/ts940.c M rigs/kenwood/ts950.c M rigs/kenwood/ts990s.c M rigs/kenwood/ts990s.h M rigs/kenwood/tx500.c M rigs/kenwood/xg3.c M rigs/kit/dds60.c M rigs/kit/drt1.c M rigs/kit/dwt.c M rigs/kit/elektor304.c M rigs/kit/elektor507.c M rigs/kit/fifisdr.c M rigs/kit/funcube.c M rigs/kit/hiqsdr.c M rigs/kit/kit.h M rigs/kit/miniVNA.c M rigs/kit/rs_hfiq.c M rigs/kit/si570avrusb.c M rigs/kit/usrp.c M rigs/kit/usrp_impl.h M rigs/lowe/hf235.c M rigs/lowe/lowe.h M rigs/mds/4710.c M rigs/mds/9710.c M rigs/mds/mds.c M rigs/mds/mds.h M rigs/pcr/pcr.c M rigs/pcr/pcr.h M rigs/pcr/pcr100.c M rigs/pcr/pcr1000.c M rigs/pcr/pcr1500.c M rigs/pcr/pcr2500.c M rigs/prm80/prm80.h M rigs/prm80/prm8060.c M rigs/racal/ra3702.c M rigs/racal/ra37xx.c M rigs/racal/ra6790.c M rigs/racal/racal.h M rigs/rft/ekd500.c M rigs/rft/rft.h M rigs/rs/eb200.c M rigs/rs/ek89x.c M rigs/rs/ek89x.h M rigs/rs/esmc.c M rigs/rs/gp2000.h M rigs/rs/rs.h M rigs/rs/xk2100.c M rigs/skanti/skanti.h M rigs/skanti/trp8000.c M rigs/skanti/trp8255.c M rigs/tapr/dsp10.c M rigs/tapr/tapr.h M rigs/tentec/argonaut.c M rigs/tentec/jupiter.c M rigs/tentec/omnivii.c M rigs/tentec/orion.h M rigs/tentec/paragon.c M rigs/tentec/pegasus.c M rigs/tentec/rx320.c M rigs/tentec/rx331.c M rigs/tentec/rx340.c M rigs/tentec/rx350.c M rigs/tentec/tentec.c M rigs/tentec/tentec.h M rigs/tuner/tuner.h M rigs/tuner/v4l.c M rigs/tuner/v4l2.c M rigs/uniden/bc245.c M rigs/uniden/bc250.c M rigs/uniden/bc780.c M rigs/uniden/bc895.c M rigs/uniden/bc898.c M rigs/uniden/bcd396t.c M rigs/uniden/bcd996t.c M rigs/uniden/pro2052.c M rigs/uniden/uniden.c M rigs/uniden/uniden.h M rigs/winradio/g303.c M rigs/winradio/g305.c M rigs/winradio/g313-posix.c M rigs/winradio/g313-win.c M rigs/winradio/winradio.h M rigs/winradio/wr1000.c M rigs/winradio/wr1500.c M rigs/winradio/wr1550.c M rigs/winradio/wr3100.c M rigs/winradio/wr3150.c M rigs/winradio/wr3500.c M rigs/winradio/wr3700.c M rigs/wj/wj.h M rigs/wj/wj8888.c M rigs/yaesu/frg100.c M rigs/yaesu/frg8800.c M rigs/yaesu/frg9600.c M rigs/yaesu/ft100.c M rigs/yaesu/ft1000d.c M rigs/yaesu/ft1000mp.c M rigs/yaesu/ft1200.c M rigs/yaesu/ft2000.c M rigs/yaesu/ft3000.c M rigs/yaesu/ft450.c M rigs/yaesu/ft5000.c M rigs/yaesu/ft600.c M rigs/yaesu/ft710.c M rigs/yaesu/ft736.c M rigs/yaesu/ft747.c M rigs/yaesu/ft757gx.c M rigs/yaesu/ft767gx.c M rigs/yaesu/ft817.c M rigs/yaesu/ft840.c M rigs/yaesu/ft847.c M rigs/yaesu/ft857.c M rigs/yaesu/ft890.c M rigs/yaesu/ft891.c M rigs/yaesu/ft897.c M rigs/yaesu/ft900.c M rigs/yaesu/ft9000.c M rigs/yaesu/ft920.c M rigs/yaesu/ft950.c M rigs/yaesu/ft980.c M rigs/yaesu/ft980.h M rigs/yaesu/ft990.c M rigs/yaesu/ft990v12.c M rigs/yaesu/ft991.c M rigs/yaesu/ftdx10.c M rigs/yaesu/ftdx101.c M rigs/yaesu/ftdx101mp.c M rigs/yaesu/newcat.c M rigs/yaesu/newcat.h M rigs/yaesu/vr5000.c M rigs/yaesu/vx1700.c M rigs/yaesu/yaesu.c M rigs/yaesu/yaesu.h M rotators/easycomm/easycomm.c M rotators/flir/flir.c M rotators/fodtrack/fodtrack.c M rotators/grbltrk/grbltrk.c M rotators/gs232a/gs232b.c M rotators/ioptron/rot_ioptron.c M rotators/spid/spid.c M rotators/ts7400/ts7400.c M security/md5.c M security/password.c M security/sctest.c M security/sha256.c M simulators/Makefile.am M simulators/simelecraft.c A simulators/simft1000.c M simulators/simft817.c M simulators/simft818.c M simulators/simft991.c M simulators/simftdx101.c M simulators/simftdx1200.c M simulators/simftdx3000.c M simulators/simftdx5000.c M simulators/simic275.c M simulators/simic7000.c M simulators/simic705.c M simulators/simic7100.c M simulators/simic7200.c M simulators/simic7300.c M simulators/simic7600.c M simulators/simic7610.c M simulators/simic7851.c M simulators/simic905.c M simulators/simic9100.c M simulators/simic9700.c M simulators/simicgeneric.c M simulators/simid5100.c M simulators/simkenwood.c M simulators/simpowersdr.c M simulators/simqrplabs.c M simulators/simrotorez.c M simulators/simtmd700.c A simulators/simtrusdx.c M simulators/simts450.c M simulators/simts590.c M simulators/simts950.c M simulators/simts990.c M simulators/simxiegug90.c M simulators/simyaesu.c M src/amp_conf.c M src/amplifier.c M src/cache.c M src/conf.c M src/event.c M src/fifo.c M src/iofunc.c M src/misc.c M src/misc.h M src/multicast.c M src/network.c M src/register.c M src/rig.c M src/rotator.c M src/serial.c M src/settings.c M src/sleep.c M src/snapshot_data.c M src/sprintflst.c M tests/ampctl.c M tests/ampctl_parse.c M tests/ampctld.c M tests/dumpcaps.c M tests/dumpstate.c M tests/hamlibmodels.c M tests/listrigs.c M tests/memcsv.c M tests/rig_tests.c M tests/rigctl.c M tests/rigctl_parse.c M tests/rigctld.c M tests/rigctltcp.c M tests/rigfreqwalk.c M tests/rigmem.c M tests/rigtestlibusb.c M tests/rotctl.c M tests/rotctl_parse.c M tests/rotctld.c M tests/testcache.c M tests/testmW2power.c M tests/testrig.c M tests/testrigopen.c Log Message: ----------- Merge upstream and fix conflicts Commit: 2358cba6a4df6172e560bbcccda5e1bde7706c1b https://github.com/Hamlib/Hamlib/commit/2358cba6a4df6172e560bbcccda5e1bde7706c1b Author: Mikael Nousiainen <mik...@ik...> Date: 2024-01-04 (Thu, 04 Jan 2024) Changed paths: M rigs/dummy/dummy.c M rigs/yaesu/newcat.c Log Message: ----------- Fix issues with Dummy rig VFOs. Fix Yaesu ST split command. Commit: 051e671bfaad6b1450b5a35e4441d723d3c44e23 https://github.com/Hamlib/Hamlib/commit/051e671bfaad6b1450b5a35e4441d723d3c44e23 Author: Mikael Nousiainen <mik...@ik...> Date: 2024-01-04 (Thu, 04 Jan 2024) Changed paths: M NEWS M doc/man1/rigctl.1 M doc/man1/rigctld.1 M include/hamlib/rig.h M include/hamlib/riglist.h M rigs/dummy/flrig.c M rigs/dummy/netrigctl.c A rigs/hamlib_voice_cw_memory_4.6.0.xlsx M rigs/icom/ic703.c M rigs/icom/ic7100.c M rigs/icom/ic7300.c M rigs/icom/ic737.c M rigs/icom/ic738.c M rigs/icom/ic7410.c M rigs/icom/ic746.c M rigs/icom/ic751.c M rigs/icom/ic7600.c M rigs/icom/ic761.c M rigs/icom/ic7610.c M rigs/icom/ic7700.c M rigs/icom/ic7800.c M rigs/icom/icom.c M rigs/icom/id1.c M rigs/icom/id31.c M rigs/icom/id4100.c M rigs/icom/id5100.c M rigs/icom/omni.c M rigs/icom/perseus.c M rigs/icom/xiegu.c M rigs/kenwood/flex.c M rigs/kenwood/flex6xxx.c M rigs/kenwood/k2.c M rigs/kenwood/k3.c M rigs/kenwood/kenwood.c M rigs/kenwood/kenwood.h M rigs/kenwood/ts2000.c M rigs/kenwood/ts570.c M rigs/kenwood/ts590.c M rigs/kenwood/ts870s.c M rigs/kenwood/ts890s.c M rigs/kenwood/ts990s.c M rigs/yaesu/ft1200.c M rigs/yaesu/ft2000.c M rigs/yaesu/ft3000.c M rigs/yaesu/ft450.c M rigs/yaesu/ft5000.c M rigs/yaesu/ft710.c M rigs/yaesu/ft891.c M rigs/yaesu/ft9000.c M rigs/yaesu/ft950.c M rigs/yaesu/ft991.c M rigs/yaesu/ftdx10.c M rigs/yaesu/ftdx101.c M rigs/yaesu/ftdx101mp.c M rigs/yaesu/newcat.c M rigs/yaesu/newcat.h M rotators/easycomm/easycomm.c M src/network.c M src/sprintflst.c M tests/rigctl_parse.c M tests/rotctl_parse.c Log Message: ----------- Merge upstream changes and fix conflicts. Use snprintf() in most sprintflst.c functions to avoid buffer overflows. Commit: eb7634abfbc712ffdb6f837e4d50d97411267e73 https://github.com/Hamlib/Hamlib/commit/eb7634abfbc712ffdb6f837e4d50d97411267e73 Author: Mikael Nousiainen <mik...@ik...> Date: 2024-01-15 (Mon, 15 Jan 2024) Changed paths: M NEWS M include/hamlib/amplifier.h M include/hamlib/rig.h M include/hamlib/riglist.h M include/hamlib/rotator.h A rigs/barrett/4100.c M rigs/barrett/Makefile.am M rigs/barrett/barrett.c M rigs/barrett/barrett.h M rigs/icom/ic7700.c M rigs/kenwood/elecraft.c M rigs/kenwood/ic10.c M rigs/kenwood/kenwood.c M rigs/kenwood/kenwood.h M rigs/kenwood/thd72.c M rigs/kenwood/thd74.c M rigs/kenwood/tmd710.c M rigs/kenwood/ts2000.c M rigs/kenwood/ts450s.c M rigs/kenwood/ts480.c M rigs/kenwood/ts570.c M rigs/kenwood/ts590.c M rigs/kenwood/ts850.c M rigs/kenwood/ts870s.c M rigs/kenwood/ts930.c M rigs/kenwood/xg3.c M rigs/yaesu/ftdx10.c M rigs/yaesu/newcat.c M rigs/yaesu/newcat.h M simulators/Makefile.am A simulators/simtmd710.c M simulators/simxiegug90.c M src/Makefile.am M src/amplifier.c A src/band_changed.c M src/conf.c M src/misc.c M src/misc.h M src/multicast.c M src/network.c M src/rig.c M src/rotator.c M src/serial.c M src/snapshot_data.c M tests/example.c M tests/rigctl.c Log Message: ----------- Merge upstream changes and fix conflicts Commit: 4b3a7514caa04e95ce0fca28ce6512f81f85fecf https://github.com/Hamlib/Hamlib/commit/4b3a7514caa04e95ce0fca28ce6512f81f85fecf Author: Mikael Nousiainen <mik...@ik...> Date: 2024-01-20 (Sat, 20 Jan 2024) Changed paths: M NEWS M include/hamlib/rig.h M rigs/yaesu/ftdx101.h M rigs/yaesu/newcat.c M rigs/yaesu/newcat.h M src/band_changed.c M src/misc.c M src/rig.c M src/sprintflst.c Log Message: ----------- Merge upstream and fix conflicts Commit: 8bb5bcefb92a60751f8b7f198087f7fa0d1bac0b https://github.com/Hamlib/Hamlib/commit/8bb5bcefb92a60751f8b7f198087f7fa0d1bac0b Author: Mikael Nousiainen <mik...@ik...> Date: 2024-01-21 (Sun, 21 Jan 2024) Changed paths: M rigs/yaesu/newcat.c M src/rig.c Log Message: ----------- Merge upstream and fix conflicts Commit: 1dfd17cc187f32ada47118b6d0be51a02b2a43a8 https://github.com/Hamlib/Hamlib/commit/1dfd17cc187f32ada47118b6d0be51a02b2a43a8 Author: Michael Black <mdb...@ya...> Date: 2024-01-21 (Sun, 21 Jan 2024) Changed paths: M include/hamlib/rig.h M rigs/dummy/dummy.c M rigs/dummy/dummy_common.c M rigs/icom/ic7100.c M rigs/icom/ic7200.c M rigs/icom/ic7300.c M rigs/icom/ic7410.c M rigs/icom/ic746.c M rigs/icom/ic756.c M rigs/icom/ic7600.c M rigs/icom/ic7610.c M rigs/icom/ic7700.c M rigs/icom/ic7800.c M rigs/icom/ic785x.c M rigs/icom/ic821h.c M rigs/icom/ic9100.c M rigs/icom/icom.c M rigs/icom/icom.h M rigs/icom/icom_defs.h M rigs/icom/xiegu.c M rigs/yaesu/newcat.c M rigs/yaesu/newcat.h M src/cache.c M src/iofunc.c M src/misc.c M src/network.c M src/rig.c M src/sprintflst.c M tests/dumpcaps.c M tests/rigctl.c M tests/rigctl_parse.c M tests/rigctld.c M tests/rotctl_parse.c Log Message: ----------- Merge pull request #1481 from mikaelnousiainen/streamline-vfo-targeting-and-split-functionality Streamline VFO targeting and split functionality Compare: https://github.com/Hamlib/Hamlib/compare/7d0c737e961c...1dfd17cc187f |
|
From: Brian M. <bd...@fe...> - 2024-01-21 19:33:38
|
On Fri, 19 Jan 2024 18:03:19 -0600 Nate Bargmann <n0...@n0...> wrote: > * On 2024 19 Jan 16:35 -0600, Phil GM3ZZA via Hamlib-developer wrote: > > Mike, > > > > There are some AR types out there who will want warning free > > compilations. > > Then this will be a good way to get feedback on what systems are not > 2038 ready. +1 ;-) -- Brian G8SEZ |
|
From: Nate B. <n0...@n0...> - 2024-01-21 17:45:39
|
* On 2024 21 Jan 08:51 -0600, Greg Troxel wrote: > Nate Bargmann <n0...@n0...> writes: > > > It's not out of the realm of possibility that I'll still have some 32 > > bit hardware laying around 14 years from now. I doubt any of it will be > > used to run Hamlib and on the only system I use Hamlib on I've been > > running 64 bit Linux for years but that doesn't necessarily mitigate the > > issue as I understand it (not well). > > This is not about systems with CPUs with 32-bit native word sizes. It > is about operating systems that choose a 32-bit type for time_t. Apparently there are still places in the GNU/Linux world where that is the case. Linux Weekly News has been covering this for years: https://lwn.net/Articles/776435/ https://lwn.net/Articles/812767/ https://lwn.net/Articles/938149/ and many more simply by searching for 2038 in the site's Search page. I'm not going to debate who is right and who is not. My effort is to simply be sure that nothing is hiding in the Hamlib code that someone comes along at some later date grumpily pointing out that this project did not do its due diligence. That is all. 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: Michael B. <no...@gi...> - 2024-01-21 17:40:33
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 7d0c737e961cbb0103960a8c376c756952e18020 https://github.com/Hamlib/Hamlib/commit/7d0c737e961cbb0103960a8c376c756952e18020 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-01-21 (Sun, 21 Jan 2024) Changed paths: M src/rig.c Log Message: ----------- Fix Icom startup with poweron https://github.com/Hamlib/Hamlib/issues/1480 |
|
From: Greg T. <gd...@le...> - 2024-01-21 14:53:41
|
"C. van Wüllen" <van...@ch...> writes: > I believe that the assumption > > sizeof(time_t) = sizeof(long) = sizeof(void *) > > will hold for the forseeable future just for supporting > code of lazy programmers (there is no *need* to have > the same size for these), so I guess there will be > *something* done for 32-bit systems, e.g. internally > referencing this to 1. Jan. 2000, but this remains to > be seen. That assumption already is not true and has been not true for well over 10 years. C99/POSIX does not guarantee anything close to that, especially time_t, which is only required to be an integral type: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html Therefore any code which assumes anything about which integral type has been buggy from the day it was written. |
|
From: Greg T. <gd...@le...> - 2024-01-21 14:50:22
|
Nate Bargmann <n0...@n0...> writes: > It's not out of the realm of possibility that I'll still have some 32 > bit hardware laying around 14 years from now. I doubt any of it will be > used to run Hamlib and on the only system I use Hamlib on I've been > running 64 bit Linux for years but that doesn't necessarily mitigate the > issue as I understand it (not well). This is not about systems with CPUs with 32-bit native word sizes. It is about operating systems that choose a 32-bit type for time_t. >> Is there a defined 64bit time type in C? Hamlib is C isn't it? > > I believe that glibc does have a 64 bit time_t, but my > (mis)understanding is that time_t is limited to 32 bits. Perhaps this > link is helpful: > > https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html Wow, it's "LFS" all over again, instead of just changing the types to be big enough and versioning the binary syscalls. I think it would be a net minus to ick up the code to accomodate this, but maybe it can be done with a block of #defines that is gated on if it is glibc. That says "not actually implemented", so it seems unwise to put effort into it until the support becomes real. > I am not sure what other C libraries are doing for mitigation. This is an OS bug and should be fixed there, and if not, oh well. The BSD world fixed it long ago. The Linux approach seems to be that 64-bit CPUs have a reasonable time_t size, and 32-bit CPUs do not. That is, whether they would see it that way or not, a decision by Linux that 32-bit CPU systems may not be used close to/after 2038. I say don't tilt at this windmill at all; it's not about hamlib and many other things are going to break. I think that 32-bit computers running Unix are going to be extremely rare by 2038 and even 2033, in other than a retrocomputing for fun kind of way. I tend to have old computers because I keep things that work and accept free-to-good-home for random testing use. I am running NetBSD in i386 mode on a few systems which would accept amd64 (but time_t is fine). And in earmv7hf-el (32) mode on 2 systems that would accept evbarm64-el (64) mode. I'm doing this not for any good reason, other than that some systems were installed long ago (18 years in one case), and I haven't seen a reason to switch to amd64/aarch64, since with limited memory (1-2GB) it doesn't really help anything. The only (unix-capable) hardware I have that wouldn't run in a 64-bit cpu mode is: one RPI1 soekris net5501 Today, neither is in use. I might try to use the RPI1 soon. But I can't imagine wanting to use or keep using either after January, 2034. That's not really about 32-bit CPU so much as limited RAM (512 MB in each case) and slow. Already today, running a system with that little RAM is a recipe for grief. I bet that by then people will be saying to me "I'm going to recycle some RPI3s - do you want them?". Do we really expect people to be using 32-bit-only hardware (really using, not proving that there is a problem) after 2033? How many people are using it *today*, with hamlib? Is there anyone? If so, why and what is the path between now and 2033? |
|
From: Michael B. <no...@gi...> - 2024-01-21 04:30:14
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 77aa5ddb551f66f064c5f8a6031fc73622ce8ed1 https://github.com/Hamlib/Hamlib/commit/77aa5ddb551f66f064c5f8a6031fc73622ce8ed1 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-01-20 (Sat, 20 Jan 2024) Changed paths: M rigs/yaesu/newcat.c Log Message: ----------- Revert FT991 change |
|
From: Greg T. <gd...@le...> - 2024-01-21 02:01:28
|
Nate Bargmann <n0...@n0...> writes: > Early this morning at 03:14:07 UTC the time remaining until the Unix > Epoch rollover where the signed 32 bit count of seconds since 01 Jan > 1970 00:00:00 UTC is just under 14 years. Certainly, that is a long > time off, but, Hamlib is now 23 1/2 years old! > > I have not looked deeply, but it may be useful to ensure that Hamlib contains > no problematic uses of time_t or anything that uses the 32 bit signed integer > of the Unix epoch. I see the following: Briefly, I think it's a bug of an operating system to be using a 32-bit type for time_t, and that systems should either change that type to e.g. int64_t or expect people to migrate away from them. In NetBSD, we changed time_t from a historical type that was 32 bits to int64_t over 10 years ago, and versioned interfaces for binary compat. So for hamlib, the correctness condition is to not store a time_t in any other type, and when using it with printf, not to assume that it's %ld. I think it would be regrettable to put in workarounds for systems that have unsuitable time_t types. 73 de n1dam |
|
From: G0GJV <g0...@go...> - 2024-01-20 22:29:43
|
Thanks Mike I'll release with a nightly, and expect a point release when you release. Get well soon! Mike G0GJV > I'm hoping for end of month but not sure I'll make that date either. > I'm somewhat out of commission right now with an injury and limited in development work. > I don't want to release 4.6 with any known bugs and there are several I need to fix. > > Mike W9MDB > > On Saturday, January 20, 2024 at 12:11:43 PM CST, G0GJV <g0...@go...> > wrote: > > What is the anticipated release date for 4.6? Do I wait for it, or do > my release with a nightly? > > Mike G0GJV |
|
From: Black M. <mdb...@ya...> - 2024-01-20 21:48:45
|
I'm hoping for end of month but not sure I'll make that date either. I'm somewhat out of commission right now with an injury and limited in development work. I don't want to release 4.6 with any known bugs and there are several I need to fix. Mike W9MDB On Saturday, January 20, 2024 at 12:11:43 PM CST, G0GJV <g0...@go...> wrote: What is the anticipated release date for 4.6? Do I wait for it, or do my release with a nightly? Mike G0GJV _______________________________________________ Hamlib-developer mailing list Ham...@li... https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: G0GJV <g0...@go...> - 2024-01-20 18:11:26
|
What is the anticipated release date for 4.6? Do I wait for it, or do my release with a nightly? Mike G0GJV |
|
From: Michael B. <no...@gi...> - 2024-01-20 16:16:10
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: eff0c7b6362bf13de8e65a31fd92c6cf95dbbe42 https://github.com/Hamlib/Hamlib/commit/eff0c7b6362bf13de8e65a31fd92c6cf95dbbe42 Author: Mike Black W9MDB <mdb...@ya...> Date: 2024-01-20 (Sat, 20 Jan 2024) Changed paths: M rigs/yaesu/newcat.c Log Message: ----------- Add SY command validation remove FT991 from vfo adjustment |
|
From: Black M. <mdb...@ya...> - 2024-01-20 14:58:43
|
time_t would only be used for logging new QSOs in WSJT-X for example. Older ones in ADIF won't use that value when converting strings to time. On Saturday, January 20, 2024 at 08:11:01 AM CST, gm3zza via Hamlib-developer <ham...@li...> wrote: Have we had problems at the other end of the spectrum? Not hamlib, but in logging software with people trying to enter their old logs that predate the time_t datum in 1970? Phil GM3ZZA On 20 January 2024, at 13:20, Nate Bargmann <n0...@n0...> wrote: * On 2024 20 Jan 04:03 -0600, "C. van Wüllen" wrote: > I remember well all the cassandras warning for the „Y2K“ > proble - - and nothing happened. Nothing happened because the prior several years were spent testing/fixing/replacing problematic systems. It was a real thing not to be discounted despite the irresponsible media hype and the liars and thieves y2k gathered along the way, particularly the past 18 months or so. I recall the 2038 issue being raised not long after y2k had passed. Of course, some responses were along the lines of "38 years? We have plenty of time..." and now 24 of those years have passed and ideas are still being debated on the best fixes. In light of that, 14 years will go by quickly. Mike has opened an issue: https://github.com/Hamlib/Hamlib/issues/1478 This will probably be a long running issue as making sure the code base as it exists today is compliant is not enough but also that future commits don't introduce regressions. 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 |
|
From: Nate B. <n0...@n0...> - 2024-01-20 14:39:59
|
Actually, the rollover takes the date back to late 1901, not 1910. Wikipedia has a GIF that shows the rollover: https://en.wikipedia.org/wiki/Unix_time#/media/File:Year_2038_problem.gif 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...> - 2024-01-20 14:36:40
|
* On 2024 20 Jan 08:11 -0600, gm3zza via Hamlib-developer wrote: > Have we had problems at the other end of the spectrum? Not hamlib, but > in logging software with people trying to enter their old logs that > predate the time_t datum in 1970? Likely not as the Unix epoch is a signed integer and handles dates going back to 1910 or so. However, Unix systems are capable of dealing with dates/times outside the Unix epoch which are likely from the C and other libraries independent of the monotonic timer. Regardless, the monotonic timers that have traditionally been held in a 32 bit signed integer will set bit 31 just under 14 years from now and the date will appear to jump to the 1910 time frame. More than anyone wants to know: https://en.wikipedia.org/wiki/Unix_time 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: gm3zza <gm...@bt...> - 2024-01-20 14:10:49
|
Have we had problems at the other end of the spectrum? Not hamlib, but in logging software with people trying to enter their old logs that predate the time_t datum in 1970? Phil GM3ZZA On 20 January 2024, at 13:20, Nate Bargmann <n0...@n0...> wrote: * On 2024 20 Jan 04:03 -0600, "C. van Wüllen" wrote: > I remember well all the cassandras warning for the „Y2K“ > proble - - and nothing happened. Nothing happened because the prior several years were spent testing/fixing/replacing problematic systems. It was a real thing not to be discounted despite the irresponsible media hype and the liars and thieves y2k gathered along the way, particularly the past 18 months or so. I recall the 2038 issue being raised not long after y2k had passed. Of course, some responses were along the lines of "38 years? We have plenty of time..." and now 24 of those years have passed and ideas are still being debated on the best fixes. In light of that, 14 years will go by quickly. Mike has opened an issue: https://github.com/Hamlib/Hamlib/issues/1478 This will probably be a long running issue as making sure the code base as it exists today is compliant is not enough but also that future commits don't introduce regressions. 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: Black M. <mdb...@ya...> - 2024-01-20 13:40:28
|
The only problems I see is setting the clock on rigs as that uses system time and the multicast packets would have the wrong time too. Also the times in the debug output is not really a problem with operations but will be wrong. I'll have to grab a 32-bit OS image and do some testing. I can imagine capturing the time functions and adding an offset to them if that's needed. That could be done by libc if they implemented that. Mike W9MDB On Saturday, January 20, 2024 at 07:19:53 AM CST, Nate Bargmann <n0...@n0...> wrote: * On 2024 20 Jan 04:03 -0600, "C. van Wüllen" wrote: > I remember well all the cassandras warning for the „Y2K“ > proble - - and nothing happened. Nothing happened because the prior several years were spent testing/fixing/replacing problematic systems. It was a real thing not to be discounted despite the irresponsible media hype and the liars and thieves y2k gathered along the way, particularly the past 18 months or so. I recall the 2038 issue being raised not long after y2k had passed. Of course, some responses were along the lines of "38 years? We have plenty of time..." and now 24 of those years have passed and ideas are still being debated on the best fixes. In light of that, 14 years will go by quickly. Mike has opened an issue: https://github.com/Hamlib/Hamlib/issues/1478 This will probably be a long running issue as making sure the code base as it exists today is compliant is not enough but also that future commits don't introduce regressions. 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 |
|
From: Nate B. <n0...@n0...> - 2024-01-20 13:19:41
|
* On 2024 20 Jan 04:03 -0600, "C. van Wüllen" wrote: > I remember well all the cassandras warning for the „Y2K“ > proble - - and nothing happened. Nothing happened because the prior several years were spent testing/fixing/replacing problematic systems. It was a real thing not to be discounted despite the irresponsible media hype and the liars and thieves y2k gathered along the way, particularly the past 18 months or so. I recall the 2038 issue being raised not long after y2k had passed. Of course, some responses were along the lines of "38 years? We have plenty of time..." and now 24 of those years have passed and ideas are still being debated on the best fixes. In light of that, 14 years will go by quickly. Mike has opened an issue: https://github.com/Hamlib/Hamlib/issues/1478 This will probably be a long running issue as making sure the code base as it exists today is compliant is not enough but also that future commits don't introduce regressions. 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.
