hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] Yaesu FTX-1--target for 4.7.0?

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

I do have a couple of things I would like to see in 5.0, and I've been 
doing some reading and doodling about them; nothing concrete yet, but 
here's my blue-sky ideas:

1. Update the requirements for building/running/developing with Hamlib.

  * ANSI C is 35 years old - no need to support K&R C anymore.  I'd like
    to see -std=c17 at least, but -std=c11 would still be better than c89.
  * 4.6.x won't compile without P_THREADS - make that an overt requirement.
  * Split include/hamlib/rig.h so including rig.h gives the app access
    to the whole API, but none of the structures - and guarantee this is
    stable. Allows app developers to not worry about Hamlib internal
    changes unless they explicitly need/include the structure definitions.

2. Follow up on the cache move by breaking out the port and state 
structures.  Now I'm not sure we can make things transparent across 
4.7<->5.0 - having cache inside state inside rig throws a monkey wrench 
into what I had hoped to do.

3. Regarding thread safety; the answer could be 'yes', 'no', or 'which 
one?' There at least 4 different locking mechanisms in Hamlib.  None 
cover everything.  Current code(rig_lock()) fixes interference between 
some API calls and morse_data_handler() so CW works, and I think the 
Icom code handles their flavor of automatic updates.  The multicast 
stuff I haven't looked into, and the original morse_mutex() could now be 
replaced by a simple flag. And none of these look like a good candidate 
for the whole shebang.

4. The usual lineup of bug busting and feature/model requests.

Whew!  Writing that tells me I might have bitten off more than anyone 
can chew. Prioritize away!

73 n3gb

On 6/18/25 12:28 PM, Nate Bargmann wrote:
> * On 2025 18 Jun 10:44 -0500, George Baltz wrote:
>> I don't have any problem with working just from the manual(when there is
>> one), but I don't think the FTX-1 should be the defining feature of 4.7.
>> Since we don't have any clue as to what the command set even looks like,
>> it's really hard to give a time line.  I guess I should check out the
>> feature set and see how much it shares with previous hardware.
> I did take a look at the Yaesu site earlier
> (https://www.yaesu.com/product-detail.aspx?Model=FTX-1%20Series&CatName=HF%20Transceivers/Amplifiers)
> and there isn't a CAT manual that I could find.  The operating manual
> has the menu items for changing serial rate and such but not even a
> command summary is included.
>
>> We would need some volunteers who have one to check out the daily builds and
>> give feedback.
> Certainly.
>
>> It is ready when it is ready.
> I agree.
>
> That said, perhaps we need a feature roadmap (bugs will always be
> stomped as they become visible).  I know Mike was setting various
> feature issues to various milestones but that isn't a concise list of
> items that can be checked off or progress documented.  It seemed the
> roadmap was in his mind which made it a bit inaccessible to the rest of
> us.
>
> I know you have some things to work on as does Daniele, myself, and
> likely others.  Such a list should probably be no more than six to ten
> items long.  It may be that not all items are 100% complete but I think
> we need some kind of an idea of where we're going with each release.
>
> What are everyone's thoughts on this idea?
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Yaesu FTX-1--target for 4.7.0?

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

Nate Bargmann wrote:
>
> * On 2025 18 Jun 10:44 -0500, George Baltz wrote:
> > I don't have any problem with working just from the manual(when there is
> > one), but I don't think the FTX-1 should be the defining feature of 4.7.

I agree on both points

> > It is ready when it is ready.
>
> I agree.

I agree too

WRT a feature roadmap, I would like to see
* the Python bindings mostly complete and the other languages at least
working for some basic functionality such as set/get frequency (some
time before 5.0)
* the tests that currently use the Dummy devices working also with the
simulators (and with real hardware where it makes sense)
* the work done by George for the cache
* the work done by George for thread safety (is it finished?)

-- 
73 de IU5HKX Daniele

Re: [Hamlib-developer] Yaesu FTX-1

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

* On 2025 18 Jun 13:16 -0500, Daniel Hice wrote:
> Rodger just replied, it is expected by the end of June. 🤞

