hamlib-developer — hamlib developers forum

[Hamlib-developer] [Hamlib/Hamlib] fac456: Update README.developer and ReleaseNotes

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

  Branch: refs/heads/Hamlib-4.7
  Home:   https://github.com/Hamlib/Hamlib
  Commit: fac4566742679ac6841e46e1b14ac64375b082b7
      https://github.com/Hamlib/Hamlib/commit/fac4566742679ac6841e46e1b14ac64375b082b7
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-05 (Thu, 05 Feb 2026)

  Changed paths:
    M README.developer
    M ReleaseNotes_4.7.md

  Log Message:
  -----------
  Update README.developer and ReleaseNotes

Tell developers about upcoming C standard change
Rework some of the text in relnote

Still need something about support term of 4.7 - placeholder at top
  of ReleaseNotes_4.7

Should go into both 4.7 & master

(cherry picked from commit 89a8a75c7fa68014b2d58ee882cf06e30636aa94)


  Commit: 84a57eee4959ca6f3b835790000e61ffed2b44de
      https://github.com/Hamlib/Hamlib/commit/84a57eee4959ca6f3b835790000e61ffed2b44de
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-05 (Thu, 05 Feb 2026)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  Update NEWS

New date
Add IC-7300MK2
Drop bullet already in 4.6.4

(cherry picked from commit f42e9730bc0ffca38d8a6cfc76d1a8d7c5aaa1e2)


  Commit: c6b74c76215db9ac92f7a46745da59bcab0dbe17
      https://github.com/Hamlib/Hamlib/commit/c6b74c76215db9ac92f7a46745da59bcab0dbe17
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-05 (Thu, 05 Feb 2026)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  Revert one change, add a line

(cherry picked from commit a9db84a8ee8df2fb730a4885c9857dab04a263b4)


Compare: https://github.com/Hamlib/Hamlib/compare/02d3eea0332d...c6b74c76215d

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

[Hamlib-developer] [Hamlib/Hamlib] 1c541e: Update status of macro use for buffers

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 1c541ef5aee60a1554c282e7b45f8fdb08336f4b
      https://github.com/Hamlib/Hamlib/commit/1c541ef5aee60a1554c282e7b45f8fdb08336f4b
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-01 (Sun, 01 Feb 2026)

  Changed paths:
    M include/hamlib/rig.h

  Log Message:
  -----------
  Update status of macro use for buffers

There's no going back now.


  Commit: f42e9730bc0ffca38d8a6cfc76d1a8d7c5aaa1e2
      https://github.com/Hamlib/Hamlib/commit/f42e9730bc0ffca38d8a6cfc76d1a8d7c5aaa1e2
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-02 (Mon, 02 Feb 2026)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  Update NEWS

New date
Add IC-7300MK2
Drop bullet already in 4.6.4


  Commit: 89a8a75c7fa68014b2d58ee882cf06e30636aa94
      https://github.com/Hamlib/Hamlib/commit/89a8a75c7fa68014b2d58ee882cf06e30636aa94
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-02 (Mon, 02 Feb 2026)

  Changed paths:
    M README.developer
    M ReleaseNotes_4.7.md

  Log Message:
  -----------
  Update README.developer and ReleaseNotes

Tell developers about upcoming C standard change
Rework some of the text in relnote

Still need something about support term of 4.7 - placeholder at top
  of ReleaseNotes_4.7

Should go into both 4.7 & master


  Commit: a9db84a8ee8df2fb730a4885c9857dab04a263b4
      https://github.com/Hamlib/Hamlib/commit/a9db84a8ee8df2fb730a4885c9857dab04a263b4
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-05 (Thu, 05 Feb 2026)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  Revert one change, add a line


Compare: https://github.com/Hamlib/Hamlib/compare/ba280ac3b19a...a9db84a8ee8d

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

Re: [Hamlib-developer] Hamlib 4.7.0--tentative release date: 15 Feb 2026

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

Hello,

releasing 4.7.0 in a couple of weeks looks good to me

-- 
73 de IU5HKX Daniele

Re: [Hamlib-developer] Hamlib 4.7.0--tentative release date: 15 Feb 2026

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

* On 2026 01 Feb 17:49 -0600, George Baltz wrote:
> Now to work on the docs.

👍

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 4.7.0--tentative release date: 15 Feb 2026

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

I'm good with that.  I have no more 4.7 code in my pipeline, unless an 
issue gets raised.

Now to work on the docs.

73 n3gb

On 2/1/26 12:18 PM, Nate Bargmann wrote:
> As the subject notes, My plan right now is to release 4.7.0 in two weeks
> time.  With much improved FTX-1 support and now support for the
> IC-7300MK2 added, I think it's time to get it released.
>
> The plan is to continue to support new devices and update current
> support in the 4.7 series for some time.  I suspect that length of time
> will be around a year but will likely be something else.
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Hamlib 4.7.0--tentative release date: 15 Feb 2026

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

Since I was asked privately for the URL of the 4.7 snapshots, here are
the URLs:

https://hamlib.sourceforge.net/snapshots-4.7/
https://hamlib.sourceforge.net/snapshots/

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 4.7.0--tentative release date: 15 Feb 2026

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

As the subject notes, My plan right now is to release 4.7.0 in two weeks
time.  With much improved FTX-1 support and now support for the
IC-7300MK2 added, I think it's time to get it released.

