hamlib-developer Mailing List for Ham Radio Control Libraries (Page 24)
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
(44) |
Dec
|
|
From: Phil G. <gm...@bt...> - 2025-04-13 09:06:40
|
<html><body><div dir="auto">IIRC hamlib does its best to standardise all meter level readings for the different rigs. So S9 should always be a reading of 0 regardless of how the rig CAT encodes it.</div><div dir="auto"><br></div><div dir="auto">Phil GM3ZZA</div><div id="ms-outlook-mobile-body-separator-line" dir="auto"><br></div><div id="ms-outlook-mobile-signature" dir="auto">Get <a href="https://aka.ms/AAb9ysg">Outlook for Android</a></div><div dir="auto" id="mail-editor-reference-message-container"><br><hr style="display: inline-block; width: 98%;"><div id="divRplyFwdMsg" style="font-size: 11pt;" dir="auto"><b>From:</b> Stephen Pattinson via Hamlib-developer <ham...@li...><br><b>Sent:</b> Sunday, April 13, 2025 5:56:49 AM<br><b>To:</b> ham...@li... <ham...@li...><br><b>Subject:</b> Re: [Hamlib-developer] Introduction and Question about S-Meter-Reading<br></div><br> Hi Richard,<br> <br> Sounds like an awesome project - good on you.<br> <br> As it happens, I've just finished getting STRENGTH data from an Icom-7300, so I can explain how that works. However, looking through various posts and the documentation, I suspect the return of STRENGTH information may not be perfectly aligned across various rigs.<br> <br> The IC-7300 returns a dB figure, with 0dB corresponding to S9 - 50 microvolts into 50 ohms.<br> Given this, any positive number is dB above S9.<br> To determine S0 to S8, just consider that for each 6dB the STRENTH value decreases below S9, its one less S point<br> <br> My implementation is (Python, but probably valid C code as well)<br> spoint= 9 + ((int((levInt+1)/6))-1)<br> where levInt is the value returned by STRENGTH when <u>negative</u><br> Any positive value of STRENGTH is just S9<br> <br> Officially, S9 is really -73dBm, so if you want a dBm figure from the IC-7300, just subtract 73 from the STRENGTH amount.<br> <br> Cheers<br> Steve<br> VK3SPX<br> <br> <br> <br> <div dir="auto" class="moz-cite-prefix">On 13/04/2025 04:36, Richard Emling wrote:<br> </div><blockquote>Hello. <br> <br> <br> My name is Richard. I have been blind since birth and am currently working on a project that uses Hamlib to develop a system that helps blind individuals, especially those who are not very computer-savvy, to operate amateur radio transceivers. Particularly, people who have lost their sight later in life and older individuals often lack the ability to adapt to the changed situation and therefore require special assistance. <br> <br> A Raspberry Pi hosts the Hamlib, transceiver functions can be controlled via a connected numeric keypad, and a speech output reads everything aloud. <br> Optionally, a MIDI controller can be connected to control the functions of the radio device. <br> Anyone interested in seeing the current progress of the project and willing to provide tips on how I might use some Hamlib functions more effectively is welcome to visit <a href="https://github.com/do9re/midi2hamlib" class="moz-txt-link-freetext">https://github.com/do9re/midi2hamlib</a> . <br> <br> <br> My first question concerns reading the S-meter on a transceiver. As I understand it, the STRENGTH level provides this information. <br> <br> But where can I find a conversion table that tells me which S-level corresponds to the read value? <br> <br> <br> I am excited to be part of the Hamlib family and look forward to a good exchange. <br> <br> <br> 73 <br> <br> Richard (DO9RE) <br> <br> <br> _______________________________________________ <br> Hamlib-developer mailing list <br> <a href="mailto:Ham...@li..." class="moz-txt-link-abbreviated">Ham...@li...</a> <br> <a href="https://lists.sourceforge.net/lists/listinfo/hamlib-developer" class="moz-txt-link-freetext">https://lists.sourceforge.net/lists/listinfo/hamlib-developer</a> <br> </blockquote><br> <br></div></body></html> |
|
From: Stephen P. <st...@bi...> - 2025-04-13 04:56:31
|
Hi Richard, Sounds like an awesome project - good on you. As it happens, I've just finished getting STRENGTH data from an Icom-7300, so I can explain how that works. However, looking through various posts and the documentation, I suspect the return of STRENGTH information may not be perfectly aligned across various rigs. The IC-7300 returns a dB figure, with 0dB corresponding to S9 - 50 microvolts into 50 ohms. Given this, any positive number is dB above S9. To determine S0 to S8, just consider that for each 6dB the STRENTH value decreases below S9, its one less S point My implementation is (Python, but probably valid C code as well) spoint= 9 + ((int((levInt+1)/6))-1) where levInt is the value returned by STRENGTH when _negative_ Any positive value of STRENGTH is just S9 Officially, S9 is really -73dBm, so if you want a dBm figure from the IC-7300, just subtract 73 from the STRENGTH amount. Cheers Steve VK3SPX On 13/04/2025 04:36, Richard Emling wrote: > Hello. > > > My name is Richard. I have been blind since birth and am currently > working on a project that uses Hamlib to develop a system that helps > blind individuals, especially those who are not very computer-savvy, > to operate amateur radio transceivers. Particularly, people who have > lost their sight later in life and older individuals often lack the > ability to adapt to the changed situation and therefore require > special assistance. > > A Raspberry Pi hosts the Hamlib, transceiver functions can be > controlled via a connected numeric keypad, and a speech output reads > everything aloud. > Optionally, a MIDI controller can be connected to control the > functions of the radio device. > Anyone interested in seeing the current progress of the project and > willing to provide tips on how I might use some Hamlib functions more > effectively is welcome to visit https://github.com/do9re/midi2hamlib . > > > My first question concerns reading the S-meter on a transceiver. As I > understand it, the STRENGTH level provides this information. > > But where can I find a conversion table that tells me which S-level > corresponds to the read value? > > > I am excited to be part of the Hamlib family and look forward to a > good exchange. > > > 73 > > Richard (DO9RE) > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Richard E. <DO...@ho...> - 2025-04-12 19:45:54
|
Hello everyone, I would like to understand how to interpret the CTCSS tones from the --CAPS-DUMP list when transmitting them to the transceiver. They are listed with a decimal point. However, when I transmit them using the C command and later query with the c command, only the number before the decimal point is returned, as if the part after the decimal point is lost. What am I doing wrong? Best regards, Richard (DO9RE) |
|
From: Richard E. <DO...@ho...> - 2025-04-12 18:37:24
|
Hello. My name is Richard. I have been blind since birth and am currently working on a project that uses Hamlib to develop a system that helps blind individuals, especially those who are not very computer-savvy, to operate amateur radio transceivers. Particularly, people who have lost their sight later in life and older individuals often lack the ability to adapt to the changed situation and therefore require special assistance. A Raspberry Pi hosts the Hamlib, transceiver functions can be controlled via a connected numeric keypad, and a speech output reads everything aloud. Optionally, a MIDI controller can be connected to control the functions of the radio device. Anyone interested in seeing the current progress of the project and willing to provide tips on how I might use some Hamlib functions more effectively is welcome to visit https://github.com/do9re/midi2hamlib . My first question concerns reading the S-meter on a transceiver. As I understand it, the STRENGTH level provides this information. But where can I find a conversion table that tells me which S-level corresponds to the read value? I am excited to be part of the Hamlib family and look forward to a good exchange. 73 Richard (DO9RE) |
|
From: Bob N. <bn...@gm...> - 2025-04-12 16:22:01
|
I have a AntRunner rotor unit that connects to my raspberry pi with a usb
cable. The instructions say to run "rotctld -vvvvv -m 2401 -r /dev/ttyUSB0"
to connect. It fails each time.
The connection is Device 004. I am at a loss , as to getting the connection
up and running. It does work on my laptop with hamlib so I know that the
unit works. Any help is greatly appreciated.
pi@rpq5:~ $ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 005: ID 1546:01a7 U-Blox AG [u-blox 7]
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Running the script.
pi@rpq5:~ $ rotctld -vvvvv -m 2401 -r /dev/ttyUSB0
rotctld, Hamlib 4.5.4 Jan 10 01:31:41Z 2023 SHA=921cc5
Report bugs to <ham...@li...>
rot_init called
initrots4_grbltrk: _init called
rot_register (2401)
rot_register (2402)
grbltrk_rot_init:454 rot->caps->rot_model: 2401
set_conf: called
rot_open called
serial_open: /dev/ttyS0
serial_open(229): open failed#1
serial_open(229): open failed#2
serial_open(229): open failed#3
serial_open(229): open failed#4
serial_open: Unable to open /dev/ttyS0 - No such file or directory
rot_open: error = set_conf: called
rot_open called
serial_open: /dev/ttyS0
serial_open(229): open failed#1
serial_open(229): open failed#2
serial_open(229): open failed#3
serial_open(229): open failed#4
serial_open: Unable to open /dev/ttyS0 - No such file or directory
IO error
DEvice info from hamlib.
2401 BG5DIW GRBLTRK via Serial 20220515.0 Beta
ROT_MODEL_GRBLTRK_SER
2402 BG5DIW GRBLTRK via Net 20220515.0 Beta
ROT_MODEL_GRBLTRK_NET
--
Bob Nazro, W1RPQ
phone: (860) 941-7993
b <Jos...@cp...>na...@gm...
|
|
From: Bill B. <bi...@wi...> - 2025-04-11 19:31:54
|
Thanks George. I confess to being aware of that doc but not reading it as thoroughly as I should have. On 4/11/2025 10:32 AM, George Baltz wrote: > See README.developer in the top level directory of the source tree. > > On 4/11/25 12:40 PM, Bill Bennett wrote: >> Some time ago I think I remember someone pointing to a guidelines or >> cookbook document, how to add a new rig to hamlib. But I can't find >> it... Does anyone know of such a thing, or more generally, any >> detailed guidance on how to get started? >> >> I am perhaps one of very few still using a Kachina 505DSP as the main >> daily rig here. There is a bare stub of an implementation - I'd like >> to flesh it out. >> >> Thanks for any suggestions. >> >> 73 - Bill N7DZ >> >> >> >> _______________________________________________ >> Hamlib-developer mailing list >> Ham...@li... >> https://lists.sourceforge.net/lists/listinfo/hamlib-developer > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Nate B. <n0...@n0...> - 2025-04-11 17:51:21
|
* On 2025 11 Apr 12:43 -0500, Henry Ketter wrote: > Sorry the infomation was not complete: > > I use Inerface IF-100 from AMSAT on /dev/parport0. Hi Henry. Welcome to Hamlib! Sorry to hear you are having trouble. To help us help you, please add '-vvvvv' to the rotctl command line and post all of the output including the full command you used to start rotctl. 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-04-11 17:33:08
|
See README.developer in the top level directory of the source tree. On 4/11/25 12:40 PM, Bill Bennett wrote: > Some time ago I think I remember someone pointing to a guidelines or > cookbook document, how to add a new rig to hamlib. But I can't find > it... Does anyone know of such a thing, or more generally, any > detailed guidance on how to get started? > > I am perhaps one of very few still using a Kachina 505DSP as the main > daily rig here. There is a bare stub of an implementation - I'd like > to flesh it out. > > Thanks for any suggestions. > > 73 - Bill N7DZ > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Bill B. <bi...@wi...> - 2025-04-11 16:40:43
|
Some time ago I think I remember someone pointing to a guidelines or cookbook document, how to add a new rig to hamlib. But I can't find it... Does anyone know of such a thing, or more generally, any detailed guidance on how to get started? I am perhaps one of very few still using a Kachina 505DSP as the main daily rig here. There is a bare stub of an implementation - I'd like to flesh it out. Thanks for any suggestions. 73 - Bill N7DZ |
|
From: Henry K. <dh...@t-...> - 2025-04-11 09:30:10
|
Sorry the infomation was not complete: I use Inerface IF-100 from AMSAT on /dev/parport0. Have a niche weekend! 73 Henry |
|
From: Henry K. <dh...@t-...> - 2025-04-11 09:01:24
|
Hallo, I use Yeasu-Rotor AZ/EL. Befor update Hamlib all okay. In Moment Problem : Rotator command: R Reset: 1 error = rotctl Hamlib 4.6.2 2025-02-09T21:03:50Z SHA=870364 64-bit Report bugs to <ham...@li...> rot_init called initrots4_amsat called rot_register (1201) rot_token_lookup called lookup south_zero rot_token_lookup called lookup south_zero rot_set_conf called frontrot_set_conf called rot_open called par_open called ser_set_dtr: DTR=0 ser_set_dtr: Cannot change DTR - Invalid argument ser_set_rts: RTS=0 ser_set_rts: Cannot change RTS - Invalid argument Backend version: 20110531.0, Status: Stable rotctl_parse: input_line: R rot_reset called Rotator command: p error = rot_init called initrots4_amsat called rot_register (1201) rot_token_lookup called lookup south_zero rot_token_lookup called lookup south_zero rot_set_conf called frontrot_set_conf called rot_open called par_open called ser_set_dtr: DTR=0 ser_set_dtr: Cannot change DTR - Invalid argument ser_set_rts: RTS=0 ser_set_rts: Cannot change RTS - Invalid argument Backend version: 20110531.0, Status: Stable rotctl_parse: input_line: R rot_reset called Feature not available rotctl_parse: input_line: p rot_get_position called Feature not available Command P ist works. Can you help? 73 Henry Feature not available |
|
From: Nate B. <no...@gi...> - 2025-04-09 19:06:21
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 285a865d9ff9a0dff484b5c880f3d17097692175 https://github.com/Hamlib/Hamlib/commit/285a865d9ff9a0dff484b5c880f3d17097692175 Author: Nate Bargmann <n0...@n0...> Date: 2025-04-09 (Wed, 09 Apr 2025) Changed paths: M configure.ac Log Message: ----------- Restore libtool default of building shared and static libs Commit 43159e5 prevented the libtool default of building both shared and static libraries during a compilation run. This addresses GitHub issue 1500 that seeks to enable both shared and static libs. At this point, I have not found the motivation for commit 43159e5 despite searching all forums and the mailing list. While the reason might not now be ever known, restoring the default behavior alligns the project with other software package. Commit: 34698df17acf6cc2ee72d3944b4149f0f621515a https://github.com/Hamlib/Hamlib/commit/34698df17acf6cc2ee72d3944b4149f0f621515a Author: Nate Bargmann <n0...@n0...> Date: 2025-04-09 (Wed, 09 Apr 2025) Changed paths: M configure.ac Log Message: ----------- Merge pull request #1694 from N0NB/static_lib Restore libtool default of building shared and static libs Compare: https://github.com/Hamlib/Hamlib/compare/d8a3aac62587...34698df17acf To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <n0...@n0...> - 2025-04-09 13:09:35
|
Going through the issue list I found issue #1500: https://github.com/Hamlib/Hamlib/issues/1500 Wherein Mike notes that it should be possible to build both shared and static libraries. I thought that odd as I seemed to recall that in the past both were built as SOP. I spent some time with configure and its options and not working out why it was either/or. Not thinking (we could probably stop right there) that it was anything to do with Hamlib I posted to the libtool mailing list seeking some help: https://mail.gnu.org/archive/html/libtool/2025-04/msg00005.html A kind soul by the name of Simon helped out and pointed out a section in our configure.ac file that sets the variables that control shared and static libraries in an exclusive OR fashion. The use of 'git blame' showed this section was added in the following commit: https://github.com/Hamlib/Hamlib/commit/43159e55a1c4351199fada21eb6be4632001d930 My testing shows that commenting that section enables the default libtool behavior of building both shared and static libraries and dynamically linking the executables (rigctl, etc.) to the shared library. I've also tested the Windows 32 and 64 bit binaries and I don't see any build issues (I've not tested run time). I've looked through the closed issues, the discussion and mailing list archives, and even my private mail and don't see anything that prompted that commit. Even more puzzling is the opening of the issue two and a half months later. Regardless, it is my intent to temporarily revert that commit by commenting the relevant lines and seeing who yells. 🤔 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: Phil <phi...@gm...> - 2025-04-08 23:22:00
|
On 8/4/25 21:49, George Baltz wrote: > > You need to add PYTHON_VERSION=3 to the command. > Thank you George. Using the python binding is going to keep me occupied for quite some time. -- Regards, Phil |
|
From: George B. <geo...@gm...> - 2025-04-08 11:50:11
|
It's looking for python, you probably only have python3. You need to add PYTHON_VERSION=3 to the command. On Tue, Apr 8, 2025, 1:32 AM Phil <phi...@gm...> wrote: > > On 7/4/25 17:29, Nate Bargmann wrote: > > Hi Phil. > > I presume you're on Linux, which distribution? > > Xubuntu 24.10 > > Thank you Nate for taking the time to answer. > > Running configure this time the result is : (previously I ran "env > PYTHON=/usr/bin/python3 ./configure --with-python-binding" which did find > python) > > /phil@phil-ThinkPad-X1-Carbon-Gen-11:~/Downloads/Hamlib$ ./configure --with-python-binding > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > 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 build environment is sane... yes > checking for a race-free mkdir -p... /usr/bin/mkdir -p > checking for gawk... no > checking for mawk... mawk > checking whether make sets $(MAKE)... yes > checking whether make supports the include directive... yes (GNU style) > checking whether make supports nested variables... yes > checking dependency style of gcc... gcc3 > checking whether make supports nested variables... (cached) yes > 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) mawk > checking whether ln -s works... yes > 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... yes > checking for sgtty.h... yes > checking for stddef.h... yes > checking for termio.h... yes > checking for termios.h... yes > checking for values.h... yes > checking for arpa/inet.h... yes > checking for dev/ppbus/ppbconf.hdev/ppbus/ppi.h... no > checking for linux/hidraw.h... yes > checking for linux/ioctl.h... yes > checking for linux/parport.h... yes > checking for linux/ppdev.h... yes > checking for netinet/in.h... yes > checking for sys/ioccom.h... no > checking for sys/ioctl.h... yes > checking for sys/param.h... yes > checking for sys/socket.h... yes > checking for sys/stat.h... (cached) yes > checking for sys/time.h... yes > checking for sys/select.h... yes > checking for glob.h... yes > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu > checking for ws2tcpip.h... no > checking for wspiapi.h... no > checking for library containing nanosleep... none required > checking for pthread.h... yes > checking for sys/types.h... (cached) yes > checking for windows.h... no > checking for winioctl.h... no > checking for winbase.h... no > 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... no > 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... yes > checking for size_t... yes > checking for siginfo_t... yes > checking for sig_atomic_t... yes > checking for sin... no > checking for connect... yes > checking for gethostbyname... yes > checking for gethostbyname... (cached) yes > checking for timeBeginPeriod... no > checking for main in -lwinmm... no > 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... yes > checking for floor... no > checking for getpagesize... yes > checking for getpagesize... (cached) yes > checking for gettimeofday... (cached) yes > checking for inet_ntoa... yes > checking for ioctl... yes > checking for memchr... yes > checking for memmove... yes > checking for memset... yes > checking for pow... no > checking for rint... no > checking for select... yes > checking for setitimer... yes > checking for setlocale... yes > checking for sigaction... yes > checking for signal... yes > checking for snprintf... yes > checking for socket... yes > checking for sqrt... no > 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... yes > checking for socketpair... yes > checking for working alloca.h... yes > 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... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B > checking the name lister (/usr/bin/nm -B) interface... BSD nm > checking the maximum length of command line arguments... 1572864 > checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop > checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop > checking for /usr/bin/ld option to reload object files... -r > checking for file... file > checking for objdump... objdump > checking how to recognize dependent libraries... pass_all > checking for dlltool... no > checking how to associate runtime and link libraries... printf %s\n > checking for archiver @FILE support... @ > checking for strip... strip > checking for ranlib... ranlib > checking command to parse /usr/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... mt > checking if mt is a manifest tool... no > checking for dlfcn.h... yes > checking for objdir... .libs > checking if gcc supports -fno-rtti -fno-exceptions... no > checking for gcc option to produce PIC... -fPIC -DPIC > checking if gcc PIC flag -fPIC -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 (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > 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++... /usr/bin/ld -m elf_x86_64 > checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC -DPIC > checking if g++ PIC flag -fPIC -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 (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes > checking dynamic linker characteristics... (cached) GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking for windres... no > 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... no > configure: WARNING: readline support not found, using internal input handling. > 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... yes > checking whether to build perl binding... no > checking whether to build python binding... yes > checking for python... no > configure: error: Cannot find python in your system path > > This all looks good, except for python not found. > > I have the latest hamlib from github, I wonder if that differs from the > version that you have? > > git clone https://github.com/Hamlib/Hamlib.git > > -- > Regards, > Phil > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer > |
|
From: Phil <phi...@gm...> - 2025-04-08 05:32:01
|
On 7/4/25 17:29, Nate Bargmann wrote: > Hi Phil. > > I presume you're on Linux, which distribution? Xubuntu 24.10 Thank you Nate for taking the time to answer. Running configure this time the result is : (previously I ran "|envPYTHON=/usr/bin/python3 ./configure --with-python-binding" which did find python) | > /phil@phil-ThinkPad-X1-Carbon-Gen-11:~/Downloads/Hamlib$ ./configure --with-python-binding > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > 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 build environment is sane... yes > checking for a race-free mkdir -p... /usr/bin/mkdir -p > checking for gawk... no > checking for mawk... mawk > checking whether make sets $(MAKE)... yes > checking whether make supports the include directive... yes (GNU style) > checking whether make supports nested variables... yes > checking dependency style of gcc... gcc3 > checking whether make supports nested variables... (cached) yes > 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) mawk > checking whether ln -s works... yes > 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... yes > checking for sgtty.h... yes > checking for stddef.h... yes > checking for termio.h... yes > checking for termios.h... yes > checking for values.h... yes > checking for arpa/inet.h... yes > checking for dev/ppbus/ppbconf.hdev/ppbus/ppi.h... no > checking for linux/hidraw.h... yes > checking for linux/ioctl.h... yes > checking for linux/parport.h... yes > checking for linux/ppdev.h... yes > checking for netinet/in.h... yes > checking for sys/ioccom.h... no > checking for sys/ioctl.h... yes > checking for sys/param.h... yes > checking for sys/socket.h... yes > checking for sys/stat.h... (cached) yes > checking for sys/time.h... yes > checking for sys/select.h... yes > checking for glob.h... yes > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu > checking for ws2tcpip.h... no > checking for wspiapi.h... no > checking for library containing nanosleep... none required > checking for pthread.h... yes > checking for sys/types.h... (cached) yes > checking for windows.h... no > checking for winioctl.h... no > checking for winbase.h... no > 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... no > 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... yes > checking for size_t... yes > checking for siginfo_t... yes > checking for sig_atomic_t... yes > checking for sin... no > checking for connect... yes > checking for gethostbyname... yes > checking for gethostbyname... (cached) yes > checking for timeBeginPeriod... no > checking for main in -lwinmm... no > 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... yes > checking for floor... no > checking for getpagesize... yes > checking for getpagesize... (cached) yes > checking for gettimeofday... (cached) yes > checking for inet_ntoa... yes > checking for ioctl... yes > checking for memchr... yes > checking for memmove... yes > checking for memset... yes > checking for pow... no > checking for rint... no > checking for select... yes > checking for setitimer... yes > checking for setlocale... yes > checking for sigaction... yes > checking for signal... yes > checking for snprintf... yes > checking for socket... yes > checking for sqrt... no > 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... yes > checking for socketpair... yes > checking for working alloca.h... yes > 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... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B > checking the name lister (/usr/bin/nm -B) interface... BSD nm > checking the maximum length of command line arguments... 1572864 > checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop > checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop > checking for /usr/bin/ld option to reload object files... -r > checking for file... file > checking for objdump... objdump > checking how to recognize dependent libraries... pass_all > checking for dlltool... no > checking how to associate runtime and link libraries... printf %s\n > checking for archiver @FILE support... @ > checking for strip... strip > checking for ranlib... ranlib > checking command to parse /usr/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... mt > checking if mt is a manifest tool... no > checking for dlfcn.h... yes > checking for objdir... .libs > checking if gcc supports -fno-rtti -fno-exceptions... no > checking for gcc option to produce PIC... -fPIC -DPIC > checking if gcc PIC flag -fPIC -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 (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > 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++... /usr/bin/ld -m elf_x86_64 > checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC -DPIC > checking if g++ PIC flag -fPIC -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 (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes > checking dynamic linker characteristics... (cached) GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking for windres... no > 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... no > configure: WARNING: readline support not found, using internal input handling. > 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... yes > checking whether to build perl binding... no > checking whether to build python binding... yes > checking for python... no > configure: error: Cannot find python in your system path This all looks good, except for python not found. I have the latest hamlib from github, I wonder if that differs from the version that you have? |git clonehttps://github.com/Hamlib/Hamlib.git | -- Regards, Phil |
|
From: Nate B. <n0...@n0...> - 2025-04-07 07:30:14
|
* On 2025 06 Apr 23:25 -0500, Phil wrote: > Thank you for reading this. > > The recent discussion about using rigctl within Python code has rekindled my > interest in this subject. I don't remember ever being able to build the > Python bindings and so I had used rigctl instead, which is still working. I > decided to try to build the bindings today but without success. > > I do have hamlib-utils installed which gives me rigctl. > > This is what I'd tried: > > git clone https://github.com/Hamlib/Hamlib.git > cd Hamlib > > ./bootstrap > ./configure --with-python-binding > > This ends with "cannot find python". Hi Phil. I presume you're on Linux, which distribution? I just tried it here on Debian 12 and everything works as expected. I have the 'python3-dev' package installed which *should* pull in everything else (header files, etc.). Here is my 'configure' excerpt: ../hamlib/configure --prefix=$HOME/local --with-python-binding ... checking whether to build python binding... yes checking for python... /usr/bin/python checking for a version of Python >= '2.1.0'... yes checking for a version of Python >='2.1'... yes checking for the sysconfig Python package... yes checking for Python include path... -I/usr/include/python3.11 checking for Python library path... -L/usr/lib/x86_64-linux-gnu -lpython3.11 checking for Python site-packages path... /home/nate/local/lib/python3.11/site-packages checking for Python platform specific site-packages path... /home/nate/local/lib/python3.11/site-packages checking python extra libraries... -ldl -lm checking python extra linking flags... -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions checking consistency of all components of python development environment... yes checking whether /usr/bin/python version is >= 2.1... yes checking for /usr/bin/python version... 3.11 checking for /usr/bin/python platform... linux checking for GNU default /usr/bin/python prefix... ${prefix} checking for GNU default /usr/bin/python exec_prefix... ${exec_prefix} checking for /usr/bin/python script directory (pythondir)... ${PYTHON_PREFIX}/lib/python3.11/site-packages checking for /usr/bin/python extension module directory (pyexecdir)... ${PYTHON_EXEC_PREFIX}/lib/python3.11/site-packages ... Package features: With C++ binding yes With Perl binding no With Python binding yes With TCL binding no With Lua binding no With rigmem XML support no With Readline support yes With INDI support no ... Then 'make' and 'make install'. And since I am installing into my home directory I have the following file: $HOME/.local/lib/python3.11/site-packages/home_local.pth which contains: /home/nate/local/lib/python3.11/site-packages I successfully ran 'py3test.py' from the bindings directory. 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: Phil <phi...@gm...> - 2025-04-07 04:24:14
|
Thank you for reading this. The recent discussion about using rigctl within Python code has rekindled my interest in this subject. I don't remember ever being able to build the Python bindings and so I had used rigctl instead, which is still working. I decided to try to build the bindings today but without success. I do have hamlib-utils installed which gives me rigctl. This is what I'd tried: git clone https://github.com/Hamlib/Hamlib.git cd Hamlib ./bootstrap ./configure --with-python-binding This ends with "cannot find python". I also tried "env PYTHON=/usr/bin/python3 ./configure --with-python-binding". This resulted in a configuration table that showed "With Python binding yes" amongst other listings. "make" followed by "sudo make install" didn't generate any errors, however, Python cannot find either the "Hamlib" or "hamlib" module. I've spent hours searching the internet for an answer and my AI friend, although helpful, wasn't able suggest anything that solved the problem. -- Regards, Phil |
|
From: Nate B. <n0...@n0...> - 2025-04-06 19:29:25
|
* On 2025 06 Apr 13:04 -0500, George Baltz wrote: > On 4/5/25 5:11 PM, Nate Bargmann wrote: > > Hi all. > > > > Over the past several days I've been looking over the issue tracker on > > GitHub and doing a little bit of triage that Mike was unable to get to. > I also spent some time going through the issues, and picked out a couple to > work on. There are also some duplicates, and some that might be complete > except for verification. Hi George. Thanks for looking through the list. I've been going through it a bit and have assigned some to myself that interest me. I invite anyone who chooses to work on an issue to assign themself to it. Doing so doesn't set your name in stone, it is just merely an alert to others browsing the list that someone has taken an interest in that particular issue. Also, if an issue is of interest and someone shows as assigned, contact that person and collaborate! > > I know Mike had a vision of a future release timeline. It's not set in > > stone so I'm not suggesting that the project hold itself rigidly to it. > > For example, he envisioned 5.0 by late 2026. As I recall, bumping the > > major version is only necessary if the C ABI changes to such an extent > > that recompilation of client programs is necessary, so, for now, I don't > > foresee 5.0 being imminent. > Good. The ones that I saw that could benefit from a 5.0 are the rig > structure changes (1445, 1420, 536 and 487); see my comments in 1445. None > of them will be ready soon. Would it help to have a feature branch that your work can be pushed to that could also track master? Would that assist in parallel development and perhaps shorten the time from where we are now to 5.0? > > What I would like to do is ask that everyone take a look at the issue > > tracker: > > > > https://github.com/Hamlib/Hamlib/issues > > > > and look for something that you can help with. Some are getting to be > > quite old with the oldest at almost five years. Some require some > > testing with certain hardware to see if an issue still exists. It's > > impossible for anyone to have all of the hardware Hamlib supports so the > > project has always depended on help from those with hardware. To that > > end I would like to see the number of issues reduced by month's end, if > > possible. > OK. Will try to bring the numbers down. Thanks! > > This leads to my plan for the next release. I would like to roll up the > > current master branch into a 4.6.3 release by the end of April. As all > > of the commits since 4.6.2 appear to be fixes and not new features, > > please limit Pull Requests (PRs) to fixes including closing issues. > > Upon release, 4.6.3 will be dedicated to the memory of Mike. > > > > After the next release, master will be open to new features and be > > planned as a 4.7.0 release. I've been a bit lax in adding the '.0' to > > the initial minor release in a series and I think that has resulted in > > some confusion over the years. Hopefully 4.7.0 can be released in a few > > months. > Great. If we decide to work toward a 5.0 release, I think I can make it > possible to build a 4.7 client that will be API-compatible with both pre-4.7 > and 5.0 libraries. I'm intrigued. > > At one time I proposed to have a release cadence of late winter > > and late summer to stay ahead of the Ubuntu release cycle. I'm not sure > > if this is still a reasonable release strategy as I'm unsure if Ubuntu > > is still the amateur radio favorite it once was. It's likely best that > > we make releases when it is the best timing for this project, i.e. when > > it's ready. > Definitely. I don't see a 4.7 coming together before the end of the year. Before we go any further, I'll explain what I see as my role in the project. First, I joined the project in early 2001. While I have contributed code in the past I am not nor will I ever be the lead developer. I'm the old guy that was here and took on the admin role on SourceForge when Stephane stepped away and Set up the initial project on GitHub. I've done work wrangling with the build system and documentation. Second, I also don't have much of a vision for Hamlib except for the project to be accessible and to help keep the project active and viable as best I can. APIs change over time and I think all of the projects that use Hamlib understand and are accepting of that so long as changes are communicated well in advance. Also, advancing the major number, i.e. 4.x.x to 5.x.x, and so on, communicates that change. Third, in light of the above, I see my role as being a facilitator for those that write the actual Hamlib code. Unlike Mike and many others, I lack the experience and knowledge to engage in a discussion such as that in issue 1445, though I find it fascinating. As a project, Hamlib is nearing its 25th anniversary--quite a milestone! Along the way best practices have changed and Hamlib should change to match and I defer to those with the knowledge to lead that effort. My pledge to the project is to merge pull requests and patches and make sure that all contributors get credit for commits. I'll also do what I can to answer questions here and in our forums though everyone is welcome to chime in. It's not too likely that I'll get deeply involved in technical discussions as I'll leave that to those with a better vision of how Hamlib should be interested. My inbox is always open. I will continue to do releases when we determine the code is ready. 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-04-06 18:03:29
|
On 4/5/25 5:11 PM, Nate Bargmann wrote: > Hi all. > > Over the past several days I've been looking over the issue tracker on > GitHub and doing a little bit of triage that Mike was unable to get to. I also spent some time going through the issues, and picked out a couple to work on. There are also some duplicates, and some that might be complete except for verification. > I know Mike had a vision of a future release timeline. It's not set in > stone so I'm not suggesting that the project hold itself rigidly to it. > For example, he envisioned 5.0 by late 2026. As I recall, bumping the > major version is only necessary if the C ABI changes to such an extent > that recompilation of client programs is necessary, so, for now, I don't > foresee 5.0 being imminent. Good. The ones that I saw that could benefit from a 5.0 are the rig structure changes (1445, 1420, 536 and 487); see my comments in 1445. None of them will be ready soon. > What I would like to do is ask that everyone take a look at the issue > tracker: > > https://github.com/Hamlib/Hamlib/issues > > and look for something that you can help with. Some are getting to be > quite old with the oldest at almost five years. Some require some > testing with certain hardware to see if an issue still exists. It's > impossible for anyone to have all of the hardware Hamlib supports so the > project has always depended on help from those with hardware. To that > end I would like to see the number of issues reduced by month's end, if > possible. OK. Will try to bring the numbers down. > This leads to my plan for the next release. I would like to roll up the > current master branch into a 4.6.3 release by the end of April. As all > of the commits since 4.6.2 appear to be fixes and not new features, > please limit Pull Requests (PRs) to fixes including closing issues. > Upon release, 4.6.3 will be dedicated to the memory of Mike. > > After the next release, master will be open to new features and be > planned as a 4.7.0 release. I've been a bit lax in adding the '.0' to > the initial minor release in a series and I think that has resulted in > some confusion over the years. Hopefully 4.7.0 can be released in a few > months. Great. If we decide to work toward a 5.0 release, I think I can make it possible to build a 4.7 client that will be API-compatible with both pre-4.7 and 5.0 libraries. > > At one time I proposed to have a release cadence of late winter > and late summer to stay ahead of the Ubuntu release cycle. I'm not sure > if this is still a reasonable release strategy as I'm unsure if Ubuntu > is still the amateur radio favorite it once was. It's likely best that > we make releases when it is the best timing for this project, i.e. when > it's ready. Definitely. I don't see a 4.7 coming together before the end of the year. > > Thoughts? > > 73, Nate > -- 73 n3gb |
|
From: Nate B. <n0...@n0...> - 2025-04-05 21:11:30
|
Hi all. Over the past several days I've been looking over the issue tracker on GitHub and doing a little bit of triage that Mike was unable to get to. I know Mike had a vision of a future release timeline. It's not set in stone so I'm not suggesting that the project hold itself rigidly to it. For example, he envisioned 5.0 by late 2026. As I recall, bumping the major version is only necessary if the C ABI changes to such an extent that recompilation of client programs is necessary, so, for now, I don't foresee 5.0 being imminent. What I would like to do is ask that everyone take a look at the issue tracker: https://github.com/Hamlib/Hamlib/issues and look for something that you can help with. Some are getting to be quite old with the oldest at almost five years. Some require some testing with certain hardware to see if an issue still exists. It's impossible for anyone to have all of the hardware Hamlib supports so the project has always depended on help from those with hardware. To that end I would like to see the number of issues reduced by month's end, if possible. This leads to my plan for the next release. I would like to roll up the current master branch into a 4.6.3 release by the end of April. As all of the commits since 4.6.2 appear to be fixes and not new features, please limit Pull Requests (PRs) to fixes including closing issues. Upon release, 4.6.3 will be dedicated to the memory of Mike. After the next release, master will be open to new features and be planned as a 4.7.0 release. I've been a bit lax in adding the '.0' to the initial minor release in a series and I think that has resulted in some confusion over the years. Hopefully 4.7.0 can be released in a few months. At one time I proposed to have a release cadence of late winter and late summer to stay ahead of the Ubuntu release cycle. I'm not sure if this is still a reasonable release strategy as I'm unsure if Ubuntu is still the amateur radio favorite it once was. It's likely best that we make releases when it is the best timing for this project, i.e. when it's ready. Thoughts? 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...> - 2025-04-03 13:12:22
|
Hi all. A recent message was held by Mailman for having an attachment too large for the list. Unfortunately, while I received a notice to approve the message, Mailman, apparently helpfully, lost it. 🤬 As a result I have raised the limit considerably but I ask that attachments be limited to 500k or less as it's likely we have list members on slow links. Oft times a screenshot is better than several paragraphs and are welcome. 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: Adrian <vk...@gm...> - 2025-04-03 09:53:01
|
I added a question on rigctld comp meter for the FTDX101 as well, which
does not appear covered.
The get level COMP just provided the proc setting and not the COMP meter.
In the end I used
msg.payload = "W RM3;\n";
with a string node and range node to get a COMP meter output on ssb TX
Everything above works via a rigctld server on windows.
73
vk4tux
On 3/4/25 19:30, Nate Bargmann wrote:
> This dropped into my administrator queue on Tuesday but Mailman never
> gave me a message to approve.
>
> 73, Nate
>
> ----- Forwarded message fro...@li... -----
>
> Date: Tue, 1 Apr 2025 14:58:15 +1000
> From: Adrian<vk...@gm...>
> To: Stephen Pattinson<st...@bi...>, Dave Baxter
> <g8k...@go...>,n0...@n0..., Erik Icket<run...@gm...>
> Cc:ham...@li...
> Subject: Re: [Hamlib-developer] Python API
> User-Agent: Mozilla Thunderbird
>
> Just to add, node-red works well <> with hamlib, and it is how
>
> I access my windows FTDX101MP serial connected rigctld bat process from the
> lan with node-red running on Debian ;
>
> Then other flows like the SPE amp flow can be linked in/out to auto control
> drive power, and temperature protection.
>
> In node-red settings.js
>
> **/
> process.env.RIGADDRESS = '192.168.0.2'
> process.env.RIGPORT = '4532'
> process.env.RIGADDRESS1 = '192.168.0.32'
> process.env.RIGPORT1 = '4532'
> module.exports = {
>
>
> Covers two rigs I have connected using hamlib rigctld. The other is lan
> connected to macos running rigctld connected to a FT-747GX.
>
> 73
>
>
> vk4tux
>
>
> On 1/4/25 14:36, Stephen Pattinson wrote:
>> Hi Dave, Erik, Adrian & Nate,
>>
>> Thanks for your help guys. I now have my Python app talking to rigctld via
>> TCP and getting frequency, mode and tx status, which as was pointed out is
>> probably the preferred way to go. Of course, I could just use rigctl if
>> all I wanted to do was send the odd command to the radio, but the main
>> purpose was to have rigctld running so I could get multiple processes to
>> talk to my radio.
>>
>> Dave, your code snippet was most helpful - thanks.
>> Eric, I am starting rigctld from Popen(). The whole idea was to develop a
>> little app to start and stop rigctld in a window (tkinter) without having
>> to resorts to the command line.
>>
>> It does expose another issue however in that I seem to have a reliability
>> problem with the IC7300 USB interface which results in the rigctld daemon
>> getting into a state where it doesn't respond and using up 25% of the PCs
>> CPU. I don't have physical access to the system at present, so I'll wait
>> till I do and maybe ask another question.
>>
>> Anyway - thanks guys.
>> 73 Steve
>>
>> PS Sad news about W9MDB - I was very sorry to hear that.
>>
>>
> ----- End forwarded message -----
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Nate B. <n0...@n0...> - 2025-04-03 09:31:11
|
This dropped into my administrator queue on Tuesday but Mailman never
gave me a message to approve.
73, Nate
----- Forwarded message from ham...@li... -----
Date: Tue, 1 Apr 2025 14:58:15 +1000
From: Adrian <vk...@gm...>
To: Stephen Pattinson <st...@bi...>, Dave Baxter
<g8k...@go...>, n0...@n0..., Erik Icket <run...@gm...>
Cc: ham...@li...
Subject: Re: [Hamlib-developer] Python API
User-Agent: Mozilla Thunderbird
Just to add, node-red works well <> with hamlib, and it is how
I access my windows FTDX101MP serial connected rigctld bat process from the
lan with node-red running on Debian ;
Then other flows like the SPE amp flow can be linked in/out to auto control
drive power, and temperature protection.
In node-red settings.js
**/
process.env.RIGADDRESS = '192.168.0.2'
process.env.RIGPORT = '4532'
process.env.RIGADDRESS1 = '192.168.0.32'
process.env.RIGPORT1 = '4532'
module.exports = {
Covers two rigs I have connected using hamlib rigctld. The other is lan
connected to macos running rigctld connected to a FT-747GX.
73
vk4tux
On 1/4/25 14:36, Stephen Pattinson wrote:
> Hi Dave, Erik, Adrian & Nate,
>
> Thanks for your help guys. I now have my Python app talking to rigctld via
> TCP and getting frequency, mode and tx status, which as was pointed out is
> probably the preferred way to go. Of course, I could just use rigctl if
> all I wanted to do was send the odd command to the radio, but the main
> purpose was to have rigctld running so I could get multiple processes to
> talk to my radio.
>
> Dave, your code snippet was most helpful - thanks.
> Eric, I am starting rigctld from Popen(). The whole idea was to develop a
> little app to start and stop rigctld in a window (tkinter) without having
> to resorts to the command line.
>
> It does expose another issue however in that I seem to have a reliability
> problem with the IC7300 USB interface which results in the rigctld daemon
> getting into a state where it doesn't respond and using up 25% of the PCs
> CPU. I don't have physical access to the system at present, so I'll wait
> till I do and maybe ask another question.
>
> Anyway - thanks guys.
> 73 Steve
>
> PS Sad news about W9MDB - I was very sorry to hear that.
>
>
----- End forwarded message -----
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
|
|
From: Adrian <vk...@gm...> - 2025-04-02 05:37:23
|
On further reading I realized I needed RM3; so with W RM3; I get intermittent results "RM3000000;" 4/2/2025, 3:33:02 PMnode: debug 65 <http://192.168.0.3:1880/#>msg.payload : string[7] //"RPRT 0↵" 4/2/2025, 3:33:06 PMnode: debug 65 <http://192.168.0.3:1880/#>msg.payload : string[11] "RM3163000;" 4/2/2025, 3:33:06 PMnode: debug 65 <http://192.168.0.3:1880/#>msg.payload : string[7] //"RPRT 0↵" 4/2/2025, 3:33:08 PMnode: debug 65 <http://192.168.0.3:1880/#>msg.payload : string[11] "RM5030000;" 4/2/2025, 3:33:08 PMnode: debug 65 <http://192.168.0.3:1880/#>msg.payload : string[7] //"RPRT 0↵" 4/2/2025, 3:33:10 PMnode: debug 65 <http://192.168.0.3:1880/#>msg.payload : string[11] "RM3000000;" Would be great if it could be passed to a hamlib cmd for a numeral result. Can filter above with node-red for now. 73 vk4tux On 2/4/25 14:55, Adrian wrote: > > Using > > msg.payload = "l COMP\n"; > > I am getting a return that appears to match the set proc level/100, > rather than the level matching and/or tracking the comp meter , as > show below when I adjust proc 76 to 74. > > 4/2/2025, 2:51:50 PMnode: debug 65 > <http://192.168.0.3:1880/#>msg.payload : string[5] > "0.76↵" > 4/2/2025, 2:51:51 PMnode: debug 65 > <http://192.168.0.3:1880/#>msg.payload : string[5] > "0.75↵" > 4/2/2025, 2:51:52 PMnode: debug 65 > <http://192.168.0.3:1880/#>msg.payload : string[5] > "0.75↵" > 4/2/2025, 2:51:53 PMnode: debug 65 > <http://192.168.0.3:1880/#>msg.payload : string[5] > "0.74↵" > 4/2/2025, 2:51:54 PMnode: debug 65 > <http://192.168.0.3:1880/#>msg.payload : string[5] > "0.74↵" > 4/2/2025, 2:51:55 PMnode: debug 65 > <http://192.168.0.3:1880/#>msg.payload : string[5] > "0.74↵" Is there a rigctld method to read the comp meter ? Using W PL; > is not working for me. ? Thankyou 73 vk4tux |
33 messages has been excluded from this view by a project administrator.
