Commands via API always seem to use VFO mode #930

giordyb · 2022-01-17T17:19:03Z

Hi,

I'm trying to remotely control an SDR software (https://github.com/AlexandreRouma/SDRPlusPlus) that implements a rigctld compatible backend but without VFO mode.

I can connect and send commands just fine with rigctl, as you can see it sends the right command:

Rigctl command: 'F 146000000.000000'

but If I connect to the backend via the python bindings the command is always sent as with VFO mode ON

netrigctl_set_freq: cmd=F VFOA 145000000.000000

which breaks compatibility with the backend (that sends me a "protocol error").

if I run the dump caps command I can see that "Has targetable VFO: N", which I presume is how rigctl determines if it's supported or not.

Rig command: \dump_caps
Caps dump for model: 2
Model name:	NET rigctl
Mfg name:	Hamlib
Backend version:	20211123.0
Backend copyright:	LGPL
Backend status:	Stable
Rig type:	Other
PTT type:	Rig capable (Mic/Data)
DCD type:	Rig capable
Port type:	Network link
Write delay: 0mS, timeout 10000mS, 5 retry
Post Write delay: 0mS
Has targetable VFO: N
Has async data support: N
Announce: 0x0
Max RIT: -0.0kHz/+0.0kHz
Max XIT: -0.0kHz/+0.0kHz
Max IF-SHIFT: -0.0kHz/+0.0kHz
Preamp: None
Attenuator: None
AGC levels: 0=OFF 1=SUPERFAST 2=FAST 3=SLOW 4=USER 5=MEDIUM 6=AUTO
CTCSS: None
DCS: None
Get functions:
Set functions:
Extra functions:
Get level: SQL(0..0/0) STRENGTH(0..0/0)
Set level: SQL(0..0/0)
Extra levels:
Get parameters:
Set parameters:
Extra parameters:
Mode list: AM CW USB LSB FM WFM CWR AMS
VFO list: VFOA
VFO Ops:
Scan Ops:
Number of banks:	0
Memory name desc size:	0
Memories: None
TX ranges #1 for TBD:
RX ranges #1 for TBD:
TX ranges #2 for TBD:
RX ranges #2 for TBD:
TX ranges #3 for TBD:
RX ranges #3 for TBD:
TX ranges #4 for TBD:
RX ranges #4 for TBD:
TX ranges #5 for TBD:
RX ranges #5 for TBD:
TX ranges #1 status for TBD:	OK (0)
RX ranges #1 status for TBD:	OK (0)
TX ranges #2 status for TBD:	OK (0)
RX ranges #2 status for TBD:	OK (0)
TX ranges #3 status for TBD:	OK (0)
RX ranges #3 status for TBD:	OK (0)
TX ranges #4 status for TBD:	OK (0)
RX ranges #4 status for TBD:	OK (0)
TX ranges #5 status for TBD:	OK (0)
RX ranges #5 status for TBD:	OK (0)
Tuning steps: None! This backend might be bogus!
Tuning steps status:	OK (0)
Filters: None. This backend might be bogus!
Bandwidths:
	AM	Normal: 10.0000 kHz,	Narrow: 5.0000 kHz,	Wide: 20.0000 kHz
	CW	Normal: 500.0 Hz,	Narrow: 200.0 Hz,	Wide: 2.0000 kHz
	USB	Normal: 2.7000 kHz,	Narrow: 1.4000 kHz,	Wide: 3.9000 kHz
	LSB	Normal: 2.7000 kHz,	Narrow: 1.4000 kHz,	Wide: 3.9000 kHz
	RTTY	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	FM	Normal: 10.0000 kHz,	Narrow: 5.0000 kHz,	Wide: 20.0000 kHz
	WFM	Normal: 160.0000 kHz,	Narrow: 120.0000 kHz,	Wide: 200.0000 kHz
	CWR	Normal: 500.0 Hz,	Narrow: 200.0 Hz,	Wide: 2.0000 kHz
	RTTYR	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	AMS	Normal: 10.0000 kHz,	Narrow: 5.0000 kHz,	Wide: 20.0000 kHz
	PKTLSB	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	PKTUSB	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	FM-D	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	ECSSUSB	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	ECSSLSB	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	FAX	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	SAM	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	SAL	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	SAH	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	DSB	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
		Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	FMN	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	AM-D	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	P25	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	D-STAR	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	DPMR	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	NXDN-VN	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	NXDN-N	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	DCR	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	AMN	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
	PSK	Normal: 0.0 Hz,	Narrow: 0.0 Hz,	Wide: 0.0 Hz