The plan is to continue to support new devices and update current
support in the 4.7 series for some time.  I suspect that length of time
will be around a year but will likely be something else.

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] Fw: possible changes to how data from FLRig is handled

[Peter S. <vk...@gm...>]

Hello Nate,
  as I am not familiar with the way GIT displays changes, (I am a scripter
not a real programmer LOL) I cannot easily confirm this is what is needed
in flrig.c, all I can do is compare what ZIP's I can get from GIT manually
(browser downloads)

I just grabbed the source for version 4.7 from GIT and can see the model
name is now set to be "FLRig" on line 145 and no further reference .
changes to ".model_name" variable occur later in the code around line 870,
unlike the 4.6.5 source I have here.

-- ver 4.7 --

 RIG_MODEL(RIG_MODEL_FLRIG),
    .model_name = "FLRig",
    .mfg_name = "FLRig",
    .version = "20260130.0",

At present the code I can see in 4.7 looks like what I have used in my
custom build, so in a long way around, yes it looks good to me

Regards,
Peter, vk5pj

On Sat, Jan 31, 2026 at 1:53 PM Nate Bargmann <n0...@n0...> wrote:

> I have created Pull Request 1987 with Phil's patch.[1]  It compiles
> clean here.  Peter, can you test this or confirm that these are the
> exact changes that work for you?
>
> 73, Nate
>
> [1] https://github.com/Hamlib/Hamlib/pull/1987
>
> --
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>

Re: [Hamlib-developer] Upcoming WSJT-X 3.0.0 GA / Hamlib 5.0 DLLs

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

* On 2026 31 Jan 07:56 -0600, Uwe, DG2YCB via Hamlib-developer wrote:
> By the way, your other reply to my second email address ended up in my spam
> folder. Sorry, I have now read it (which, however, does not answer my
> question there). But I completely understand if you want to focus on the
> ongoing work on the 4.7.0 release first.

I did reply to your original email after this one so you might need to
check that spam box again.

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] c495b2: Revert updating FLRig model name

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

  Branch: refs/heads/Hamlib-4.7
  Home:   https://github.com/Hamlib/Hamlib
  Commit: c495b2737f2ced6050529aa3fb2d3521f67c8744
      https://github.com/Hamlib/Hamlib/commit/c495b2737f2ced6050529aa3fb2d3521f67c8744
  Author: Philip Rose <gm...@bt...>
  Date:   2026-01-31 (Sat, 31 Jan 2026)

  Changed paths:
    M rigs/dummy/flrig.c

  Log Message:
  -----------
  Revert updating FLRig model name

Per discussion on the mailing list:
https://sourceforge.net/p/hamlib/mailman/message/59275001/

The additions in commit c22392e5cd are causing issues for users of
mutliple radios when using the FLrig interface.  This commit reverts
c22392e5cd and partially reverts commit 11acef5d3b as it applies to
flrig.c

Thanks to Peter Sumner, VK5PJ, and Philip Rose, GM3ZZA, for working this
out.

(cherry picked from commit ba280ac3b19a5897ac1a01d40f6f0752ea76db88)


  Commit: 02d3eea0332d54daed9cd170fc94deb0e7a0baa9
      https://github.com/Hamlib/Hamlib/commit/02d3eea0332d54daed9cd170fc94deb0e7a0baa9
  Author: Nate Bargmann <n0...@n0...>
  Date:   2026-01-31 (Sat, 31 Jan 2026)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  Update NEWS reverting FLRig model name


Compare: https://github.com/Hamlib/Hamlib/compare/473380f396fe...02d3eea0332d

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

Re: [Hamlib-developer] Upcoming WSJT-X 3.0.0 GA / Hamlib 5.0 DLLs

[Uwe, D. <dg...@gm...>]

Hi Nate,

Thanks for your reply. Then it is best for us to wait for the official 
Hamlib 4.7.0 release and use that for WSJT-X 3.0.0 GA.

By the way, your other reply to my second email address ended up in my 
spam folder. Sorry, I have now read it (which, however, does not answer 
my question there). But I completely understand if you want to focus on 
the ongoing work on the 4.7.0 release first.

73 de DG2YCB,
Uwe
________________________________________
German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg...@gm...
Info: www.qrz.com/db/DG2YCB


Am 31.01.2026 um 13:27 schrieb Nate Bargmann:
> * On 2026 31 Jan 04:26 -0600, Uwe, DG2YCB via Hamlib-developer wrote:
>> Hi Nate and all,
>>
>> FYI: We plan to publish the official WSJT-X 3.0.0 GA release sometime in
>> February or March. Which Hamlib version can you recommend for this? Will
>> there be any official Hamlib release 4.7 from you by then? If not, are the
>> daily snapshots in your 4.7 branch reliable enough? Are there any important
>> changes still to come for 4.7?
> Hi Uwe.
>
> Please continue to use 4.7.  Rig support will be the same between the
> two branches for the foreseeable future.  I've added the FTX-1 additions
> a few days ago to both branches and some command fixes for the new
> IC-7300MK2 last night.  A handful more fixes remain and I plan to
> release 4.7.0 in about two weeks time--15 Feb.
>
>> Then, dear Nate, I sent you two off-list emails with an important question
>> about the Hamlib 5.0 DLLs, but I haven't received a reply yet. Did you get
>> them? If not, please check your spam folder.
> I received them and replied to the second one a few days ago.
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] [Hamlib/Hamlib] ba280a: Revert updating FLRig model name

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: ba280ac3b19a5897ac1a01d40f6f0752ea76db88
      https://github.com/Hamlib/Hamlib/commit/ba280ac3b19a5897ac1a01d40f6f0752ea76db88
  Author: Philip Rose <gm...@bt...>
  Date:   2026-01-30 (Fri, 30 Jan 2026)

  Changed paths:
    M rigs/dummy/flrig.c

  Log Message:
  -----------
  Revert updating FLRig model name

