I see an interesting issue here. As I use wfview mainly for operation two remote stations, I have written a “controller” script, to make the usage easier for the different ops. This script does several things: reports frequency, mode and rfpower to a managemwent system; disables split, as soon as WSJT-X has been startet or the delta between VFO A and B is bigger the 100Khz; etc.
Now I have seen, that with V2.01 the box data on/off keeps toggeling, if USB-D is selected on the radio. So I was thinking of a problem with the software (it was not the case in V1.64). As I tried to dig deeper in it, I found out, that this effect is only showing, as long as my control script is running.
Digging deeper I saw, that just the rigctl request for reading the current RFPOWER ist switching DATA to off. After a while it is switched to on again. The request is done with: “rigctl -r localhost:4533 -m 2 l RFPOWER”. It also happens, when my script is stopped and I just send that command via CLI.
As you may remember, I was quite keen for the reenabling of the virtual serial ports. When I just use that: “rigctl -r /home/pi/rig-pty1 -m 3073 l RFPOWER”, the answer is the same, however, DATA mode keeps on in wfview (as expected). So I think, there must be happening something, when that command is going through wfview’s rigctl.
It is because we are reading the reply for your program’s VFO B query and not interpreting the reply as being VFO B. likely B was set to data mod on and A was set to data mod off.
This is a tricky area.
Can you send us the commands you are sending? Maybe we can figure it out. We hit a similar bug once before but I thought we had it squashed.
those are the commands I am sending:
rigctl -r localhost:4533 -m 2 f
rigctl -r localhost:4533 -m 2 m
rigctl -r localhost:4533 -m 2 l RFPOWER
rigctl -r localhost:4533 -m 2 L RFPOWER
rigctl -r localhost:4533 -m 2 l KEYSPD
rigctl -r localhost:4533 -m 2 L KEYSPD
rigctl -r localhost:4533 -m 2 s
rigctl -r localhost:4533 -m 2 S 0 VFOA
rigctl -r localhost:4533 -m 2 S 0 VFOB
I have just testet if that happenes if VFOA and VFOB are 100% the same: it does.
Thomas, DL3EL
As you are selecting VFOA then VFOB, this will select those VFOs on the radio, when VFOB is selected, it will become the ‘selected’ VFO and VFOA will become ‘unselected’.
As far as I know, this is expected behaviour, and if one of the VFOs doesn’t have data enabled, that is why you are seeing data on/off.
The reason this didn’t happen with 1.64 is that didn’t really understand the concept of VFOA/B.
That sounds reasonable. However: I have changed my script to skip all parts, where I deal with VFOA or VFOB. That had no effect, the toggling is still happening.
I digged it down to a single line:
rigctl -r localhost:4533 -m 2 f
which should just read the qrg. More or less parallel to that command, wfview shows data off, after a while it shows on again. When I use
rigctl -r localhost:4533 -m 2 V VFOA f or
rigctl -r localhost:4533 -m 2 V Main f
the same happens. I do not know, what I am doing wrong, when just trying to read a frequency. Btw. both VFOs have the same setting.
When I try to get the current mode with
rigctl -r localhost:4533 -m 2 m
the answer is (while testing data-mode) always “USB”. Which is wrong imho. When starting the version 1.64 in this envireonment, the answer is PKTUSB, which I was expecting.
Looking at the commands you are sending, there are some issues. Firstly you are sending L commands which are for setting a value, but aren’t sending a value!
rigctl -r localhost:4533 -m 2 L RFPOWER 0.5
Will set the TX power to 50%
If you aren’t in CW mode, the “l KEYSPD” command will likely not work as we don’t regularly request that when not in CW mode.
Apart from setting the CW speed (which I will investigate) all other commands worked as expected for me:
rigctl -r localhost:4533 -m 2 f
7074000
rigctl -r localhost:4533 -m 2 m
PKTUSB
3000
rigctl -r localhost:4533 -m 2 l RFPOWER
1.000000
rigctl -r localhost:4533 -m 2 l KEYSPD
20
rigctl -r localhost:4533 -m 2 s
0
VFOB
By default, wfview will always use the “non selected” VFO for the split TX, there is no capability to set a specific VFO without significantly more work (for minimal reward)
very sorry, I did not want to bother you with my code. So yes, if I send a set command to the rig, I make sure, that all variables are filled as needed.
ie.: $cmd = “rigctl -r " . $host . “:” . $port .” -m 2 L RFPOWER " . $rigNewPower;
The odd thing with CW is, that in V1.64 the l KEYSPD returned a value more or less 4 WPM below the actual Speed. With 2.01 that has been changed to a stepper with 5 WPM. Is there a specific reason for that?
My investigation has shown, that L KEYSPD 4 sets the speed to 20 WPM, regardless what mode the ICOM 7300 is in. So it works for me.
Reason for that whole code around CW Speed was, that with 1.64, when you startet wfview with the radio *without power" (no 12v) and then shut down wfview again, the probability was high, that with the next correct power on cycle the cw speed was set to 6 WPM. My code checked that and set the speed to 22 WPM. The speed doesn’t really matter as long as it is not 6 WPM
In V 2.01 I have not seen this behaviour until now. If you know it and this was a bug, then I can delete my code.
For what reason ever, I could not get the split frequency, when I looked at it yesterday. So I removed the code for the 100KHz split-shut-off. However I do need to switch off split mode, when the OP has startet WSJT-X, otherwise that program will report a failure. Same is for the memory mode, however in V1.64 you could not really switch to the radios Memory mode remote, so I skipped that, for the time being.
Yesterday evening I did lots of tests with rigctl via the cli (to exclude my code). It turned out that
rigctl -r localhost:4533 -m 2 f
lets data Mode toogle every now and then. When you repeat quickly it happens after 5 or 6 commands (always the same) when you do it slowly, at least once in 10s. Very odd.
OK, I think that I have “finally” worked out what’s happening.
As you know, wfview supports over 20 different Icom radios, many of the older radios only have very simple commands for setting mode/freq etc. The rigctld will try to work out the best command to use for a particular radio. This command is also dependent on the VFO, as some radios have have two receivers (sub/main) like the IC7610 and others two VFOs (A/B) like the IC7300.
There are also radios like the IC9700/IC9100 that have both sub/main receivers and each receiver has VFOA/B.
This makes for a very complex set of rules, and if you try to select (for example) sub on a radio that doesn’t have sub/main, it would fall back to a simple mode set command. That mode set doesn’t set the data mode and will cause the radio to switch to non-data.
I have changed the code so attempts to set main will actually set A and sub will set B (for a radio that doesn’t have sub/main) and similarly attempts to set A will select main and B will select sub (for radios that don’t have A/B)
I think that I have thought of every possible permutation, but the only way to know is to test it. I plan to release v2.02 very soon, which will have this enhancement.