Thanks, Daniel.

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] Yaesu FTX-1

[Daniel H. <da...@ad...>]

Rodger just replied, it is expected by the end of June. 🤞

73

Daniel Hice, AD2GL

________________________________
From: Nate Bargmann <n0...@n0...>
Sent: Wednesday, June 18, 2025 1:53 PM
To: Daniel Hice <da...@ad...>
Cc: ham...@li... <ham...@li...>
Subject: Re: [Hamlib-developer] Yaesu FTX-1

* On 2025 18 Jun 12:00 -0500, Daniel Hice wrote:
> Nate,
>
> I just dropped Rodger a note asking about it. He’s been quite
> responsive to my question, but US support doesn’t seem to have much
> more info than us consumers. Fingers crossed either way 😊

It makes me wonder if they're still developing firmware and that is
being reflected in changing CAT commands as the reason for the delay.

> When I asked about this directly with the WSJT-X group they said HRD
> works perfectly fine as a CAT already. Are there any collaborations
> between the programs or not with them being commercial?

Between HRD and Hamlib? No. Between WSJT-X and Hamlib? Some. Two
SKs, Bill Sommerville, G4WJS, and Mike, W9MDB, both worked in the WSJT-X
project or were very closely associated with it and also here, but other
than that, no one has revealed an association.

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] Yaesu FTX-1

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

* On 2025 18 Jun 12:00 -0500, Daniel Hice wrote:
> Nate,
> 
> I just dropped Rodger a note asking about it. He’s been quite
> responsive to my question, but US support doesn’t seem to have much
> more info than us consumers. Fingers crossed either way 😊

It makes me wonder if they're still developing firmware and that is
being reflected in changing CAT commands as the reason for the delay.

> When I asked about this directly with the WSJT-X group they said HRD
> works perfectly fine as a CAT already. Are there any collaborations
> between the programs or not with them being commercial?

Between HRD and Hamlib?  No.  Between WSJT-X and Hamlib?  Some.  Two
SKs, Bill Sommerville, G4WJS, and Mike, W9MDB, both worked in the WSJT-X
project or were very closely associated with it and also here, but other
than that, no one has revealed an association.

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] [Fwd: RE: Yaesu FTX-1]

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

----- Forwarded message from David Balharrie <da...@ba...> -----

Date: Wed, 18 Jun 2025 16:43:13 +0000
From: David Balharrie <da...@ba...>
To: Nate Bargmann <n0...@n0...>
Subject: RE: [Hamlib-developer] Yaesu FTX-1

I found this on a groups.io talking about the FTx-1 and CAT/WSJTX

" Got this working this morning. Using Standard Yaesu USB driver, Ham Radio Deluxe configured for FTDX10 and linked to WSJT-X to HRD. Not sure why the other variations I tried didn't work, however this is a satisfactory solution for me.
 
Alan AK6DG"

Link to the thread.. https://groups.io/g/FTX-1F/topic/cat_control/113179751

It might not be too difficult to get it working in Hamlib..

73 de David M0DGB/G8FKH

-----Original Message-----
From: Nate Bargmann <n0...@n0...> 
Sent: 18 June 2025 17:30
To: Daniel Hice <da...@ad...>
Cc: ham...@li...
Subject: Re: [Hamlib-developer] Yaesu FTX-1

As a follow up, I did check the Yaseu site earlier and while several manuals are listed, I didn't find a CAT command reference among them.

I wonder if they'd provide one upon request?

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


----- End forwarded message -----

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

Re: [Hamlib-developer] Yaesu FTX-1

[Daniel H. <da...@ad...>]

Nate,

I just dropped Rodger a note asking about it. He’s been quite responsive to my question, but US support doesn’t seem to have much more info than us consumers. Fingers crossed either way 😊 When I asked about this directly with the WSJT-X group they said HRD works perfectly fine as a CAT already. Are there any collaborations between the programs or not with them being commercial?

On 6/18/25, 12:30, "Nate Bargmann" <n0...@n0...> wrote:
As a follow up, I did check the Yaseu site earlier and while several
manuals are listed, I didn't find a CAT command reference among them.

