hamlib-developer — hamlib developers forum

[Hamlib-developer] (no subject)

[Bob N. <bn...@gm...>]

Setting up GPREDICT with my IC-7900. It's communicating, but I get several
errors. Not sure what to do. Are there additional parameters that I need to
add to the command line?

Radio is setup and COM 7 is 115200 baud. Any help is greatly appreciated.


This is the command line I am running on the Windows desktop

"C:\Program Files\hamlib-w64-4.6.2\bin\rigctld.exe" -m 3081 -r COM7 -t 4532
-s 115200 -vvv





This is what I get when I run it:

icom_get_powerstat: get freq failed, assuming power is off

icom_rig_open: rig error getting frequency retry=1, err=read_string_generic
called, rxmax=200 direct=1, expected_len=1

read_string_generic(): RX 6 characters, direct=1

*****5:frame.c(452):icom_one_transaction returning(-9) Command rejected by
the rig

Command rejected by the rig

****4:frame.c(556):icom_transaction returning(-9) Command rejected by the
rig

rig_get_freq(2597): freqMainA=0, modeMainA=, widthMainA=0

rig_get_freq(2597): freqMainB=0, modeMainB=, widthMainB=0

rig_get_freq(2597): freqSubA=0, modeSubA=, widthSubA=0

rig_get_freq(2597): freqSubB=0, modeSubB=, widthSubB=0

rig_get_cache(328):  vfo=currVFO, current_vfo=currVFO

rig_get_cache(523): vfo=VFOA, freq=0, mode=, width=0

rig_set_cache_freq(171):  vfo=currVFO, current_vfo=currVFO

***3:rig_get_freq: elapsed=0ms

***3:rig.c(2714):rig_get_freq returning(-9) Command rejected by the rig

Command rejected by the rig

Command rejected by the rig

icom_rig_open: rig error getting frequency retry=0, err=read_string_generic
called, rxmax=200 direct=1, expected_len=1

read_string_generic(): RX 6 characters, direct=1

*****5:frame.c(452):icom_one_transaction returning(-9) Command rejected by
the rig

Command rejected by the rig

****4:frame.c(556):icom_transaction returning(-9) Command rejected by the
rig

rig_get_freq(2597): freqMainA=0, modeMainA=, widthMainA=0

rig_get_freq(2597): freqMainB=0, modeMainB=, widthMainB=0

rig_get_freq(2597): freqSubA=0, modeSubA=, widthSubA=0

rig_get_freq(2597): freqSubB=0, modeSubB=, widthSubB=0

rig_get_cache(328):  vfo=currVFO, current_vfo=currVFO

rig_get_cache(523): vfo=VFOA, freq=0, mode=, width=0

rig_set_cache_freq(171):  vfo=currVFO, current_vfo=currVFO

***3:rig_get_freq: elapsed=4ms

***3:rig.c(2714):rig_get_freq returning(-9) Command rejected by the rig

Command rejected by the rig

Command rejected by the rig

Opened rig model 3081, 'IC-9700'






-- 
Bob Nazro, W1RPQ
phone: (860) 941-7993
b <Jos...@cp...>na...@gm...

Re: [Hamlib-developer] Question on Frequency Adjustment with Rigctl

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

On 4/17/25 2:11 PM, Stefan Jansen wrote:
> Hi David, hi list,
>
> First, let men introduce myself. I am Stefan, living in Germany and 
> developing together with Richard on a piece of software that uses 
> hamlib and mainly rigctl.
>
> Now back to the topic if this thread:
>
> David, it is clear that you do not have to query the current frequency 
> before setting an arbitrary new value. But what if you want to just 
> increase the current frequency by, let’s say, 1kHz? To do so, would 
> you query the current frequency with the „f“ command, add 1000 to it 
> and set the new value with „F“? Or is there a command to just 
> increment or decrement the current frequency by a given step size?
>
See rig_vfo_op(), which does have UP/DOWN operations. Implementation may 
depend on what each rig can do.
> Vy 73 de Stefan, DK7STJ
>
> --
> Stefan Jansen    ***    E-Mail: DK7STJ@darc.d