Spectrum scopes: None
Spectrum modes:
Spectrum spans:
Spectrum averaging modes:
Spectrum attenuator: None
Has priv data:	N
Has Init:	Y
Has Cleanup:	Y
Has Open:	Y
Has Close:	Y
Can set Conf:	N
Can get Conf:	N
Can set Frequency:	Y
Can get Frequency:	Y
Can set Mode:	Y
Can get Mode:	Y
Can set VFO:	Y
Can get VFO:	Y
Can set PTT:	Y
Can get PTT:	Y
Can get DCD:	Y
Can set Repeater Duplex:	Y
Can get Repeater Duplex:	Y
Can set Repeater Offset:	Y
Can get Repeater Offset:	Y
Can set Split Freq:	Y
Can get Split Freq:	Y
Can set Split Mode:	Y
Can get Split Mode:	Y
Can set Split VFO:	Y
Can get Split VFO:	Y
Can set Tuning Step:	Y
Can get Tuning Step:	Y
Can set RIT:	Y
Can get RIT:	Y
Can set XIT:	Y
Can get XIT:	Y
Can set CTCSS:	Y
Can get CTCSS:	Y
Can set DCS:	Y
Can get DCS:	Y
Can set CTCSS Squelch:	Y
Can get CTCSS Squelch:	Y
Can set DCS Squelch:	Y
Can get DCS Squelch:	Y
Can set Power Stat:	Y
Can get Power Stat:	Y
Can Reset:	N
Can get Ant:	Y
Can set Ant:	Y
Can set Transceive:	N
Can get Transceive:	N
Can set Func:	Y
Can get Func:	Y
Can set Level:	Y
Can get Level:	Y
Can set Param:	Y
Can get Param:	Y
Can send DTMF:	Y
Can recv DTMF:	Y
Can send Morse:	Y
Can send Voice:	Y
Can decode Events:	N
Can set Bank:	Y
Can set Mem:	Y
Can get Mem:	Y
Can set Channel:	Y
Can get Channel:	Y
Can ctl Mem/VFO:	Y
Can Scan:	Y
Can get Info:	Y
Can get power2mW:	Y
Can get mW2power:	Y

Overall backend warnings: 2

here is the python code that I am using to connect to the rigctld backend of the sdr

#%%
import sys

sys.path.append("/usr/local/lib/python3.9/site-packages/")
import Hamlib
import time

Hamlib.rig_set_debug(Hamlib.RIG_DEBUG_VERBOSE)

my_rig = Hamlib.Rig(Hamlib.RIG_MODEL_NETRIGCTL)
my_rig.set_conf("rig_pathname", "localhost:4532")
my_rig.set_conf("retry", "5")
my_rig.open()

my_rig.set_freq(145000000)

any tips on how I can make my code compatible with non-vfo mode?

thanks,

Giordy

The text was updated successfully, but these errors were encountered:

mdblack98 · 2022-01-17T21:21:05Z

Try adding

my_rig.set_vfo_opt(0)

giordyb · 2022-01-18T07:57:27Z

@mdblack98 If I try that command I get

AttributeError: 'Rig' object has no attribute 'set_vfo_opt'

it looks like that function is not defined in the rig object in the python bindings

#930

mdblack98 · 2022-01-18T19:32:08Z

Please try the latest...hopefully fixed. Mike W9MDB On Tuesday, January 18, 2022, 01:57:38 AM CST, giordyb ***@***.***> wrote: @mdblack98 If I try that command I get AttributeError: 'Rig' object has no attribute 'set_vfo_opt' it looks like that function is not defined in the rig object in the python bindings — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

#930

giordyb · 2022-01-21T20:02:05Z

After pulling & recompiling if I try set_vfo_opt(0) I now get an error:

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Input In [8], in <module>
----> 1 my_rig.set_vfo_opt(0)

TypeError: set_vfo_opt() takes 1 positional argument but 2 were given

#930

giordyb · 2022-01-23T19:12:40Z

Hi @mdblack98 sorry if I bother you with one last question:

