today we’ll push out 1.2b – some more testing is needed in the rigctld area:
if you use wsjtx etc – please try and use rictld instead of pseudo serial ports and the like
to connect to wfview.
The following highlights are in this 1.x-release:
many changes/mods/updates/enhancements to rigctld
rigctld box added in the UI
build process changed: you can add the install prefix (derSuessmann)
added "do not ask again" for switching off rig and exiting wfview
added opus as audio transport
dual meter support
rigctl basic split support
rigctl prevents switching off civ transceive
added 25 kHz step
Roeland,
Can you explain how to use rigctld when using Log4OM and WSJT-x controlled via OmniRig at the server side?
I see COM3 as Port choice, does it mean that in OmniRig Rigctld is selectable as input Port?
I have never used Hamlib and Rigctld.
The whole point of using rigctld emulation is so that you can avoid the need for OmniRig. Both WSJT-X and Log4OM can connect directly to the wfview rigctld, I will be writing a manual page for this in the coming days but basically you just need to select the rig as rigctld within WSJT-X and Log4OM.
connecting WSJT-X to wfview via rigctld does not work here.
(IC-7300, Debian 11)
wfview log:
2021-09-07 18:14:39.597 INF rigctld: started on port 4533
2021-09-07 18:14:39.675 INF rigctld: Got rigcaps for: “IC-7300”
2021-09-07 18:15:02.213 INF rigctld: session connected: 32
2021-09-07 18:15:02.213 INF rigctld: no rigState!
2021-09-07 18:15:03.214 INF rigctld: no rigState!
2021-09-07 18:15:04.218 INF rigctld: no rigState!
2021-09-07 18:15:05.216 INF rigctld: session connected: 33
2021-09-07 18:15:05.217 INF rigctld: no rigState!
2021-09-07 18:15:06.218 INF rigctld: no rigState!
2021-09-07 18:15:07.218 INF rigctld: no rigState!
2021-09-07 18:15:08.219 INF rigctld: no rigState!
2021-09-07 18:15:09.220 INF rigctld: 32 disconnected
2021-09-07 18:15:09.221 INF rigctld: no rigState!
2021-09-07 18:15:10.222 INF rigctld: 33 disconnected
WSJT-X connects to wfview and is sending commands to wfview (I can see that in wireshark). wfview is answering with tcp
packets without any data (I see only the tcp headers).
The no rigState! messages are a critical error which means that rigctld hasn’t received the rigState information. I have just checked the source code and sure enough, it is not setting the initial rig state when connected over USB (my testing has been done almost exclusively over LAN).
I have just pushed a 1 line fix to master which should address this. As you are on Debian, can you try this fix? This kind of report is exactly why we beta test
Phil just got a post about the new rigctrl is not compatible with rasping, I’ll try and find the link. It’s Jason ACK on YouTube that does all the work on raspi for amateur radio
So let me ask about rigctrl…what does this get me? I’m running Flrig alongside wfview because for the moment Flrig has more functionality. Is there any advantage to me using rigctrl?
If you are “only” using flrig then no as flrig is not compatible with rigctld. If you also use fldigi/wsjt-x or any other program that ‘does’ support rigctld, then I strongly advise you to use it. The two are not mutually exclusive, rigctld just allows multiple applications to share the rig. There is nothing stopping you also also using flrig via a virtual serial port.
It isn’t really new, it has been ‘hidden’ within wfview since v1. I would be very surprised if it isn’t compatible as one of my test setups is a Pi4 connected via USB to an IC7100.
In 1.2b I enabled Rigctld, virtual Port: none
In WSJT-x I selected Hamlib NET rigctl as radio, and used address 4533.
Did a Test CAT, got a error message CAT test falied
If you are connecting to a USB radio (IC7300 etc.) then you will need 1.2c which was released a couple of hours ago as we discovered a problem with 1.2b that only affects USB connected rigs!
with this fix WSJT-X via rigctld is now working here.
There is now another strange problem:
(IC-7300, Debian 11, wfview 1.2c)
Switching to TX by activating the Tune button in WSJT-X does not always work.
Sometimes WSJT-X shows that it is in TX mode, but wfview shows that it is receiving.
Switching to TX (and back to RX) by activating the button in wfview does always work.
I have also tested WSJT-X without wfview with hamlib rigctld, then the error does not occur.
It seems that when using the wfview rigctld emulation sometimes commands from wsjtx to wfview get lost.
I can’t replicate that issue, every time I click TUNE in WSJT-X my rig goes into TX. Can you confirm that you have “PTT Method” set to CAT within WSJT-X? I have tried this both with a USB and LAN connected rig on Windows, Linux and MacOS.
if so if you start later wsjtx – do you use 127.0.0.1:4533 ? (e.g. use localhost)
if your s/w can use rigctld then just completely forget com ports when configuring this.
(obviously not the com port you used to talk to with wfview; no virtual ports further nor
serial ports on other external software or helper programs that mimic serial ports).