-- 

73 n3gb

[Hamlib-developer] Actually a difference for get and set_functions list for certain transceiver?

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

Greetings Listers.


I am wondering, if there are actually transceivers, for which there is a 
difference in the lists for get and set_functions, when used with the 
question mark parameter or in the dump caps list? I ask, because we 
write toggle scripts for functions in accordance with the list retrived 
from the output of set_functions ?. So: Do we need to check against the 
output from get_functions ?, to see, if there is a difference, or can we 
assume, that every function which can be setted also can be getted and 
the otherway around?


Thanks in advance


-- 
73

Richard, DO9RE

Re: [Hamlib-developer] Where does the data for certain lists come from?

[David B. <da...@ba...>]

The parameters for a radio are stored in the radio Hamlib backend as you can't query a radio for its supported parameters, those have to be gleaned from the CAT listing for the radio.

There is no explicit "list supported modes" command. Using rigctl and the -u command you can extract the modes from the Bandwidth list. You can do the same with the Hamlib API.

Looking at a the Hamlib listing for a radio, there is a differentiation between TX modes and RX modes, but not VFO.

If you want to check the if a mode is supported by a particular VFO, you could try and set the mode and see if the return is an error. No error it is supported, error not supported.

73 de David M0DGB/G8FKH



-----Original Message-----
From: Richard Emling <DO...@ho...> 
Sent: 17 April 2025 23:18
To: Hamlib Developers Mailingliste <ham...@li...>
Subject: [Hamlib-developer] Where does the data for certain lists come from?

Hi everyone,

I've been exploring some list commands and I'm wondering where exactly the information returned by these commands originates.

Currently, I retrieve all necessary details using the --caps-dump command, which works fine. However, it would be great if I could use for example get_modes and  get_vfo_list instead. My main question is: are these lists generated based on data from the backend (e.g., the Raspberry Pi), or are they fetched directly from the connected radio each time the command is issued?

The distinction is important, since not all radios are capable of reporting their supported modes or VFO combinations. If the radio is queried every time, this would make the commands less reliable across diverse hardware.

Additionally, is there any way to generate these lists dynamically depending on the currently selected VFO? For instance, We've come across radios where for example VFOA supports FM, AM, and Digital, but VFOB supports only FM and Digital. It would be very useful if the command could reflect these distinctions based on actual capabilities.

Thanks a lot in advance!

--
73

Richard, DO9RE



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

Re: [Hamlib-developer] Hamlib version in Raspbian Bookworm the latest?

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

* On 2025 17 Apr 17:41 -0500, Richard Emling wrote:
> Hi Nate.
> 
> 
> I had a look at the sources. This is taff. Dunno, if I am able to compile
> this. Are there pre compiled binaries available for Raspi OS Bookworm? Or
> could you point me to where to start when I need to compile it myself?

Hi Richard.

I don't know if anyone is providing up-to-date packages for RPi OS
Bookworm.  If that is being done, I'd like to add a link to our Web
sites for such packages.

For compiling on your system, you can install the build-essential package which 
should pull in everything needed for a basic build of Hamlib.  The
released source tarball has already been prepared for ease compilation.
For the latest release this archive is:

https://github.com/Hamlib/Hamlib/releases/download/4.6.2/hamlib-4.6.2.tar.gz

The archive will unpack into its own directory named hamlib-4.6.2 with
all files and other directories under that.  In that directory you
should find the INSTALL file which should give guidance for building
Hamlib and installing it to your system.  There is quite a bit of
information, not all of which will apply to your installation.

Section 5 is important so the runtime dynamic linker can find the newly
installed libhamlib files.  Fortunately, this doesn't need to be done
often and probably won't be required until there is a Hamlib version 5
(quite some time).

After it has been done a few times and you get the hang of it, you might
want to try the daily snapshots, but for now try the latest release and
see if that provides any more functions.

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 version in Raspbian Bookworm the latest?

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