Per discussion on the mailing list:
https://sourceforge.net/p/hamlib/mailman/message/59275001/

The additions in commit c22392e5cd are causing issues for users of
mutliple radios when using the FLrig interface.  This commit reverts
c22392e5cd and partially reverts commit 11acef5d3b as it applies to
flrig.c

Thanks to Peter Sumner, VK5PJ, and Philip Rose, GM3ZZA, for working this
out.



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

Re: [Hamlib-developer] Upcoming WSJT-X 3.0.0 GA / Hamlib 5.0 DLLs

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

* On 2026 31 Jan 04:26 -0600, Uwe, DG2YCB via Hamlib-developer wrote:
> Hi Nate and all,
> 
> FYI: We plan to publish the official WSJT-X 3.0.0 GA release sometime in
> February or March. Which Hamlib version can you recommend for this? Will
> there be any official Hamlib release 4.7 from you by then? If not, are the
> daily snapshots in your 4.7 branch reliable enough? Are there any important
> changes still to come for 4.7?

Hi Uwe.

Please continue to use 4.7.  Rig support will be the same between the
two branches for the foreseeable future.  I've added the FTX-1 additions
a few days ago to both branches and some command fixes for the new
IC-7300MK2 last night.  A handful more fixes remain and I plan to
release 4.7.0 in about two weeks time--15 Feb.

> Then, dear Nate, I sent you two off-list emails with an important question
> about the Hamlib 5.0 DLLs, but I haven't received a reply yet. Did you get
> them? If not, please check your spam folder.

I received them and replied to the second one a few days ago.

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] Upcoming WSJT-X 3.0.0 GA / Hamlib 5.0 DLLs

[Uwe, D. <dg...@gm...>]

Hi Nate and all,

FYI: We plan to publish the official WSJT-X 3.0.0 GA release sometime in 
February or March. Which Hamlib version can you recommend for this? Will 
there be any official Hamlib release 4.7 from you by then? If not, are 
the daily snapshots in your 4.7 branch reliable enough? Are there any 
important changes still to come for 4.7?

Then, dear Nate, I sent you two off-list emails with an important 
question about the Hamlib 5.0 DLLs, but I haven't received a reply yet. 
Did you get them? If not, please check your spam folder.

73 de DG2YCB,
Uwe
________________________________________
German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg...@gm...
Info: www.qrz.com/db/DG2YCB

Re: [Hamlib-developer] Fw: possible changes to how data from FLRig is handled

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

I have created Pull Request 1987 with Phil's patch.[1]  It compiles
clean here.  Peter, can you test this or confirm that these are the
exact changes that work for you?

73, Nate

[1] https://github.com/Hamlib/Hamlib/pull/1987

-- 
"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] 0c8de5: Add the missing commit

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

  Branch: refs/heads/Hamlib-4.7
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 0c8de5ab79d28a353e92e024ca1cd927b412ae54
      https://github.com/Hamlib/Hamlib/commit/0c8de5ab79d28a353e92e024ca1cd927b412ae54
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-01-30 (Fri, 30 Jan 2026)

  Changed paths:
    M tests/rigctl_parse.c

  Log Message:
  -----------
  Add the missing commit

Plus a few more arbitrary lengths, so `git grep scanfc` shows no more
  bare "%s" format strings.

(cherry picked from commit f6734ad832e63f8dfb7d7167721532bec1f492f6)


  Commit: 246690a5082d801f7b02f6503fbd0d885c7eb1c8
      https://github.com/Hamlib/Hamlib/commit/246690a5082d801f7b02f6503fbd0d885c7eb1c8
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-01-30 (Fri, 30 Jan 2026)

  Changed paths:
    M rigs/icom/icom.c

  Log Message:
  -----------
  Get rid of bogus case entry.

All RIG_LEVEL_USB_AF data is in priv_caps->extcmds

(cherry picked from commit a7ba5a13793d99a33139f6c9ee386ac39b2987c2)


  Commit: 988f4ec09aa25ec1ed2da1704f68c4956a992f30
      https://github.com/Hamlib/Hamlib/commit/988f4ec09aa25ec1ed2da1704f68c4956a992f30
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-01-30 (Fri, 30 Jan 2026)

  Changed paths:
    M rigs/icom/ic7300.c

  Log Message:
  -----------
  Update various extra commands for IC-7300MK2

Change these CI-V parameters per the IC-7300MK2 CI-V REFERENCE GUIDE

RIG_PARM_
   ANN
   BACKLIGHT
   SCREENSAVER
   TIME
   BANDSELECT
   KEYERTYPE
RIG_LEVEL_
   VOXDELAY
   SPECTRUM_AVG
   USB_AF
