Radios with Main/Sub also have similar controls within the main window
Ability to configure button on/off colours for “toggle” buttons within settings
Add ability to PTT via DTR as well as RTS. This is selected via the radio settings
Custom rig files now must be the same or newer version as system provided rig files, otherwise they will not be loaded
The ability to operate in Split mode with ricgtl connected software like wsjt-x. This is not 100% but I am not sure how many issues are caused by other software
Quick question: when I manually enter on a raspberry (IC7300 connected via USB)
rigctl -r localhost:4533 -m 2 f
if the “main” VFO is VFOA, it reads back the current qrg of VFOA. However it quickly switches VFOA<>VFOB twice.
if the “main” VFO is VFOB, it reads back the current qrg of VFOB. However it quickly switches VFOA<>VFOB once, so that after the command, the radio is on VFOA.
I assume, that is not intended.
More infos:
Main VFO is VFOA
rigctl -r localhost:4533 -m 2 v → Answer is “none”, toggles VFOs, Main is still VFOA
Main VFO is VFOB
rigctl -r localhost:4533 -m 2 v → Answer is “none”, but toggle VFOs that Main is VFOA
Main VFO is VFOA
rigctl -r localhost:4533 -m 2 V VFOA f → Answer is qrg from VFOA, toggles VFOs, Main is still VFOA
rigctl -r localhost:4533 -m 2 V VFOB f → Answer is qrg from VFOA (not expected), toggles VFOs, Main is VFOB (expected)
hmm problems
a) the only way I know to talk directly to the radio, when wfview is running, is via the virtual serial ports. I use this, however, it seems not 100% reliable. Sometimes it takes a lomg while until an answer is sent, sometimes the answer is wrong (qrg = 0, ie)
b) with V2.03, it looks like it does not work anymore. Could it be, that the virtual serial prot is broken?
EDIT: I tried it three times and it did not work. On the fourth time it worked again …
It should work fine, if you have updated your RPi, it may have broken something? I have tested the Windows version quite extensively. I don’t like using it as it bypasses the wfview queue and sends commands directly to the radio, which on some radios like the IC-7100 can cause collisions.
Of course, assuming a fairly recent version of rigctl you can always run:
since the tests with the new version I have not changed the basis of the rpi. Before I report something strange, i check back with V1.64 on the same machine.
I am currently using
“rigctl Hamlib 4.7~git from indeterminate source revision. 64-bit”
and --skipinit does not seem to make a big difference. In my last tests
rigctl -r /home/pi/rig-pty1 -m 3073 --skipinit f
reported the correct qrg in 50% of all calls.
Why on earth are you using the pty with rigctl, the whole point of having a rigctld in wfview was to stop people having to talk directly and disrupt wfviews communications.
The fact is that --skipinit will stop rigctl from selecting any VFOs itself.
Not sure what side the issue is on but after upgrading to v2 then I connect with SDR-Control on my iPad only the frequency loads and nothing else. I have already contacted the developer of the app to have him check it out.
The other thing I noticed is the “F Lock” is only locking the onscreen control, it is not locking my RC-28 remote controller.
Unfortunately the developer of SDR Control has not answered our emails about the integration of wfview server and SDR Control, and we do not have copies of the app. So I cannot really tell why his app is not working.
I think our wfview F Lock checkbox only locks out the wfview UI, not any controllers or external apps. Locking out controllers connected to wfview makes sense, we will put it down for the next time we are in that area of the code
I am e-mailing back and forth with the developer of SDR-Control. What we think is happening is wfview is not passing through the CI-V address of the radio. The app connects, and I get audio but because the app does not know the CI-V address of the radio it does not know what controls to load. The radio tab in the app shows a “?” for the radio model and “00” for the CI-V address.
