hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] Strange problem with response from IC-7300

[Sakari N. <sak...@ni...>]

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

[Hamlib-developer] Strange problem with response from IC-7300

[Stephen P. <st...@bi...>]

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] [Hamlib/Hamlib] 0b68dc: Also check the "name" parameter

[dforsi <no...@gi...>]

  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

[Hamlib-developer] Moving rig_cache out of rig_state into private storage

[George B. <geo...@gm...>]

A large portion of the code I have added to Hamlib over the past year+ 
has been to enable moving some fixed structures out of rig_struct into 
somewhat more flexible calloc'ed structures.  Now I've gotten back to 
implementing those, starting with rig_cache(Issue #1420).  After 
thinking about it quite a while, I'd like to do this a bit differently.

I think the rig_cache structure should be completely internal to Hamlib, 
and not visible to the calling application.  Deprecating the definitions 
in rig.h and adding the new declaration to src/cache.h allows us 
complete freedom to modify/enhance/rework the caching operations without 
worrying about outside effects.

Also -

  * This is much closer to current programming techniques.  Data and
    implementation details should be hidden from the outside world, and
    only the API (external interface) should be seen. Even within Hamlib
    the cache won't be visible without '#include "cache.h"'.
  * Reduces the possibility of the app/library mis-match in definitions
    or allocations.
  * In the event of major changes, removes the need for extra
    programming to satisfy older data accesses.
  * And the big technical impact - if Hamlib ever going to handle rigs
    that send unsolicited data (Auto Information in Kenwood speak), then
    the whole notion of cache needs to change - STATE(rig) should always
    be up to date, commands sent to the rig should be confirmed
    automatically, and cache timeouts should no longer be a factor. 
    There may not even be a rig_cache buffer in that case.

I have been running a version of these changes for about a week now, 
using CQRLOG and WSJT-X-improved with no ill effects; I hope there's no 
big use of this data elsewhere. If so, I can add something to freshen up 
the deprecated space in rig_struct, but I reallllllllly hope we can put 
that practice behind us.

Comments and opinions please (to the list).

-- 

73 n3gb

Re: [Hamlib-developer] Question about a native hamlib protocol?

[Nate B. <n0...@n0...>]

* On 2025 10 May 20:46 -0500, William Gaylord wrote:
> I am working on a project that I hope to add rigctl support to. (As in
> buidling a homebrew radio) Is there a 'native' / generic rigctl protocol
> that I van implement as its cat interface or should I just pretent to be an
> existing radio?

In the past the Kenwood protocol has been recommended.  It is well
understood and well supported by both Hamlib and other software.  In my
opinion, that doesn't mean you should limit yourself to a particular
Kenwood model as a custom backend could easily support your radio.  The
benefit of the Kenwood protocol is that it is human readable as it is
ASCII on the wire which makes things a bit easier.  Even Yaesu switched
from its proprietary binary protocol to the Kenwood style around the
turn of the Century.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[Hamlib-developer] Question about a native hamlib protocol?

[William G. <wga...@jw...>]

I am working on a project that I hope to add rigctl support to. (As in
buidling a homebrew radio) Is there a 'native' / generic rigctl protocol
that I van implement as its cat interface or should I just pretent to be an
existing radio?

KD9KCK

[Hamlib-developer] [Hamlib/Hamlib] 49b0be: Update the directory tree

[dforsi <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 49b0be5be2cb40e565da74a8ba7a393747d48cb4
      https://github.com/Hamlib/Hamlib/commit/49b0be5be2cb40e565da74a8ba7a393747d48cb4
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M README.developer

  Log Message:
  -----------
  Update the directory tree


  Commit: 7a466c779ac1bbe0427429670899f82e6c63787f
      https://github.com/Hamlib/Hamlib/commit/7a466c779ac1bbe0427429670899f82e6c63787f
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M README.developer

  Log Message:
  -----------
  Remove old version numbers


  Commit: 6f789b60ecdd19a4ebd6f1a5e17805c665d51073
      https://github.com/Hamlib/Hamlib/commit/6f789b60ecdd19a4ebd6f1a5e17805c665d51073
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M README.developer

  Log Message:
  -----------
  Update copyright year


  Commit: fb8abe93bb3805127d457be3c11d1e6d87789f1e
      https://github.com/Hamlib/Hamlib/commit/fb8abe93bb3805127d457be3c11d1e6d87789f1e
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M README.developer

  Log Message:
  -----------
  List more optional dependencies


  Commit: f4b95826d490bd033c7fb87e849c0edc428775d2
      https://github.com/Hamlib/Hamlib/commit/f4b95826d490bd033c7fb87e849c0edc428775d2
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M README.developer

  Log Message:
  -----------
  Explain how to use the simulators


  Commit: 584ddb001d5ba15bb3047a566adbd242fa4710ff
      https://github.com/Hamlib/Hamlib/commit/584ddb001d5ba15bb3047a566adbd242fa4710ff
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M simulators/simid5100.c

  Log Message:
  -----------
  Fix compilation error in simid5100.c

Fixes:
simid5100.c:90:35: error: ‘errno’ undeclared (first use in this function)


  Commit: e5d8dc0f07bd0de56b87430811f549e3f2e2a1f1
      https://github.com/Hamlib/Hamlib/commit/e5d8dc0f07bd0de56b87430811f549e3f2e2a1f1
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M simulators/simicr8600.c

  Log Message:
  -----------
  Fix compilation error in simicr8600.c

Fixes:
simicr8600.c:445:5: warning: ‘main’ is normally a non-static function [-Wmain]


  Commit: 6dfa118dace16c3fff039d071ca87a4210c91793
      https://github.com/Hamlib/Hamlib/commit/6dfa118dace16c3fff039d071ca87a4210c91793
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M README.developer

  Log Message:
  -----------
  Describe the use of simulators


Compare: https://github.com/Hamlib/Hamlib/compare/12cc40f4f77c...6dfa118dace1

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

Re: [Hamlib-developer] 4.6.3 and 4.7.0 releases plan

[Nate B. <n0...@n0...>]

* On 2025 03 May 13:19 -0500, Daniele Forsi wrote:
> Hello,
> 
> I'm also ok with a 4.6.3 now. I have 3 PRs in draft which are more
> suitable for 4.7 or later because they involve changes in the builds.

Ack.

> > Yes, I plan to create a 4.6.3 branch off master.  In the future I hope
> > to get back to having a branch such as "4.7"
> 
> creating a stable branch makes it easier for contributors to send pull
> requests to fix small bugs, being small, they are probably easy to
> cherry-pick in the development branch.

Agreed.  Cherry-picking can work the other way as well so long as the
file in master hasn't diverged too much from stable.  In that case a new
commit is likely needed.

> > This is probably an area that could be improved so I'm open to ideas on
> > how best to have PRs integrate into an existing stable branch and the
> > master development branch.
> 
> one possible workflow is to accept in the stable branch only fixes
> that improve stability (eg. parameter checking or error handling);
> changes to the documentation could also go in stable if they improve
> the life of downstream maintainers or users; changes related to
> firmwares probably need a decision on a case by case basis.

Agreed.  That has always been my intent.  The last few releases have
been somewhat chaotic and it didn't work, or rather it was too much
work, to work through what seemed to be a series of commits that
happened each time a file was saved and then a series of corrections and
such.  Better, IMO, is to edit, save, test, and then when mostly
satisfied commit.  Or, if the workflow of an editor demands a commit
each time a file is saved, then rebase to make a single or a couple of
commits.  As Seve, AI4QR, once quipped, "Rebase allows me to look like I
know what I'm doing," or something close to that!  Over time I came to
really appreciate that comment.

> What would be the name of the development branch? I have a slight
> preference for a fixed name such as devel or next (o something else)
> versus a numbered name, because it can create ambiguity until it's
> released (eg. if we had Hamlib-4.6.23 and Hamlib-4.7 it wouldn't be
> clear if 4.7 is stable or not)

The development branch has always been "master".  Admittedly, this got a
bit clouded over the past several months, at least since the 4.6
release.  The version string in 'configure.ac' is an indicator of the
next milestone target.  For example, it will remain "4.7~git" for a
while, at least until 4.7.0 is released and then it could advance to
"4.8~git" or "5.0~git" depending on the plan for incompatible C ABI
changes, i.e. if the ABI is not backward compatible then the major
number should be advanced, but the version string in master will always
have '~git' appended as in indicator that it is from the development
branch.

After the 4.6.3 branch is created, I will merge more substantial changes
into master such as new device families or new device models and some
other things that others have expressed an interest in contributing.
Some of these decisions as to what will be ported to a stable branch
will remain ad hoc to retain some level of flexibility.

Hope that helps.

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

Re: [Hamlib-developer] 4.6.3 and 4.7.0 releases plan

[Daniele F. <iu...@gm...>]

Hello,

I'm also ok with a 4.6.3 now. I have 3 PRs in draft which are more
suitable for 4.7 or later because they involve changes in the builds.

> Yes, I plan to create a 4.6.3 branch off master.  In the future I hope
> to get back to having a branch such as "4.7"

creating a stable branch makes it easier for contributors to send pull
requests to fix small bugs, being small, they are probably easy to
cherry-pick in the development branch.

> This is probably an area that could be improved so I'm open to ideas on
> how best to have PRs integrate into an existing stable branch and the
> master development branch.

one possible workflow is to accept in the stable branch only fixes
that improve stability (eg. parameter checking or error handling);
changes to the documentation could also go in stable if they improve
the life of downstream maintainers or users; changes related to
firmwares probably need a decision on a case by case basis.

What would be the name of the development branch? I have a slight
preference for a fixed name such as devel or next (o something else)
versus a numbered name, because it can create ambiguity until it's
released (eg. if we had Hamlib-4.6.23 and Hamlib-4.7 it wouldn't be
clear if 4.7 is stable or not)

-- 
73 de IU5HKX Daniele

Re: [Hamlib-developer] 4.6.3 and 4.7.0 releases plan

[Nate B. <n0...@n0...>]

* On 2025 03 May 12:17 -0500, George Baltz wrote:
> I'm OK with that.  Will you keep a 4.6.x branch for anything urgent, or just
> a 4.7(master) ?

Yes, I plan to create a 4.6.3 branch off master.  In the future I hope
to get back to having a branch such as "4.7" and release 4.7.0, 4.7.1, etc
from it by applying fixes either with pull requests that directly
reference that branch or doing cherry-picks as needed.

This is probably an area that could be improved so I'm open to ideas on
how best to have PRs integrate into an existing stable branch and the
master development branch.

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

Re: [Hamlib-developer] 4.6.3 and 4.7.0 releases plan

[George B. <geo...@gm...>]

I'm OK with that.  Will you keep a 4.6.x branch for anything urgent, or 
just a 4.7(master) ?


On 5/3/25 11:56 AM, Nate Bargmann wrote:
> Quite a few fixes have been applied over the past couple of weeks, so,
> are there any objections to my releasing 4.6.3 from the current master
> or does anyone have a work in progress that I should wait a bit longer?
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] 4.6.3 and 4.7.0 releases plan

[Nate B. <n0...@n0...>]

Quite a few fixes have been applied over the past couple of weeks, so,
are there any objections to my releasing 4.6.3 from the current master
or does anyone have a work in progress that I should wait a bit longer?

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[Hamlib-developer] [Hamlib/Hamlib] 12cc40: Fix IC-705 filter selection and bandwidth handling...

[Kenji R. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 12cc40f4f77c5dea54d03b39c8657e8a6038a05f
      https://github.com/Hamlib/Hamlib/commit/12cc40f4f77c5dea54d03b39c8657e8a6038a05f
  Author: Kenji Rikitake <ken...@ac...>
  Date:   2025-05-03 (Sat, 03 May 2025)

  Changed paths:
    M rigs/icom/frame.c
    M rigs/icom/ic7300.c
    M rigs/icom/icom.c

  Log Message:
  -----------
  Fix IC-705 filter selection and bandwidth handling for FM and WFM

* Enable `.fm_filters` in `IC705_priv_caps`
* `icom_get_mode_without_data()`: activate FM filter selection code if `RIG_IS_IC705`
* `icom2rig_mode()`: activate FM filter fixed width code if `RIG_IS_IC705`
* TODO: cases in WFM should be solved independently
* `icom2rig_mode()`: handle FM and WFM separately and correctly at least for IC-705, no changes for IC-7300 and IC-9700
* `icom_get_mode_without_data()`: add WFM to the code assuming that values from `icom2rig_mode()` is correct
* icom.c: A partial rollback for https://github.com/Hamlib/Hamlib/pull/1719/commits/a395b91be6bd19d760e57005ecb8079b15af9ede
* The workaround to use `icom_set_mode_without_data()` is not necessary
* The later experiments showed CI-V command 0x26 worked OK too for WFM
* Add WFM freq to ic705_caps.filters
* Fix icom_set_mode_x26() FM behavior

`icom_set_mode_x26()` did not pass the correct command value
for FM or PKTFM modes when width is set to
`RIG_PASSBAND_NORMAL` (i.e., 0 (zero)).
With this source code change,
the command value `buf[2]` is forcefully set to 1
when `RIG_PASSBAND_NORMAL` or `RIG_PASSBAND_NOCHANGE` are
passed to the parameter `width`.

This fix solves the bug for IC-705 with rigctl when
entering the command `M FM 0` after `M WFM 0` *did not*
change the mode properly to (narrow) FM.



To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

[Hamlib-developer] [Hamlib/Hamlib] d89397: Fix IC-705 COMP, VD, and ID meter calibration values

[Nate B. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: d893974b3d3fb26cfb46e3f85adaa1b0f9da9ac2
      https://github.com/Hamlib/Hamlib/commit/d893974b3d3fb26cfb46e3f85adaa1b0f9da9ac2
  Author: Kenji Rikitake <ken...@ac...>
  Date:   2025-05-02 (Fri, 02 May 2025)

  Changed paths:
    M rigs/icom/ic7300.c

  Log Message:
  -----------
  Fix IC-705 COMP, VD, and ID meter calibration values

* Define IC-705-specific values ported from flrig-2.0.05.93


  Commit: fa2520c894c91f23c1c7be58e7ee4566e1dc102c
      https://github.com/Hamlib/Hamlib/commit/fa2520c894c91f23c1c7be58e7ee4566e1dc102c
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-05-02 (Fri, 02 May 2025)

  Changed paths:
    M rigs/icom/ic7300.c

  Log Message:
  -----------
  Merge pull request #1723 from jj1bdx/jj1bdx-ic705-meters

Fix IC-705 COMP, VD, and ID meter calibration values


Compare: https://github.com/Hamlib/Hamlib/compare/fe3bb8b84a47...fa2520c894c9

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

Re: [Hamlib-developer] [Hamlib/Hamlib] c8838c: Avoid truncating AC Log frequencies above 1 GHz

[George B. <geo...@gm...>]

On 5/2/25 2:00 PM, Nate Bargmann wrote:
> * On 2025 02 May 12:41 -0500, George Baltz wrote:
>> Maybe I'm missing something, but did anybody ask the upstream why they were
>> adding human-oriented punctuation to a computer-to-computer communication?
>> Formatting should almost always be done at the final user interface, to
>> allow for locality based display.
> Mike, K7MDL, noted this in the initial report:
>
> "I first posted this to the WSJT-X dev list but this seems to be a more
> proper place to file the bug. Also spoke with N3FJP about maybe removing
> the comma on the AC Log side but that API is used with several apps and
> could result in breakage, making the change here is the safest."
>
> https://github.com/Hamlib/Hamlib/issues/1704
>
> Just another one of those decisions that becomes painful to fix later
> on.

You can say that again.  Aside from being flat-out wrong for a good 
portion of the world, it requires special processing on both ends of the 
connection, and sort of defeats the purpose of XML.


Sigh.

73 n3gb

> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] [Hamlib/Hamlib] c8838c: Avoid truncating AC Log frequencies above 1 GHz

[Nate B. <n0...@n0...>]

* On 2025 02 May 12:41 -0500, George Baltz wrote:
> Maybe I'm missing something, but did anybody ask the upstream why they were
> adding human-oriented punctuation to a computer-to-computer communication? 
> Formatting should almost always be done at the final user interface, to
> allow for locality based display.

Mike, K7MDL, noted this in the initial report:

"I first posted this to the WSJT-X dev list but this seems to be a more
proper place to file the bug. Also spoke with N3FJP about maybe removing
the comma on the AC Log side but that API is used with several apps and
could result in breakage, making the change here is the safest."

https://github.com/Hamlib/Hamlib/issues/1704

Just another one of those decisions that becomes painful to fix later
on.

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

Re: [Hamlib-developer] [Hamlib/Hamlib] c8838c: Avoid truncating AC Log frequencies above 1 GHz

[George B. <geo...@gm...>]

Maybe I'm missing something, but did anybody ask the upstream why they 
were adding human-oriented punctuation to a computer-to-computer 
communication?  Formatting should almost always be done at the final 
user interface, to allow for locality based display.


On 5/1/25 9:48 PM, Nate Bargmann via Hamlib-developer wrote:
>    Branch: refs/heads/master
>    Home:   https://github.com/Hamlib/Hamlib
>    Commit: c8838cd3a6f4ea57ccbde8cb646c5a4fbfd82a3e
>        https://github.com/Hamlib/Hamlib/commit/c8838cd3a6f4ea57ccbde8cb646c5a4fbfd82a3e
>    Author: Nate Bargmann <n0...@n0...>
>    Date:   2025-05-01 (Thu, 01 May 2025)
>
>    Changed paths:
>      M rigs/dummy/aclog.c
>
>    Log Message:
>    -----------
>    Avoid truncating AC Log frequencies above 1 GHz
>
> Per GitHub issue #1704, frequencies higher than 1 GHz passed from AC Log
> have an embedded comma.  Even though sscanf() offers the "'" (single
> quote) character as a means of ignoring thousands separator, apparently
> it depends on the environment variable LC_NUMERIC being set correctly
> and that may not be supported on all platforms.
>
> This patch just parses through the string while skipping any comma that
> may appear and then uses strtold() to convert to a numeric variable.  It
> is supected that AC Log always uses a comma as a thousands separator.
>
>
>    Commit: fe3bb8b84a47ec4e928e65fc5a9a104b89747162
>        https://github.com/Hamlib/Hamlib/commit/fe3bb8b84a47ec4e928e65fc5a9a104b89747162
>    Author: Nate Bargmann <n0...@n0...>
>    Date:   2025-05-01 (Thu, 01 May 2025)
>
>    Changed paths:
>      M rigs/dummy/aclog.c
>
>    Log Message:
>    -----------
>    Merge pull request #1722 from N0NB/aclog_get_freq-thousands_separator
>
> Avoid truncating AC Log frequencies above 1 GHz
>
>
> Compare: https://github.com/Hamlib/Hamlib/compare/12265fde9ad3...fe3bb8b84a47
>
> To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] [Hamlib/Hamlib] c8838c: Avoid truncating AC Log frequencies above 1 GHz

[Nate B. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: c8838cd3a6f4ea57ccbde8cb646c5a4fbfd82a3e
      https://github.com/Hamlib/Hamlib/commit/c8838cd3a6f4ea57ccbde8cb646c5a4fbfd82a3e
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-05-01 (Thu, 01 May 2025)

  Changed paths:
    M rigs/dummy/aclog.c

  Log Message:
  -----------
  Avoid truncating AC Log frequencies above 1 GHz

Per GitHub issue #1704, frequencies higher than 1 GHz passed from AC Log
have an embedded comma.  Even though sscanf() offers the "'" (single
quote) character as a means of ignoring thousands separator, apparently
it depends on the environment variable LC_NUMERIC being set correctly
and that may not be supported on all platforms.

This patch just parses through the string while skipping any comma that
may appear and then uses strtold() to convert to a numeric variable.  It
is supected that AC Log always uses a comma as a thousands separator.


  Commit: fe3bb8b84a47ec4e928e65fc5a9a104b89747162
      https://github.com/Hamlib/Hamlib/commit/fe3bb8b84a47ec4e928e65fc5a9a104b89747162
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-05-01 (Thu, 01 May 2025)

  Changed paths:
    M rigs/dummy/aclog.c

  Log Message:
  -----------
  Merge pull request #1722 from N0NB/aclog_get_freq-thousands_separator

Avoid truncating AC Log frequencies above 1 GHz


Compare: https://github.com/Hamlib/Hamlib/compare/12265fde9ad3...fe3bb8b84a47

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

[Hamlib-developer] [Hamlib/Hamlib] 5cf875: Update ax_lua.m4 macro file

[Nate B. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 5cf875582756aec6c4d5f97267a37374e05541f1
      https://github.com/Hamlib/Hamlib/commit/5cf875582756aec6c4d5f97267a37374e05541f1
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-05-01 (Thu, 01 May 2025)

  Changed paths:
    M configure.ac
    M macros/ax_lua.m4

  Log Message:
  -----------
  Update ax_lua.m4 macro file

Per GitHub issue #1712, the older macro file was causing bootstrap
issues on Fedora 42.


  Commit: 12265fde9ad35e36ebdf591f0d88421dd08e121c
      https://github.com/Hamlib/Hamlib/commit/12265fde9ad35e36ebdf591f0d88421dd08e121c
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-05-01 (Thu, 01 May 2025)

  Changed paths:
    M configure.ac
    M macros/ax_lua.m4

  Log Message:
  -----------
  Merge pull request #1720 from N0NB/lua_macro

Update ax_lua.m4 macro file


Compare: https://github.com/Hamlib/Hamlib/compare/7c5c71588881...12265fde9ad3

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

[Hamlib-developer] [Hamlib/Hamlib] a395b9: Add support of setting IC-705 WFM mode

[Nate B. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: a395b91be6bd19d760e57005ecb8079b15af9ede
      https://github.com/Hamlib/Hamlib/commit/a395b91be6bd19d760e57005ecb8079b15af9ede
  Author: Kenji Rikitake <ken...@ac...>
  Date:   2025-05-01 (Thu, 01 May 2025)

  Changed paths:
    M rigs/icom/ic7300.c
    M rigs/icom/icom.c

  Log Message:
  -----------
  Add support of setting IC-705 WFM mode

On IC-705, setting WFM mode via ICOM CI-V command 0x26 does not work.
This patch implements a workaround using CI-V command 0x06 instead
via icom_set_mode_without_data for IC-705 setting mode WFM.


  Commit: 7c5c71588881fe9c81eb9c0ce15544703208db44
      https://github.com/Hamlib/Hamlib/commit/7c5c71588881fe9c81eb9c0ce15544703208db44
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-05-01 (Thu, 01 May 2025)

  Changed paths:
    M rigs/icom/ic7300.c
    M rigs/icom/icom.c

  Log Message:
  -----------
  Merge pull request #1719 from jj1bdx/jj1bdx-ic705-wfm

Add support of setting IC-705 WFM mode


Compare: https://github.com/Hamlib/Hamlib/compare/edef6206f7e1...7c5c71588881

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

[Hamlib-developer] [Hamlib/Hamlib] 037c49: Fix name of function in error messages

[Nate B. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 037c4953ed1f7d3b31b2c09d48dbf9e79210b8b1
      https://github.com/Hamlib/Hamlib/commit/037c4953ed1f7d3b31b2c09d48dbf9e79210b8b1
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-04-30 (Wed, 30 Apr 2025)

  Changed paths:
    M simulators/simatd578.c
    M simulators/simeasycomm.c
    M simulators/simelecraft.c
    M simulators/simelecraftk4.c
    M simulators/simft1000.c
    M simulators/simft450.c
    M simulators/simft710.c
    M simulators/simft736.c
    M simulators/simft747gx.c
    M simulators/simft817.c
    M simulators/simft818.c
    M simulators/simft847.c
    M simulators/simft897.c
    M simulators/simft990.c
    M simulators/simft991.c
    M simulators/simftdx101.c
    M simulators/simftdx1200.c
    M simulators/simftdx3000.c
    M simulators/simftdx5000.c
    M simulators/simic2730.c
    M simulators/simic275.c
    M simulators/simic7000.c
    M simulators/simic705.c
    M simulators/simic7100.c
    M simulators/simic7200.c
    M simulators/simic7300.c
    M simulators/simic7600.c
    M simulators/simic7610.c
    M simulators/simic7700.c
    M simulators/simic7851.c
    M simulators/simic905.c
    M simulators/simic910.c
    M simulators/simic9100.c
    M simulators/simic9700.c
    M simulators/simicgeneric.c
    M simulators/simicr8600.c
    M simulators/simid5100.c
    M simulators/simjupiter.c
    M simulators/simkenwood.c
    M simulators/simmicom.c
    M simulators/simorion.c
    M simulators/simpmr171.c
    M simulators/simpowersdr.c
    M simulators/simqrplabs.c
    M simulators/simrotorez.c
    M simulators/simspid.c
    M simulators/simtmd700.c
    M simulators/simtmd710.c
    M simulators/simtrusdx.c
    M simulators/simts450.c
    M simulators/simts590.c
    M simulators/simts890.c
    M simulators/simts950.c
    M simulators/simts990.c
    M simulators/simxiegug90.c
    M simulators/simxiegux108g.c
    M simulators/simxiegux6100.c
    M simulators/simyaesu.c

  Log Message:
  -----------
  Fix name of function in  error messages

Fixed with:
perl -pe s/pstname/ptsname/ -i *.c


  Commit: 3448c735b064dccd2aea26d5b15c9a30d06a1650
      https://github.com/Hamlib/Hamlib/commit/3448c735b064dccd2aea26d5b15c9a30d06a1650
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-04-30 (Wed, 30 Apr 2025)

  Changed paths:
    M simulators/simatd578.c
    M simulators/simeasycomm.c
    M simulators/simelecraft.c
    M simulators/simelecraftk4.c
    M simulators/simft1000.c
    M simulators/simft450.c
    M simulators/simft710.c
    M simulators/simft736.c
    M simulators/simft747gx.c
    M simulators/simft817.c
    M simulators/simft818.c
    M simulators/simft847.c
    M simulators/simft897.c
    M simulators/simft990.c
    M simulators/simft991.c
    M simulators/simftdx101.c
    M simulators/simftdx1200.c
    M simulators/simftdx3000.c
    M simulators/simftdx5000.c
    M simulators/simic2730.c
    M simulators/simic275.c
    M simulators/simic7000.c
    M simulators/simic705.c
    M simulators/simic7100.c
    M simulators/simic7200.c
    M simulators/simic7300.c
    M simulators/simic7600.c
    M simulators/simic7610.c
    M simulators/simic7700.c
    M simulators/simic7851.c
    M simulators/simic905.c
    M simulators/simic910.c
    M simulators/simic9100.c
    M simulators/simic9700.c
    M simulators/simicgeneric.c
    M simulators/simicr8600.c
    M simulators/simid5100.c
    M simulators/simjupiter.c
    M simulators/simkenwood.c
    M simulators/simmicom.c
    M simulators/simorion.c
    M simulators/simpmr171.c
    M simulators/simpowersdr.c
    M simulators/simqrplabs.c
    M simulators/simrotorez.c
    M simulators/simspid.c
    M simulators/simtmd700.c
    M simulators/simtmd710.c
    M simulators/simtrusdx.c
    M simulators/simts450.c
    M simulators/simts590.c
    M simulators/simts890.c
    M simulators/simts950.c
    M simulators/simts990.c
    M simulators/simxiegug90.c
    M simulators/simxiegux108g.c
    M simulators/simxiegux6100.c
    M simulators/simyaesu.c

  Log Message:
  -----------
  Remove non-working compilation instructions from comments

Some instructions were a copy and paste error, some did not link
to Hamlib. Compile all simulators with: make -C simulators check
or compile a single simulator replacing "check" with the name of
the simulator.

Fixed with:
perl -pe 's,// gcc.*\n,,' -i *.c
perl -pe 's,// On mingw.*\n,,' -i *.c


  Commit: aeb827a2f1dab1d7a481e873890e8beee0ddb8ab
      https://github.com/Hamlib/Hamlib/commit/aeb827a2f1dab1d7a481e873890e8beee0ddb8ab
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-04-30 (Wed, 30 Apr 2025)

  Changed paths:
    M bindings/ignore.swg

  Log Message:
  -----------
  Remove duplicated line


  Commit: 24eafbd2a4affe66e6cef0af38343652a4a54f09
      https://github.com/Hamlib/Hamlib/commit/24eafbd2a4affe66e6cef0af38343652a4a54f09
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-04-30 (Wed, 30 Apr 2025)

  Changed paths:
    M src/rig.c

  Log Message:
  -----------
  Fix Doxygen comment

The description of hamlib_version was attached to hamlib_license
and hamlib_license was missing the description.


  Commit: 8feb174711bcc6756e46547837116499b80e2057
      https://github.com/Hamlib/Hamlib/commit/8feb174711bcc6756e46547837116499b80e2057
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-04-30 (Wed, 30 Apr 2025)

  Changed paths:
    M include/hamlib/rig.h
    M src/debug.c

  Log Message:
  -----------
  Fix typos


  Commit: 56b075ab452c92017a9a144c74dcebd5271c5fa3
      https://github.com/Hamlib/Hamlib/commit/56b075ab452c92017a9a144c74dcebd5271c5fa3
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-04-30 (Wed, 30 Apr 2025)

  Changed paths:
    M include/hamlib/rig.h

  Log Message:
  -----------
  Fix Doxygen comment

It is about the tpyedef, not the defines.


  Commit: c1788e2cf86edfad398ff6eb7e7e5389cc58cf66
      https://github.com/Hamlib/Hamlib/commit/c1788e2cf86edfad398ff6eb7e7e5389cc58cf66
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-04-30 (Wed, 30 Apr 2025)

  Changed paths:
    M src/misc.c

  Log Message:
  -----------
  Fix names of parameters in Doxygen comments


  Commit: bd5ed18bddbef070b893ed278c6e12d6706739f3
      https://github.com/Hamlib/Hamlib/commit/bd5ed18bddbef070b893ed278c6e12d6706739f3
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-04-30 (Wed, 30 Apr 2025)

  Changed paths:
    M include/hamlib/rig.h

  Log Message:
  -----------
  Add documentation for RIG_CONF_END

Fixes:
warning: explicit link request to 'RIG_CONF_END' could not be resolved


  Commit: dda30532b512e34d65308c03dd68205de09ba2b8
      https://github.com/Hamlib/Hamlib/commit/dda30532b512e34d65308c03dd68205de09ba2b8
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-04-30 (Wed, 30 Apr 2025)

  Changed paths:
    M include/hamlib/rig.h
    M src/extamp.c
    M src/rig.c
    M src/rot_ext.c

  Log Message:
  -----------
  Add cross references hash mark for Doxygen


  Commit: edef6206f7e11b74237e927939a5b1ea6ceecfdb
      https://github.com/Hamlib/Hamlib/commit/edef6206f7e11b74237e927939a5b1ea6ceecfdb
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-05-01 (Thu, 01 May 2025)

  Changed paths:
    M bindings/ignore.swg
    M include/hamlib/rig.h
    M simulators/simatd578.c
    M simulators/simeasycomm.c
    M simulators/simelecraft.c
    M simulators/simelecraftk4.c
    M simulators/simft1000.c
    M simulators/simft450.c
    M simulators/simft710.c
    M simulators/simft736.c
    M simulators/simft747gx.c
    M simulators/simft817.c
    M simulators/simft818.c
    M simulators/simft847.c
    M simulators/simft897.c
    M simulators/simft990.c
    M simulators/simft991.c
    M simulators/simftdx101.c
    M simulators/simftdx1200.c
    M simulators/simftdx3000.c
    M simulators/simftdx5000.c
    M simulators/simic2730.c
    M simulators/simic275.c
    M simulators/simic7000.c
    M simulators/simic705.c
    M simulators/simic7100.c
    M simulators/simic7200.c
    M simulators/simic7300.c
    M simulators/simic7600.c
    M simulators/simic7610.c
    M simulators/simic7700.c
    M simulators/simic7851.c
    M simulators/simic905.c
    M simulators/simic910.c
    M simulators/simic9100.c
    M simulators/simic9700.c
    M simulators/simicgeneric.c
    M simulators/simicr8600.c
    M simulators/simid5100.c
    M simulators/simjupiter.c
    M simulators/simkenwood.c
    M simulators/simmicom.c
    M simulators/simorion.c
    M simulators/simpmr171.c
    M simulators/simpowersdr.c
    M simulators/simqrplabs.c
    M simulators/simrotorez.c
    M simulators/simspid.c
    M simulators/simtmd700.c
    M simulators/simtmd710.c
    M simulators/simtrusdx.c
    M simulators/simts450.c
    M simulators/simts590.c
    M simulators/simts890.c
    M simulators/simts950.c
    M simulators/simts990.c
    M simulators/simxiegug90.c
    M simulators/simxiegux108g.c
    M simulators/simxiegux6100.c
    M simulators/simyaesu.c
    M src/debug.c
    M src/extamp.c
    M src/misc.c
    M src/rig.c
    M src/rot_ext.c

  Log Message:
  -----------
  Merge pull request #1718 from dforsi/fix/typos

Fix/typos


Compare: https://github.com/Hamlib/Hamlib/compare/d03cde33b053...edef6206f7e1

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

Re: [Hamlib-developer] 4.6.3 and 4.7.0 releases plan

[Nate B. <n0...@n0...>]

All three of those have now been closed/merged.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[Hamlib-developer] [Hamlib/Hamlib] 12c538: Remove duplicated cppcheck suppressions

[Nate B. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 12c538fc1424f8ae5e34d27852cf48e0e9f0a7eb
      https://github.com/Hamlib/Hamlib/commit/12c538fc1424f8ae5e34d27852cf48e0e9f0a7eb
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-04-22 (Tue, 22 Apr 2025)

  Changed paths:
    M cppcheck.sh

  Log Message:
  -----------
  Remove duplicated cppcheck suppressions

Fixes:
cppcheck: error: suppression '*:extra/gnuradio/wfm.h' already exists
cppcheck: error: suppression '*:extra/gnuradio/HrAGC.h' already exists


  Commit: d03cde33b05367231b69309064edae9aef402f5a
      https://github.com/Hamlib/Hamlib/commit/d03cde33b05367231b69309064edae9aef402f5a
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-04-27 (Sun, 27 Apr 2025)

  Changed paths:
    M cppcheck.sh

  Log Message:
  -----------
  Merge pull request #1714 from dforsi/fix/cppcheck

Remove duplicated cppcheck suppressions


Compare: https://github.com/Hamlib/Hamlib/compare/4f6c61719cd1...d03cde33b053

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

[Hamlib-developer] [Hamlib/Hamlib] 535fb6: Fix typos

[Nate B. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 535fb6e2bd8ae96cd561ee6b7369672234d4bd24
      https://github.com/Hamlib/Hamlib/commit/535fb6e2bd8ae96cd561ee6b7369672234d4bd24
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-04-26 (Sat, 26 Apr 2025)

  Changed paths:
    M include/hamlib/rig.h
    M rigs/codan/README.codan

  Log Message:
  -----------
  Fix typos


  Commit: 4f6c61719cd1962f8942f5044e43f868cf54cb26
      https://github.com/Hamlib/Hamlib/commit/4f6c61719cd1962f8942f5044e43f868cf54cb26
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-04-27 (Sun, 27 Apr 2025)

  Changed paths:
    M include/hamlib/rig.h
    M rigs/codan/README.codan

  Log Message:
  -----------
  Merge pull request #1715 from dforsi/fix/typos

Fix typos


Compare: https://github.com/Hamlib/Hamlib/compare/5d81ea38bbdf...4f6c61719cd1

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

Re: [Hamlib-developer] 4.6.3 and 4.7.0 releases plan

[Daniele F. <iu...@gm...>]

Hello,

this issue can be closed because the author wrote that it is fixed
https://github.com/Hamlib/Hamlib/issues/1449

some of the issues I was looking at where had already a milestone of
version 4.7 set by Mike and some other will need some time, so except
for my pull requests
https://github.com/Hamlib/Hamlib/pull/1714
https://github.com/Hamlib/Hamlib/pull/1715
I have nothing more to push for version 4.6.3

-- 
73 de IU5HKX Daniele