RIG_FUNC_
   TRANSCEIVE

Also changes RIG_LEVEL_VOXDELAY for IC-7300 to agree with its CI-V
   description.

Should close issue #1985

(cherry picked from commit e52a92caa6ea070be5757f713f45a0029c73dd50)


  Commit: 473380f396fefd1e1c760cb20e67c505ddf80882
      https://github.com/Hamlib/Hamlib/commit/473380f396fefd1e1c760cb20e67c505ddf80882
  Author: Nate Bargmann <n0...@n0...>
  Date:   2026-01-30 (Fri, 30 Jan 2026)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  Update NEWS with target date, IC-7300MK2 commands


Compare: https://github.com/Hamlib/Hamlib/compare/61809a8b1e46...473380f396fe

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

[Hamlib-developer] [Hamlib/Hamlib] a7ba5a: Get rid of bogus case entry.

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: a7ba5a13793d99a33139f6c9ee386ac39b2987c2
      https://github.com/Hamlib/Hamlib/commit/a7ba5a13793d99a33139f6c9ee386ac39b2987c2
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-01-30 (Fri, 30 Jan 2026)

  Changed paths:
    M rigs/icom/icom.c

  Log Message:
  -----------
  Get rid of bogus case entry.

All RIG_LEVEL_USB_AF data is in priv_caps->extcmds


  Commit: e52a92caa6ea070be5757f713f45a0029c73dd50
      https://github.com/Hamlib/Hamlib/commit/e52a92caa6ea070be5757f713f45a0029c73dd50
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-01-30 (Fri, 30 Jan 2026)

  Changed paths:
    M rigs/icom/ic7300.c

  Log Message:
  -----------
  Update various extra commands for IC-7300MK2

Change these CI-V parameters per the IC-7300MK2 CI-V REFERENCE GUIDE

RIG_PARM_
   ANN
   BACKLIGHT
   SCREENSAVER
   TIME
   BANDSELECT
   KEYERTYPE
RIG_LEVEL_
   VOXDELAY
   SPECTRUM_AVG
   USB_AF
RIG_FUNC_
   TRANSCEIVE

Also changes RIG_LEVEL_VOXDELAY for IC-7300 to agree with its CI-V
   description.

Should close issue #1985


  Commit: e3c8291ad5c448b04afb58ffd218b27aa5b0be9c
      https://github.com/Hamlib/Hamlib/commit/e3c8291ad5c448b04afb58ffd218b27aa5b0be9c
  Author: Nate Bargmann <n0...@n0...>
  Date:   2026-01-30 (Fri, 30 Jan 2026)

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

  Log Message:
  -----------
  Merge GitHub PR #1986


Compare: https://github.com/Hamlib/Hamlib/compare/f6734ad832e6...e3c8291ad5c4

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

[Hamlib-developer] [Hamlib/Hamlib] 21ebcf: Fix typos in man pages

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

  Branch: refs/heads/Hamlib-4.7
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 21ebcfbd9964520ec42e7bb2b40ed2700ade0a9f
      https://github.com/Hamlib/Hamlib/commit/21ebcfbd9964520ec42e7bb2b40ed2700ade0a9f
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-01-30 (Fri, 30 Jan 2026)

  Changed paths:
    M doc/man1/rigctl.1
    M doc/man1/rigctld.1

  Log Message:
  -----------
  Fix typos in man pages

(cherry picked from commit cda9d0bcc9d7083544438d715210700361919370)


  Commit: 897ad1062ad61269838033f17d85310517a38486
      https://github.com/Hamlib/Hamlib/commit/897ad1062ad61269838033f17d85310517a38486
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-01-30 (Fri, 30 Jan 2026)

  Changed paths:
    M tests/rigctl_parse.c

  Log Message:
  -----------
  Fix unbounded scanf string in rigctl_parse.c

Thanks to Vlatko Kosturjak with Marlink Cyber, for reporting it.

(cherry picked from commit 9d40f9f180ee3a6a9e36149288e7b1dc87854154)


  Commit: 37e57f4a0c91b5ca162e7c0c506c2dd4bf9917a6
      https://github.com/Hamlib/Hamlib/commit/37e57f4a0c91b5ca162e7c0c506c2dd4bf9917a6
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-01-30 (Fri, 30 Jan 2026)

  Changed paths:
    M tests/rotctl_parse.c

  Log Message:
  -----------
  Fix string overflows in rotctl_parse.c

(cherry picked from commit 330b7912167497a92e5db0ca89080be30a5be7e3)


  Commit: 61809a8b1e4650954909cc63f6c45d0162ebe461
      https://github.com/Hamlib/Hamlib/commit/61809a8b1e4650954909cc63f6c45d0162ebe461
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-01-30 (Fri, 30 Jan 2026)

  Changed paths:
    M NEWS
    M tests/ampctl_parse.c
    M tests/rotctl_parse.c

  Log Message:
  -----------
  Same for ampctl_parse.c

Update NEWS
Fix compiler snit about possible truncation

(cherry picked from commit de5087f57a715b75cb9f4131e9321ae2709218d3)


Compare: https://github.com/Hamlib/Hamlib/compare/e2c13f986f0f...61809a8b1e46

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

