hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] Bug report for Icom IC-R8600

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

Hi David,

Note that Joe released "his" WSJT-X 3.0.0 GA with an outdated Hamlib 
version. It comes with Hamlib 4.6.1 2025-01-21, meaning that this 
version is outdated for more than a year now. So, firstofall, 
IrecommendupdatingHamlibtoarecentversion(specifically4.7.0or4.7.1-rc) if 
you like to stay with 3.0.0 GA.

Furthermore, as everyone can see from the commit history, "Joe's" 3.0.0 
GA build was forked from WSJT-X Improved i+ 3.0.0 251203, 
andapparentlywasn'tverywellmaintainedafterward. 
Thismeansthateventhe251212versionofWSJT-XImproved3.0.0 
includesafewmorefixesthanWSJT-X3.0.0GA. NottomentionthelatestWSJT-X 
Improved3.1.0version(which is scheduled to be updated again on April 18, 
by the way).

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


Am 08.04.2026 um 13:01 schrieb dj...@ta... djmowen--- via 
Hamlib-developer:
>
> Hi
>
> I would like to report a possible bug in Hamlib when used with WSJT-X 
> 3.0.0.
>
> WSJT-X reports that the frequency cannot be set in the R8600 then exits.
>
> This only happens when attempting to set the frequency with the 
> frequency box in WSJT-X - when the frequency
>
> is set at the radio it is correctly recognised by WSJT-X an the 
> program runs normally.
>
> Hamlib has worked correctly in the past (about 2 years ago) with the 
> IC-R8600.
>
> I suspect that Hamlib is sending a "Select VFO A/B" command to the 
> radio even though the radio
>
> only has 1 VFO. The command error returned by the radio causes WSJT-X 
> to abort without even trying
>
> to set the frequency.
>
> Regards
>
> David Owen
>
> GM1OXB
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] K3 SWR > 2.5 at the end of every transmission.

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

Hi Nate,

Thanks for your prompt reply. Okay, 
I'llwaittoreleasemynewWSJT-XImproved3.1.0untilHamlib4.7.1hasbeenreleased. 
ThatleadsmetoconcludethatApril18isapossiblereleasedate for 
WSJT-XImproved3.1.0 (260418).

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


Am 08.04.2026 um 12:44 schrieb Nate Bargmann:
> * On 2026 07 Apr 19:16 -0500, w2yf wrote:
>> When using 4.7.1 with WSJT-X-improved and turning on the Rig data options
>> of Pwr/SWR along with the stop transmit if SWR is > 2.5, every single
>> transmit ends with an SWR over 2.5 (reports a 20.9:1 !!!).
> That would probably be seen with every prior version of Hamlib as well.
> I've also seen the glitch and it appears on my P3 with Wattmeter
> accessory as well at times and with WSJT-X 3.1.0 improved PLUS as
> packaged by Debian running with Hamlib 4.7.1~rc.
>
>> Second question, is it worth addressing?
> Given that the issue is internal to the radio, I'm not sure just how we
> could address it properly.  One thought I had was to store and average
> the last N readings but then if/when SWR really does change dramatically
> during TX (water contamination, etc.), that won't be reflected properly
> (pun intended).
>
> I suspect that the firmware is doing so many things at the point of
> ending TX that the reported SWR value gets corrupted.  Regardless, until
> about a decade ago when remote operation became very popular and near
> real-time radio control became an expectation, radios simply weren't
> designed with that amount of information flow in mind.  As you note, the
> K4 doesn't have the issue as it exists in the current era where near
> real-time control of all aspects is expected.  Also, it has an Ethernet
> port.  There is only so much data to be pushed through a serial port,
> even at 38400 bps.
>
> I appreciate your work on learning about this issue and where the
> problem lies.  I may be wrong but I just see this a part of the changing
> tech landscape where new expectations are pressed onto old(er) tech
> that's not really worth trying to paper over.  Of course, I'll merge any
> patches that do address this in a way that is helpful.
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] Bug report for Icom IC-R8600

[<dj...@ta...>]

Hi
I would like to report a possible bug in Hamlib when used with WSJT-X 
3.0.0.
 
WSJT-X reports that the frequency cannot be set in the R8600 then exits.
This only happens when attempting to set the frequency with the 
frequency box in WSJT-X - when the frequency
is set at the radio it is correctly recognised by WSJT-X an the program 
runs normally.
 
Hamlib has worked correctly in the past (about 2 years ago) with the 
IC-R8600.
 
I suspect that Hamlib is sending a "Select VFO A/B" command to 
the radio even though the radio
only has 1 VFO. The command error returned by the radio causes WSJT-X to 
abort without even trying
to set the frequency. 
 
Regards
 
David Owen
 
GM1OXB
 
 
 
 
 

Re: [Hamlib-developer] K3 SWR > 2.5 at the end of every transmission.

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

* On 2026 07 Apr 19:16 -0500, w2yf wrote:
> When using 4.7.1 with WSJT-X-improved and turning on the Rig data options
> of Pwr/SWR along with the stop transmit if SWR is > 2.5, every single
> transmit ends with an SWR over 2.5 (reports a 20.9:1 !!!).

That would probably be seen with every prior version of Hamlib as well.
I've also seen the glitch and it appears on my P3 with Wattmeter
accessory as well at times and with WSJT-X 3.1.0 improved PLUS as
packaged by Debian running with Hamlib 4.7.1~rc.

