Thanks for posting that in such a readable format. I find myself handing out lists of 7300 settings for various apps, and it really helps to have the visuals.
One thing many users seem to miss is the fact that settings for various modes can all be saved on the SD card for instant recall. And in order to know what preference settings are in use at the moment, I find it handy to insert the name I’ve given to those settings under DISPLAY > My Call (in place of my call sign), so that it displays upon ‘power up.’
Do you mean that I can store CIV settings as a sort of “profile” on the SD card? Can one SD card have more than one profile? I think that’s what you’re getting at, which would be super handy!
I haven’t seen any way to share them yet, but it would be very handy if Icom would let us share Presets like the FT8 preset they included with Firmware 1.4. I’ll have to look and see if I can find any one way to save those to the SD card.
I am using OmniRig so both wsjt-x and my logbook program Log4OM can read and use the usb Port. This works great.
In most cases Hamlib is causing problems and switching to OmniRig solves the problem.
In OmniRig you need to select ic7300 data.
In wsjt-x and Log4om, I select OmniRig 1 as radio.
This means in Wfview there must be the option to select OmniRig 1 as radio.
I have successfully connected OmniRig to the wfview virtual serial port but wfview must connect direct to the radio first and then OmniRig connects to wfview.
It can’t work the other way round as a: wfview does not support OmniRig (it is very unlikely that it ever will as OmniRig is Windows only) and b: wfview relies on accessing features of the radio that OmniRig cannot provide.
Hi Phil,
Thanks for trying out.
I guess when Omnirig is in 7300 data mode it passes
all the required data to Wfview just like it does to WSJTx and Log4om.
If Wfview requires full control to the radio, does wfview support remote operation for WSJTx as WSJTx Neede to switch band and mode?
wfview requires a LOT more information from the radio than WSJT-X and Log4OM, much of it OmniRig isn’t even aware of, especially waterfall data. As I said though it is a non-issue as you can use software like VSPE to create a “pair” of virtual serial ports, wfview connects to one of these and OmniRig connects to the other one as described in the manual https://wfview.org/wfview-user-manual/sharing-control/ wfview then passes any commands that it receives from OmniRig to the radio (filtering out any commands that would cause wfview to stop working)
I’m responding to this post because of the power off comment; I found that after a firmware update to the radio, a power cycling of the power supply, NOT just the radio, was necessary. However, it gets stickier than that …
Initial it wasn’t working and I found the CI-V USB was linked to remote. Unlinking from remote got it working. I also checked CI-V USB Baud rate (was set to auto but changing it had no effect) and CI-V transceive (it was on).
Then updated the radio firmware to 1.4, restarted it and WFview wouldn’t connect.
I disconnected and reconnected the USB cable, then switched the radio off and on, no help.
Then I powered the power supply off and back on and that brought it back to connection.
To prepare for this post I checked the baud rate again to see what it was set to originally and I found two different baud rate settings; the “CI-V Baud rate” and the “USB CI-V Baud Rate”.
Both were set to auto - and the waterfall seemed a little sluggish compared to the radio - so I set it to 115200 and WFView stopped working again.
I of course reset it to auto but that did not help.
Now, nothing I have done - including checking all of the CI-V settings or power cycling things - will make it work; WFview remains unconnected to the radio (green/blue dots and “NONE” in the lower right corner.
The waterfall over USB will always be sluggish compared to the radio, there is nothing that we can do about that as it is the speed that the radio sends the waterfall data.
It will almost certainly be a setting within the radio causing the issue but as you have discovered, there are a few different ones. If you have used any other software that uses Hamlib then this will have reconfigured things, especially CI-V transceive.
The next build will have the ability to manually configure the radio address so there is less reliance on CI-V transceive.
I have never had to power cycle any radio during testing so I would make sure that you are running the latest version of the Icom USB driver and auto baud rate should be fine.
There are indeed two baud rate settings. I think one is basically for the 1-wire CI-V connector, and the other is for the serial port emulated over USB. Here are the settings I am using on my IC-7300:
The two baud rate settings:
CI-V Baud rate: Auto
CI-V USB Baud Rate: 115200
Other:
CI-V address: 94h (default)
CI-V Transceive ON
CI-V USB-> REMOTE Transceive Address: 00h
CI-V Output (for ANT): OFF
CI-V USB Port: Unlink from REMOTE
CI-V USB Echo Back: OFF
USB Keying (CW and RTTY): Off
USB SEND: Off
As Phil said, the IC-7300 doesn’t send out waterfall data as often as the other rigs. But it should never feel “behind”, rather, just slow.
I went through your setup pages earlier and found nothing additional or different.
Then I found a recommendation and instruction on how to see if the com port was working using this code in a power shell. Get-Content $env:TEMP\wfview.log -Wait -Tail 30
It wasn’t working even though it had been before.
I set it to use the specific com port and that fixed it.
Working now.
I’d like to hear how that 7100 goes. I’ve put a lot of support in for that rig and the 7200, but we haven’t had much feedback on how all the widgets function. Those two rigs in particular are kind of neat because they have lots of modern features, including USB audio, making them nice candidates for remote operation.
My most exciting rig to try was the IC-706… it works, but there isn’t much that it does (no PTT, no tune button, no USB audio, etc).