[Hamlib-developer] [Hamlib/Hamlib] cda9d0: Fix typos in man pages

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: cda9d0bcc9d7083544438d715210700361919370
      https://github.com/Hamlib/Hamlib/commit/cda9d0bcc9d7083544438d715210700361919370
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-01-27 (Tue, 27 Jan 2026)

  Changed paths:
    M doc/man1/rigctl.1
    M doc/man1/rigctld.1

  Log Message:
  -----------
  Fix typos in man pages


  Commit: 9d40f9f180ee3a6a9e36149288e7b1dc87854154
      https://github.com/Hamlib/Hamlib/commit/9d40f9f180ee3a6a9e36149288e7b1dc87854154
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-01-27 (Tue, 27 Jan 2026)

  Changed paths:
    M tests/rigctl_parse.c

  Log Message:
  -----------
  Fix unbounded scanf string in rigctl_parse.c

Thanks to Vlatko Kosturjak with Marlink Cyber, for reporting it.


  Commit: 330b7912167497a92e5db0ca89080be30a5be7e3
      https://github.com/Hamlib/Hamlib/commit/330b7912167497a92e5db0ca89080be30a5be7e3
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-01-27 (Tue, 27 Jan 2026)

  Changed paths:
    M tests/rotctl_parse.c

  Log Message:
  -----------
  Fix string overflows in rotctl_parse.c


  Commit: de5087f57a715b75cb9f4131e9321ae2709218d3
      https://github.com/Hamlib/Hamlib/commit/de5087f57a715b75cb9f4131e9321ae2709218d3
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-01-28 (Wed, 28 Jan 2026)

  Changed paths:
    M NEWS
    M tests/ampctl_parse.c
    M tests/rotctl_parse.c

  Log Message:
  -----------
  Same for ampctl_parse.c

Update NEWS
Fix compiler snit about possible truncation


  Commit: f6734ad832e63f8dfb7d7167721532bec1f492f6
      https://github.com/Hamlib/Hamlib/commit/f6734ad832e63f8dfb7d7167721532bec1f492f6
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-01-28 (Wed, 28 Jan 2026)

  Changed paths:
    M tests/rigctl_parse.c

  Log Message:
  -----------
  Add the missing commit

Plus a few more arbitrary lengths, so `git grep scanfc` shows no more
  bare "%s" format strings.


Compare: https://github.com/Hamlib/Hamlib/compare/f39018fc1eaa...f6734ad832e6

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

Re: [Hamlib-developer] Fw: possible changes to how data from FLRig is handled

[<gm...@bt...>]

________________________________
From: Nate Bargmann <n0...@n0...>
Sent: 29 January 2026 1:20 AM
To: ham...@li... <ham...@li...>
Subject: Re: [Hamlib-developer] Fw: possible changes to how data from FLRig is handled

* On 2026 28 Jan 14:00 -0600, Peter Sumner wrote:
> Hello Nate and Phil,
>
> Nate, I have carefully read your assessment of the reasons to not apply the
> patch and can fully understand your doubt as to what reverting to its
> previous state may cause.  I had no clue that the interface to FLRIG was
> considered a "hack" in hamlib but it does seem to work quite well in most
> situations so for me I am glad someone included it in the features of
> hamlib.

I noted that it being a hack is strictly my opinion.  That said, I'm not
advocating that it be removed.  Obviously it is being used and useful
code makes the project more valuable overall.

> If we were to go with a method where the ability to report the radio name
> from FLRig could be turned off via a small config file in the same folder
> as the HAMLIB binary would that be acceptable?  I do recall that Mike had
> on many occasions in the past had supplied people with a JSON file to make
> customisations to the behavior of HAMLIB.

I find that interesting as I'm not aware of any such capability in the
library.  Perhaps that file is consumed by Flrig and not Hamlib?  If the
capability exists in Hamlib, I'm sure someone will kindly point me in
the right direction.

There is a capability in WSJT-X to change the hamlib configuration by applying a patch
"hamlib_settings.json".  It obviously requires that WSJT-X knows about and can control hamlib
operational parameters. I don't think this forms part of the official WSJT-X documentation.

Phil.


> Might this be an option, then this extra information can be left in
> place but turned off for those who where it is a problem? Or indeed
> the complete reverse be done where this extra information is OFF until
> turned on by a customization file?

As I understand things, such capability would need to be implemented.
Mike had opened several feature request issues regarding just such a
capability but none were ever completed or had commits or pull requests
referenced.  I know I closed at least two that were duplicates last year
and one remains open for anyone who wishes to work on such capability.

> Over the last 12 months I have looked for alternatives to hamlib and flrig
> but have not found anything that gives me a GUI interface to the rig and
> the simplicity of  the HAMLIB / FLRig combination in my day to day
> operations here in VK5.
>
> Ultimately I am in your hands Nate, I have with the help of others been
> able to build a custom windows version of hamlib on my raspberry PI thanks
> to  David M0DGB/G8FKH for his scripts and guidance in that endeavour as my
> attempts to get JTSDK going under windows 11 went down in flames. This
> custom build yielded a usable libhamlib-4.dll that I now use across all my
> PC's with great success, ensuring I am not stuck on an ancient hamlib
> release. Of course in the long term I would love to be able to use the
> released versions of hamlib for my daily needs.

Thanks for the background, Peter.

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] Fw: possible changes to how data from FLRig is handled

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