I wonder if they'd provide one upon request?

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] Yaesu FTX-1

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

As a follow up, I did check the Yaseu site earlier and while several
manuals are listed, I didn't find a CAT command reference among them.

I wonder if they'd provide one upon request?

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] Yaesu FTX-1--target for 4.7.0?

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

* On 2025 18 Jun 10:44 -0500, George Baltz wrote:
> I don't have any problem with working just from the manual(when there is
> one), but I don't think the FTX-1 should be the defining feature of 4.7. 
> Since we don't have any clue as to what the command set even looks like,
> it's really hard to give a time line.  I guess I should check out the
> feature set and see how much it shares with previous hardware.

I did take a look at the Yaesu site earlier
(https://www.yaesu.com/product-detail.aspx?Model=FTX-1%20Series&CatName=HF%20Transceivers/Amplifiers)
and there isn't a CAT manual that I could find.  The operating manual
has the menu items for changing serial rate and such but not even a
command summary is included.

> We would need some volunteers who have one to check out the daily builds and
> give feedback.

Certainly.

> It is ready when it is ready.

I agree.

That said, perhaps we need a feature roadmap (bugs will always be
stomped as they become visible).  I know Mike was setting various
feature issues to various milestones but that isn't a concise list of
items that can be checked off or progress documented.  It seemed the
roadmap was in his mind which made it a bit inaccessible to the rest of
us.

I know you have some things to work on as does Daniele, myself, and
likely others.  Such a list should probably be no more than six to ten
items long.  It may be that not all items are 100% complete but I think
we need some kind of an idea of where we're going with each release.

What are everyone's thoughts on this idea?

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] Yaesu FTX-1--target for 4.7.0?

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

I don't have any problem with working just from the manual(when there is 
one), but I don't think the FTX-1 should be the defining feature of 
4.7.  Since we don't have any clue as to what the command set even looks 
like, it's really hard to give a time line.  I guess I should check out 
the feature set and see how much it shares with previous hardware.

We would need some volunteers who have one to check out the daily builds 
and give feedback.

It is ready when it is ready.

73 n3gb

On 6/15/25 11:27 AM, Nate Bargmann wrote:
> I have received a couple of private queries about when support will land
> for the FTX-1.  One of those queries also admitted that Yaesu has not
> released a programmer's reference for it yet.  Whether it would be
> available under an NDA, I don't know.
>
> I do know that I won't be buying one!  The question I do have is that
> apparently there is interest in it and I hope someone finds a recent
> Yaesu model that will enable it to work with WSJT-X, et. al. in the
> interim, should a 4.7.0 release be more or less contingent on when
> support for this radio is added?
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Yaesu FTX-1

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

* On 2025 18 Jun 07:18 -0500, Daniel Hice wrote:
> Good afternoon,
> 
> Apologies if I’m 10,000+ in line. Is there a planned update to add
> support for the Yaesu FTX-1? Is there anything I can provide to
> assist?

Hi Daniel.

You're only about third or fourth in line.  🤣

I was told in one private query that the programmer's reference is still
unavailable from Yaesu.  Being able to get documentation on the radio
would be the biggest help.

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] b365b0: Un-break hamlib on TM-D710/TM-V71/etc

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

  Branch: refs/heads/Hamlib-4.6.3
  Home:   https://github.com/Hamlib/Hamlib
  Commit: b365b0afe0886d5b183e1739953f62f472b12631
      https://github.com/Hamlib/Hamlib/commit/b365b0afe0886d5b183e1739953f62f472b12631
  Author: Lars Kellogg-Stedman <la...@od...>
  Date:   2025-06-17 (Tue, 17 Jun 2025)

  Changed paths:
    M rigs/kenwood/kenwood.c

  Log Message:
  -----------
   Un-break hamlib on TM-D710/TM-V71/etc

Commit d1e0e3f introduced a `remove_nonprint` method that breaks hamlib on
all TM-D710/TM-V71A devices by erroneously removing the command termination
character (`\r`).

This commit adopts a solution proposed by @GeoBaltz that only runs
`remove_nonprint` if the command termination character itself is printable.

