A number of people testing wfview have found that they are unable to display the waterfall from their rig or control it from wfview. This is generally due to a setting in the menu of your Icom rig called “C-IV Transceive”.
Wfview uses this setting to auto-detect the rig model but unfortunately we have discovered that Hamlib (and likely other software) disables this setting on all Icom rigs as their software generally has problems dealing with C-IV responses that it hasn’t requested.
If you are experiencing this issue, the “fix” is simple, within the Menu of your rig, select Set/Connectors/C-IV and enable C-IV transceive. If wfview is then used to connect to your rig, it will automatically filter any other programs attempts to disable this setting via the virtual serial port/pseudo tty. You should then be able to connect and receive the waterfall and full control of your rig.
One note with regards to this. I was unable to control the rig or see the waterfall even though my ICOM 7300 still had CI-V Transceive shown as ON in the menu. I was able to get it to work through a series of setting it off / on and power cycling, but I’m not sure how much of that was necessary.
I just meant the CI-V Setting. It appears that just unplugging the rig from USB and back into the PC resolves the issue that WSJT-X leaves the port state in. The menus on the radio indicate the CI-V Tranceive was still set to ON.
Interesting… I’ve been playing with CI-V commands via the Remote port ( with arduino… etc ), I usually set the CI-V address in my software as I didn’t know how to auto detect it ( other that whizzing through loads of possibilities ). I do however check for the presence of a radio by requesting the Date/Time from it (unfortunately the R8600 uses a different command to the 7300 ! ) . I thought that Transceive messages were only output by VFO or Mode or Filter change … and if a radio received a Transceive message it doesn’t output a reply.
It turns out that a lot of commands can be sent to destination 0x00, and if a radio has the transceive option enabled, it will respond. So, if we send a 0x19 “rig id” query to 0x00, every radio connected will reply. And from the reply, we get the rig’s model and the CI-V address, which we use after we discover it.
What we might do though, is manually query the models we know are common, and fall back to broadcast if it fails. That way folks don’t have to enable transceive (we will enable it for them upon rig discovery though, because the responsivity to live control operation is very fluid with this enabled).
BTW, time/date, we will probably make it an option to set the clock on the radio in sync with the computer, I’ve wanted that a long time on the 7300 as that clock seems to DRIFT!
Thanks for that Elliot, I was unaware of the rig id command.
re the 7300 clock battery failure … a while ago I had been experimenting with a CI-V / Network bridge ( https://youtu.be/N0np3d6_tgw ) when I also grabbed Date & Time from a NTP server and set my 7300’s clock ( https://youtu.be/q2oqa5LpxlY )
Been playing with wfview and had an initial problem with CIV Transceive - you suggested turn it on - yes that worked fine as far as vfview goes.
However, I have some other software contest logger Minos and to a lesser extent wsjt-x has issues with hamlib giving errors. The solution from the authors is to turn CIV Transceive Off.
Yes that fixes the other software but gives problems with wfview.
I don’t really want to have to keep toggling the menu option off and on. If there a workaround?
Have it working nicely on a IC-7610, occasional lockups but basic stuff working fine. Having problems with the Linux build but havent give up yet. Linux build is on a OrangePi running Ubuntu 18.04 (bionic). GNOME 3.28.2, Kernel 4.9.170-sun50iw9. One heck of a mini computer
I found the transceive messages to be a little annoying with my arduino control solutions. Also I note that the VFO value shown in Wfv can be altered (when the network link to my 8600 appears to be broken) … that implies that Wfv sends a VFO change command (actually a new VFO value) and assumes it got to the radio, however (despite the potential latency in updates) is it not better to instruct the new VFO frequency and then Read it back as positive confirmation of it’s current value. I.e. poll for all displayed attributes, otherwise Wfv displays what it thinks is the radio’s state, and perhaps not what is the actual state? By the way I poll for S-meter, mode and VFO - but interleave so that S-meter data is gathered with every other CI-V message I send…my next bolt on will be NB and NR related settings to be controlled via rotary encoders.
Yes, for some things, we do update the UI right away, although we also send a command to verify. For example, a user rapidly scroll-wheeling around the spectrum, we can send out change frequency commands pretty quickly, and just update the UI as we go. When the scrolling stops, we can check and make sure we’re correct.
The other thing about transceive, if you open wfview and you’re sitting at the radio and you just spin the dial, you really won’t believe how fast wfview responds to the change. It may even appear to be “as fast” as the radio’s screen. Compare that to most polling solutions, such as fldigi or flrig, it’s very noticeable, even when the polling is set rather fast.
I think what you folks are doing is great, and I once was going to use PROCESSING to create something similar for me, but decided on a hardware solution locally - mostly to avoid using the touch screen. it’s still a wok in progress . https://youtu.be/4Y8DB74AjZk
“Processing” as in the javascript graphics artwork environment? Brave man!
It looks like you’re good with hardware. What do you think in terms of hardware controllers? We are considering supporting MIDI control codes so that generic MIDI controllers could be used (and there are so many to pick from, which is nice). But we’re also looking at custom controllers and other things.
I wasn’t going to mention it until I had something to test but I have one of these (Contour Shuttle) and I already wrote the code to access it (in Windows) for another project so I may have a look at this once we have completed release 1! It is basically a USB HID device.
It’s a bit cheap feeling to be honest but what is quite nice is you also have a jog wheel around the outside which you can use to change the step size. 5 buttons is a bit limiting but the RC28 is only 3 buttons and a single encoder!
Most if the effort to make the controller work is actually in the software, the hardware is relatively straight forward. I haven’t played much with off the shelf controllers so can’t comment much. I guess Midi or DMX are well developed … by coincidence I’m looking at DMX for a different project.