* On 2026 28 Jan 14:00 -0600, Peter Sumner wrote:
> Hello Nate and Phil,
> 
> Nate, I have carefully read your assessment of the reasons to not apply the
> patch and can fully understand your doubt as to what reverting to its
> previous state may cause.  I had no clue that the interface to FLRIG was
> considered a "hack" in hamlib but it does seem to work quite well in most
> situations so for me I am glad someone included it in the features of
> hamlib.

I noted that it being a hack is strictly my opinion.  That said, I'm not
advocating that it be removed.  Obviously it is being used and useful
code makes the project more valuable overall.

> If we were to go with a method where the ability to report the radio name
> from FLRig could be turned off via a small config file in the same folder
> as the HAMLIB binary would that be acceptable?  I do recall that Mike had
> on many occasions in the past had supplied people with a JSON file to make
> customisations to the behavior of HAMLIB.

I find that interesting as I'm not aware of any such capability in the
library.  Perhaps that file is consumed by Flrig and not Hamlib?  If the
capability exists in Hamlib, I'm sure someone will kindly point me in
the right direction.

> Might this be an option, then this extra information can be left in
> place but turned off for those who where it is a problem? Or indeed
> the complete reverse be done where this extra information is OFF until
> turned on by a customization file?

As I understand things, such capability would need to be implemented.
Mike had opened several feature request issues regarding just such a
capability but none were ever completed or had commits or pull requests
referenced.  I know I closed at least two that were duplicates last year
and one remains open for anyone who wishes to work on such capability.

> Over the last 12 months I have looked for alternatives to hamlib and flrig
> but have not found anything that gives me a GUI interface to the rig and
> the simplicity of  the HAMLIB / FLRig combination in my day to day
> operations here in VK5.
> 
> Ultimately I am in your hands Nate, I have with the help of others been
> able to build a custom windows version of hamlib on my raspberry PI thanks
> to  David M0DGB/G8FKH for his scripts and guidance in that endeavour as my
> attempts to get JTSDK going under windows 11 went down in flames. This
> custom build yielded a usable libhamlib-4.dll that I now use across all my
> PC's with great success, ensuring I am not stuck on an ancient hamlib
> release. Of course in the long term I would love to be able to use the
> released versions of hamlib for my daily needs.

Thanks for the background, Peter.

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] Fw: possible changes to how data from FLRig is handled

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

* On 2026 28 Jan 16:13 -0600, Peter Sumner wrote:
> Hi Nate,
>  further to my previous reply I realised I had not covered a few
> questions you raised.

Thanks, Peter.

> I have raised the possibility of WSJT-X moving to using HAMLIB rig numbers
> rather than names with Uwe some time ago while trying to chase down where
> else this issue could be resolved, Uwe told me there was no appetite for
> such a major change of the WSJT-X code at this time.  Which led me to try
> and talk to the FLRig developer about this but these enquiries went nowhere.

I appreciate the background information.

> The changes made by Mike, seem to fall into two different possible streams,
> -A- it was a change requested by a hamlib user which he coded to meet that
> need OR -B- it was a capability Mike found in the data coming back from
> FLRig and he thought it was a nice idea to enhance HAMLIB for some future
> use-case and was a "do it because I can" addition. Without Mike being
> around it's only my guess.

That's all any of us are doing is guessing as to Mike's motivation.

> If the code for 'flrig.c' is returned to how it was and a real use case is
> at a later time presented by a hamlib user for it to be enhanced again, I
> will stand by that decision and go back to my custom build process (had
> better backup my Micro SD card for my PI-4).  But to not do it based on a
> Might happen one day would seem to be worrying about a rainy day in summer
> that might not ever happen.
> 
> I will be the first to admit that my use-case is pretty slim, the problem
> only shows up IF you use FLRIG and WSJT-X/Hamlib together and only if you
> use multiple WSJT-X configurations.  Most WSJT-X users seem to plod along
> using a single 'configuration' on FT8 and would never be troubled by this
> issue, so I can understand why I am the squeaky wheel as a long time ago I
> took the advice of Joe K1JT to embrace the use of configurations in WSJT-X
> and would not go back to the 'old ways' now.
> 
> I hope that covers the questions.

Yes, indeed.  Thanks to you and Phil for the feedback.  I'll go ahead
and apply the patch reverting the commits in question.

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] Fw: possible changes to how data from FLRig is handled

[Peter S. <vk...@gm...>]

Hi Nate,
 further to my previous reply I realised I had not covered a few
questions you raised.

I have raised the possibility of WSJT-X moving to using HAMLIB rig numbers
rather than names with Uwe some time ago while trying to chase down where
else this issue could be resolved, Uwe told me there was no appetite for
such a major change of the WSJT-X code at this time.  Which led me to try
and talk to the FLRig developer about this but these enquiries went nowhere.

The changes made by Mike, seem to fall into two different possible streams,
-A- it was a change requested by a hamlib user which he coded to meet that
need OR -B- it was a capability Mike found in the data coming back from
FLRig and he thought it was a nice idea to enhance HAMLIB for some future
use-case and was a "do it because I can" addition. Without Mike being
around it's only my guess.

If the code for 'flrig.c' is returned to how it was and a real use case is
at a later time presented by a hamlib user for it to be enhanced again, I
will stand by that decision and go back to my custom build process (had
better backup my Micro SD card for my PI-4).  But to not do it based on a
Might happen one day would seem to be worrying about a rainy day in summer
that might not ever happen.

