I’ve seen this behavior mentioned in other threads, not sure if it has it’s own thread so I figured I’d start one. (Let me know if it’s duplicate.)
IC7300, working well with the most recent Windows build.
I shutdown Wfview, start WSJT-X and get no connection.
WSJT is set to 115200 baud rate so, I lower it and no success, return it back to 115200.
Next thing I try is radio power cycle using the hardware button.
That fixed it.
Note, I did not disconnect the USB cable, nor did I turn off the power supply to the radio so the com port remained connected throughout.
Thanks Elliott, that works, but now I have to change the com port in WSJT every time I switch between running both Wfview and WSJT, or WSJT alone.
I could - and probably will - just always run Wfview as a “server” for WSJT and other digital stuff from the PC, just need to spend some time to see if that will work for me.
Still, it seems to me that a power cycling the radio shouldn’t be necessary to be able to switch to a different PC application. I’m wondering what state in the radio gets reset with the power cycling, and whether exiting Wfview could reset that state.
Yes we have discussed the need for wfview to reset the state of the rig back to where it was. This is quite a complex issue as many rigs have literally 100s of settings, and some may not have been changed by wfview itself but by whatever app is connected to it.
Yeah Phil, I get it. It’s a complex task.
Recording current state then putting it back at shutdown, or making it optional to do either, there really are no easy answers given the large number of radios it supports.
But something needs to be fixed.
It seems every time I want to restart Wfview it doesn’t work, and when I change the settings to make it work, then it fails when I want to use other programs - either though Wfview or without it.
Right now I’m trying to get Wfview running and it won’t connect. No idea what I did to make it not work anymore.
I don’t use WSJT but on WSJT-X, I have set up two different config files to allow me to switch between USB connection and Wifi+WFView - does WSJT have this as an option? Mind you, it’s somewhat moot because keying up below 50MHz disconnects the USB anyway despite all the ferrite on the lead, so I shall be using Wifi most of the time anyway
In my extensive testing (all 1 day of it so far!) I’d say the biggest pain is on the rig side where you need to switch the Mod Input settings between USB and Wifi - not sure if WFview could automate that when it detects a connection by USB instead of Wifi?
There also seems to be a “feature” of the rig that you can set the mod input to Mic AND USB but not to Mic AND WLAN but I guess that’s down to Icom to fix!
Hey Martin
I use the terms “WSJT” and “WSJT-X” interchangeably but I use the -X version.
I also have several configurations including one for an RSP receiver which I can run concurrently with the transmitting version, but I really dislike fiddling with it because the default of a new configuration makes separate logs and then they all have to be uploaded.
I have even experimented with running multiple instances of WSJT-X on the same radio, transmitting multiple streams at the same time. It works but it creates a real operator task load.
But still, the real annoyance as far as Wfview is concerned is that the radio has to be reconfigured every time something changes.
When I tried FLrig the other evening, the radio started randomly switching frequencies and doing other uncommanded/undesired changes.
Then it was happening even with Wfview off so I assume some setting on the radio which Wfview needs is confusing FLrig.
But I still need to confirm.
Re :flrig, flrig is a great program, but I too find it annoying that it goes to a default frequency and changes receive filters every time I open it. I feel like it has a configuration for this, but I can’t seem to get it to work.
I’'m not perfectly certain yet but the CI-V transceive seems to be important.
I still need to experiment though. I just recently installed Log4OM and initially, using the radio control (through Omni-Rig or Hamlib) caused the VFO to rapidly and randomly switch back and forth. The transceive setting setting seemed to fix that.
I’ll update as soon as I get a clearer picture.
If you define the CI-V address manually in wfview, you do not have to have transceive turned on. However, wfview won’t track any changes made by turning the knob on the rig (or might but poorly so).
Thanks Elliot, that’s a good tip.
Wfview doesn’t initially recognize the radio if transceive is off but if it’s turned off after Wfview is started, it works just like you describe it.
When I have Wfview running, I generally prefer controlling the radio with it anyway so that may be an option - transceive off if I’m running other programs.
Something else I wasn’t aware of and ran across while trying to set up Log4OM is that the 7300 and a few other radios have a second CI-V port. The “CI-V USB Port (Default: Unlink from [REMOTE])” function will either link or unlink these.
The Remote CI-V port uses 5v but there are cables available which connect to USB so I’m going to order one of those cables, use the main USB for Wfview and the other port for the log or data modes.
Just a warning, if you enable the traditional CI-V 1-wire port on the 7300, then you will not have waterfall capability. This is because Icom only enables waterfall if you are at 115200 baud, and the CI-V port is limited to 19200. You might also experience echos on the bus, which could cause some unintended behavior.
If you define the CI-V address under Settings in wfview, press Save Settings, close wfview, and then open it, you should see wfview discover the radio almost immediately and report the correct model in the lower-right corner within about half a second of starting wfview. This is with or without CI-V Transceive turned on. But remember you must:
Thx Elliot, sounds like a plan.
Except …
Any address higher than 7e returns an error message in the bottom left corner “Could not use provided CI-V address”. All other numbers below that seem to be accepted.
Checking the table of Icom radios, 7e seems to be unused so I set both the radio and wfview to that.
It also did find the radio, either with or without transcieve activated.
Next try was 7d, also seems to be an unused by Icom address and this worked.
Obviously that’s going to affect my other software so it’s really not a solution.
EDIT - saw other posts that this is a known issue.
Thx.
Just a warning, if you enable the traditional CI-V 1-wire port on the 7300, then you will not have waterfall capability. This is because Icom only enables waterfall if you are at 115200 baud, and the CI-V port is limited to 19200. You might also experience echos on the bus, which could cause some unintended behavior
Again, using the 7300…
I finally received the cheap USB to CI-V port cables and hooked it up. Win 10 recognized the com port just fine, no driver needed.
On the radio I changed the CI-V USB→REMOTE Transceive Address from 0 to 94h.
I now have full waterfall on wfview, CI-V Transceive = ON and can now control the radio with either Omnirig, FLRIG or WSJT-X (Hamlib?), while running wfview without having to change anything on either the radio or the other control apps.
One caveat is that Omnirig sets CI-V transceive to off. The rest seem to leave that setting alone.
This also eliminates another problem I was having daisy chaining off of the wfview virtual serial port; control dropouts. Intermittently, every few minutes or so, WSJT-X or Omnirig would just lose connection to the radio, and pressing retry usually reconnected. I suspect this came from the high baud rate having to go through wfview but not really sure.
So the separate CI-V hardware port on the 7300 can be run at it’s max speed of 19200 while the USB CI-V port runs at 115200.
This now seems to be a great configuration … if I wasn’t out of USB ports on my PC
(Also note, this is still early testing but so far it’s working better than the virtual serial port)
but I guess that’s down to Icom to fix!