hamlib-developer Mailing List for Ham Radio Control Libraries (Page 11)
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
(14) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: dforsi <no...@gi...> - 2025-05-26 15:51:48
|
Branch: refs/heads/Hamlib-4.6.3 Home: https://github.com/Hamlib/Hamlib Commit: ffb61c29a5aa0eca95d4cf62e3cb15c610a223ce https://github.com/Hamlib/Hamlib/commit/ffb61c29a5aa0eca95d4cf62e3cb15c610a223ce Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-26 (Mon, 26 May 2025) Changed paths: M rigs/dummy/amp_dummy.c Log Message: ----------- Fix typo (cherry picked from commit 3034631b2f99f32680e2939035f45019a2fc38c3) Commit: f0ac83bcba5b7bf0a6a2db18d31069bbd118cd41 https://github.com/Hamlib/Hamlib/commit/f0ac83bcba5b7bf0a6a2db18d31069bbd118cd41 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-26 (Mon, 26 May 2025) Changed paths: M doc/man1/rotctld.1 Log Message: ----------- Fix typo Add closing tag for example text. (cherry picked from commit 43017b38f08c6ed75fa9c5a4d88bdb0875e7c15a) Compare: https://github.com/Hamlib/Hamlib/compare/e641162a6be7...f0ac83bcba5b To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <n0...@n0...> - 2025-05-26 02:33:06
|
Astute observers will have noticed that I updated the NEWS file, created the Hamlib-4.6.3 branch, and updated its configure.ac to version 4.6.3~rc1. I plan to generate an rc1 tarball and Windows binaries and put them in a temporary directory on the daily snapshots page for testing. While I wanted to get to this about a month earlier, real life had other ideas! I've set a target release date of 10 June which should give a change to shake down this branch and get a good solid release out while opening up 'master' to development for 4.7.0. 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...> - 2025-05-26 02:23:47
|
Branch: refs/heads/Hamlib-4.6.3 Home: https://github.com/Hamlib/Hamlib Commit: e641162a6be7570a20b6e0189a53063cdbca1a39 https://github.com/Hamlib/Hamlib/commit/e641162a6be7570a20b6e0189a53063cdbca1a39 Author: Nate Bargmann <n0...@n0...> Date: 2025-05-25 (Sun, 25 May 2025) Changed paths: M configure.ac Log Message: ----------- Advance to 4.6.3~rc1 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2025-05-26 01:53:01
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: f459eea516a3e5c9b74c72dd4a430fcde1764f71 https://github.com/Hamlib/Hamlib/commit/f459eea516a3e5c9b74c72dd4a430fcde1764f71 Author: Nate Bargmann <n0...@n0...> Date: 2025-05-25 (Sun, 25 May 2025) Changed paths: M NEWS Log Message: ----------- Update NEWS for 4.6.3 release To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Stephen P. <st...@bi...> - 2025-05-24 01:31:03
|
Hi, I have several programs that interrogate rigctld simultaneously which among other things request various radio parameters from my IC-7300 every second. With just one rigctld client program running I have no issue, but I have discovered a number of issues that the developers may or may not consider worth of rectification, when multiple rigctld clients request radio parameters more of less simultaneously. I can work around these issues, but nevertheless, I think they are worth of reporting. Hamlib version is - hamlib-w64-4.6.2 Windows (10) DOS Command to start rigctld is as follows: “rigctld -m 3073 -r COM4 -s 115200 -vvv” These issues are probably all related or indeed have the same cause, but I’ll list separately. 1 – Two Python programs are requesting the ptt status of the radio every second. There is no synchronization between the two programs, so whether or not they request the ptt status at the same time is hard to say. The programs also request the frequency and mode of the radio. Both programs request the ptt status using the “extended” method, ie the TCP message is (in Python code). I’m using the optional ‘|’ separator as can be seen from the code snippet sentBytes = rigctldSock.sendall(b'|t\n') response = rigctldSock.recv(1024) The response should be b'get_ptt:|PTT: 0|RPRT 0\n' however, every now and again, the response is of the form b'get_ptt:\nPTT: 0\nRPRT 0\n' which causes my parsing to fail. The response looks like the result as if the ‘+’ separator was used, however this is not the case. Perhaps I can avoid this by using the ‘+’ separator, but it shouldn’t be necessary. 2- Running the commercial LOG4OM program which is configured to use the “Hamlib NET rigctl Stable” rig model, and one of my Python programs has a similar effect as described in issue 1 above. I don’t of course know the exact command that LOG4OM is using other than it is communicating to rigctld on port 4532. Also, the issue arises with multiple parameters. Once again, my program uses the ‘|’ separator character. I don’t know what LOG4OM uses, or indeed if it uses the “extended” or “default” method. As before, expected responses are of the form ( for get_ptt and get_mode commands) b'get_ptt:|PTT: 0|RPRT 0\n' b'get_mode:|Mode: LSB|Passband: 2400|RPRT 0\n' however, occasionally the responses are b'get_ptt:\nPTT: 0\nRPRT 0\n' b'get_mode:\nMode: LSB\nPassband: 2400\nRPRT 0\n' which fails my parsing due to the LF char unexpectedly replacing the ‘|’ char. The cause is no doubt the same as in issue one. It may or may not matter if two programs accessing rigctld use the same separator character. 3 – A similar issue arises if one rigctld TCP client is using the “default” protocol and other the “extended” protocol more of less simultaneously. For example, I have one Python program accessing rig frequency using the “extended” protocol which results in a response of this form b'get_freq:|Frequency: 1424840|RPRT 0\n' at the same approximate time, the second client program uses the “default” protocol which results in a response of this form b'1424840\n' however, every once in a while, the response to the “default” protocol results in this response b'1424840|\n' It appears that the “default” response has been “infected” by the separation character of the “extended” response due to the other client. Of course, maybe I shouldn’t allow mixing of the two types of request, but of course I have no easy way of knowing what any other arbitrary program might be using that may simultaneously request radio parameters. In summary, I feel these issues which probably all have the same root cause may warrant looking at, but I will totally understand if it is regarded as low priority or not worth fixing. In my case, I’ll probably alter my programs to use the ‘+’ separator character that results in ‘\n’ characters separating the fields as I suspect this is what is usually used. Thanks for reading. Rgds Steve VK3SPX |
|
From: Mooneer S. <no...@gi...> - 2025-05-23 02:20:07
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 0fd094f4765737c00f852838c739c702a2e7376f https://github.com/Hamlib/Hamlib/commit/0fd094f4765737c00f852838c739c702a2e7376f Author: Mooneer Salem <mo...@gm...> Date: 2025-05-22 (Thu, 22 May 2025) Changed paths: M include/num_stdio.h Log Message: ----------- Fix issue where Hamlib attempts to use memory returned by setlocale() after being freed. To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2025-05-22 23:28:29
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 84376c45616d0a50023815f10b89eafe6f45e02a https://github.com/Hamlib/Hamlib/commit/84376c45616d0a50023815f10b89eafe6f45e02a Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-22 (Thu, 22 May 2025) Changed paths: M scripts/build-w32.sh M scripts/build-w64.sh Log Message: ----------- Use the variable with the version number in the example path Commit: 4109d606b598a8ca84ebdbe6d06b740928b4e5bf https://github.com/Hamlib/Hamlib/commit/4109d606b598a8ca84ebdbe6d06b740928b4e5bf Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-22 (Thu, 22 May 2025) Changed paths: M rigs/aor/ar7030.c M rigs/dummy/aclog.c M rigs/dummy/flrig.c M rigs/dummy/tci1x.c M rigs/elad/elad.c M rigs/icom/frame.c M rigs/icom/ic746.c M rigs/icom/ic756.c M rigs/icom/ic820h.c M rigs/icom/ic821h.c M rigs/icom/icom.c M rigs/jrc/jrc.c M rigs/kenwood/kenwood.c M rigs/kenwood/tmv7.c M rigs/kenwood/ts870s.c M rigs/kit/drt1.c M rigs/kit/elektor507.c M rigs/kit/pcrotor.c M rigs/uniden/uniden.c M rigs/uniden/uniden_digital.c M rigs/wj/wj8888.c M rigs/yaesu/ft757gx.c M rigs/yaesu/ft817.c M rigs/yaesu/ft857.c M rigs/yaesu/ft891.c M rigs/yaesu/ft897.c M rigs/yaesu/pmr171.c M rigs/yaesu/vr5000.c M rigs/yaesu/vx1700.c M rotators/celestron/celestron.c M rotators/gs232a/gs232.c M rotators/gs232a/gs232a.c M rotators/gs232a/gs232b.c M rotators/ioptron/rot_ioptron.c M rotators/m2/rc2800.c M rotators/meade/meade.c M rotators/prosistel/prosistel.c M rotators/spid/spid.c M simulators/simts890.c M tests/dumpmem.c M tests/rigctl_parse.c M tests/test2038.c Log Message: ----------- Fix typos Commit: 87311035ea67d73a1a02d99e55b2a522486bead7 https://github.com/Hamlib/Hamlib/commit/87311035ea67d73a1a02d99e55b2a522486bead7 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-22 (Thu, 22 May 2025) Changed paths: M README.md M scripts/build-w32.sh M scripts/build-w64.sh Log Message: ----------- Also mention amplifiers Commit: dbe89b2092f808e4fe3d7286b6459a9803cd5361 https://github.com/Hamlib/Hamlib/commit/dbe89b2092f808e4fe3d7286b6459a9803cd5361 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-22 (Thu, 22 May 2025) Changed paths: M configure.ac Log Message: ----------- Remove duplicated comment Commit: 9570d9963b44a4ee2ad8d2a6befb982fd4dcb6fc https://github.com/Hamlib/Hamlib/commit/9570d9963b44a4ee2ad8d2a6befb982fd4dcb6fc Author: Nate Bargmann <n0...@n0...> Date: 2025-05-22 (Thu, 22 May 2025) Changed paths: M README.md M configure.ac M rigs/aor/ar7030.c M rigs/dummy/aclog.c M rigs/dummy/flrig.c M rigs/dummy/tci1x.c M rigs/elad/elad.c M rigs/icom/frame.c M rigs/icom/ic746.c M rigs/icom/ic756.c M rigs/icom/ic820h.c M rigs/icom/ic821h.c M rigs/icom/icom.c M rigs/jrc/jrc.c M rigs/kenwood/kenwood.c M rigs/kenwood/tmv7.c M rigs/kenwood/ts870s.c M rigs/kit/drt1.c M rigs/kit/elektor507.c M rigs/kit/pcrotor.c M rigs/uniden/uniden.c M rigs/uniden/uniden_digital.c M rigs/wj/wj8888.c M rigs/yaesu/ft757gx.c M rigs/yaesu/ft817.c M rigs/yaesu/ft857.c M rigs/yaesu/ft891.c M rigs/yaesu/ft897.c M rigs/yaesu/pmr171.c M rigs/yaesu/vr5000.c M rigs/yaesu/vx1700.c M rotators/celestron/celestron.c M rotators/gs232a/gs232.c M rotators/gs232a/gs232a.c M rotators/gs232a/gs232b.c M rotators/ioptron/rot_ioptron.c M rotators/m2/rc2800.c M rotators/meade/meade.c M rotators/prosistel/prosistel.c M rotators/spid/spid.c M scripts/build-w32.sh M scripts/build-w64.sh M simulators/simts890.c M tests/dumpmem.c M tests/rigctl_parse.c M tests/test2038.c Log Message: ----------- Merge GitHub PR #1742 Compare: https://github.com/Hamlib/Hamlib/compare/9b177cd8b3bc...9570d9963b44 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2025-05-22 22:31:59
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 5fe81cdef4fcceff52c7cedc0eac6788c2f64881 https://github.com/Hamlib/Hamlib/commit/5fe81cdef4fcceff52c7cedc0eac6788c2f64881 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-17 (Sat, 17 May 2025) Changed paths: M rigs/kit/usrp.c M rigs/kit/usrp_impl.cc Log Message: ----------- Fix compilation errors and warnings and link failure Compile-tested with commit 8ea3f0e (tag: 3.4.10) from https://github.com/osmocom/libusrp Fixes: usrp_impl.cc:33:10: fatal error: usrp_standard.h: No such file or directory usrp_impl.cc:49:63: error: expected '(' before 'malloc' usrp_impl.cc:49:100: error: expected ')' before ';' token usrp_impl.cc:72:39: error: invalid 'static_cast' from type 'rig_state*' to type 'usrp_priv_data*' usrp_impl.cc:86:39: error: invalid 'static_cast' from type 'rig_state*' to type 'usrp_priv_data*' usrp_impl.cc:104:39: error: invalid 'static_cast' from type 'rig_state*' to type 'usrp_priv_data*' usrp_impl.cc:129:45: error: invalid 'static_cast' from type 'rig_state*' to type 'usrp_priv_data*' usrp_impl.cc:151:45: error: invalid 'static_cast' from type 'rig_state*' to type 'usrp_priv_data*' usrp_impl.cc:169:45: error: invalid 'static_cast' from type 'rig_state*' to type 'usrp_priv_data*' usrp_impl.cc:114:37: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] usrp_impl.cc:139:38: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] /usr/bin/ld: ../src/.libs/libhamlib.so: undefined reference to `usrp_caps' Commit: 9b177cd8b3bcbc47126961377e6b14c689918af2 https://github.com/Hamlib/Hamlib/commit/9b177cd8b3bcbc47126961377e6b14c689918af2 Author: Nate Bargmann <n0...@n0...> Date: 2025-05-22 (Thu, 22 May 2025) Changed paths: M rigs/kit/usrp.c M rigs/kit/usrp_impl.cc Log Message: ----------- Merge GitHub PR #1739. Compare: https://github.com/Hamlib/Hamlib/compare/91a4d914d9dd...9b177cd8b3bc To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2025-05-22 22:20:38
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 57e5dba438cd01adb9ccca1024a74d2665cfd914 https://github.com/Hamlib/Hamlib/commit/57e5dba438cd01adb9ccca1024a74d2665cfd914 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-14 (Wed, 14 May 2025) Changed paths: M tests/ampctl.c M tests/ampctld.c M tests/rigctl.c M tests/rigctld.c M tests/rigctltcp.c M tests/rigmem.c M tests/rigsmtr.c M tests/rigswr.c M tests/rotctl.c M tests/rotctld.c Log Message: ----------- Make usage texts more similar Commit: dc3a71da1b826099f7c1586f7fc451bf3c842571 https://github.com/Hamlib/Hamlib/commit/dc3a71da1b826099f7c1586f7fc451bf3c842571 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-14 (Wed, 14 May 2025) Changed paths: M tests/ampctl.c M tests/rigctl.c M tests/rotctl.c Log Message: ----------- Document existing option to read commands from stdin Commit: e34ae180a23a99f4dcff3e6b67310029189f04e9 https://github.com/Hamlib/Hamlib/commit/e34ae180a23a99f4dcff3e6b67310029189f04e9 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-14 (Wed, 14 May 2025) Changed paths: M tests/rigctld.c Log Message: ----------- Remove unused definition of -z command line option Commit: 55cae893f02455a2a00491f9b8f165996e672ee3 https://github.com/Hamlib/Hamlib/commit/55cae893f02455a2a00491f9b8f165996e672ee3 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-14 (Wed, 14 May 2025) Changed paths: M tests/rigctlsync.c Log Message: ----------- Fix definition of -B/--mapa2b command line option It doesn't accept an argument. Commit: b03dea99b5ad2183f3cf30032794c991b0995d28 https://github.com/Hamlib/Hamlib/commit/b03dea99b5ad2183f3cf30032794c991b0995d28 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-14 (Wed, 14 May 2025) Changed paths: M tests/rigctlsync.c Log Message: ----------- Allow to give the command lines options --list or --version Commit: 91a4d914d9dd1a8aed8822e185109cacc143057c https://github.com/Hamlib/Hamlib/commit/91a4d914d9dd1a8aed8822e185109cacc143057c Author: Nate Bargmann <n0...@n0...> Date: 2025-05-22 (Thu, 22 May 2025) Changed paths: M tests/ampctl.c M tests/ampctld.c M tests/rigctl.c M tests/rigctld.c M tests/rigctlsync.c M tests/rigctltcp.c M tests/rigmem.c M tests/rigsmtr.c M tests/rigswr.c M tests/rotctl.c M tests/rotctld.c Log Message: ----------- Merge branch 'fix/usage-texts' of github.com:dforsi/Hamlib into dforsi-fix/usage-texts >From GitHub PR #1735. Compare: https://github.com/Hamlib/Hamlib/compare/73607aeb5414...91a4d914d9dd To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2025-05-22 21:57:21
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: daa5c83a82f12fe397c8a553cb4940bb7b4a72b5 https://github.com/Hamlib/Hamlib/commit/daa5c83a82f12fe397c8a553cb4940bb7b4a72b5 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-13 (Tue, 13 May 2025) Changed paths: M configure.ac Log Message: ----------- Fix --enable-winradio[=yes] being considered =no Commit: 50462e65644056efd43de533798eda5b23097b7f https://github.com/Hamlib/Hamlib/commit/50462e65644056efd43de533798eda5b23097b7f Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-13 (Tue, 13 May 2025) Changed paths: M configure.ac Log Message: ----------- Fix --enable-parallel[=yes] being considered =no Commit: 5370bbd32e0d5d212357b2d0f9f4d608eb242b21 https://github.com/Hamlib/Hamlib/commit/5370bbd32e0d5d212357b2d0f9f4d608eb242b21 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-13 (Tue, 13 May 2025) Changed paths: M configure.ac Log Message: ----------- Fix --enable-html-matrix[=yes] being considered =no Commit: 9aee8f8343812a0e671f7b1fa330ba6a8f25da26 https://github.com/Hamlib/Hamlib/commit/9aee8f8343812a0e671f7b1fa330ba6a8f25da26 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-13 (Tue, 13 May 2025) Changed paths: M configure.ac Log Message: ----------- Fix --with-readline[=yes] being considered =no Commit: ce95b034c65251999c931403ba1228dbef252cf6 https://github.com/Hamlib/Hamlib/commit/ce95b034c65251999c931403ba1228dbef252cf6 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-13 (Tue, 13 May 2025) Changed paths: M configure.ac Log Message: ----------- Fix --with-libusb[=yes] being considered =no Commit: 435a354ee072f9e6fe033add021b5fe44a92b19d https://github.com/Hamlib/Hamlib/commit/435a354ee072f9e6fe033add021b5fe44a92b19d Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-17 (Sat, 17 May 2025) Changed paths: M configure.ac Log Message: ----------- Fix --with-indi[=no] being considered =yes Commit: 94bf1d717aaa29678a98cf50455648a6410df795 https://github.com/Hamlib/Hamlib/commit/94bf1d717aaa29678a98cf50455648a6410df795 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-17 (Sat, 17 May 2025) Changed paths: M configure.ac Log Message: ----------- Fix failure of ./configure --with-tcl-binding --with-xml-support If pkg-config has found tcl.pc, then tclConfig.sh is not executed and $TCL_INCLUDE_SPEC is empty so the test for tcl.h fails. This patch moves the test inside the "else" case where the variable is always defined. The is a bug exposed by the fact that --with-xml-support redefines the macro PKG_CHECK_MODULES. Fix verified moving aside /usr/lib/x86_64-linux-gnu/pkgconfig/tcl.pc Fixes: configure: error: Unable to find Tcl headers Commit: 73607aeb5414c90e63f2c1f92ece65c550d76895 https://github.com/Hamlib/Hamlib/commit/73607aeb5414c90e63f2c1f92ece65c550d76895 Author: Nate Bargmann <n0...@n0...> Date: 2025-05-22 (Thu, 22 May 2025) Changed paths: M configure.ac Log Message: ----------- Merge branch 'dforsi-fix/ac_arg_enable' Reference GitHub PR #1731. Compare: https://github.com/Hamlib/Hamlib/compare/ad824fa85e42...73607aeb5414 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Mikael N. <mik...@fa...> - 2025-05-22 20:13:53
|
Hi! Writing down my 2 cents here, as I've developed parts of the caching code (+ UDP packet updates when cached data changes, incl. waterfall data streaming). The rig_cache struct and everything related to caching should indeed be completely internal to Hamlib. It's great to have the public API of Hamlib cleaned up. 73, Mikael OH3BHX On Sat, May 17, 2025, at 19:45, George Baltz wrote: > On 5/17/25 4:44 AM, Daniele Forsi wrote: >> Hello, >> >>> I think the rig_cache structure should be completely internal to Hamlib, and not visible to the calling application. >> that's a good thing > > ^ > > very > >> >>> I hope there's no big use of this data elsewhere. >> how external software would be using the current cache API? > Strange are the ways of application programmers >> >> I grepped for "rig_cache" in the sources that I have locally (mostly >> from Debian) and I found it only in Hamlib >> >> I searched on github for >> language:C symbol:rig_cache NOT (path:rig.h OR path:cache.h OR path:cache.c) >> >> and found 15 results unrelated to Hamlib; a search that doesn't >> exclude the files above returns more than 3000 results, including >> various copies of Hamlib > > Given that there were no other responses, I'll go ahead and finish > tidying up the code, and create a PR for master. > > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: <fam...@ao...> - 2025-05-22 10:33:01
|
Hello, There's a problem with Hamlib w64-4.6.2. The serial port is recognized but not working. I get this message: C:\Program Files\hamlib-w64-4.6.2\bin>rotctld.exe -m 202 -r COM4 -s 9600 -T 127.0.0.1 -t 4533 -vvv serial_setup: tcsetattr failed: No error rot_open: error = Report bugs to < <mailto:ham...@li...> ham...@li...> rot_init called initrots4_easycomm called rot_register (201) rot_register (202) rot_register (204) rot_open called serial_open: serial port COM4 is OK serial_open: COM4 serial_setup: tcgetattr serial_setup: cfsetispeed=9600,0x000d serial_setup: cfsetospeed=9600,0x000d serial_setup: data_bits=8 serial_setup: stopbits=1 serial_setup: parity=0 serial_setup: Handshake=None serial_setup: tcsetattr TCSANOW serial_setup: tcsetattr failed: No error Invalid configuration C:\Program Files\hamlib-w64-4.6.2\bin> Nom de l'appareil DESKTOP-3HCNLPN Processeur Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz 2.11 GHz Mémoire RAM installée 16,0 Go (15,8 Go utilisable) ID de périphérique 1D549E56-3766-44B9-9743-889BF51E8248 ID de produit 00330-53173-72831-AAOEM Type du système Système d’exploitation 64 bits, processeur x64 Stylet et fonction tactile Prise en charge du stylet et de la fonction tactile avec 10 points de contact Édition Windows 11 Professionnel Version 24H2 Installé le 29/01/2025 Build du système d’exploitation 26100.4061 Expérience Pack d’expérience de fonctionnalités Windows 1000.26100.84.0 Best regards, Alain |
|
From: Stefan J. <DK...@da...> - 2025-05-21 21:03:00
|
Hi dear hamlib experts, Sorry for my maybe stupid question. But I have to say that I am not familiar with the internals ofhamlib, I am only using it to develop some rig control software. :-) When I look at the output of the rigctl —dump-caps option for my Elecraft KX2 transceiver, I can see that hamlib seems to support setting filters and bandwidths. Yes, I know that my KX2 has some predefined filters, for example the audio peek filter APF. And I can apply change the center frequency and bandwidth of the IF passband. That’s fine. But what about the bandwidth? I suppose that the bandwidth should affect the HF signal when transmitting and should also affect demodulation. So for CW, I find bandwidths of 600Hz (normal), 300Hz (narrow) and 2400Hz (wide). But I never found a way to control the bandwidth from the keys and knobs of the KX2 itself. Does anybody know what hamlib does to set this? Or how I could figure out? I guess without knowing anything about the structure of hamlib backends I might get stuck without any hints where to get started. Vy 73 de Stefan, DK7STJ -- Stefan Jansen *** E-Mail: DK...@da... |
|
From: Daniele F. <iu...@gm...> - 2025-05-20 20:29:15
|
Hello, I'm working on using the Python bindings to add regression tests to Hamlib. While adding proper unit tests would be nice, we would still need to test all language bindings, so using the bindings allows us to also test some parts of Hamlib. The first step is creating tests to document the current behavior of the Dummy backends and in future detect regressions: https://github.com/Hamlib/Hamlib/pull/1726 It is mostly ready for Hamlib 4.7.0 but I might still rebase and/or force push and there are 2 functions that need fixing. This has shown a bug (PR #1727) and a missing check for NULL (first commit of PR #176)) so it has been useful. The next step could be modifying the bindings that currently are void functions (which means return None to Python callers) to return RIG_OK/RIG_E* as appropriate. This could also be for 4.7.0 because it is backward compatible if we keep the rig_error property. There are open issues about adding some functionality (to Python), these could go in Hamlib 4.8.0. Then the bindings could be changed to be more Pythonic or maybe the other language bindings could need changes. Comments and opinions are welcome. Do you know of other projects that have language bindings that could serve as an example? -- 73 de IU5HKX Daniele |
|
From: Nate B. <n0...@n0...> - 2025-05-19 19:33:13
|
* On 2025 19 May 10:17 -0500, George Baltz wrote: > I noticed 'Build_OS is mingw32' yet something is looking for a 64 bit > routine. Is that OK? When I do a DDG for clock_gettime64 the first hit is: https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html I wonder if this is some sort of macro that MSYS2 is looking for? Or, that MinGW supplies from the C library. Using objdump on an older 64 bit DLL I get: $ objdump -p libhamlib-4.dll | grep clock_gettime bae924 13 clock_gettime And on today's 32 bit DLL: $ objdump -p libhamlib-4.dll | grep clock_gettime a6823c 13 clock_gettime Searching for clock_gettime64 in either file returned zero results each. Undoubtedly this has to do with Y2038 mitigation. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 |
|
From: George B. <geo...@gm...> - 2025-05-19 15:16:46
|
I noticed 'Build_OS is mingw32' yet something is looking for a 64 bit routine. Is that OK? On 5/19/25 8:59 AM, Nate Bargmann wrote: > * On 2025 19 May 07:38 -0500, Hamlib Developer wrote: >> Hi Folks, >> >> An issue has been encountered with Hamlib pulled from master as of UTC >> 2025-05-18 @ 08:00:00 . >> >> The development environment is a fully clean and deployed JTSDK >> 4.0.1u1 (see https://sourceforge.net/projects/hamlib-sdk/ ) and has >> worked perfectly up until the time that Mike W9MDB became SK (and of >> course he is therefore of no help to us now ☹) >> >> “Fully updated” means that the deployed MSYS2 environment is FULLY >> updated with pacman -Syuu, >> >> LibUSB is the supplied 1.0.28 version that is known to work, and a >> known-to-work Boost 1.88.0 environment has also been deployed with the >> kit. The Qt environ is publicly-available Qt version being Qt 5.15.2. >> >> These are known facts: >> >> * Hamlib pulls the latest code from GIT, updates and compiles cleanly. >> * WSJT-X pulls the latest code from GIT and compiles cleanly. >> >> But on execution of a freshly built WSJT-X 2.7.0 the following message >> is displayed: >> >> The procedure entry point clock_gettime64 could not be located in the >> dynamic link library c:\wsjt\wsjtx\bin\libhamlib4-dll > I'm not familiar with the SDK or building WXJT-X, etc. I can state that > "clock_gettime64" is not found in the Hamlib repository as 'git grep > clock_gettime64' returns nothing. > > I presume the issue exists outside of Hamlib. Sorry. > > 73, Nate > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Nate B. <n0...@n0...> - 2025-05-19 12:59:38
|
* On 2025 19 May 07:38 -0500, Hamlib Developer wrote: > Hi Folks, > > An issue has been encountered with Hamlib pulled from master as of UTC > 2025-05-18 @ 08:00:00 . > > The development environment is a fully clean and deployed JTSDK > 4.0.1u1 (see https://sourceforge.net/projects/hamlib-sdk/ ) and has > worked perfectly up until the time that Mike W9MDB became SK (and of > course he is therefore of no help to us now ☹) > > “Fully updated” means that the deployed MSYS2 environment is FULLY > updated with pacman -Syuu, > > LibUSB is the supplied 1.0.28 version that is known to work, and a > known-to-work Boost 1.88.0 environment has also been deployed with the > kit. The Qt environ is publicly-available Qt version being Qt 5.15.2. > > These are known facts: > > * Hamlib pulls the latest code from GIT, updates and compiles cleanly. > * WSJT-X pulls the latest code from GIT and compiles cleanly. > > But on execution of a freshly built WSJT-X 2.7.0 the following message > is displayed: > > The procedure entry point clock_gettime64 could not be located in the > dynamic link library c:\wsjt\wsjtx\bin\libhamlib4-dll I'm not familiar with the SDK or building WXJT-X, etc. I can state that "clock_gettime64" is not found in the Hamlib repository as 'git grep clock_gettime64' returns nothing. I presume the issue exists outside of Hamlib. Sorry. 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: Hamlib D. <ham...@ou...> - 2025-05-18 11:26:26
|
Hi Folks, An issue has been encountered with Hamlib pulled from master as of UTC 2025-05-18 @ 08:00:00 . The development environment is a fully clean and deployed JTSDK 4.0.1u1 (see https://sourceforge.net/projects/hamlib-sdk/ ) and has worked perfectly up until the time that Mike W9MDB became SK (and of course he is therefore of no help to us now ☹) “Fully updated” means that the deployed MSYS2 environment is FULLY updated with pacman -Syuu, LibUSB is the supplied 1.0.28 version that is known to work, and a known-to-work Boost 1.88.0 environment has also been deployed with the kit. The Qt environ is publicly-available Qt version being Qt 5.15.2. These are known facts: * Hamlib pulls the latest code from GIT, updates and compiles cleanly. * WSJT-X pulls the latest code from GIT and compiles cleanly. But on execution of a freshly built WSJT-X 2.7.0 the following message is displayed: The procedure entry point clock_gettime64 could not be located in the dynamic link library c:\wsjt\wsjtx\bin\libhamlib4-dll The environment here is: * A fully updated JTSDK 4.0.0.1u2 and previously functional Hamlib build environment (including pacman updates of the embedded MSYS2 environment) * LibUSB 1.0.28 * Boost 1.88.0 * Windows 11 25H4 [ Fully updatesd ] This issue has been replicated on a number of machines. Any suggestions? Remember the aim of this kit is to be able to build everything from scratch ! What further information do you require? 73 Hamlib SDK Developers Ps: If one drops in the DLL's from https://n0nb.users.sourceforge.net/ (i.e. https://n0nb.users.sourceforge.net/hamlib-w64-4.7~git-20250518-ad824fa85.zip ) then the WSJT-X 2.7.0 that we have just built works ! The issue is building from the LATEST GIT Pull with the VERY LATEST MSYS2 packages. All should just work ! ................................................................................................................ $ build-hamlib ________________________________ JTSDK64 Tools MSYS2 Hamlib Build Script v4.0.0.1 ________________________________ * This script compiles Hamlib Libraries for the JTSDK build system. ________________________________ COMPILE INFORMATION [ Hamlib ] Script Option(s) ...: None (Default = Dynamic with LibUSB) Date ...............: 18-05-2025 Package ............: Hamlib User ...............: stepheni CPU/Job Count ......: 1 Compiler ...........: /mingw64/bin/gcc Platform ...........: MINGW64 Source Dir .........: /home/stepheni/ Build Dir ..........: /home/stepheni/src/hamlib/build LibUSB Include .....: /c/JTSDK64-Tools/tools/libusb/1.0.28/include LibUSB DLL .........: /c/JTSDK64-Tools/tools/libusb/1.0.28/bin Package Config......: /c/JTSDK64-Tools/tools/hamlib/qt/5.15.2/lib/pkgconfig/hamlib.pc Install Prefix .....: /c/JTSDK64-Tools/tools/hamlib/qt/5.15.2 ________________________________ CHECKING TOOL-CHAIN [ QT 5.15.2 ] ar .................: OK nm .................: OK ld .................: OK gcc ................: OK g++ ................: OK ranlib .............: OK Compiler ...........: gcc.exe (Rev4, Built by MSYS2 project) 15.1.0 Compiler Path ......: /mingw64/bin Bin Utils ..........: GNU ranlib (GNU Binutils) 2.44 Libtool ............: libtool (GNU libtool) 2.5.4 Pkg-Config .........: 2.3.0 Tool-Chain .........: OK ________________________________ CLONING GIT REPOSITORY [ MASTER ] Already up to date. ________________________________ PERFORM BOOTSTRAP [ Hamlib ] * Performing bootstrap Running 'autoreconf -i' to process configure.ac and generate the configure script. ________________________________ CONFIGURING [ Hamlib ] * Running configure script: This may take a several minutes to complete --> Build Type: Shared/Dynamic built with LibUSB --> configure: loading site script /etc/config.site checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether the compiler supports GNU C... yes checking whether gcc accepts -g... yes checking for gcc option to enable C11 features... none needed checking whether gcc understands -c and -o together... yes checking for stdio.h... yes checking for stdlib.h... yes checking for string.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for strings.h... yes checking for sys/stat.h... yes checking for sys/types.h... yes checking for unistd.h... yes checking for wchar.h... yes checking for minix/config.h... no checking whether it is safe to define EXTENSIONS... yes checking whether _XOPEN_SOURCE should be defined... no checking for a BSD-compatible install... /usr/bin/install -c checking whether sleep supports fractional seconds... yes checking filesystem timestamp resolution... 0.01 checking whether build environment is sane... yes checking for a race-free mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports the include directive... yes (GNU style) checking whether make supports nested variables... yes checking xargs -n works... yes checking dependency style of gcc... gcc3 checking for gcc... (cached) gcc checking whether the compiler supports GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to enable C11 features... (cached) none needed checking whether gcc understands -c and -o together... (cached) yes checking for g++... g++ checking whether the compiler supports GNU C++... yes checking whether g++ accepts -g... yes checking for g++ option to enable C++11 features... none needed checking dependency style of g++... gcc3 checking how to run the C preprocessor... gcc -E checking for gawk... (cached) gawk checking whether ln -s works... no, using cp -pR checking for g++... yes checking for ar... ar checking the archiver (ar) interface... ar checking for inline... inline checking AM_CFLAGS for maximum warnings... -Wall checking AM_CXXFLAGS for maximum warnings... -Wall checking for errno.h... yes checking for fcntl.h... yes checking for getopt.h... yes checking for limits.h... yes checking for locale.h... yes checking for malloc.h... yes checking for netdb.h... no checking for sgtty.h... no checking for stddef.h... yes checking for termio.h... no checking for termios.h... no checking for values.h... no checking for arpa/inet.h... no checking for dev/ppbus/ppbconf.hdev/ppbus/ppi.h... no checking for linux/hidraw.h... no checking for linux/ioctl.h... no checking for linux/parport.h... no checking for linux/ppdev.h... no checking for netinet/in.h... no checking for sys/ioccom.h... no checking for sys/ioctl.h... no checking for sys/param.h... yes checking for sys/socket.h... no checking for sys/stat.h... (cached) yes checking for sys/time.h... yes checking for sys/select.h... no checking for glob.h... no checking build system type... x86_64-w64-mingw32 checking host system type... x86_64-w64-mingw32 checking for ws2tcpip.h... yes checking for wspiapi.h... yes checking for library containing nanosleep... none required checking for pthread.h... yes checking for sys/types.h... (cached) yes checking for windows.h... yes checking for winioctl.h... yes checking for winbase.h... yes checking for getopt... yes checking for getopt_long... yes checking for usleep... yes checking for sleep... yes checking for nanosleep... yes checking for gettimeofday... yes checking for struct timezone... yes checking for ssize_t... yes checking for getopt... (cached) yes checking for getopt_long... (cached) yes checking for usleep... (cached) yes checking for gettimeofday... (cached) yes checking for Sleep... yes checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no checking for PTHREAD_PRIO_INHERIT... yes checking POSIX termios... no checking for size_t... yes checking for siginfo_t... no checking for sig_atomic_t... yes checking for sin... yes checking for connect... no checking for main in -lsocket... no checking for accept... no checking for gethostbyname... no checking for main in -lnsl... no checking for gethostbyname... (cached) no checking for main in -lws2_32... yes checking for timeBeginPeriod... no checking for main in -lwinmm... yes checking for gcc options needed to detect all undeclared functions... none needed checking for struct addrinfo... yes checking whether gai_strerror is declared... yes checking for getaddrinfo... (cached) yes checking for cfmakeraw... no checking for floor... yes checking for getpagesize... yes checking for getpagesize... (cached) yes checking for gettimeofday... (cached) yes checking for inet_ntoa... no checking for ioctl... no checking for memchr... yes checking for memmove... yes checking for memset... yes checking for pow... yes checking for rint... yes checking for select... no checking for setitimer... no checking for setlocale... yes checking for sigaction... no checking for signal... yes checking for snprintf... yes checking for socket... no checking for sqrt... yes checking for strchr... yes checking for strdup... yes checking for strerror... yes checking for strncasecmp... yes checking for strrchr... yes checking for strstr... yes checking for strtol... yes checking for glob... no checking for socketpair... no checking for working alloca.h... no checking for alloca... yes checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe checking if the linker (C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /mingw64/bin/nm -B checking the name lister (/mingw64/bin/nm -B) interface... BSD nm checking the maximum length of command line arguments... 8192 checking how to convert x86_64-w64-mingw32 file names to x86_64-w64-mingw32 format... func_convert_file_msys_to_w32 checking how to convert x86_64-w64-mingw32 file names to toolchain format... func_convert_file_msys_to_w32 checking for C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe option to reload object files... -r checking for file... file checking for objdump... objdump checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL checking for dlltool... dlltool checking how to associate runtime and link libraries... func_cygming_dll_for_implib checking for ranlib... ranlib checking for archiver @file<https://github.com/file> support... @ checking for strip... strip checking command to parse /mingw64/bin/nm -B output from gcc object... ok checking for sysroot... no checking for a working dd... /usr/bin/dd checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1 checking for mt... no checking if : is a manifest tool... no checking for dlfcn.h... no checking for as... as checking for dlltool... (cached) dlltool checking for objdump... (cached) objdump checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking how to run the C++ preprocessor... g++ -E checking for ld used by g++... C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe checking if the linker (C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes checking whether the g++ linker (C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes checking for g++ option to produce PIC... -DDLL_EXPORT -DPIC checking if g++ PIC flag -DDLL_EXPORT -DPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking if g++ supports -c -o file.o... (cached) yes checking whether the g++ linker (C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking for windres... windres checking whether C99 struct/array initializers are supported... yes checking whether to build USB dependent backends... yes checking for libusb_init in -lusb-1.0... yes checking for libusb.h... no checking for libusb-1.0/libusb.h... yes checking whether to use readline in rigctl/rotctl... yes checking for a readline compatible library... -lreadline checking for readline.h... no checking for readline/readline.h... yes checking whether readline supports history... yes checking for history.h... no checking for readline/history.h... yes checking whether to use INDI in rigctl/rotctl... checking whether to build HTML rig feature matrix... check checking for gd.h... no checking whether to build rigmem XML support... no checking whether to build USRP backend... no checking whether to build C++ binding... no checking whether to build perl binding... no checking whether to build python binding... no checking Whether to build Tcl bindings... no checking whether to build lua binding... no checking whether to build bindings... no checking whether to build winradio backend... yes checking whether to build parallel port devices... yes checking for dlopen in -ldl... no configure: WARNING: dlopen was not found in libdl--linradio backend will be disabled checking whether g++ supports C++11 features with -std=c++11... yes Build_OS is mingw32 checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating macros/Makefile config.status: creating include/Makefile config.status: creating lib/Makefile config.status: creating src/Makefile config.status: creating security/Makefile config.status: creating c++/Makefile config.status: creating bindings/Makefile config.status: creating doc/Makefile config.status: creating doc/hamlib.cfg config.status: creating rotators/amsat/Makefile config.status: creating rotators/apex/Makefile config.status: creating rotators/ars/Makefile config.status: creating rotators/celestron/Makefile config.status: creating rotators/cnctrk/Makefile config.status: creating rotators/grbltrk/Makefile config.status: creating rotators/easycomm/Makefile config.status: creating rotators/ether6/Makefile config.status: creating rotators/flir/Makefile config.status: creating rotators/fodtrack/Makefile config.status: creating rotators/gs232a/Makefile config.status: creating rotators/heathkit/Makefile config.status: creating rotators/ioptron/Makefile config.status: creating rotators/m2/Makefile config.status: creating rotators/meade/Makefile config.status: creating rotators/prosistel/Makefile config.status: creating rotators/rotorez/Makefile config.status: creating rotators/sartek/Makefile config.status: creating rotators/saebrtrack/Makefile config.status: creating rotators/spid/Makefile config.status: creating rotators/ts7400/Makefile config.status: creating rotators/indi/Makefile config.status: creating rotators/satel/Makefile config.status: creating rotators/skywatcher/Makefile config.status: creating rotators/radant/Makefile config.status: creating rigs/adat/Makefile config.status: creating rigs/alinco/Makefile config.status: creating rigs/aor/Makefile config.status: creating rigs/barrett/Makefile config.status: creating rigs/codan/Makefile config.status: creating rigs/commradio/Makefile config.status: creating rigs/dorji/Makefile config.status: creating rigs/drake/Makefile config.status: creating rigs/dummy/Makefile config.status: creating rigs/elad/Makefile config.status: creating rigs/flexradio/Makefile config.status: creating rigs/icmarine/Makefile config.status: creating rigs/icom/Makefile config.status: creating rigs/jrc/Makefile config.status: creating rigs/kachina/Makefile config.status: creating rigs/kenwood/Makefile config.status: creating rigs/kit/Makefile config.status: creating rigs/lowe/Makefile config.status: creating rigs/pcr/Makefile config.status: creating rigs/prm80/Makefile config.status: creating rigs/racal/Makefile config.status: creating rigs/rft/Makefile config.status: creating rigs/rs/Makefile config.status: creating rigs/skanti/Makefile config.status: creating rigs/tapr/Makefile config.status: creating rigs/tentec/Makefile config.status: creating rigs/tuner/Makefile config.status: creating rigs/uniden/Makefile config.status: creating rigs/winradio/Makefile config.status: creating rigs/wj/Makefile config.status: creating rigs/yaesu/Makefile config.status: creating rigs/gomspace/Makefile config.status: creating rigs/mds/Makefile config.status: creating rigs/anytone/Makefile config.status: creating rigs/motorola/Makefile config.status: creating tests/Makefile config.status: creating scripts/Makefile config.status: creating android/Makefile config.status: creating amplifiers/elecraft/Makefile config.status: creating amplifiers/gemini/Makefile config.status: creating amplifiers/expert/Makefile config.status: creating simulators/Makefile config.status: creating hamlib.pc config.status: creating include/hamlib/config.h config.status: include/hamlib/config.h is unchanged config.status: executing depfiles commands config.status: executing libtool commands ________________________________ Hamlib Version 4.7~git configuration: Prefix /c/JTSDK64-Tools/tools/hamlib/qt/5.15.2 Preprocessor gcc -E -I/c/JTSDK64-Tools/tools/libusb/1.0.28/include C Compiler gcc -g -O2 C++ Compiler g++ -std=c++11 -g -O2 Package features: With C++ binding no With Perl binding no With Python binding no With TCL binding no With Lua binding no With rigmem XML support no With Readline support yes With INDI support no Enable HTML rig feature matrix no Enable WinRadio yes Enable Parallel yes Enable USRP no Enable USB backends yes Enable shared libs yes Enable static libs no ________________________________ ________________________________ RUNNING MAKE CLEAN [ Hamlib ] * /c/JTSDK64-Tools/config/hlclean flag not set ________________________________ INSTALLING [ Hamlib ] * Clearing out old /c/JTSDK64-Tools/tools/hamlib/qt/5.15.2: Complete ,,,, (etc) |
|
From: George B. <geo...@gm...> - 2025-05-17 16:46:01
|
On 5/17/25 4:44 AM, Daniele Forsi wrote: > Hello, > >> I think the rig_cache structure should be completely internal to Hamlib, and not visible to the calling application. > that's a good thing ^ very > >> I hope there's no big use of this data elsewhere. > how external software would be using the current cache API? Strange are the ways of application programmers > > I grepped for "rig_cache" in the sources that I have locally (mostly > from Debian) and I found it only in Hamlib > > I searched on github for > language:C symbol:rig_cache NOT (path:rig.h OR path:cache.h OR path:cache.c) > > and found 15 results unrelated to Hamlib; a search that doesn't > exclude the files above returns more than 3000 results, including > various copies of Hamlib Given that there were no other responses, I'll go ahead and finish tidying up the code, and create a PR for master. |
|
From: Daniele F. <iu...@gm...> - 2025-05-17 08:44:30
|
Hello, > I think the rig_cache structure should be completely internal to Hamlib, and not visible to the calling application. that's a good thing > I hope there's no big use of this data elsewhere. how external software would be using the current cache API? I grepped for "rig_cache" in the sources that I have locally (mostly from Debian) and I found it only in Hamlib I searched on github for language:C symbol:rig_cache NOT (path:rig.h OR path:cache.h OR path:cache.c) and found 15 results unrelated to Hamlib; a search that doesn't exclude the files above returns more than 3000 results, including various copies of Hamlib -- 73 de IU5HKX Daniele |
|
From: Sakari N. <sak...@ni...> - 2025-05-17 06:48:37
|
Hi! As said I gave up with two TCP connection to rigcontrol. With one TCP connection and a command stack where next command is spooled out only if answer for the previous one is received it seems that RPRT -11 never happens. (or passes by without notification) It is also hard to dig out if it just passes by in short moment. But I'll keep my debugs running always when I operate with my Ham PC. -- Saku OH1KH George Baltz kirjoitti 16.5.2025 klo 20.29: > Can either of you capture a full debug log of the rigctld with debug > level = 5(rigctld -vvvvv)? Usually RPRT = -11 means hamlib thinks > that it can't get the information the app requested, for hardware or > configuration reasons. Since it works mostly, it might be something > transient, or it might just be confused. > > Anyway, a debug log should at least narrow down the possibilities. > > 73 n3gb > > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: George B. <geo...@gm...> - 2025-05-16 17:29:18
|
Can either of you capture a full debug log of the rigctld with debug level = 5(rigctld -vvvvv)? Usually RPRT = -11 means hamlib thinks that it can't get the information the app requested, for hardware or configuration reasons. Since it works mostly, it might be something transient, or it might just be confused. Anyway, a debug log should at least narrow down the possibilities. 73 n3gb |
|
From: Sakari N. <sak...@ni...> - 2025-05-16 15:42:00
|
Hi Steve! I have seen similar, but very seldom. When I was rewriting CqrlogAlpha rigcontrol that uses simple text based TCP connections to Hamlib (no direct library access). I start rigctld always via script before any other ham program and then use rig model #2 "Net Hamlib rigctld" for all my program settings. That way there is only one USB serial user; rigctld started by script and running on background. No collisions in serial line usage. So my goal was to create one TCP connection for FMV polling (frequency, mode, vfo) as timer based and another TCP connection for direct user commands like change band, tune, rit, split etc. Third TCP connection is made for hamlib CW keying. It did not succeed by the way I was planing. The main problem was not with Hamlib, but my code that mixed receive events between those two TCP connections. But while testing I found few times similar RPRT -11 responses. Thought then it was just caused by my code. Returned back to one TCP connection for rig control and mixed poll + user command stack with timer spooling that seems to be more stable, but has slower response. Do you start rigctld with "--vfo" or without? That changes the command structure. It can be checked with \chk_vfo at the beginning of program. Depending on answer you need to use "f" or "f currVFO" for frequency query. And then comes the nasty part. If you need "f currVFO" but issue only "f" you may expect very weird responses for following other commands until rigctld gets back to right track again (may take few commands). And there are many commands, but not all (that are not listed), requiring "currVFO" addition if the startup parameter --vfo is used. What really is needed is a "flush" byte that could be sent before any new command to ensure that last issued command, succeeded or not, is completely forgotten. Or better error handling for command interpreter in case where wrong formatted command is issued and ended with linefeed that should trigger the command format checking. I.E. if you send "f" when "f currVFO" is needed the response should be RPRT -8. Now there is no response at all and next command will be added to already sent "f" causing a weird combined command and also unexpected response and RPRT. These are just my thoughts... -- Saku OH1KH Stephen Pattinson via Hamlib-developer kirjoitti 16.5.2025 klo 9.32: > Hi, > > I have a python program that starts rigctld in the background and then > interrogates my IC-7300 by using the TCP access to rigctld. This works > 100% reliably and retrieves the frequency, tx state and mode of the > radio every second. > > Whilst experimenting with the "wfview" program which connects to the > IC-7300 and allows the radio to be controlled by a PC, I have come > across an odd problem. If I run the run the wfview program (which > works just fine) and then exit the program and then execute by Python > program as described above, my program intermittently malfunctions. > Note I'm not trying to do these things at the same time. They both > require access to the IC-7300 USB port. > > To be specific, the response to the "get_freq" command using the > extended protocol is for example as follows (in a python byte array) > > b'get_freq:|Frequency: 14243000|RPRT 0\n' > > However, if I had previously run (and terminated) the wfview program, > the response to the "get_freq" command is occasionally as follows > > b'get_freq:|RPRT -11\n' > > Ie the actual frequency message is missing and back end code -11 is > returned. > > The analogous thing happens for "get_ptt" and "get_mode" commands > every once in a while, although the error code is different. > > If I cycle the power on the radio, the problem goes away, so clearly > the wfview has changed something in the radio, but I have been unable > so far to see any config that it has changed that might have a > bearing on this issue. I'm hoping that either the "-11" error code > might convey a clue to the problem, or that someone might have come > across this as well. > > I get the same malfunction if I use the "simple" protocol instead. > > I don't believe this is a hamlib error, but I'm hoping that someone > here might have a suggestion for me to try. > > Thanks de VK3SPX (Steve) > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Stephen P. <st...@bi...> - 2025-05-16 06:47:18
|
Hi, I have a python program that starts rigctld in the background and then interrogates my IC-7300 by using the TCP access to rigctld. This works 100% reliably and retrieves the frequency, tx state and mode of the radio every second. Whilst experimenting with the "wfview" program which connects to the IC-7300 and allows the radio to be controlled by a PC, I have come across an odd problem. If I run the run the wfview program (which works just fine) and then exit the program and then execute by Python program as described above, my program intermittently malfunctions. Note I'm not trying to do these things at the same time. They both require access to the IC-7300 USB port. To be specific, the response to the "get_freq" command using the extended protocol is for example as follows (in a python byte array) b'get_freq:|Frequency: 14243000|RPRT 0\n' However, if I had previously run (and terminated) the wfview program, the response to the "get_freq" command is occasionally as follows b'get_freq:|RPRT -11\n' Ie the actual frequency message is missing and back end code -11 is returned. The analogous thing happens for "get_ptt" and "get_mode" commands every once in a while, although the error code is different. If I cycle the power on the radio, the problem goes away, so clearly the wfview has changed something in the radio, but I have been unable so far to see any config that it has changed that might have a bearing on this issue. I'm hoping that either the "-11" error code might convey a clue to the problem, or that someone might have come across this as well. I get the same malfunction if I use the "simple" protocol instead. I don't believe this is a hamlib error, but I'm hoping that someone here might have a suggestion for me to try. Thanks de VK3SPX (Steve) |
|
From: dforsi <no...@gi...> - 2025-05-11 22:58:16
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 0b68dc588539e0d53bdb758fdf1639e5808f010e https://github.com/Hamlib/Hamlib/commit/0b68dc588539e0d53bdb758fdf1639e5808f010e Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-08 (Thu, 08 May 2025) Changed paths: M src/conf.c Log Message: ----------- Also check the "name" parameter Avoids a segfault if calling strtol(NULL, NULL, 0). Commit: dcf4b7a4e0c03a02396694479a5069108b3555e2 https://github.com/Hamlib/Hamlib/commit/dcf4b7a4e0c03a02396694479a5069108b3555e2 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-08 (Thu, 08 May 2025) Changed paths: M include/hamlib/rig.h Log Message: ----------- Fix syntax of #define It was invalid C syntax, but it is currently unused. Commit: b73f64f49865ca2d2006f6ef21c6013a57152d7d https://github.com/Hamlib/Hamlib/commit/b73f64f49865ca2d2006f6ef21c6013a57152d7d Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-08 (Thu, 08 May 2025) Changed paths: M bindings/Makefile.am Log Message: ----------- Remove redundant dependencies All *.swg files are in $(SWIGDEP) via $(SWGFILES). Commit: 5c05881e0ed0b9fc440bc64f6b60b369f4109139 https://github.com/Hamlib/Hamlib/commit/5c05881e0ed0b9fc440bc64f6b60b369f4109139 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-08 (Thu, 08 May 2025) Changed paths: M bindings/Makefile.am M c++/Makefile.am M simulators/Makefile.am M src/Makefile.am M tests/Makefile.am Log Message: ----------- Add rules to build dependencies of libhamlib.la in other directories This makes it possible to run "make -C src/" or "make -C tests/ rigctl" or "make -C bindings/ check" (and so on) in a clean tree, but it doesn't rebuild those targets if libhamlib.la is changed; for this run make from the top directory as usual, to rebuild all SUBDIRS if needed. Commit: 23a54a7bdf088394e73182d7a2b911e01ca326a7 https://github.com/Hamlib/Hamlib/commit/23a54a7bdf088394e73182d7a2b911e01ca326a7 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-08 (Thu, 08 May 2025) Changed paths: M security/Makefile.am Log Message: ----------- Remove unneeded dependency Commit: 56eea198beb22db9aa4f0a1447282e14d4ce7ea3 https://github.com/Hamlib/Hamlib/commit/56eea198beb22db9aa4f0a1447282e14d4ce7ea3 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-08 (Thu, 08 May 2025) Changed paths: M c++/Makefile.am Log Message: ----------- Remove unneeded test script testcpp.sh Library directory ../dummy/.libs doesn't exist anymore and ../c++/.libs (a.k.a. .libs) is already used by the libtool wrapper script that runs the testcpp program. Commit: 1e7b1a628eefad3114e2d484ff18bc441552adb5 https://github.com/Hamlib/Hamlib/commit/1e7b1a628eefad3114e2d484ff18bc441552adb5 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-08 (Thu, 08 May 2025) Changed paths: M rigs/dummy/aclog.c M rigs/dummy/flrig.c M rigs/dummy/sdrsharp.c M rigs/dummy/tci1x.c M rigs/yaesu/newcat.c M src/rig.c Log Message: ----------- Fix error return values All constant error values RIG_E* should be negated when returned. Found with: grep -nrE RETURNFUNC.?.RIG_E.+ --include=*.{c,h} | grep -v \- Commit: de01821c5121c1097695ff3d783dc0b88ddf95d3 https://github.com/Hamlib/Hamlib/commit/de01821c5121c1097695ff3d783dc0b88ddf95d3 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-08 (Thu, 08 May 2025) Changed paths: M src/debug.c Log Message: ----------- Fix typo Commit: da60d2d38324bb1d090f6a0d7bf46fa1f01315bd https://github.com/Hamlib/Hamlib/commit/da60d2d38324bb1d090f6a0d7bf46fa1f01315bd Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-09 (Fri, 09 May 2025) Changed paths: M src/Makefile.am Log Message: ----------- Replace non-portable make rule with one that is also easier to understand Fixes: warning: '%'-style pattern rules are a GNU make extension Commit: c7ba4f5384bad446be7bf392539576dd1c572bd2 https://github.com/Hamlib/Hamlib/commit/c7ba4f5384bad446be7bf392539576dd1c572bd2 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-09 (Fri, 09 May 2025) Changed paths: M c++/Makefile.am M configure.ac Log Message: ----------- Fix --without-cxx-binding being ignored Do not build the C++ bindings if the configure script was called with the option --without-cxx-binding. Commit: ad824fa85e42fbf185addef24526427803056f1e https://github.com/Hamlib/Hamlib/commit/ad824fa85e42fbf185addef24526427803056f1e Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-05-09 (Fri, 09 May 2025) Changed paths: M c++/Makefile.am Log Message: ----------- Remove duplicated assignment of compilation flags Fixes a double "-g -O2 -g -O2" in compiler invocation. Compare: https://github.com/Hamlib/Hamlib/compare/6dfa118dace1...ad824fa85e42 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
33 messages has been excluded from this view by a project administrator.