Resolves: #1767 #1698
(cherry picked from commit 85c9e15eac641ddddad57fc4b1683becaa6d7e83)


  Commit: cea177f3959cb57673573273f839bea2450f93b5
      https://github.com/Hamlib/Hamlib/commit/cea177f3959cb57673573273f839bea2450f93b5
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-06-17 (Tue, 17 Jun 2025)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  Update NEWS on Kenwood command terminator fix


Compare: https://github.com/Hamlib/Hamlib/compare/371db9ffd2ef...cea177f3959c

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

[Hamlib-developer] [Hamlib/Hamlib] 85c9e1: Un-break hamlib on TM-D710/TM-V71/etc

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 85c9e15eac641ddddad57fc4b1683becaa6d7e83
      https://github.com/Hamlib/Hamlib/commit/85c9e15eac641ddddad57fc4b1683becaa6d7e83
  Author: Lars Kellogg-Stedman <la...@od...>
  Date:   2025-06-17 (Tue, 17 Jun 2025)

  Changed paths:
    M rigs/kenwood/kenwood.c

  Log Message:
  -----------
   Un-break hamlib on TM-D710/TM-V71/etc

Commit d1e0e3f introduced a `remove_nonprint` method that breaks hamlib on
all TM-D710/TM-V71A devices by erroneously removing the command termination
character (`\r`).

This commit adopts a solution proposed by @GeoBaltz that only runs
`remove_nonprint` if the command termination character itself is printable.

Resolves: #1767 #1698


  Commit: b25ba02aca830895fe63d7aadbfd1918398e463e
      https://github.com/Hamlib/Hamlib/commit/b25ba02aca830895fe63d7aadbfd1918398e463e
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-06-17 (Tue, 17 Jun 2025)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  Update news on Kenwood command terminator fix


Compare: https://github.com/Hamlib/Hamlib/compare/aca0b2d1c63e...b25ba02aca83

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

[Hamlib-developer] Yaesu FTX-1

[Daniel H. <da...@ad...>]

Good afternoon,

Apologies if I’m 10,000+ in line. Is there a planned update to add support for the Yaesu FTX-1? Is there anything I can provide to assist?

[Hamlib-developer] rigctld port usage looks weird

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

HI!

I have feeling there is something weird with rigctld TCP port usage.
My memory may be poor, but if I remember right rigctld did not allow 
starting a new instance to same TCP port that is already in use.

Now this seems to happen:

[saku@hamtpad ~]$ rigctld --version
rigctld Hamlib 4.7~git 2025-06-09T09:26:07Z SHA=93434b 64-bit
[saku@hamtpad ~]$ /usr/local/bin/rigctld -m 1 -t 4532 &
[1] 5927
[saku@hamtpad ~]$ /usr/local/bin/rigctld -m 2 -t 4532 &
[2] 5931
[saku@hamtpad ~]$ /usr/local/bin/rigctld -m 4 -t 4532 &
[3] 5937
[saku@hamtpad ~]$ ps ax | grep rig
    5927 pts/0    Sl     0:00 /usr/local/bin/rigctld -m 1 -t 4532
    5931 pts/0    Sl     0:00 /usr/local/bin/rigctld -m 2 -t 4532
    5937 pts/0    S      0:00 /usr/local/bin/rigctld -m 4 -t 4532
    5940 pts/0    S+     0:00 grep --color=auto rig
[saku@hamtpad ~]$


Do I remember wrong?

-- 
Saku
OH1KH

[Hamlib-developer] [Hamlib/Hamlib] aca0b2: Ignore files generated when building for Windows

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: aca0b2d1c63eb27b23ce376eaf630da169c17a0a
      https://github.com/Hamlib/Hamlib/commit/aca0b2d1c63eb27b23ce376eaf630da169c17a0a
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-06-15 (Sun, 15 Jun 2025)

  Changed paths:
    M .gitignore

  Log Message:
  -----------
  Ignore files generated when building for Windows



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