After your patch I was able to call the function and if I understand this correctly I have to call set_vfo_opt(0) in my code if I want to switch to the "old style" (non-vfo) command set, correct?

What I don't understand is the following: this command actually sends a \set_vfo_opt command to rigctld but I don't see it implemented in the older code (I'm looking at 3.2). How is this supposed to work with an older rigctld if it doesn't understand that command?

What I am trying to do here is have my python code (compiled with Hamlib master) talk to a "rigctld-compatible" backend that does not implement the "new style" of commands. Is that even possible?

mdblack98 · 2022-01-23T21:30:32Z

I don't think you need set_vfo_opt or you can just ignore the error returned in 3.2 I'm not 100% sure about that though. Mike W9MDB On Sunday, January 23, 2022, 01:12:51 PM CST, giordyb ***@***.***> wrote: Hi @mdblack98 sorry if I bother you with one last question: After your patch I was able to call the function and if I understand this correctly I have to call set_vfo_opt(0) in my code if I want to switch to the "old style" (non-vfo) command set, correct? What I don't understand is the following: this command actually sends a \set_vfo_opt command to rigctld but I don't see it implemented in the older code (I'm looking at 3.2). How is this supposed to work with an older rigctld if it doesn't understand that command? What I am trying to do here is have my python code (compiled with Hamlib master) talk to a "rigctld-compatible" backend that does not implement the "new style" of commands. Is that even possible? — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

mdblack98 · 2022-01-23T21:31:14Z

What rigctld compatible backend? Mike On Sunday, January 23, 2022, 01:12:51 PM CST, giordyb ***@***.***> wrote: Hi @mdblack98 sorry if I bother you with one last question: After your patch I was able to call the function and if I understand this correctly I have to call set_vfo_opt(0) in my code if I want to switch to the "old style" (non-vfo) command set, correct? What I don't understand is the following: this command actually sends a \set_vfo_opt command to rigctld but I don't see it implemented in the older code (I'm looking at 3.2). How is this supposed to work with an older rigctld if it doesn't understand that command? What I am trying to do here is have my python code (compiled with Hamlib master) talk to a "rigctld-compatible" backend that does not implement the "new style" of commands. Is that even possible? — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

mdblack98 added the needs test Patches have been submitted but need testing to close issue label Jan 17, 2022

mdblack98 added a commit that referenced this issue Jan 18, 2022

Add set_vfo_opt to rig.swg

9e3afe2

#930

mdblack98 added a commit that referenced this issue Jan 18, 2022

Fix rig_set_vfo_opt in rig.swg and add new METHOD1SET

28174de

#930

mdblack98 added the fixed Issue has been fixed label Jan 19, 2022

mdblack98 added a commit that referenced this issue Jan 22, 2022

Fix rig.swg set_vfo_opt

506fcd1

#930

mdblack98 closed this as completed Jan 23, 2022

giordyb mentioned this issue Jan 23, 2022

add Hamlib 4.x partial compatibility AlexandreRouma/SDRPlusPlus#610

Closed

mdblack98 removed the needs test Patches have been submitted but need testing to close issue label Feb 6, 2022

x31415926 mentioned this issue Apr 8, 2023

Hamlib/WSJT-X issue with SDRPlusPlus #1266

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Commands via API always seem to use VFO mode #930

Commands via API always seem to use VFO mode #930

giordyb commented Jan 17, 2022 •

edited

mdblack98 commented Jan 17, 2022

giordyb commented Jan 18, 2022

mdblack98 commented Jan 18, 2022 via email

giordyb commented Jan 21, 2022 •

edited

giordyb commented Jan 23, 2022

mdblack98 commented Jan 23, 2022 via email

mdblack98 commented Jan 23, 2022 via email

Commands via API always seem to use VFO mode #930

Commands via API always seem to use VFO mode #930

Comments

giordyb commented Jan 17, 2022 • edited

mdblack98 commented Jan 17, 2022

giordyb commented Jan 18, 2022

mdblack98 commented Jan 18, 2022 via email

giordyb commented Jan 21, 2022 • edited

giordyb commented Jan 23, 2022

mdblack98 commented Jan 23, 2022 via email

mdblack98 commented Jan 23, 2022 via email

giordyb commented Jan 17, 2022 •

edited

giordyb commented Jan 21, 2022 •

edited