Has anyone been able to connect sdr console or sdruno to wfview? Both only use omnirig to connect, as far as I know. I don’t think either one uses hamlib, at least I can’t find any reference to it. Right now I have splitter set up in VSPE and point both wfview and sdr console, or sdruno, to that virtual port which is connected to the ic7300 com port. That works fine but I would like to try connecting through wfview if possible.
If you can use gqrx to talk to the SDR Uno, then we have a script which can synchronize the tuning between the two programs.
This is just a very basic script mind you. It could be expanded a lot. You need to enable the rigctld-compatible server in wfview (see the manual) and then run this script in python3:
—E
de W6EL
This sounds interesting, and perhaps might be on the route to getting a remote waterfall display from HDSDR running an Airspy connected as an IF tap to my Icom 7100. I’ve still got to overcome the no sound problems first, though.
Well after more research I still have not been able to connect sdruno or sdrconsole directly to wfview. Everything except log4om is connected directly to the ic7300 via a splitter setup in vspe with sdruno, or sdrconsole, using omnirig. Log4om is connected to wfview via hamlib rigctld. Problem is, I can turn on the ci-v transceive on the 7300 but as soon as I startup either of the sdr programs omnirig turns off the ci-v transceive. Right now I have wfview set to use the Manual Radio CI-V Address: 94. Waiting for the new version of sdruno, called sdrconnect, to be release sometime before the end of the year to see if it might have different connection options besides omnirig. Also going to check out hdsdr and see what connection options it has. I really love wfview and will continue to use it but I’d like to be able to use it the way it suppose to be used, with ci-v transceive turned on.
Here’s the deal with CI-V Transceive:
With CI-V Transceive ON, wfview can automatically find the radio on the CI-V bus simply by sending a query to the address “0x00” and asking for rig ID. This, I believe, is how CI-V is intended to be used and is sort of the “magic” of this protocol. No more entering in manual CI-V addresses, and model numbers are automatic for most radios! Additionally, when the user makes a change to frequency or mode (or band), the change is automatically sent by the radio to anything connected over CI-V. This means we can track the radio’s tuning dial and mode in near-real-time. You can spin the dial on the radio and wfview will show the frequency as fast as the radio’s built-in screen.
With CI-V Transceive OFF, you do need to specify the radio’s CI-V address in wfview. But once you do this, the experience will be very similar. wfview won’t track a dial spin at the radio as fast, but it does poll the radio for current frequency at regular intervals, so it will never be wrong for more than a brief period of time.
That’s the consequence. Not much really. If it works ok for you with CI-V Transceive off, I’d keep it that way. The reason some other programs keep turning it off for you is that they cannot cope with the radio producing CI-V data that they don’t expect. Many radio control libraries, like Hamlib, are designed to send a query and then interpret the reply, and if they receive data they do not expect, they fail to decode (or decode incorrectly). wfview is different in this respect, we run any data received from the radio through all our “what command is that” code, always, no matter if we were expecting something or not. This lets us be rather responsive to the radio. It’s also the only way to deal with the waterfall data, which come in unannounced at a rather brisk pace. Once you turn on the waterfall faucet, you have to contend with a constant rush of data. Fortunately, CI-V traffic is padded with very easily recognizable bits, indicating the start, end, to, and from in a way that is different from the rest of the CI-V “packet”. It’s elegant, and I can see why Icom stuck with it all these years.
If you have trouble using wfview with CI-V Transceive OFF, let us know, maybe there are some issues that we haven’t worked out yet?
–E
de W6EL
2 Likes
Thanks, that explains a lot.
I think I will keep wfview setup the way it is, for right now at least. My setup is wfview and log4om which I have connected via rigctld. Sometimes I use sdruno, or sdrconsole via a virtual com port (VSPE splitter, com20 to com4, com4 being the usb port on my 7300). Wfview is also connected to com20. I also run jtdx, or wsjt-x, and gridtracker when working ft8/ft4. Jtdx, or wsjt-s, is connected to the 7300 via com8 which is the 7300 ci-v usb port. Everything seems to work fine setup this way.
The only problem I’ve had is when I’ve tried to connect a program to the wfview virtual port. I have a virtual pair setup in VSPE. I’ve tried jtdx, wsjt-x, sdruno, sdrconsole, and log4om. jtdx and wsjt-x will connect directly, sdruno, sdrconsole, and log4om all connect through omnirig. I can get any of those programs to connect ok, but the frequency display on all of them keep changing back and forth between the 7300’s vfo a and vfo b. It changes about every 5 seconds. Not sure if this has anything to do with the ci-v tranceive setting or not.
Thanks again!
Hi Alan,
I suspect the flipping between VFO A and VFO B is a consequence of more than one hamlib-based program trying to grab both VFO frequencies. Hamlib by default flips between both VFOs to make sure it has the frequency of each. But I imagine if two or more programs were doing this concurrently, it could become a race condition. Maybe if you can slow one program down significantly or cause it to not query for a moment that will help? I doubt it has anything to do with CI-V Transceive.
This is one reason wfview doesn’t have dual VFO yet, we want to make sure we do it right, and it’s so easy to make it very complicated.
–E
de W6EL
The only software that is currently using hamlib is log4om connected to wfview. The vfo issue only occurs when I connect a software to the Virtual Serial Port in wfview.
That is likely going to be the same issue, that the software connected to the VSP is constantly requesting VFOA and VFOB. There is nothing that wfview can do about that and it has nothing to do with CIV transceive, just how the software works unfortunately.
Phil
1 Like