Hi Nate.


I had a look at the sources. This is taff. Dunno, if I am able to 
compile this. Are there pre compiled binaries available for Raspi OS 
Bookworm? Or could you point me to where to start when I need to compile 
it myself?


73


Richard

[Hamlib-developer] Where does the data for certain lists come from?

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

Hi everyone,

I've been exploring some list commands and I'm wondering where exactly 
the information returned by these commands originates.

Currently, I retrieve all necessary details using the --caps-dump 
command, which works fine. However, it would be great if I could use for 
example get_modes and  get_vfo_list instead. My main question is: are 
these lists generated based on data from the backend (e.g., the 
Raspberry Pi), or are they fetched directly from the connected radio 
each time the command is issued?

The distinction is important, since not all radios are capable of 
reporting their supported modes or VFO combinations. If the radio is 
queried every time, this would make the commands less reliable across 
diverse hardware.

Additionally, is there any way to generate these lists dynamically 
depending on the currently selected VFO? For instance, We've come across 
radios where for example VFOA supports FM, AM, and Digital, but VFOB 
supports only FM and Digital. It would be very useful if the command 
could reflect these distinctions based on actual capabilities.

Thanks a lot in advance!

-- 
73

Richard, DO9RE

Re: [Hamlib-developer] Hamlib version in Raspbian Bookworm the latest?

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

Thanks, this answers my question.

Re: [Hamlib-developer] Question on Frequency Adjustment with Rigctl

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

Thanks for the clarification.

Re: [Hamlib-developer] Question on Frequency Adjustment with Rigctl

[David B. <da...@ba...>]

I would store the current frequency in your programme, then add the desired offset to your stored frequency. You will be updating the current radio frequency by polling the radio.

Once you have the current frequency, add your desired offset, then send the desired frequency to the radio. You might want to check the frequency is in band first.

73 de David M0DGB/G8FKH

From: Stefan Jansen <DK...@da...>
Sent: 17 April 2025 19:12
To: Hamlib Developers Mailingliste <ham...@li...>
Subject: Re: [Hamlib-developer] Question on Frequency Adjustment with Rigctl

Hi David, hi list,

First, let men introduce myself. I am Stefan, living in Germany and developing together with Richard on a piece of software that uses hamlib and mainly rigctl.

Now back to the topic if this thread:

David, it is clear that you do not have to query the current frequency before setting an arbitrary new value. But what if you want to just increase the current frequency by, let’s say, 1kHz? To do so, would you query the current frequency with the „f“ command, add 1000 to it and set the new value with „F“? Or is there a command to just increment or decrement the current frequency by a given step size?

Vy 73 de Stefan, DK7STJ

--
Stefan Jansen    ***    E-Mail: DK...@da...<mailto:DK...@da...>


Am 17.04.2025 um 11:46 schrieb David Balharrie <da...@ba...<mailto:da...@ba...>>:

You don't need to query the frequency from the radio before setting the frequency on the radio.

73 de David M0DGB/G8FKH

-----Original Message-----
From: Richard Emling <DO...@ho...<mailto:DO...@ho...>>
Sent: 16 April 2025 21:02
To: ham...@li...<mailto:ham...@li...>
Subject: [Hamlib-developer] Question on Frequency Adjustment with Rigctl

Hi all,

I have a general question about frequency adjustment. Thankfully, with the small 'f' command we can query the current frequency, and with the capital 'F' we can set a new one.

I'm currently writing a script that changes the frequency in predefined steps—either increasing or decreasing it in a loop. My question is:

Do I really have to query the current frequency from the rig during each loop iteration, add or subtract my step size, and then set the new value again? Or is there a more elegant or efficient way to do this?

I think I read somewhere that it's possible to increment the frequency relative to the current setting. If that's true, how would I go about doing that?

Any tips or pointers would be much appreciated!

Best regards,

--
73

Richard, DO9RE