I will be the first to admit that my use-case is pretty slim, the problem
only shows up IF you use FLRIG and WSJT-X/Hamlib together and only if you
use multiple WSJT-X configurations.  Most WSJT-X users seem to plod along
using a single 'configuration' on FT8 and would never be troubled by this
issue, so I can understand why I am the squeaky wheel as a long time ago I
took the advice of Joe K1JT to embrace the use of configurations in WSJT-X
and would not go back to the 'old ways' now.

I hope that covers the questions.

Regards, Peter, vk5pj

On Thu, Jan 29, 2026 at 6:28 AM Peter Sumner <vk...@gm...> wrote:

> Hello Nate and Phil,
>
> Nate, I have carefully read your assessment of the reasons to not apply
> the patch and can fully understand your doubt as to what reverting to its
> previous state may cause.  I had no clue that the interface to FLRIG was
> considered a "hack" in hamlib but it does seem to work quite well in most
> situations so for me I am glad someone included it in the features of
> hamlib.
>
> If we were to go with a method where the ability to report the radio name
> from FLRig could be turned off via a small config file in the same folder
> as the HAMLIB binary would that be acceptable?  I do recall that Mike had
> on many occasions in the past had supplied people with a JSON file to make
> customisations to the behavior of HAMLIB.  Might this be an option, then
> this extra information can be left in place but turned off for those who
> where it is a problem? Or indeed the complete reverse be done where this
> extra information is OFF until turned on by a customization file?
>
> Over the last 12 months I have looked for alternatives to hamlib and flrig
> but have not found anything that gives me a GUI interface to the rig and
> the simplicity of  the HAMLIB / FLRig combination in my day to day
> operations here in VK5.
>
> Ultimately I am in your hands Nate, I have with the help of others been
> able to build a custom windows version of hamlib on my raspberry PI thanks
> to  David M0DGB/G8FKH for his scripts and guidance in that endeavour as my
> attempts to get JTSDK going under windows 11 went down in flames. This
> custom build yielded a usable libhamlib-4.dll that I now use across all my
> PC's with great success, ensuring I am not stuck on an ancient hamlib
> release. Of course in the long term I would love to be able to use the
> released versions of hamlib for my daily needs.
>
> Regards,
> Peter, vk5pj
>
>
> On Wed, Jan 28, 2026 at 11:45 PM Nate Bargmann <n0...@n0...> wrote:
>
>> * On 2026 10 Jan 07:12 -0600, gm3zza--- via Hamlib-developer wrote:
>> > Nate,
>> >
>> > I posted a patch a week or two back that fixes Peter's issue with
>> > renaming flrig after it gets connected and therefore fails to connect
>> > next time it tries to connect. The issue is apparent when trying to
>> > switch configurations in WSJT-X.
>>
>> Thanks, Phil and Peter.
>>
>> This proposed patch reverts commit c22392e5cd from Mike:
>>
>> https://github.com/Hamlib/Hamlib/commit/c22392e5cd8654874b9e18bdc99d80293c0f28a8
>>
>> and partially 11acef5d3b from George:
>>
>> https://github.com/Hamlib/Hamlib/commit/11acef5d3bc4645ad70881759b2aeaf0de443cfe
>>
>> From where I sit, here is my dilemma.  After this patch is applied and
>> pushed, who is going to yell that it should be added back, and what
>> should be done then?  Clearly, Mike thought this change necessary and
>> useful but as is notable for his commits, it is quite short on a
>> reference for what problem its application solved.  So, I'm left with
>> one user that wants this changed back and I don't know how many that
>> aren't having an issue.  The other question is whether WSJT-X has been
>> modified to account for this change and will applying this patch break
>> it or what other client programs?
>>
>> In my opinion, this interface to Flrig is a hack.  It should only be
>> used in limited circumstances and life would be better if this didn't
>> exist at all.  However, it does exist, but I must ask Peter if there is
>> a possibility that he could move away from using this hack?
>>
>> > It's really a case of WSJT-X using the rig name rather than number,
>> > but that's a ship long sailed!
>>
>> Sadly true.  In Hamlib strings like the device name are intended for
>> user information, the entire library is keyed on the device model
>> number.  We had a disruptive change of radio model numbers several years
>> back.  Hopefully, that won't be necessary for a long time to come.  We
>> really try to preserve model number stability throughout all Hamlib
>> versions.
>>
>> > Is there any chance of creating a Windows build with it included,
>> please.
>>
>> Well, sure, the daily snapshot builds would include the change once
>> applied, but I am hesitant to apply this patch as I don't know what
>> client software now relies on its current behavior, i.e. commit
>> c22392e5cd in place.  The resulting fallout is unknowable at this time.
>>
>> 73, Nate
>>
>> --
>> "The optimist proclaims that we live in the best of all
>> possible worlds.  The pessimist fears this is true."
>> Web: https://www.n0nb.us
>> Projects: https://github.com/N0NB
>> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>>
>> _______________________________________________
>> Hamlib-developer mailing list
>> Ham...@li...
>> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>>
>

Re: [Hamlib-developer] Fw: possible changes to how data from FLRig is handled

[Peter S. <vk...@gm...>]

