I have done some testing this morning with 1.2a and also seen this problem in previous versions.
The setting on my IC7300 for CI-V transceive changes back to OFF when I close wfview on the remote computer. Not always but a lot of times. Have had several trips down the stairs today to change it back on the radio. Server computer win10 and client both win10 and win11. latest firmware on the radio.
Is there any way to prevent this? Anybody else noticed this?
br
George
No other radio software running on the server computer.
wfview âitselfâ does not change the CI-V transceive setting. What other software are you running on the âclientâ computer? The virtual serial port code attempts to detect and block any commands that disable CI-V transceive but it is possible that one is being missed.
Can you let me know what other software is running and I will try to replicate your setup?
I have found the problem, the virtual serial port/pty code tries to filter-out the CI-V Transceive command but unfortunately, I hadnât realized that each rig uses a different command for this (thanks Icom!).
I have now added a more robust (rig specific) check for this which seems to work so once we have tested it internally, we will release a 1.2b.
Came up on this older thread, and looks like this started happening again when v2.0 was released. Prior to I was using v1.64 for MacOS and itâs been working fine. Currently on v2.11 for the Mac and CI-V Transceive is changing it back to off on the rig when I exit wfView. BTW, Iâm using a Icom-7300 with WSJT and MacloggerDX.
I can 100% guarantee that wfview isnât doing this!
Most likely some other program is sending the transceive off command and wfview isnât detecting and blocking it.
I will check that the code to detect this is still working as it is possible that it got broken in the move to individual rig files that was introduced in v2.0
I had a similar issue when trying to set-up WFView external control with Log4OM. In the WFView manual I read it works with Omnirig. I just couldnât get it to work but using Omnirig on its own switched CI-V Tranceive off. I can use Log4OM fine as connected to the same COM port alone, but not alongside WFView with either Omni or Hamlib. Possibly more a problem for Log4OM than WFView which in all other respects is working fine for me.
Thanks Phil for getting back to me. Looks like when I run standalone wfView it doesnât toggle the CI-V off. But when I startup MacloggerDX I get this msg in wfView log -2025-05-15 05:54:19.551 WRN rig: Unhandled command received from rig: CIV Transceive value: 00. Should I reach out to Don (MLDX) on this?
Itâs been my observation that Omni-Rig will turn Transceive OFF when activated! In other words, Omni-Rig and wfview does not play well together.
If I manually set Transceive ON to satisfy wfview when Omni-Rig is in use, my Omni-Rig devices stop working. It seems to me that wfview should look for ways to NOT be dependent on having Transceive ON so we can enjoy many other ham radio software applications and devices that depend on Omni-Rig.
CI-V Transceive has been around and documented since the 1980s. Itâs time for software to catch up.
What CI-V Transceive allows is for the radio to update the software as to its current state. Without being queried (polled) constantly.
Modern software can simply be written to interpret any radio data received. But very ancient and/or poorly-written software seem to have issues decoding data they did not personally query.
I think we really should lean forward here and ask software programmers to step up. wfview works very well with radio control precisely because of features like CI-V Transceive, which allow us to stay syncâd up with the radio quite well, without saturating it with polling traffic. Features such as the spectrum display cannot work (as well) if we are polling the radio to death with redundant requests.
You can turn CI-V Transceive off if you really want to, but there will be a hit in usability and performance. And you will need to define the CI-V address manually in wfview settings.
I forgot to mention about the obvious USB serial port COM4 conflict between radio control when using omni-rig 1.20 and wfview, when both are dependent on the silicon lab Icom driver. Itâs primarily a COM port conflict!
From a user friendly standpoint, if the user accepts this fact, then the user would expect the âchosen program in useâ to take control of the Transceive setting by turning it ON automatically when using wfview, just like when Omni-Rig turns if OFF automatically when in use. If wfview is programmed to do that (set Tranceive ON when launched), its not working here.
CI-V Transceive has been around and documented since the 1980s. Itâs time for software to catch up.
What CI-V Transceive allows is for the radio to update the software as to its current state. Without being queried (polled) constantly.
Modern software can simply be written to interpret any radio data received. But very ancient and/or poorly-written software seem to have issues decoding data they did not personally query.
I think we really should lean forward here and ask software programmers to step up. wfview works very well with radio control precisely because of features like CI-V Transceive, which allow us to stay syncâd up with the radio quite well, without saturating it with polling traffic. Features such as the spectrum display cannot work (as well) if we are polling the radio to death with redundant requests.
You can turn CI-V Transceive off if you really want to, but there will be a hit in usability and performance. And you will need to define the CI-V address manually in wfview settings.
That isnât possible, at the point of connection, wfview doesnât know the address of the radio, and C-IV transceive being enabled is what allows wfview to query for it (and detect the model of radio).
As long as wfview is always the âmasterâ and Omni-rig/Hamlib/whatever connect to wfview via the virtual serial port, then the command to disable C-IV transceive should be detected by wfview and not sent to the radio (which is the original subject of this thread) if this isnât working, then we will fix it!
IMHO, wfview is one of the best works of software out there for the ham community!
In regards to my observation on Transceive behavior, here are my observations and the steps I used:
step 1: Launched wfview on with Transceive set to On (working great)
step 2: Disconnected from wfview and verified Transceive was still set to On.
step 3: Next, I launched Omni Rig and it automatically set Transceive to Off.
step 4: X out of Omni Rig and return to wfview. Verified Transceive was still set to Off.
step 5: Launch wfview again and verified Transceive remained set to Off. I had to manually set Transcieve to On. Verified that wfview did not do this automatically.
Hope this information helps duplicate my observation.
No duplication is necessary, everything is working exactly as itâs designed to do.
If you allow Omnirig to connect directly to the radio, IT WILL disable C-IV transceive. As I said in my previous reply, it is NOT POSSIBLE for wfview to enable it as C-IV transceive must already be enabled for wfview to detect the radio model, and if C-IV transceive is disabled, wfview is unable to send commands to the radio (as it doesnât know its model/address).
This is how it has always been, and how it always will be as C-IV transceive is fundamental to the way that wfview operates.
Anyway, this has nothing to do with the actual topic of this post, which is a specific feature of wfview to detect when a VSP client is trying to disable C-IV transceive. As I said before, if you never let any other software connect directly to the radio (always go through wfview with a VSP, rigctld, TCP or TCI connection) then this shouldnât be an issue (assuming the feature to detect disabling of C-IV transceive is working)
Interesting. With Trancieve off, my wfview can still launch and work with limitations. Most importantly, it returns with a full compliment of radio status like; CIV address, radio type, baud rate, ip, etc. You should be able to issue the CIV command to turn trancieve back On.
|