Thread: [Hamlib-developer] Old issues in the GitHub issue tracker
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: Nate B. <n0...@n0...> - 2025-07-30 21:32:58
Attachments:
signature.asc
|
Like most I likely just look at no more than the first couple of pages of the GitHub issue tracker. As the number is at 195 open issues, it becomes a chore to start wading deeper into the pool and it becomes easy to decide to do something else. On the Issue page one can select the order shown to be oldest first and I've been looking at some of those and have closed a couple. The oldest issues are just over five years old and in many cases the project has resolved these issues but no followup was done because it may have been forgotten that an issue had been opened months or years before. In other cases, Mike opened a number of issues with enhancement ideas. Some of these seem more doable than others but to the person with the right motivation, they would be a useful challenge and addition. I'm hesitant to close these no matter how old they get unless there is sufficient feedback along the lines of, "No, this doesn't fit within the scope of Hamlib." Fortunately, for the issues that are labeled, filters can be applied to limit the list. To make this work, it's likely that I need to assure there are relevant labels applied to each issue. I can also add a "Type" that is currently limited to four--None, Feature, Bug, and Task. This will produce a more general list that could be narrowed with the filter. Also, I can add multiple labels to an issue but only one type. I'll start working my way through the list adding types and labels. Nearly all of the issues will be assigned a type of either Feature or Bug, then labels can give an indication of what it entails. Once complete, anything with the Bug type should be looked at and fixed or closed. 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-07-30 21:56:29
Attachments:
signature.asc
|
This will be the first of a number of followups in this thread where I will request comments on a specific issue. First up is issue 498 that concerns replacing the ITU frequency ranges with more generic frequency ranges in the backends: https://github.com/Hamlib/Hamlib/issues/498 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-07-30 22:00:57
Attachments:
signature.asc
|
https://github.com/Hamlib/Hamlib/issues/661 The rig model USRP0 & USRP should be removed, as well as any GNURADIO code. The actual code is using a deprecated library (libusrp), and is a maintenance burden for no use (e.g. #355). The extra/gnuradio is not maintained anymore, and such features are generally implemented in a separate SDR application. Should USRP support be wanted, it's better to rewrite support for UHD[1] which is more versatile anyway. -------------- 73, Nate [1] https://github.com/EttusResearch/uhd -- "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-07-30 22:11:34
Attachments:
signature.asc
|
https://github.com/Hamlib/Hamlib/issues/674 Improve simicom to emulate all Icom rigs by command line options. satmode, 0x25/0x26 command, Also get it working on Windows. --------------- This is one of those that may have fallen through the cracks insofar as getting updated/closed. It's possible that these commands are working. Or not. 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-07-30 22:25:06
|
I think this one was directed more towards making a generic Iom simulator where you could pick-and-choose which features were present in any Icom rig. I think this might be what simicgeneric.c was supposed to be. I did a little of this when I was hacking on simic705.c about a month ago, but didn't follow through. This might go in the "interesting projects" category. On 7/30/25 6:11 PM, Nate Bargmann wrote: > https://github.com/Hamlib/Hamlib/issues/674 > > Improve simicom to emulate all Icom rigs by command line options. > satmode, 0x25/0x26 command, > Also get it working on Windows. > > --------------- > > This is one of those that may have fallen through the cracks insofar as > getting updated/closed. It's possible that these commands are working. > Or not. > > 73, Nate > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Nate B. <n0...@n0...> - 2025-07-30 22:28:15
Attachments:
signature.asc
|
* On 2025 30 Jul 17:26 -0500, George Baltz wrote: > I think this one was directed more towards making a generic Iom simulator > where you could pick-and-choose which features were present in any Icom > rig. I think this might be what simicgeneric.c was supposed to be. > > I did a little of this when I was hacking on simic705.c about a month ago, > but didn't follow through. > > This might go in the "interesting projects" category. Another label type! Rushes off... 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-07-30 22:55:15
Attachments:
signature.asc
|
https://github.com/Hamlib/Hamlib/issues/807 Requires adding a linked list and inserting the rig ptr during open and removing it during close. Replaces #785[1] --------- 73, Nate [1] https://github.com/Hamlib/Hamlib/issues/785 -- "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-07-30 23:05:25
|
I think the first half of this is done - rig_open() builds a list of opened rig_structs, but nobody checks it on each rig_*() call. Overhead problem? On 7/30/25 6:55 PM, Nate Bargmann wrote: > https://github.com/Hamlib/Hamlib/issues/807 > > Requires adding a linked list and inserting the rig ptr during open and > removing it during close. > > Replaces #785[1] > > --------- > > 73, Nate > > [1] https://github.com/Hamlib/Hamlib/issues/785 > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Daniele F. <iu...@gm...> - 2025-08-21 11:29:09
|
George Baltz wrote:
> I think the first half of this is done - rig_open() builds a list of
> opened rig_structs, but nobody checks it on each rig_*() call. Overhead
> problem?
maby, but there is already some overhead because many (all?) functions
use the macro
#define CHECK_RIG_ARG(r) (!(r) || !(r)->caps || !STATE((r))->comm_state)
in some cases the last macro check is equivalent to checking if the
rig is in the list because rig_close() calls remove_opened_rig(rig);
and sets rs->comm_state = 0;
So comm_state is certainly zero when the struct is not in the list (it
may be zero even when the rig is in the list but it is a different
case).
rig_close is like this:
int HAMLIB_API rig_close(RIG *rig)
{
[...]
if (!rs->comm_state)
{
RETURNFUNC(-RIG_EINVAL);
}
remove_opened_rig(rig);
[...]
rs->comm_state = 0;
[...]
}
However issue #785 talked about memory corruption (so that even
comm_state may appear non-zero when the rig is no more in the list and
what I have written above doesn't hold).
I'm not sure if this issue #807 still covers the memory corruption,
but I don't think that protecting against this kind of memory
corruption is worth our time when there are many fixed length buffers
and suspicious uses of sprintf-like functions.
This list of open rigs could be useful if rigctld gets the ability to
handle more than one rig at a time, but it would add extra complexity
to clients, that in some cases can be avoided running more copies of
rigctld on different ports.
If everybody agrees that it is a rare case not worth protecting
against, that memory corruption affects only a rig pointer and not
other important data or the stack, can we close this?
--
73 de IU5HKX Daniele
|
|
From: Nate B. <n0...@n0...> - 2025-07-30 23:52:02
Attachments:
signature.asc
|
https://github.com/Hamlib/Hamlib/issues/1018 Concept is: ./configure --with-yaesu --with-icom Which would build the main parts required by all and only radio types in the yaesu and icom radio classes. Hamlib takes an eternity to build (particularly on an SOC) and most users have one or two brands of radios and don't need all the rest. Also, consider --with-rotator, --with-antenna for those who need them, and then the rest of us can avoid the 'noid. I don't expect any feedback. I figure if you find the idea worth doing, you'll just do it. ;) --------- My opinion is that with 40 radio backends at present that this might exceed the command line limit on some OS. I can appreciate the idea and especially the long compile time on an SOC, but most will use a distribution's precompiled package (Linux). The gain seems minimal for the pain. 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-07-31 00:56:10
|
I might consider it, but not any time soon. I only have 1 radio (plus the dummys) so it might be worth it since I seem to do a lot of compiles :-( Maybe a "sorta interesting project" On 7/30/25 7:51 PM, Nate Bargmann wrote: > https://github.com/Hamlib/Hamlib/issues/1018 > > Concept is: > > ./configure --with-yaesu --with-icom > > Which would build the main parts required by all and only radio types in > the yaesu and icom radio classes. > > Hamlib takes an eternity to build (particularly on an SOC) and most > users have one or two brands of radios and don't need all the rest. > > Also, consider --with-rotator, --with-antenna for those who need them, > and then the rest of us can avoid the 'noid. > > I don't expect any feedback. I figure if you find the idea worth doing, > you'll just do it. ;) > > --------- > > My opinion is that with 40 radio backends at present that this might > exceed the command line limit on some OS. I can appreciate the idea and > especially the long compile time on an SOC, but most will use a > distribution's precompiled package (Linux). The gain seems minimal for > the pain. > > 73, Nate > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Daniele F. <iu...@gm...> - 2025-08-21 11:49:20
|
I agree that it would be nice to compile only what is needed, however ordinary users should prefer using packages from distributions, while I argue that experimenters that want to use SOCs should cross-compile. For the time needed to compile, on my 13 years old PC it takes less than 1 minute to compile the library only (make -j12 src), it takes me much longer to write this email :-( An "interesting project" if I can somehow pass just the model number(s) and have compiled only those, otherwise choosing what to compile risks to become similar to Linux kbuild (nice the first time, then a pain): there are 36 brands of rigs, 26 of rotators and 3 of amplifiers, 317 rigs, 57 rotators, 5 amplifiers. -- 73 de IU5HKX Daniele |
|
From: Nate B. <n0...@n0...> - 2025-07-31 01:01:38
Attachments:
signature.asc
|
https://github.com/Hamlib/Hamlib/issues/1019 It's only used in two rigs and has been replaced by individual meter calls find . -name "*.c" -exec grep RIG_METER {} \; -print case RIG_METER_SWR: case RIG_METER_COMP: case RIG_METER_ALC: val->i = RIG_METER_SWR; val->i = RIG_METER_COMP; val->i = RIG_METER_ALC; val->i = RIG_METER_NONE; ./rigs/kenwood/ts480.c case '1': val->i = RIG_METER_ALC; break; case '2': val->i = RIG_METER_SWR; break; case '3': val->i = RIG_METER_COMP; break; case '4': val->i = RIG_METER_IC; break; case '5': val->i = RIG_METER_VDD; break; default: val->i = RIG_METER_NONE; break; ./rigs/kenwood/ts990s.c case RIG_METER_ALC: SNPRINTF(priv->cmd_str, sizeof(priv->cmd_str), format, 1); case RIG_METER_PO: case RIG_METER_SWR: SNPRINTF(priv->cmd_str, sizeof(priv->cmd_str), format, 3); case RIG_METER_COMP: SNPRINTF(priv->cmd_str, sizeof(priv->cmd_str), format, 0); case RIG_METER_IC: SNPRINTF(priv->cmd_str, sizeof(priv->cmd_str), format, 4); case RIG_METER_VDD: SNPRINTF(priv->cmd_str, sizeof(priv->cmd_str), format, 5); if (tuner && meter.i != RIG_METER_SWR) && meter.i == RIG_METER_SWR) ? '2' : '6', case '0': val->i = RIG_METER_COMP; break; case '1': val->i = RIG_METER_ALC; break; case '2': val->i = RIG_METER_PO; break; case '3': val->i = RIG_METER_SWR; break; case '4': val->i = RIG_METER_IC; break; /* ID CURRENT */ case '5': val->i = RIG_METER_VDD; break; /* Final Amp Voltage */ ./rigs/yaesu/newcat.c ----------------- Turns out Mike truncated the output from newcat.c so it's likely that more radio backends depend on this enumeration. Also not shown is that the ts2000.c file contains these values as well. If the enum values can be replaced by better functions, then that should be the path to take. 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-07-31 02:47:27
Attachments:
signature.asc
|
https://github.com/Hamlib/Hamlib/issues/1353 Implement PARM_BAND_SELECT for Icom and Kenwood rigs 0x1a 0x01 for Icom rigs (7300). ---------- Mike included three commits that referenced this issue: Add parm BANDSELECT for Yaesu rigs  ... d7d450d Fill out BANDSELECT frequency table  ... 1f50b88 Add BANDSELECT to PowerSDR  ... fb3d83a ---------- I'm not sure if this is complete. 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-07-31 15:03:30
|
This seems to vary by manufacturer - many references in rigs/yaesu/, a few in rigs/icom/, only flex6xxx in rigs/kenwood/ and nothing else. Still more work to do. On 7/30/25 10:47 PM, Nate Bargmann wrote: > https://github.com/Hamlib/Hamlib/issues/1353 > > Implement PARM_BAND_SELECT for Icom and Kenwood rigs > > 0x1a 0x01 for Icom rigs (7300). > > ---------- > > Mike included three commits that referenced this issue: > > Add parm BANDSELECT for Yaesu rigs  ... d7d450d > Fill out BANDSELECT frequency table  ... 1f50b88 > Add BANDSELECT to PowerSDR  ... fb3d83a > > ---------- > > I'm not sure if this is complete. > > 73, Nate > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Nate B. <n0...@n0...> - 2025-07-31 23:36:45
Attachments:
signature.asc
|
https://github.com/Hamlib/Hamlib/issues/1588 Icom echo is now dynamically detected in frame.c We can remove the echo off testing elsewhere ------------- I've no idea what Mike was talking about here. 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-08-01 01:42:16
Attachments:
signature.asc
|
I've completed wading through the list and adding the "type" flag to all open issues. Along the way I was able to pare the list down to 174. Still about 150 more than I would like to see, but, oh well. The biggest group by far is the Feature type at 122 while the Bug type are at 49. I placed the Release Goals issues into the Tasks category. I presume that bug hunters can more easily get a list of bugs to work on and those looking for a challenge can investigate the Features category. Mike opened enough issues that are an enhancement to keep us busy for years to come. Some are clearly wishlist items while others should be considered seriously. A few of the ones he gave the label "Enhancement" I classified as a Bug as it seemed to me they fall more into that category although it would be new code. Anyway, I hope this effort proves fruitful. 🤔 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 |
Thanks for helping keep SourceForge clean.
X