[Hamlib-developer] [Hamlib/Hamlib] 49e65d: Get rid of spurious messages from \dump_caps

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 49e65de2031559c47b9b1d61692916704b93a45e
      https://github.com/Hamlib/Hamlib/commit/49e65de2031559c47b9b1d61692916704b93a45e
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-06-14 (Sat, 14 Jun 2025)

  Changed paths:
    M src/sprintflst.c

  Log Message:
  -----------
  Get rid of spurious messages from \dump_caps

rig_sprintf_func() outputs a RIG_DEBUG_ERR message for each
  function that the rig does not support.


  Commit: 07d0d91a440ba2fc43aae326f9bcb228e14d23fc
      https://github.com/Hamlib/Hamlib/commit/07d0d91a440ba2fc43aae326f9bcb228e14d23fc
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-06-15 (Sun, 15 Jun 2025)

  Changed paths:
    M rigs/dummy/dummy.c
    M rigs/icom/frame.c
    M rigs/icom/icf8101.c
    M rigs/icom/icom.c
    M src/network.c
    M tests/ampctl_parse.c
    M tests/rigctl_parse.c
    M tests/rotctl_parse.c

  Log Message:
  -----------
  Yet more cppcheck messages silenced.


Compare: https://github.com/Hamlib/Hamlib/compare/bddd3ace002e...07d0d91a440b

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

[Hamlib-developer] Yaesu FTX-1--target for 4.7.0?

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

I have received a couple of private queries about when support will land
for the FTX-1.  One of those queries also admitted that Yaesu has not
released a programmer's reference for it yet.  Whether it would be
available under an NDA, I don't know.

I do know that I won't be buying one!  The question I do have is that
apparently there is interest in it and I hope someone finds a recent
Yaesu model that will enable it to work with WSJT-X, et. al. in the
interim, should a 4.7.0 release be more or less contingent on when
support for this radio is added?

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] bddd3a: Revert 17b404a6c71f3d0bd60153a9191088e6cc9960c5

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: bddd3ace002ede56a26741838f5e11157ab7ef0d
      https://github.com/Hamlib/Hamlib/commit/bddd3ace002ede56a26741838f5e11157ab7ef0d
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-06-14 (Sat, 14 Jun 2025)

  Changed paths:
    M include/hamlib/rotator.h
    M rotators/meade/meade.c
    M src/locator.c
    M tests/rotctl_parse.c
    M tests/testloc.c

  Log Message:
  -----------
  Revert 17b404a6c71f3d0bd60153a9191088e6cc9960c5

These changes were unnecessary as the real bug is that the incorrect
function was being called in meade.c.

Closes GitHub issue #268.

Fix testloc.c



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

[Hamlib-developer] [Hamlib/Hamlib] df2bf0: Fix 0x26 command in simic705.c - off by 1 byte

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: df2bf0c6349dfc88004348631a5d9ca8bfeb138e
      https://github.com/Hamlib/Hamlib/commit/df2bf0c6349dfc88004348631a5d9ca8bfeb138e
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-06-13 (Fri, 13 Jun 2025)

  Changed paths:
    M simulators/simic705.c

  Log Message:
  -----------
  Fix 0x26 command in simic705.c - off by 1 byte

Reduce usage of rig.h idioms - use Icom values.
Reduce/cleanup some debug output.
Add width set (1A 03)



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

Re: [Hamlib-developer] 4.6.3 released!

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

Hi!

I had rigctld Hamlib 4.7~git 2025-03-12T17:49:17Z SHA=f8740d 64-bit  in 
use and now upgraded.


I tried 4.6.3 and also rigctld Hamlib 4.7~git 2025-06-09T09:26:07Z 
SHA=93434b 64-bit

Something has happened with Icom ic7300 since the 2025-03-12 release.
Everything seems to work but response is some what slower.

I had to increase poll timeout 50% because of lot of timeouts appeared.

First I thought the reason was Linux update that want always install 
Hamlib when updating because it is a dependency of some (package 
installed) programs and so there are two Hamlibs, self compiled and 
package installed.
This happens very easily if one does not look carefully the update 
process results.

After cleaned the package version away I noticed still increase of 
response times.

