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.
Dev Team,
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.
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)
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.
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
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!
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:
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.
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!
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.
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.
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.
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.
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.