_______________________________________________
Hamlib-developer mailing list
Ham...@li...<mailto:Ham...@li...>
https://lists.sourceforge.net/lists/listinfo/hamlib-developer

_______________________________________________
Hamlib-developer mailing list
Ham...@li...<mailto:Ham...@li...>
https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Question on Frequency Adjustment with Rigctl

[Stefan J. <DK...@da...>]

Hi David, hi list,

First, let men introduce myself. I am Stefan, living in Germany and developing together with Richard on a piece of software that uses hamlib and mainly rigctl.

Now back to the topic if this thread:

David, it is clear that you do not have to query the current frequency before setting an arbitrary new value. But what if you want to just increase the current frequency by, let’s say, 1kHz? To do so, would you query the current frequency with the „f“ command, add 1000 to it and set the new value with „F“? Or is there a command to just increment or decrement the current frequency by a given step size?

Vy 73 de Stefan, DK7STJ

--
Stefan Jansen    ***    E-Mail: DK...@da...

> Am 17.04.2025 um 11:46 schrieb David Balharrie <da...@ba...>:
> 
> You don't need to query the frequency from the radio before setting the frequency on the radio.
> 
> 73 de David M0DGB/G8FKH
> 
> -----Original Message-----
> From: Richard Emling <DO...@ho...> 
> Sent: 16 April 2025 21:02
> To: ham...@li...
> Subject: [Hamlib-developer] Question on Frequency Adjustment with Rigctl
> 
> Hi all,
> 
> I have a general question about frequency adjustment. Thankfully, with the small 'f' command we can query the current frequency, and with the capital 'F' we can set a new one.
> 
> I'm currently writing a script that changes the frequency in predefined steps—either increasing or decreasing it in a loop. My question is:
> 
> Do I really have to query the current frequency from the rig during each loop iteration, add or subtract my step size, and then set the new value again? Or is there a more elegant or efficient way to do this?
> 
> I think I read somewhere that it's possible to increment the frequency relative to the current setting. If that's true, how would I go about doing that?
> 
> Any tips or pointers would be much appreciated!
> 
> Best regards,
> 
> --
> 73
> 
> Richard, DO9RE
> 
> 
> 
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
> 
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Question on Frequency Adjustment with Rigctl

[David B. <da...@ba...>]

You don't need to query the frequency from the radio before setting the frequency on the radio.

73 de David M0DGB/G8FKH

-----Original Message-----
From: Richard Emling <DO...@ho...> 
Sent: 16 April 2025 21:02
To: ham...@li...
Subject: [Hamlib-developer] Question on Frequency Adjustment with Rigctl

Hi all,

I have a general question about frequency adjustment. Thankfully, with the small 'f' command we can query the current frequency, and with the capital 'F' we can set a new one.

I'm currently writing a script that changes the frequency in predefined steps—either increasing or decreasing it in a loop. My question is:

Do I really have to query the current frequency from the rig during each loop iteration, add or subtract my step size, and then set the new value again? Or is there a more elegant or efficient way to do this?

I think I read somewhere that it's possible to increment the frequency relative to the current setting. If that's true, how would I go about doing that?

Any tips or pointers would be much appreciated!

Best regards,

--
73

Richard, DO9RE



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

[Hamlib-developer] [Hamlib/Hamlib] fa5b4c: Ignore files related to tests

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

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

  Changed paths:
    M .gitignore

  Log Message:
  -----------
  Ignore files related to tests


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

  Changed paths:
    M tests/Makefile.am

  Log Message:
  -----------
  Delete a generated file when doing make clean


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

  Changed paths:
    M bindings/Makefile.am

  Log Message:
  -----------
  Delete a generated directory when doing make clean


  Commit: 1ee8fc9bd18aee629539bb911e7beabe5569756c
      https://github.com/Hamlib/Hamlib/commit/1ee8fc9bd18aee629539bb911e7beabe5569756c
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-04-16 (Wed, 16 Apr 2025)

  Changed paths:
    M .gitignore
    M bindings/Makefile.am
    M tests/Makefile.am

  Log Message:
  -----------
  Merge pull request #1696 from dforsi/fix/tests

