Brief summary of problem (put in title as well): v2.03 RIGCTL issue
Radio Model: R8600
Connectivity (USB/Ethernet/Wifi/Other): Ethernet
Operating System: Win 11
wfview version (press “About”): 2.03
Checked the wfview manual (Y/N): Y
Checked the wfview FAQ (Y/N): Y
Tried to google it (Y/N/NA): Y
I’ve wrote a python script to set the frequency in Wfview from WxToIMG.
Running manually my script, it sends the command in text encoded utf-8 “F 137100000” for instance.
wfview v1.64 respond : b’RPRT 0\n’ which once decoded gives RPRT 0 (I don’t know what it means)
wfview v2.04 respond a binary sequence : b’\xfe\xfe\x96\xe1\x15\x02\xfd’ or a longer sequence (very long more than 20 lines) b"\xfe\xfe\xe1\x96’\x00\x00\x01\x01\x00\x00\x00\x907\x01\x00\x00\x00\x01\x00\x00\x10\x02\x0f\x07\x06\x15\x0b\x00\x10\n\x0e\x16\x1d\x1a\x18\x0e\x0e\x04 … (cut)
Actually for debugging purpose I’ve removed the format decoding on the received string. Just displaying raw data
1.64 responds with a string, (what does it mean RPRT 0) ?
2.03 responds in binary (looks like a CI-V dataframe starting with 0xFE which is CI-V preamble ?)
look like the behavior is different from the two versions but not an encoding matter…
Just need to know what is the output content to adapt my code…
import sys
import socket
# Get the parameters from WXTOIMG
satellite_name = sys.argv[1]
frequency = sys.argv[2]
control_port = sys.argv[3]
# If not satellite is selected then we do nothing
if satellite_name == "" and frequency == "0.00":
print("No selectes satellite, no frequency to program.")
else:
# Convert frequency in Hz for wfview
frequency_hz = float(frequency) * 1e6
print(f"Frequency : {frequency_hz} Hz")
# Connect wfview via TCP server
try:
# wfview server parameters
wfview_host = "localhost" # To replace by wfview IP Address if not on the same computer
wfview_port = 4532 # Port set in wfview
# Connect wfview TCP server
print(f"Connexion to wfview on: {wfview_host}:{wfview_port}")
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
s.connect((wfview_host, wfview_port))
# Command to program the frequency
cmd = f"F {int(frequency_hz)}\n"
print(f"Command : {cmd}")
s.sendall(cmd.encode('utf-8'))
# Read wfview response
#response = s.recv(1024).decode('utf-8')
#print("wfview response :", response)
response = s.recv(1024) # Lire en mode binaire
print(f'raw wfview response is : {response}')
decoded_response = response.decode('latin-1')
print("wfview response :", decoded_response)
except Exception as e:
print(f"Error when connecting wfview : {e}")
this is what I was doing successfully in 1.64… but encoding in latin-1 doesn’t change the behavior. No control of the frequency and still binary response which looks like CI-V
You are sending invalid data, as the way that the command is parsed has changed, it will likely respond in a different way. If you send valid data, it will work (as I have just verified by manually sending F 137100000 to my radio)
You need to look at the actual raw data that is being sent.
Try connecting to the rigctld port using telnet (or any other raw terminal program) and enter F 137100000 and you will see that it works.
I have spotted the error, you have TCP Port configured to 4532 as well as Rigctl. TCP Port is a raw connection direct to the radio, so you are seeing the raw radio communications!
Yep ! Putting 0 in TCP server port has solved
but the same setting in 1.64 wasn’t providing the same result. you can see I have also the 4532 port in TCP server in 1.64. Does it mean the TCP server in 1.64 wasn’t working ?
It depends which was being started first. In v1.64 the rigctld was started very early in the program initialization, so it would have grabbed the port before TCP Server port could. In v2 rigctld is only started once wfview is connected to an actual radio.
Yes that was just a guess as to why you were seeing all of that data, it was only when I looked closer that I saw they were rig commands. It should really be 8-bit encoded (latin1) but the connection handler likely does the conversion for wfview?