> Second question, is it worth addressing?

Given that the issue is internal to the radio, I'm not sure just how we
could address it properly.  One thought I had was to store and average
the last N readings but then if/when SWR really does change dramatically
during TX (water contamination, etc.), that won't be reflected properly
(pun intended).

I suspect that the firmware is doing so many things at the point of
ending TX that the reported SWR value gets corrupted.  Regardless, until
about a decade ago when remote operation became very popular and near
real-time radio control became an expectation, radios simply weren't
designed with that amount of information flow in mind.  As you note, the
K4 doesn't have the issue as it exists in the current era where near
real-time control of all aspects is expected.  Also, it has an Ethernet
port.  There is only so much data to be pushed through a serial port,
even at 38400 bps.

I appreciate your work on learning about this issue and where the
problem lies.  I may be wrong but I just see this a part of the changing
tech landscape where new expectations are pressed onto old(er) tech
that's not really worth trying to paper over.  Of course, I'll merge any
patches that do address this in a way that is helpful.

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] K3 SWR > 2.5 at the end of every transmission.

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

* On 2026 08 Apr 03:09 -0500, Uwe, DG2YCB via Hamlib-developer wrote:
> However, thisraisesthefollowingquestionsformeatthemoment:
> 1.
> Doyouthinkyou'llbeabletoresolvetheremainingissuesregardingPWRandSWRbythen?

So far this only is an "issue" with the Elecraft K3 and is not harming
use of the radio with WSJT-X Improved.  I am running WSKT-X v 3.1.0
Improved PLUS as packaged by Debian and it works fine.

> 2. WhendoyouplantoreleasetheofficialHamlib 4.7.1version(not -rc)?

April 15 as detailed by a previous email to this list a week ago.

> 3. IftheissuesregardingSWRsummarizedbyW2YF(see below) cannotberesolved,
> after all, whatwouldyourecommend? ShouldIthen
> stickwithHamlib4.7.0justtobeonthesafeside?
> Orarethereanyotherimportantfixesorimprovementsinversion4.7.1?

I plan to work on the power issue--QRP versus QRO--this weekend or
earlier if time permits.  I have a real life project to complete, but
anyone is welcome to offer a patch.

The SWR issue is only with certain Elecraft radios and appears to be an
issue inside the radio firmware.  There isn't much we can do about that.
There are already notes about latency within Hamlib and the more we add
the worse that gets.  Also, every command/request sent to the radio
slows things down for other functions if real-time performance is
expected.

Other important fixes are in 4.7.1 that will affect a larger audience so
you should use it.  It will be released next week whether the above are
addressed or not.

73, Nate

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

Re: [Hamlib-developer] K3 SWR > 2.5 at the end of every transmission.

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

Dear Hamlib developers,

AnewupdateforWSJT-XImproved3.1.0isscheduledtobereleasedinaweekortwo. It 
will bring some significant improvements (e.g. full support of WAS or 
similar awards, and further improvements to the FT4, FT2 and FT8 
decoders). IwouldliketouseHamlib4.7.1forthis, asitpromises to better 
supportthePWRandSWRfeatureforseveralwidelyusedElecraftrigs. 
Itrulyappreciateandcommendyoureffortsinthisregard, 
andI’mkeepingmyfingerscrossedthattheremainingissueswillberesolved!

However, thisraisesthefollowingquestionsformeatthemoment:
1. 
Doyouthinkyou'llbeabletoresolvetheremainingissuesregardingPWRandSWRbythen?
2. WhendoyouplantoreleasetheofficialHamlib 4.7.1version(not -rc)?
3. IftheissuesregardingSWRsummarizedbyW2YF(see below) cannotberesolved, 
after all, whatwouldyourecommend? ShouldIthen 
stickwithHamlib4.7.0justtobeonthesafeside? 
Orarethereanyotherimportantfixesorimprovementsinversion4.7.1?

Thanks!

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


Am 08.04.2026 um 02:15 schrieb w2yf:
>
> When using 4.7.1 with WSJT-X-improved and turning on the Rig data 
> options of Pwr/SWR along with the stop transmit if SWR is > 2.5, every 
> single transmit ends with an SWR over 2.5 (reports a 20.9:1 !!!).
>
> This occurs on an antenna which is a 1.1:1 match, and a dummy load 
> which is 1:1.
>
> The radio does not report high SWR, as a matter of fact its bar graph 
> doesn't budge above the perfect match. I inquired on the Elecraft 
> group and they said that when the power envelope is rapidly dropping 
> (end of xmit) the calculated SWR values are suspect because of the way 
> the algorithm deals with the dropping power measurement.
>
> The KX2 and KX3 also exhibit this behavior... the K4 as of yet has not...
>
> The group thinks the only fix is if hamlib deals with this as these 
> radios are old enough that the likelihood of any firmware fixes is nil.
>
> The problem is that the K3 says PTT is still enabled while it throws 
> these erroneous values, so it is almost as if multiple test would need 
> to be performed to ascertain that the SWR is really what it says it 
> is... a sort of 3 strikes and your out test (ugly).
>
> So, first question, does anyone else see this with 4.7.1, both rig 
> data options enabled with a KX2, KX3 and/or K3?
>
> Second question, is it worth addressing?
>
> Tom, W2YF
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] K3 SWR > 2.5 at the end of every transmission.