Ignore files related to tests and delete generated files


Compare: https://github.com/Hamlib/Hamlib/compare/f9d3a2e66763...1ee8fc9bd18a

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

[Hamlib-developer] [Hamlib/Hamlib] 428e30: Additional PKTUSB and PKTLSB mapping for USB-D1/LS...

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 428e3075eb693c3e7387e48cb29ecaefa4b3ffde
      https://github.com/Hamlib/Hamlib/commit/428e3075eb693c3e7387e48cb29ecaefa4b3ffde
  Author: Arkadiusz Miśkiewicz <ar...@ma...>
  Date:   2025-04-14 (Mon, 14 Apr 2025)

  Changed paths:
    M rigs/dummy/flrig.c

  Log Message:
  -----------
  Additional PKTUSB and PKTLSB mapping for USB-D1/LSB-D1

Some radios (icom 7760 for example) expose USB/LSB-Dn modes (e.g., USB-D1).
By default, USB-D1 acts as PKTUSB and LSB-D1 as PKTLSB. Adding this mapping
improves compatibility with software expecting standard PKTUSB/PKTLSB modes.

A real-life scenario: this makes WSJT-X usage much nicer, as WSJT-X requests
PKTUSB, which is then mapped to USB-D1 — the default mode for FT4/FT8 operations
on Icom radios.


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

  Changed paths:
    M rigs/dummy/flrig.c

  Log Message:
  -----------
  Merge pull request #1695 from arekm/master

flrig: Additional PKTUSB and PKTLSB mapping for USB-D1/LSB-D1


Compare: https://github.com/Hamlib/Hamlib/compare/34698df17acf...f9d3a2e66763

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

Re: [Hamlib-developer] Question about Remote Control and Security with rigctld

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

Hi again.

I checked the --help and saw something about passwords. Upon trying rigctld -m 1 -t 54321 --password start123
I generated some kind of secret.
Dunno, if I now have to enter 
Rigctl -m2 -r hostname:54321 --password start123
Or --password 'This what ever secret'
At the client machine.
Why is it, that the password command line argument has a ? In front instead a -?
I am a little bit confused.

73s

Richard, DO9RE

[Hamlib-developer] Question about Remote Control and Security with rigctld

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

Hello everyone,

I understand that rigctld can host a server that listens on localhost by 
default. How can I use this service to remotely control a transceiver, 
and where can I implement security measures to prevent unauthorized 
access? I couldn't find any user authentication options.

Thank you for your help!

-- 
73

Richard, DO9RE

[Hamlib-developer] Question on Frequency Adjustment with Rigctl

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

Hi all,

I have a general question about frequency adjustment. Thankfully, with 
the small 'f' command we can query the current frequency, and with the 
capital 'F' we can set a new one.

I'm currently writing a script that changes the frequency in predefined 
steps—either increasing or decreasing it in a loop. My question is:

Do I really have to query the current frequency from the rig during each 
loop iteration, add or subtract my step size, and then set the new value 
again? Or is there a more elegant or efficient way to do this?

I think I read somewhere that it's possible to increment the frequency 
relative to the current setting. If that's true, how would I go about 
doing that?

Any tips or pointers would be much appreciated!

Best regards,

-- 
73

Richard, DO9RE

[Hamlib-developer] Fwd: Question on Frequency Adjustment with Rigctl

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

Dunno if the mail made it through, I didn't get it back from the list, 
so I send it again.



-------- Weitergeleitete Nachricht --------
Betreff: 	Question on Frequency Adjustment with Rigctl
Datum: 	Wed, 16 Apr 2025 22:01:30 +0200
Von: 	Richard Emling <DO...@ho...>
An: 	ham...@li...



Hi all,

I have a general question about frequency adjustment. Thankfully, with 
the small 'f' command we can query the current frequency, and with the 
capital 'F' we can set a new one.

