CI-V Transceive on
USB on COM3
com0com COM11 - COM12 to log4om using omnirig
Windows 10 x64
Response is almost immediate changing from wfview or the rig, which is great.
Response between log4on and wfview/rig is sometimes slight, other times up to 8 seconds. Seems to be worse if consecutive frequency changes made.
I have tried changing the polling interval to no effect.
What else can I try?
I have the same sort of issue but with com0com virtual port to jtdx. The lag makes it just about impossible to run jtdx. I can sometimes make FT8 contacts, but FT4 contacts, not at all. I have tried everything I can think of – no go.
Is there still a plan to make wfview and flrig work smoothly together? At one time I think it was on the road map, but I don’t see it there now.
Thanks for all the good work on wfview.
Steve - N7SE
Thank you for your response. Good to see it’s not just me.
If it helps, I also have the eval version of Win4Icom also, using com0com and that works without any lag whatsoever.
Hope the devs can sort this before my eval runs out!
do you all use the same virtual serial port s/w?
Maybe try a different one. I am not using windows but I am not aware of lagging stuff there.
(which probably is the reason it’s gone on the roadmap: it might just work with other s/w; but
I cannot be sure as I don’t run windows here)
Maybe Phil or Elliot can tell more.
Looks like we (Malcom and I) are both using com0com. I am not too much in a hurry to try any others as they seem to have a cost associated with them.
What I am hoping for is that wfview will play very nicely with flrig. I use various pieces of the FL software quiet a lot. So if playing very well with flrig can be put back in the roadmap, I would be very happy. If not, I still see wfview playing a role, albeit a more reduced role.
But I would still see a role, so again, I am very appreciative of the Dev Team. Thanks guys!!
I have never used com0com but I tested the virtual serial port code extensively with VSPE and have never seen these kinds of delays so I suspect that something in com0com is causing them?
The latest v1.2a (alpha) version of wfview includes a rigctld emulation feature which is really the preferred method of interfacing with other software. Unfortunately flrig doesn’t support connection via rigctld but fldigi and various other programs do and it utilises a caching mechanism so as not to overwhelm the rig with requests.
73 Phil M0VSE
Thank you for your responses.
If it helps, com0com works perfectly well with Win4Icom and log4om.
I will download the alpha s/w today and test it out.
Malcolm (2x “L”)
Uninstalled V1.1 and installed V1.2a
After much fiddling about I’ve got connectivity to log4OM
The configuration seems quite responsive, just a hint of lag. All controls I’ve tried work so on the whole this is looking very promising. Well done devs!
Can’t do an live on air test ATM as the cockatoos have eaten my antenna
Settings I’m using are as follows:
My suspicion is the same as yours, com0com has a problem somewhere.
I don’t know much about rigctld emulation except that I think it needs virtual com ports, which aren’t available in Windows except with additional software (such as com0com), or TCP ports, which I think are available in Windows.
Now I think I might understand why flrig was taken out of the roadmap. But if wfview can be made to work well with fldigi, I would be very happy with that too since fldigi is one of the fl components I use a lot (no surprise there I am sure!).
Being quite a bit “in the dark,” could fldigi code be modified to use wfview as a client, in the same manner that it uses flrig as a client, but by using rigctld and a TCP port(s)?
If I am being too much of a “pain,” just tell me to cease and desist and maybe you will get back to me later!
com0com works fine with Win4Icom and log4OM
I suggest that it is the way com0com and wfview are interacting.
Fldigi can connect to the rigctld emulation of wfview already, just enable rigctld in wfview and tell fldigi to use ‘Hamlib NET rigctl’ as the rig type:
73 Phil M0VSE
don’t forget that you need to match the used tcp port as well – you could overlook that stuff easy …
Just a heads up on log4om and hamlib. There is an issue with the config not being saved. When I restarted the app all my values had reverred to default.
I think it is related to this issue so until this is fixed it is not really workable.
That’s interesting Malcolm. This must have been introduced in the latest update of Log4OM as I haven’t updated yet and the settings are saved fine!
73 Phil M0VSE
I am having the same problem with lagging using VSPE as comport emulator. Response between wfview and in my case LOGHX3 can be up to 6-8 seconds as well.
Other programs works just fine, even running a winkeyer remotely with VSPE port emulator.
So unfortunately I think the problem is within wfview and how it handles virtual com ports. same for me on both 1.1 and 1.2a. win10 in the server end and win11 in the client end.
Have not seen any other problems with 1.2a yet. plays just fine. Except for the scaling on highDPI monitor but the edit of the QT variable sorted that out.
Forget my previous comment. It works to Logger32 and UCX-Log. Problem seems to be in logHX3. Sorry for not doing more checks before posting.
Thanks so much Phil. You saved me some time. When I saw Malcolm’s post I figured there already had to be a way - I just didn’t know what it was.
I install 1.2a and have fldigi working in a manner of speaking. fldigi does not respond to any changes to the radio in wfview. But I do have the waterfall and can thus get it to work CW if I just make all the changes necessary in fldigi. I will have to go back and look further at the Hamlib setup and verify that everything is as it should be. But did make a number of CW contacts in the various contests today. Very happy about that.
Also tried to get jtdx working with Hamlib. It keeps losing contact with the radio. Went back to using com0com and virtual ports. Same issue, keeps losing contact with the radio. Haven’t tried wsjt-x yet - its on the list of things to do.
I will keep playing around with both virtual com ports and Hamlib NET rigctl to see if I can get things working better. Haven’t tried using the remote PC for quite some time, so will have to update it with 1.2a and try it out again.
Steve - N7SE
Fldigi should receive changes in wfview when connected over rigctld but it can take a couple of seconds for the change to be reflected, I will test this though as it definitely was working before…
As for JTDX it’s possible that it is using rigctld commands that we haven’t implemented, I tested the rigctld extensively with WSJT-X but haven’t tried JTDX so will install it and try. One thing that you must do at the moment is use the fake-it or none setting for split operation as wfview currently doesn’t support using the rig to control split (this is something that we are working on). I find that fake-it works just as well on WSJT-X though.
73 Phil M0VSE
I have just tried enabling rig controlled split in WSJT-X and sure enough, it blows-up!
I will try to fix this so it doesn’t error but I would definitely recommend using “fake-it” for now. You will also need to manually disable split mode in the rig and restart wfview as it has no way of knowing that the split setting has changed.
73 Phil M0VSE
Thanks for checking it out. I almost exculsively use fake-it for split mode, so no problem there. But I use jtdx unless I am forced to use wsjt-x for a particular contest; so if you arrive at the fix for jtdx, please let me know.
Paying closer attention to what is going on in fldigi using Hamlib rigclt, I saw that if Initialize failed, Use Hamlib would be unchecked. After a lot of fiddling around, Initialize was successful – ONCE. After that, no amount of fiddling around, including powering everything down and bringing it all back up in order would allow Initialize to be successful again. ??? So for now, it looks like its pretty much back to using flrig for now.
Thanks to the Dev team again for all the effort you are putting into this endeavor! I am sure you will ultimately get everything all worked out.
Now to go back to the remote PC and update to 1.2a; I have not tried remote (LAN) since 1.0.
Steve - N7SE