[w2yf <w2y...@gm...>]

When using 4.7.1 with WSJT-X-improved and turning on the Rig data options
of Pwr/SWR along with the stop transmit if SWR is > 2.5, every single
transmit ends with an SWR over 2.5 (reports a 20.9:1 !!!).

This occurs on an antenna which is a 1.1:1 match, and a dummy load which is
1:1.

The radio does not report high SWR, as a matter of fact its bar graph
doesn't budge above the perfect match. I inquired on the Elecraft group and
they said that when the power envelope is rapidly dropping (end of xmit)
the calculated SWR values are suspect because of the way the algorithm
deals with the dropping power measurement.

The KX2 and KX3 also exhibit this behavior... the K4 as of yet has not...

The group thinks the only fix is if hamlib deals with this as these radios
are old enough that the likelihood of any firmware fixes is nil.

The problem is that the K3 says PTT is still enabled while it throws these
erroneous values, so it is almost as if multiple test would need to be
performed to ascertain that the SWR is really what it says it is... a sort
of 3 strikes and your out test (ugly).

So, first question, does anyone else see this with 4.7.1, both rig data
options enabled with a KX2, KX3 and/or K3?

Second question, is it worth addressing?

Tom, W2YF

[Hamlib-developer] [Hamlib/Hamlib] 31d163: Make sure simft710.c rejects RF command

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 31d1635cf3fdb561fb1144df3e74733c7986a10d
      https://github.com/Hamlib/Hamlib/commit/31d1635cf3fdb561fb1144df3e74733c7986a10d
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-04-03 (Fri, 03 Apr 2026)

  Changed paths:
    M simulators/simft710.c

  Log Message:
  -----------
  Make sure simft710.c rejects RF command

No roofing filters on this rig.
Clean out includes of rig.h and misc.c


  Commit: bf5bea401268b28cce611a6ed7509b2dada74f5c
      https://github.com/Hamlib/Hamlib/commit/bf5bea401268b28cce611a6ed7509b2dada74f5c
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-04-04 (Sat, 04 Apr 2026)

  Changed paths:
    M rigs/yaesu/newcat.c
    M simulators/simft710.c

  Log Message:
  -----------
  Use the correct SH command in newcat_set_rx_bandwidth() and simft710.c

FT-710 CAT Operations Manual says the FT-710 has 2 leading zeroes (P1
  & P2), not just 1.

Fix missing "== 0"


Compare: https://github.com/Hamlib/Hamlib/compare/1fa3444884eb...bf5bea401268

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

Re: [Hamlib-developer] Pulling my hair out

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

Hello Mike,

show the cull command line that you are using for rotctl and the debug
output with -vvvvv

--
73 de IU5HKX Daniele

Re: [Hamlib-developer] Elecraft K3 power output problem.

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

* On 2026 04 Apr 03:33 -0500, Daniele Forsi wrote:
> Nate Bargmann wrote:
> 
> > So, digging into this with my K3 I find that my radio is returning a
> > different string than the manual states with four digits instead of
> > three.  The first three digits appear to be the set power level and the
> > fourth the PA in use with 0 being the built-in and 1 being the KPA-100.
> 
> the manual
> "ELECRAFT K3S/K3/KX3/KX2 PROGRAMMER'S REFERENCE" Rev. G5, Feb. 20, 2019
> says tha K22 adds the fourth digit with 0 low range and 1 high range

Thanks for that catch.  It looks like our code does set that parameter
and hence the fourth digit is received.

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] Elecraft K3 power output problem.

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

Nate Bargmann wrote:

> So, digging into this with my K3 I find that my radio is returning a
> different string than the manual states with four digits instead of
> three.  The first three digits appear to be the set power level and the
> fourth the PA in use with 0 being the built-in and 1 being the KPA-100.

the manual
"ELECRAFT K3S/K3/KX3/KX2 PROGRAMMER'S REFERENCE" Rev. G5, Feb. 20, 2019
says tha K22 adds the fourth digit with 0 low range and 1 high range

-- 
73 de IU5HKX Daniele

[Hamlib-developer] Pulling my hair out

[Michael M. <mi...@mu...>]

I am trying to use a Sky Watcher ATGTe mount as a rotator.  Using Satdump I
get dozens of rotator errors when tracking a satellite.  Here is an example:

[06:37:55 - 03/04/2026] (E) Error setting rotator position 38.449001
43.745998!

Here is my start command which is run through a batch file at startup:

start rotctld -m 2801 -r com7 -s 9600 -t 4533
--set-conf=min_az=0,max_az=360 -vvvvv

If I start rotctl in interactive mode and issue the following commands:

Rotator command: p
Azimuth: 30.00
Elevation: 30.00

Rotator command: P 40 40
Azimuth: Elevation:
Rotator command: p
Azimuth: 40.00
Elevation: 40.00

Only the rotator never moved.

When I issue this command from a command prompt the rotator moves
accurately:

rotctl -m 2801 -r com7 P 222.0 43.1

In any event I think the position errors are prevent accurate tracking.

Can you help me?

Mike Mulcahy