I'm currently writing a script that changes the frequency in predefined 
steps—either increasing or decreasing it in a loop. My question is:

Do I really have to query the current frequency from the rig during each 
loop iteration, add or subtract my step size, and then set the new value 
again? Or is there a more elegant or efficient way to do this?

I think I read somewhere that it's possible to increment the frequency 
relative to the current setting. If that's true, how would I go about 
doing that?

Any tips or pointers would be much appreciated!

Best regards,

-- 
73

Richard, DO9RE

Re: [Hamlib-developer] Hamlib version in Raspbian Bookworm the latest?

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

* On 2025 15 Apr 15:04 -0500, Richard Emling wrote:
> Hello List.
> 
> 
> Maybe a newbie question:
> 
> Is the version in Raspbian OS Bookworm installable by APT, the latest one?

If it is the same as Debian Bookworm then it is 4.5.4 which was released
in early 2023.

> If not, are there good reasons to update from some repo and compile the
> version myself?

About two years worth of work is a good reason to get the current
version.  You can find it at:

https://github.com/Hamlib/Hamlib/releases/tag/4.6.2
https://github.com/Hamlib/Hamlib/releases/download/4.6.2/hamlib-4.6.2.tar.gz

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 version in Raspbian Bookworm the latest?

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

Hello List.


Maybe a newbie question:

Is the version in Raspbian OS Bookworm installable by APT, the latest one?

If not, are there good reasons to update from some repo and compile the 
version myself?


Thanks a lot.

-- 
73

Richard, DO9RE

[Hamlib-developer] --civaddr important?

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

Hi folks.


Is the civadddr switch of any use? currently I just connected to my Icom 
706mkIIg using only the serial port file from /dev/serial/by-id/...

There is a civ address setting in my transceivers menu. Is it of any 
help to also provide it, or is this optional?


Thanks again.

-- 
73

Richard, DO9RE

[Hamlib-developer] RAW_STRENGTH interpretation

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

Greetings Listers.


I just asked about reading S-meter using the STRENGTH level and got so 
useful and friendly answers, so I try with RAW_STRENGTH as well:

My ICOM ic-706mkIIg for example, doesn't send STRENGTH, only 
RAW_STRENGTH is accessible.

Where would I start in Order to be able to interpret these values as 
proper S-steps?

Thanks in adv advance


73


Richard, DO9RE

Re: [Hamlib-developer] Question about detecting manual changes on the transceiver via Hamlib

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

Hi Dave.


Many thanks. I have an Icom 706mkIIg. Sadly, it can't report / set Power 
and CTCSS tones. At least I saw the corresponding --caps-dump entrys as 
"no". So, I need another way of finding out, whats the current 
transmitting power. Currently fiddling around with some sort of screen 
OCR with a Raspberry camera and Tesseract. Yes, we have an interesting 
hobby. :-)


73s


Richard, DO9RE

Re: [Hamlib-developer] Question about detecting manual changes on the transceiver via Hamlib

[Dave B. <g8k...@go...>]

Richard.

Some can report "live" changes to the remote control port (Many Kenwood 
and Icom HF radios for example, but the protocol is vastly different 
between makes.)

Those two, in particular, can pair with another compatible (same make) 
radio, and one can follow the other if desired.

Else, yes you need to poll the radio for it's status.  It's easier with 
some, where one response (Kenwood HF sets in particular) contains most 
of what you might need, re frequency, mode, bandwidth and so on.

Sadly, it's very much a case of RTFM.  Some online manuals might be 
mangled too much for a screen reader to cope well, and of course the 
devil is in the detail.

For polling, run the CAT link as fast as it will go.  With regards for 
the CPU in the radio, many older rigs are limited to 4800bd or 9600bd by 
design.   My Kenwood TS-870s will run happily at 57600bd, but does need 
RTS/CTS handshaking for reliability.   I also use the DTR line to key 
the TX, using the same USB-serial port.

The Icom IC-R9000 RX, implies it will run at 9600bd, but in practice it 
is much happier at 4800bd.