As so far all seems to work there is no big problem but wanted to report 
my experience FYI.

-- 
Saku
OH1KH

Re: [Hamlib-developer] hamlib Icom IC-7851 and IC-705 WSJTX

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

Strange, as none of the WSJT-X audio goes through hamlib, but direct to 
the rig.  May be a problem with setting the audio source - I don't 
remember any changes to that but I'll look into it.

One thing to check - I had a similar problem (not with either of your 
rig types, but with a TS-890S) where I thought there was no audio to the 
rig, but there was, only 30-40dB down from where it should be.  I could 
just barely hear it with the rig's monitor function.  Resetting the aux 
input gain cured the problem. You might check the levels or do the audio 
setup from scratch.

Since you're compiling from source, are you using the git repo or the 
tarballs? If it's git, doing a 'git bisect' of the problem would really 
help us diagnose the problem.

73 n3gb

On 6/12/25 11:36 AM, Manfred Antar (KN6KBS) wrote:
> The recent changes to the icom files have broken the
> wsjtx from working on my IC-7851 and IC-705
> The wsjtx recognizes the the radio and outputs the switching
> between Transmit and receive. But no transmit audio is getting to the radio.
> The last version og hamlib that works for me is:
>
>
>
> This is on a MacPro 2019 Intel.
> I compile hamlib and wsjtx from source.
> Not sure where the problem is as there were quite a few changes to the Icom rig files.
> Thanks for all your work !!!
> Manfred
> 73
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] hamlib Icom IC-7851 and IC-705 WSJTX

[Manfred A. (KN6KBS) <ma...@pa...>]

The recent changes to the icom files have broken the 
wsjtx from working on my IC-7851 and IC-705
The wsjtx recognizes the the radio and outputs the switching 
between Transmit and receive. But no transmit audio is getting to the radio.
The last version og hamlib that works for me is:

[Hamlib-developer] 4.6.3 released!

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

Hi all.

Thanks for all of the contributions that have made the 4.6.3 release
possible.  As always, the project continues on thanks to you.  No
question, the passing of Mike, Black, W9MDB, has left a void but we are
continuing on respecting Mike's work while making the changes necessary
to allow Hamlib to meet the needs of users in the modern amateur radio
station.

4.6.3 is available from the usual download sites:

https://github.com/Hamlib/Hamlib/releases/tag/4.6.3
https://sourceforge.net/projects/hamlib/files/hamlib/4.6.3/

Most visible updates from NEWS:

Version 4.6.3
        * 2025-06-10
        * Release dedicated to the memory of Michael Black, W9MDB (SK).  Mike was a
          long-time contributor to Hamlib and led development of the project for over
          five years from 2020 to 2025.  Mike passed away on March 28, 2025 due to
          complications from ALS (Lou Gehrig's disease).

        * Fix various typos in Doxygen tags.  (TNX Daniele Forsi)
        * JRC: Removed RIG_FUNC_FAGC from 535D as erroneous, Added RIG_FUNC_NB2
          functionality to both 535D and 545. (TNX Mark Fine)
        * Restore IC-7300 spectrum data callback - regression in 4.6 (n3gb)
        * Add locking to rig_[gs]et_level() - fixes sending CW from tlf (n3gb)
        * Fix attempt to use memory returned by setlocale() after being freed (TNX Mooneer Salem)
        * Language bindings configuration and build fixes (TNX Daniele Forsi)
        * Various build system and compilation fixes (TNX Daniele Forsi)
        * IC-705 filter selection bandwidth for FM and WFM (TNX Kenji Rikitake)
        * IC-705 COMP, VD, and ID meter calibration values (TNX Kenji Rikitake)
        * Fix ACLog thousands separator
        * Documentation updates, typo fixes, man page fixes (TNX Daniele Forsi)
        * Drop redundant token lookups and make local functions static (TNX George Baltz)
        * Fix rigctl showing hamlib_verson when connecting to rigctld
        * Add rig CODAN 2110


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]

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

  Branch: refs/tags/4.6.3
  Home:   https://github.com/Hamlib/Hamlib

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