[Hamlib-developer] [Hamlib/Hamlib] 7fb567: Fix attenuator limit in level_gran_yaesu.h

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

  Branch: refs/heads/Hamlib-4.7
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 7fb567333cd103233488cade41c9805e23e11219
      https://github.com/Hamlib/Hamlib/commit/7fb567333cd103233488cade41c9805e23e11219
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-04-03 (Fri, 03 Apr 2026)

  Changed paths:
    M rigs/yaesu/level_gran_yaesu.h

  Log Message:
  -----------
  Fix attenuator limit in level_gran_yaesu.h

Since the individual attenuator steps are checked in newcat.c, let
  the max value through rig_check_level.  Fixes issue #2023

Also noticed a typo in the kludge for reinitializing structure data. This
  meant there was no LVL_KEYSPD data for Yaesu rigs for over a year.

(cherry picked from commit 30d0be546b3f6b4194366889f5902fd7d743a454)


  Commit: 459023b2bb7227a9721a7a94ec8bd7e455aae79b
      https://github.com/Hamlib/Hamlib/commit/459023b2bb7227a9721a7a94ec8bd7e455aae79b
  Author: Nate Bargmann <n0...@n0...>
  Date:   2026-04-03 (Fri, 03 Apr 2026)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  Update NEWS for Icom and Yaesu fixes

Set release date to 15 Apr 2026.


Compare: https://github.com/Hamlib/Hamlib/compare/66cc6d8ac6b2...459023b2bb72

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

[Hamlib-developer] [Hamlib/Hamlib] 30d0be: Fix attenuator limit in level_gran_yaesu.h

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 30d0be546b3f6b4194366889f5902fd7d743a454
      https://github.com/Hamlib/Hamlib/commit/30d0be546b3f6b4194366889f5902fd7d743a454
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-30 (Mon, 30 Mar 2026)

  Changed paths:
    M rigs/yaesu/level_gran_yaesu.h

  Log Message:
  -----------
  Fix attenuator limit in level_gran_yaesu.h

Since the individual attenuator steps are checked in newcat.c, let
  the max value through rig_check_level.  Fixes issue #2023

Also noticed a typo in the kludge for reinitializing structure data. This
  meant there was no LVL_KEYSPD data for Yaesu rigs for over a year.


  Commit: 1fa3444884eb76e63c879d09c6527b479b175f8d
      https://github.com/Hamlib/Hamlib/commit/1fa3444884eb76e63c879d09c6527b479b175f8d
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-04-01 (Wed, 01 Apr 2026)

  Changed paths:
    M rigs/yaesu/newcat.c

  Log Message:
  -----------
  Fix some obvious errors in newcat.c

Try a few shots in the dark for issues #2021 & #2024

Acknowledge that the FT-710 does NOT have an "RF" command.
Don't call newcat_set_roofing_filter_for_width() if there are
  no roofing filters available.
Fix runaway search for matching roofing filters; use count as there
  are no end entries the filter table.

I really can't test these(no hardware), but just looking at the code
  and the traces from the issues above it's evident that these things
  are broken. This may not fix everything, and may even break in new ways,
  but it may make the actual problems a bit easier to find.


Compare: https://github.com/Hamlib/Hamlib/compare/0b2f36f0a6af...1fa3444884eb

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

Re: [Hamlib-developer] Elecraft K3 power output problem.

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

So, digging into this with my K3 I find that my radio is returning a
different string than the manual states with four digits instead of
three.  The first three digits appear to be the set power level and the
fourth the PA in use with 0 being the built-in and 1 being the KPA-100.
It is quite apparent when the 12/13W switch point is crossed:

Rig command: w
rigctl_parse: input_line: w
Command: pc;
rigctl_parse: vfo_opt=0
rigctl_parse.c(5172):rigctl_send_cmd entered
rigctl_send_cmd: backend_num=2
rigctl_send_cmd: KENWOOD
rigctl_send_cmd: arg1=pc;
rigctl_send_cmd: bufcmd=pc;
rigctl_send_cmd: text protocol, send_cmd_term=0x0a 0x0d 0x00
rigctl_send_cmd: rigport=5, bufcmd=pc;, cmd_len=3
write_block(): TX 3 bytes
0000    70 63 3b                                            pc;             
rigctl_send_cmd: debug Cmd
read_string_generic(): RX 7 characters, direct=1
0000    50 43 30 34 35 31 3b                                PC0451;         
rigctl_parse.c(5479):rigctl_send_cmd returning2(0) 
Reply: PC0451;rigctl_parse: called, interactive=1

Rig command: w pc;
rigctl_parse: input_line: w pc;
rigctl_parse: vfo_opt=0
rigctl_parse.c(5172):rigctl_send_cmd entered
rigctl_send_cmd: backend_num=2
rigctl_send_cmd: KENWOOD
rigctl_send_cmd: arg1=pc;
rigctl_send_cmd: bufcmd=pc;
rigctl_send_cmd: text protocol, send_cmd_term=0x0a 0x0d 0x00
rigctl_send_cmd: rigport=5, bufcmd=pc;, cmd_len=3
write_block(): TX 3 bytes
0000    70 63 3b                                            pc;             
rigctl_send_cmd: debug Cmd
read_string_generic(): RX 7 characters, direct=1
0000    50 43 30 31 33 31 3b                                PC0131;         
rigctl_parse.c(5479):rigctl_send_cmd returning2(0) 
Reply: PC0131;rigctl_parse: called, interactive=1

Rig command: w pc;
rigctl_parse: input_line: w pc;
rigctl_parse: vfo_opt=0
rigctl_parse.c(5172):rigctl_send_cmd entered
rigctl_send_cmd: backend_num=2
rigctl_send_cmd: KENWOOD
rigctl_send_cmd: arg1=pc;
rigctl_send_cmd: bufcmd=pc;
rigctl_send_cmd: text protocol, send_cmd_term=0x0a 0x0d 0x00
rigctl_send_cmd: rigport=5, bufcmd=pc;, cmd_len=3
write_block(): TX 3 bytes
0000    70 63 3b                                            pc;             
rigctl_send_cmd: debug Cmd
read_string_generic(): RX 7 characters, direct=1
0000    50 43 31 32 30 30 3b                                PC1200;         
rigctl_parse.c(5479):rigctl_send_cmd returning2(0) 
Reply: PC1200;rigctl_parse: called, interactive=1

Rig command: w pc;
rigctl_parse: input_line: w pc;
rigctl_parse: vfo_opt=0
rigctl_parse.c(5172):rigctl_send_cmd entered
rigctl_send_cmd: backend_num=2
rigctl_send_cmd: KENWOOD
rigctl_send_cmd: arg1=pc;
rigctl_send_cmd: bufcmd=pc;
rigctl_send_cmd: text protocol, send_cmd_term=0x0a 0x0d 0x00
rigctl_send_cmd: rigport=5, bufcmd=pc;, cmd_len=3
write_block(): TX 3 bytes
0000    70 63 3b                                            pc;             
rigctl_send_cmd: debug Cmd
read_string_generic(): RX 7 characters, direct=1
0000    50 43 30 35 30 30 3b                                PC0500;         
rigctl_parse.c(5479):rigctl_send_cmd returning2(0) 
Reply: PC0500;rigctl_parse: called, interactive=1

Rig command: w pc;
rigctl_parse: input_line: w pc;
rigctl_parse: vfo_opt=0
rigctl_parse.c(5172):rigctl_send_cmd entered
rigctl_send_cmd: backend_num=2
rigctl_send_cmd: KENWOOD
rigctl_send_cmd: arg1=pc;
rigctl_send_cmd: bufcmd=pc;
rigctl_send_cmd: text protocol, send_cmd_term=0x0a 0x0d 0x00
rigctl_send_cmd: rigport=5, bufcmd=pc;, cmd_len=3
write_block(): TX 3 bytes
0000    70 63 3b                                            pc;             
rigctl_send_cmd: debug Cmd
read_string_generic(): RX 7 characters, direct=1
0000    50 43 30 30 30 30 3b                                PC0000;         
rigctl_parse.c(5479):rigctl_send_cmd returning2(0) 
Reply: PC0000;rigctl_parse: called, interactive=1

Rig command: w pc;
rigctl_parse: input_line: w pc;
rigctl_parse: vfo_opt=0
rigctl_parse.c(5172):rigctl_send_cmd entered
rigctl_send_cmd: backend_num=2
rigctl_send_cmd: KENWOOD
rigctl_send_cmd: arg1=pc;
rigctl_send_cmd: bufcmd=pc;
rigctl_send_cmd: text protocol, send_cmd_term=0x0a 0x0d 0x00
rigctl_send_cmd: rigport=5, bufcmd=pc;, cmd_len=3
write_block(): TX 3 bytes
0000    70 63 3b                                            pc;             
rigctl_send_cmd: debug Cmd
read_string_generic(): RX 7 characters, direct=1
0000    50 43 30 30 31 30 3b                                PC0010;         
rigctl_parse.c(5479):rigctl_send_cmd returning2(0) 
Reply: PC0010;rigctl_parse: called, interactive=1


My questions now are, what firmware revision changed this?  Does yours
return three or four digits?

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] April 15 as the tentative release date of 4.7.1

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

As the subject states, I am considering releasing 4.7.1 on April 15--two
week's time.  I'm sure there will be plenty of reasons to release 4.7.2
at some point soon...

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] Rig control errors

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

Hi Dave.

You may have missed my earlier message as I tend to only reply to the
list.

It is my guess that the radio has gotten out of sync in some way.
Another thought occurred as to whether the radio is in "auto
information" mode.  I'm not sure if WSJT-X turns that on or not (I
suspect not).

The manual states that the auto info mode is turned off when the radio
is powered off.

Again, I am just guessing.

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] Rig control errors

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

* On 2026 01 Apr 07:41 -0500, Dave Wood wrote:
> Dear Hamlib Developers
> 
> I am getting a very random Rig Control error.
> It appears to be totally random and does not appear to be RF related. In fact most of it happens when the radio is not transmitting.
> Using WSJTX for FT8, mostly when receiving. Radio is Yaesu FTX-1, currently with latest firmware.
> Windows 11 with latest everything, drivers software and updates. This has been happening since using my FTX-1 for 6 months plus
> Everything is up to date, all software and drivers. I have tried many different USB cables with and without ferrites.
> All cables have ferrites on both ends.
> Below is one of these errors
> 
> Hamlib error: read_string_generic called, rxmax=129 direct=1, expected_len=1
> read_string_generic(): RX 7 characters, direct=1
> 0000 53 48 30 30 31 39 3b SH0019;
> newcat_get_cmd: read count = 7, ret_data = SH0019;
> newcat_get_cmd: wrong reply SH for command TX
> cmd_str = TX;
> write_block(): TX 3 bytes
> 0000 54 58 3b TX;
> read_string_generic called, rxmax=129 direct=1, expected_len=1
> read_string_generic(): RX 7 characters, direct=1
> 0000 53 48 30 30 31 39 3b SH0019;
> newcat_get_cmd: read count = 7, ret_data = SH0019;
> newcat_get_cmd: wrong reply SH for command TX
> **2:newcat.c(11344):newcat_get_cmd returning(-8) Protocol error
> 
> *1:rig_get_ptt: elapsed=247ms
> rig_lock: client lock disengaged
> *1:rig.c(4036):rig_get_ptt returning(-8) Protocol error
> 
> Protocol error
> while getting PTT state
> 
> Timestamp: 2026-04-01T12:29:13.362Z

Hi Dave.

I doubt that the issue is related to USB or its subsystem driver nor
application software.  It appears the radio is simply returning the
wrong response to the query as though things have gotten out of sync.

The SH response, according to the manual I grabbed, is showing the RX
bandwidth as 2900 Hz in SSB or 3200 Hz in DATA mode on the Main RX,
which is definitely an incorrect response to the TX query.

Hopefully someone can go into more detail with you on this.

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] Rig control errors

[Dave W. <ds...@ou...>]

Dear Hamlib Developers

I am getting a very random Rig Control error.
It appears to be totally random and does not appear to be RF related. In fact most of it happens when the radio is not transmitting.
Using WSJTX for FT8, mostly when receiving. Radio is Yaesu FTX-1, currently with latest firmware.
Windows 11 with latest everything, drivers software and updates. This has been happening since using my FTX-1 for 6 months plus
Everything is up to date, all software and drivers. I have tried many different USB cables with and without ferrites.
All cables have ferrites on both ends.
Below is one of these errors

Hamlib error: read_string_generic called, rxmax=129 direct=1, expected_len=1
read_string_generic(): RX 7 characters, direct=1
0000 53 48 30 30 31 39 3b SH0019;
newcat_get_cmd: read count = 7, ret_data = SH0019;
newcat_get_cmd: wrong reply SH for command TX
cmd_str = TX;
write_block(): TX 3 bytes
0000 54 58 3b TX;
read_string_generic called, rxmax=129 direct=1, expected_len=1
read_string_generic(): RX 7 characters, direct=1
0000 53 48 30 30 31 39 3b SH0019;
newcat_get_cmd: read count = 7, ret_data = SH0019;
newcat_get_cmd: wrong reply SH for command TX
**2:newcat.c(11344):newcat_get_cmd returning(-8) Protocol error

*1:rig_get_ptt: elapsed=247ms
rig_lock: client lock disengaged
*1:rig.c(4036):rig_get_ptt returning(-8) Protocol error

Protocol error
while getting PTT state

Timestamp: 2026-04-01T12:29:13.362Z

David
M0WOO

[Hamlib-developer] Changing audio source with ICOM 7300 and HAMLIB?

[Richard E. <do...@ho...>]

Hello.


Is it possible to select the audio input source using HAMLIB with cat 
commands on my 7300? As mic, USB and so on? If yes, whats the command 
section to look at?


Thanks in advance


Richard, DO9RE

[Hamlib-developer] [Hamlib/Hamlib] 36ccee: Add generalized routines for Icom clock handling

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

  Branch: refs/heads/Hamlib-4.7
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 36ccee9bf7b9acd321df002583a18457830b28e1
      https://github.com/Hamlib/Hamlib/commit/36ccee9bf7b9acd321df002583a18457830b28e1
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-29 (Sun, 29 Mar 2026)

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

  Log Message:
  -----------
  Add generalized routines for Icom clock handling

Relies or new structure in priv_caps to find values of 0x1A 0x05
  subcommands for date, time, and offset data.

Also sets offset first, so later values are stored relative to the new one,
  not whatever was there before.

(cherry picked from commit 1512278872723f61a4ae30714c36aa4098f2417b)


  Commit: d4a2568c53ebd6356c3795a240f7b2e904e79121
      https://github.com/Hamlib/Hamlib/commit/d4a2568c53ebd6356c3795a240f7b2e904e79121
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-29 (Sun, 29 Mar 2026)

  Changed paths:
    M rigs/icom/Makefile.am
    M rigs/icom/ic7300.c
    R rigs/icom/ic7300.h
    M rigs/icom/ic785x.c

  Log Message:
  -----------
  First uses of icom_[gs]et_clock

Removes ic7300_[gs]_clock and rigs/icom/ic7300.h
Make ic785x.c less dependent on other rigs.

(cherry picked from commit faed43703b2e53b5465f667fb07221fd89e60429)


  Commit: b4afe37fcf1c50c48a0647e44900cc4dbd679266
      https://github.com/Hamlib/Hamlib/commit/b4afe37fcf1c50c48a0647e44900cc4dbd679266
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-29 (Sun, 29 Mar 2026)

  Changed paths:
    M rigs/icom/ic7300.c

  Log Message:
  -----------
  Fixes for IC-705 and IC-905

Add clock set/get to both rigs.
Add custom extcmds for IC-905
Fix RIG_LEVEL_USB_AF for IC-705 so it sets AF gain, not IF gain.
Make local data items static.

(cherry picked from commit 3d68d50a5bf27251c568d0eb2d17ce036d985c84)


  Commit: 9ea4409f71ff8692bd7318049b4c04dd1517f4ee
      https://github.com/Hamlib/Hamlib/commit/9ea4409f71ff8692bd7318049b4c04dd1517f4ee
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-29 (Sun, 29 Mar 2026)

  Changed paths:
    M rigs/icom/ic7410.c
    M rigs/icom/ic7800.c
    M rigs/icom/ic785x.c
    M rigs/icom/icr30.c

  Log Message:
  -----------
  Tidy up more Icom rigs.

Use icom_*_clock() in ic-7800
Make more local data static
Fix some more bad parameters in extcmds.

(cherry picked from commit 688762df27450630ab907b4fac49370932528231)


  Commit: 9f610e6c63b5183c74b20f60d221c0e93aa170ae
      https://github.com/Hamlib/Hamlib/commit/9f610e6c63b5183c74b20f60d221c0e93aa170ae
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-29 (Sun, 29 Mar 2026)

  Changed paths:
    M rigs/icom/ic7000.c
    M rigs/icom/ic7100.c
    M rigs/icom/ic9100.c

  Log Message:
  -----------
  Clean up IC-7000, IC-7100, and IC-9100

Replace clock routines in ic7100.c

(cherry picked from commit 48dc2d2bc8f0ee9daddcbcd2beb57fbc291197d5)


  Commit: 66cc6d8ac6b26184454688851f835a8d9fcef6f8
      https://github.com/Hamlib/Hamlib/commit/66cc6d8ac6b26184454688851f835a8d9fcef6f8
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-29 (Sun, 29 Mar 2026)

  Changed paths:
    M rigs/icom/ic7300.c

  Log Message:
  -----------
  Update IC-9700

Also mentioned in issue #2018

(cherry picked from commit 0b2f36f0a6af5f64eaf474972a5f73ac720ecf02)


Compare: https://github.com/Hamlib/Hamlib/compare/fdb413ebdbb3...66cc6d8ac6b2

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

[Hamlib-developer] [Hamlib/Hamlib] 151227: Add generalized routines for Icom clock handling

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 1512278872723f61a4ae30714c36aa4098f2417b
      https://github.com/Hamlib/Hamlib/commit/1512278872723f61a4ae30714c36aa4098f2417b
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-26 (Thu, 26 Mar 2026)

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

  Log Message:
  -----------
  Add generalized routines for Icom clock handling

Relies or new structure in priv_caps to find values of 0x1A 0x05
  subcommands for date, time, and offset data.

Also sets offset first, so later values are stored relative to the new one,
  not whatever was there before.


  Commit: faed43703b2e53b5465f667fb07221fd89e60429
      https://github.com/Hamlib/Hamlib/commit/faed43703b2e53b5465f667fb07221fd89e60429
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-26 (Thu, 26 Mar 2026)

  Changed paths:
    M rigs/icom/Makefile.am
    M rigs/icom/ic7300.c
    R rigs/icom/ic7300.h
    M rigs/icom/ic785x.c

  Log Message:
  -----------
  First uses of icom_[gs]et_clock

Removes ic7300_[gs]_clock and rigs/icom/ic7300.h
Make ic785x.c less dependent on other rigs.


  Commit: 3d68d50a5bf27251c568d0eb2d17ce036d985c84
      https://github.com/Hamlib/Hamlib/commit/3d68d50a5bf27251c568d0eb2d17ce036d985c84
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-26 (Thu, 26 Mar 2026)

  Changed paths:
    M rigs/icom/ic7300.c

  Log Message:
  -----------
  Fixes for IC-705 and IC-905

Add clock set/get to both rigs.
Add custom extcmds for IC-905
Fix RIG_LEVEL_USB_AF for IC-705 so it sets AF gain, not IF gain.
Make local data items static.


  Commit: 688762df27450630ab907b4fac49370932528231
      https://github.com/Hamlib/Hamlib/commit/688762df27450630ab907b4fac49370932528231
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-26 (Thu, 26 Mar 2026)

  Changed paths:
    M rigs/icom/ic7410.c
    M rigs/icom/ic7800.c
    M rigs/icom/ic785x.c
    M rigs/icom/icr30.c

  Log Message:
  -----------
  Tidy up more Icom rigs.

Use icom_*_clock() in ic-7800
Make more local data static
Fix some more bad parameters in extcmds.


  Commit: 48dc2d2bc8f0ee9daddcbcd2beb57fbc291197d5
      https://github.com/Hamlib/Hamlib/commit/48dc2d2bc8f0ee9daddcbcd2beb57fbc291197d5
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-26 (Thu, 26 Mar 2026)

  Changed paths:
    M rigs/icom/ic7000.c
    M rigs/icom/ic7100.c
    M rigs/icom/ic9100.c

  Log Message:
  -----------
  Clean up IC-7000, IC-7100, and IC-9100

Replace clock routines in ic7100.c


  Commit: 0b2f36f0a6af5f64eaf474972a5f73ac720ecf02
      https://github.com/Hamlib/Hamlib/commit/0b2f36f0a6af5f64eaf474972a5f73ac720ecf02
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-27 (Fri, 27 Mar 2026)

  Changed paths:
    M rigs/icom/ic7300.c

  Log Message:
  -----------
  Update IC-9700

Also mentioned in issue #2018


Compare: https://github.com/Hamlib/Hamlib/compare/debe6fcaf998...0b2f36f0a6af

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

[Hamlib-developer] [Hamlib/Hamlib] 3cf97b: Add support for rigs using the 'Simple CAT' protocol

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

  Branch: refs/heads/Hamlib-4.7
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 3cf97b5a5b91f211ce11f1c731d0eb4fdd2aa61c
      https://github.com/Hamlib/Hamlib/commit/3cf97b5a5b91f211ce11f1c731d0eb4fdd2aa61c
  Author: Dhiru Kholia <kh...@us...>
  Date:   2026-03-26 (Thu, 26 Mar 2026)

  Changed paths:
    M bindings/python/test_Hamlib_class.py
    M configure.ac
    M include/hamlib/riglist.h
    A rigs/simplecat/Android.mk
    A rigs/simplecat/Makefile.am
    A rigs/simplecat/SIMPLE_CAT_PROTOCOL.md
    A rigs/simplecat/simplecat.c
    A rigs/simplecat/simplecat.h
    M src/register.c

  Log Message:
  -----------
  Add support for rigs using the 'Simple CAT' protocol

See 'rigs/simplecat/SIMPLE_CAT_PROTOCOL.md' for the protocol spec.

Notes:

- Memory correctness checks were done using Valgrind.

- Tested with wsjtx-3.1.0_improved_PLUS_260228.tgz (with mods) and
  Bunzee Labs' DDX HF Digital Transceiver

  https://bunzee-labs.com/products/ddx

Tested on:

- Ubuntu Linux
- macOS Tahoe
- Windows 11

(cherry picked from commit debe6fcaf9983cabd0f80eca50f48f3a998ca5e9)


  Commit: fdb413ebdbb3422c7e9c17f33bf5e35b99931172
      https://github.com/Hamlib/Hamlib/commit/fdb413ebdbb3422c7e9c17f33bf5e35b99931172
  Author: Nate Bargmann <n0...@n0...>
  Date:   2026-03-26 (Thu, 26 Mar 2026)

  Changed paths:
    M NEWS
    M rigs/simplecat/simplecat.c

  Log Message:
  -----------
  Quell warning from MinGW; update NEWS for simplecat

MinGW generated the following warning:

Making install in rigs/simplecat
  CC       simplecat.lo
simplecat.c: In function 'simplecat_transaction':
simplecat.c:94:17: warning: the comparison will always evaluate as 'true' for the address of 'state' will never be NULL [-Waddress]
   94 |     if (!rig || !STATE(rig))
      |                 ^
In file included from simplecat.c:27:
../../include/hamlib/rig.h:2672:22: note: 'state' declared here
 2672 |     struct rig_state state;         /*!< Rig state */
      |                      ^~~~~
  CCLD     libhamlib-simplecat.la

This warning is due to the changes to the state structure in Hamlib 5+.


Compare: https://github.com/Hamlib/Hamlib/compare/7ff995e0b888...fdb413ebdbb3

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

[Hamlib-developer] [Hamlib/Hamlib] debe6f: Add support for rigs using the 'Simple CAT' protocol

[Dhiru K. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: debe6fcaf9983cabd0f80eca50f48f3a998ca5e9
      https://github.com/Hamlib/Hamlib/commit/debe6fcaf9983cabd0f80eca50f48f3a998ca5e9
  Author: Dhiru Kholia <kh...@us...>
  Date:   2026-03-25 (Wed, 25 Mar 2026)

  Changed paths:
    M bindings/python/test_Hamlib_class.py
    M configure.ac
    M include/hamlib/riglist.h
    A rigs/simplecat/Android.mk
    A rigs/simplecat/Makefile.am
    A rigs/simplecat/SIMPLE_CAT_PROTOCOL.md
    A rigs/simplecat/simplecat.c
    A rigs/simplecat/simplecat.h
    M src/register.c

  Log Message:
  -----------
  Add support for rigs using the 'Simple CAT' protocol

See 'rigs/simplecat/SIMPLE_CAT_PROTOCOL.md' for the protocol spec.

Notes:

- Memory correctness checks were done using Valgrind.

- Tested with wsjtx-3.1.0_improved_PLUS_260228.tgz (with mods) and
  Bunzee Labs' DDX HF Digital Transceiver

  https://bunzee-labs.com/products/ddx

Tested on:

- Ubuntu Linux
- macOS Tahoe
- Windows 11



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

Re: [Hamlib-developer] de JH3ECA

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

* On 2026 18 Mar 06:30 -0500, jh3eca--- via Hamlib-developer wrote:
> My name is Nakajima (JH3ECA).

Hi Nakajima, welcome to Hamlib.

> I'm using an ICOM IC-7300MK2.

It has received support in Hamlib 4.7.0 released about a month ago.

> I copy and paste "libhamlib4.dll" every time I use it.

Do you mean that it gets deleted from your application and you have to
copy it from a downloaded copy of hamlib-w64-4.7.0.zip and copy it over?

> Would it be possible for you to upload a version of "libhamlib4.dll"
> that is compatible with the ICOM IC-7300MK2?

I could add directories for the 32 and 64 bit versions of the DLL and
upload them separately, but it seems as easy for you to download the ZIP
file and extract it to a directory outside of your application directory
and then copy the DLL into your application directory as needed.

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