The old FT-736R (for one) is stuck at 4800bd, with no other choices.  It 
also is unable to report it's operating state, other than if the squelch 
is open/closed, and an arbitrary value relating (somehow) to what the S 
meter is showing.   Absolutely impossible to read frequency, mode or 
other settings.  Mind you, when CAT is working, most front panel 
controls are locked out.

Hamlib has some functionality now, to remember what it was set to, 
frequency and I think mode, thanks to Bill G4WJS (SK) allowing gpredict 
to work with it.  (It "Needs" to read from the rig, to tell if the rig 
is actually present!)

As above, never assume anything, and sadly much of the information you 
may need might not be in a form easily usable by you, especially for 
rigs that are not current production items. The three rigs mentioned 
above, I do have the original paper manuals, and for the Kenwood, some 
half decent pdf files.

73 Richard.

Dave G8KBV.


On 14/04/2025 01:27, Richard Emling wrote:
> Dear Hamlib community,
>
> I have a question regarding the detection of manual changes made directly on a transceiver while using Hamlib.
>
> Is there a way to immediately react to such changes—like someone turning a knob to change the operating mode or adjusting the VFO frequency—without having to continuously poll the device? Do transceivers actively notify the host about such changes via the CAT interface, or is polling required to detect them?
>
> If polling is indeed necessary, what would be a good interval to use? Would 500 milliseconds be acceptable, or would one second be more appropriate to avoid overloading the interface?
>
> I’d greatly appreciate any clarification on how to best approach this.
>
> Best regards and 73,
> Richard
> DO9RE
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] ROTCTld usb0 issue on pi5

[Bob N. <bn...@gm...>]

Randy,
 I updated HAMLIB with:
1.Open the Raspberry Pi Desktop
2.Open the browser by clicking the Globe in the toolbar.
3.Navigate to the Hamlib folder in Github to get the latest Beta version
(you can also select the latest release version):
https://github.com/Hamlib/Hamlib
4.Click the green Code button, then Download ZIP.
5.Right-click over the Hamlib-master.zip button at the bottom of the
browser and select Show in folder.
6.In the Downloads folder right-click Hamlib-master.zip and select Extract
here.
7.Close the Downloads folder and the browser.
8.Open Terminal by clicking the >_ black icon at the top of the Desktop.
9.Type these commands:
cd /home/pi/Downloads/Hamlib-master
./bootstrap
./configure
make
sudo make install

It said it was version 4.7 but when I ran  rotctld -vvvvv -m 2401 -r
/dev/ttyUSB0, it worked but said this
rotctld, Hamlib 4.5.4 Jan 10 01:31:41Z 2023 SHA=921cc5

Upside is its working, just not sure what version I now have.
Happy Monday
Bob W1RPQ

On Sun, Apr 13, 2025 at 11:15 PM Nate Bargmann <n0...@n0...> wrote:

> * On 2025 13 Apr 18:38 -0500, Bob Nazro wrote:
> > Randy helped me with:
> > sudo ln -s /dev/ttyUSB0 /dev/ttyS0
> > This crested the TTYL port and it ran rotctld . Thanks for everyone's
> help.
>
> That is a workaround, but it seems the true bug may be in the rotator
> backend that you're using.  The version of Hamlib on your system is
> quite old, 4.5.4 as I recall, that was released well over two years ago.
> Quite a bit of work has taken place since then, I'm unsure how much was
> directed at the backend you're using.  Anyway, should you get the chance
> to upgrade to a newer version, it would be nice to know if it accepts
> 'ttyUSB0' because on your version what I saw it acts like it's hard
> coded for 'ttyS0'.
>
> The current stable release is 4.6.2 and I plan to release 4.6.3 at the
> end of the month.  Unfortunately, those probably won't be available in
> Raspberry Pi OS until it updates to the next stable version of Debian.
>
> 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
>


-- 
Bob Nazro, W1RPQ
phone: (860) 941-7993
b <Jos...@cp...>na...@gm...