Hello Nate and Phil,

Nate, I have carefully read your assessment of the reasons to not apply the
patch and can fully understand your doubt as to what reverting to its
previous state may cause.  I had no clue that the interface to FLRIG was
considered a "hack" in hamlib but it does seem to work quite well in most
situations so for me I am glad someone included it in the features of
hamlib.

If we were to go with a method where the ability to report the radio name
from FLRig could be turned off via a small config file in the same folder
as the HAMLIB binary would that be acceptable?  I do recall that Mike had
on many occasions in the past had supplied people with a JSON file to make
customisations to the behavior of HAMLIB.  Might this be an option, then
this extra information can be left in place but turned off for those who
where it is a problem? Or indeed the complete reverse be done where this
extra information is OFF until turned on by a customization file?

Over the last 12 months I have looked for alternatives to hamlib and flrig
but have not found anything that gives me a GUI interface to the rig and
the simplicity of  the HAMLIB / FLRig combination in my day to day
operations here in VK5.

Ultimately I am in your hands Nate, I have with the help of others been
able to build a custom windows version of hamlib on my raspberry PI thanks
to  David M0DGB/G8FKH for his scripts and guidance in that endeavour as my
attempts to get JTSDK going under windows 11 went down in flames. This
custom build yielded a usable libhamlib-4.dll that I now use across all my
PC's with great success, ensuring I am not stuck on an ancient hamlib
release. Of course in the long term I would love to be able to use the
released versions of hamlib for my daily needs.

Regards,
Peter, vk5pj


On Wed, Jan 28, 2026 at 11:45 PM Nate Bargmann <n0...@n0...> wrote:

> * On 2026 10 Jan 07:12 -0600, gm3zza--- via Hamlib-developer wrote:
> > Nate,
> >
> > I posted a patch a week or two back that fixes Peter's issue with
> > renaming flrig after it gets connected and therefore fails to connect
> > next time it tries to connect. The issue is apparent when trying to
> > switch configurations in WSJT-X.
>
> Thanks, Phil and Peter.
>
> This proposed patch reverts commit c22392e5cd from Mike:
>
> https://github.com/Hamlib/Hamlib/commit/c22392e5cd8654874b9e18bdc99d80293c0f28a8
>
> and partially 11acef5d3b from George:
>
> https://github.com/Hamlib/Hamlib/commit/11acef5d3bc4645ad70881759b2aeaf0de443cfe
>
> From where I sit, here is my dilemma.  After this patch is applied and
> pushed, who is going to yell that it should be added back, and what
> should be done then?  Clearly, Mike thought this change necessary and
> useful but as is notable for his commits, it is quite short on a
> reference for what problem its application solved.  So, I'm left with
> one user that wants this changed back and I don't know how many that
> aren't having an issue.  The other question is whether WSJT-X has been
> modified to account for this change and will applying this patch break
> it or what other client programs?
>
> In my opinion, this interface to Flrig is a hack.  It should only be
> used in limited circumstances and life would be better if this didn't
> exist at all.  However, it does exist, but I must ask Peter if there is
> a possibility that he could move away from using this hack?
>
> > It's really a case of WSJT-X using the rig name rather than number,
> > but that's a ship long sailed!
>
> Sadly true.  In Hamlib strings like the device name are intended for
> user information, the entire library is keyed on the device model
> number.  We had a disruptive change of radio model numbers several years
> back.  Hopefully, that won't be necessary for a long time to come.  We
> really try to preserve model number stability throughout all Hamlib
> versions.
>
> > Is there any chance of creating a Windows build with it included, please.
>
> Well, sure, the daily snapshot builds would include the change once
> applied, but I am hesitant to apply this patch as I don't know what
> client software now relies on its current behavior, i.e. commit
> c22392e5cd in place.  The resulting fallout is unknowable at this time.
>
> 73, Nate
>
> --
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>

Re: [Hamlib-developer] Vulnerabilities in rigctld/rotctld - overflows

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

Thank you for reporting this.  I have created a pull request (PR #1984) 
on github.com to fix the holes I found.  Please feel free to critique 
it, or to test it for effectiveness.

73 n3gb

On 1/7/26 12:50 AM, Vlatko Kosturjak wrote:
> Hello!
>
> Thank you for making hamlib and for continuous maintenance of it.
>
> I have found two vulnerabilities in hamlib:
> 1) Stack-buffer-overflow in `rigctl_parse` when reading 
> command/argument tokens
> 2) Stack-buffer-overflow in `rotctl_parse` when reading 
> command/argument tokens
>
> Details and proof of concept crashes are in attachment.
>
> Versions tested against:
> - latest release: Hamlib 4.6.5
> - latest git master (d7e94b5d0f07164901f503a102e4b790ec0f366a)
>
> Although it can be used to crash or execute arbitrary code in some 
> cases, I guess it also qualifies for 'Segfault-award' you have :)
> https://github.com/Hamlib/Hamlib/blob/master/Segfault-award
> It even triggers segfault remotely over the network: stable crash and 
> repeatable ;)
>
> I would kindly ask you to credit vulnerability and crash as:
> Vlatko Kosturjak with Marlink Cyber
>
> If there's any questions or concerns, do not hesitate to contact me.
>
> Best regards,
> -- 
> Vlatko Kosturjak, Kost
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer