I’ve read other issue where when transmitting it shifts a few kHz, but I’m jumping from 40mhz to 146mhz or 86 MHz. I have tried to mitigate any interference by running two farads on my USB cable and running Power/Feed line/USB all in different directions away from each other. I’ve read a bunch of FAQ and I see that there is issues with WFView interfacing with the 7100, but I want to confirm before I use FLRig for Digi control.
Server machine
Dell Laptop running LinuxMint 23LTS with basic HAM software and WFView
running to a wireless AP to a Point to Point that shoots to my house over 50 feet
Client machine
Lenovo Windows 11 Desktop with VSPE and Voicemeter software
running wireless to AP
Ping from machine to machine is between 3-8 ms and WFView audio latency jumps between 40ms to 300~ms (I’m working on getting something better for PtP) with a bunch of audio drops so i actuall VNC into the server machine to run DIGI mode with the HAMLIB server.
I really want to use this software and I’m willing to help in any way I can!
long time no hear - been busy with big remtoe station upgrade (Flexsdr+openhpsdr) adn IC7100 as backup.
I observed thaat behaviour some while ago and lately was running some tests. Interesting findings!
I am only observing this behaviour, when running in Client / Server setup. Whenever I am only using local instance of wfview (ie.just to see large freq.display etc.) I dont have random changes of frequency. When I connect to the local wfview from another PC (both run on 1gbps ethernet) it starts to manifest itself. It wouldn’t be as bad, but what happens is while tuning the TUNING knob (virtual one) using a mouse - whenever there is a glitch in frequency - ie. instead of 144.320 it displays 0.14432 it tunes the radio to the 144khz - out of band and it takes few clicks or manual frequency windows to get back.
So now the question is - could there be a change in network protocol or perhaps have an option to use TCP instead of UDP for the Control port? (just thinking out loud)
Eliggett I’ll take a look at changing the baud rate once i get off work. I ran WSPR off of FLRig and WSJTX last night with no issue I’m going to change it to wfview and test ok2it theory if running server and client. At some point yesterday afternoon I was running just server and running local WSJTX and I don’t think I was having the issue only when I was running client on my windows machine for logging freq it was jumping.
The basic issue is that the CI-V protocol does not have any built-in protection against errors. We do our best to try and fish out correct versus corrupted data, but there are still some errors which slip through.
It definitely seems like some radios are worse than others in this regard. We’re still working on it though.
Ok here is what I’ve done, I started wfview on server and W11 client.
Jumps freq every 1-2 seconds I ran the USB cable in a different way just trying to keep interference away but no avail
!9200 it was jumping freq
9600 Jumping freq https://termbin.com/40j4
4800 Jumping freq https://termbin.com/3631
When I disconnect client, it does not jump freq at all.
I made sure there was no CI-V echo. I cannot raise the baud rate over 19200. I manually raised polling from auto to 75 then 150 and it still does it.
Put a clamp-on Ferrite core on your USB cable. Ensure you also have a good Functional earth on your radio. Don’t earth to the Protective earth on a mains plug.
Kind regards
Peter Juett
Unit 385/36 Hillier Rd.,
Hillier SA 5116
0418802049
pjuett@adam.com.au
Thank you, ill try a different earth tomorrow. The USB cable i bought is a shielded 6ft with a built-in ferrite and an extra clip on ferrite core on the other end of the cable.
We know this radio has this difficulty. And I imagine we can do a bit better under the hood with wfview. I’m pretty sure our V2 branch handles this a lot better.
I am NOT transmitting on my 7100 setup, and i randomly get the frequency jumping to 163Mhz (etc.)
It happens on a connection that has a wifi repeater in the mix, but does not happen to a separate setup that uses only LAN (so far…)
The whole RFi vs. USB issue is well known, and is not an Icom or 7100 specific issue, it’s a USB vs. length of Your USB cable issue. It’s especially bad with USB-C rigs. Wrapping the lead in tinfoil, using a known shielded lead, or using decent ferrites, or all of the above will solve that issue.
This Jumping frequency thing is a WFview thing, as it never happens with the Icom software on the same run, no matter how poor the connection gets.
With the 7100 it is not RFI. It’s just a difficulty dealing with the radio’s message timing versus wfview’s own timing, plus using a protocol without a specified timing and without any level of error correction. Add to it that many radios implement CI-V in half-duplex internally.
With that said it can be done better and the next version of wfview will have some improvements in this category for sure.
Hang in there guys. There’s no need to bust out the pitchforks and ferrite bead voodoo just yet.
For now, crank up the timing interval and experiment with the lowest and highest baud rate for the fewest message collisions.
I completly support what you and the team behind WFView is doing I just wanted to see if it was user error and/or give yall more information to heopfully help make this program better. If i knew anything about programming I would be on board in helping with the cons
Did some watching of my most remote radio today, and saw the Frequency leap about a little, but it was ONLY the display on my client glitching out - the radio actually does not jump about… This is the Log entry from that moment:
2024-03-02 14:19:16.774 INF rig: Unknown control level (0x14) received at register “0x-78” with level “0xf3” , int= 243
2024-03-02 14:19:24.585 INF rig: Unknown meter level (0x15) received at register 4294967176 with level 243
So, this appears to be a cosmetic issue only for me.
Exactly. It’s just a comm issue. It’ll bit you if you’re tuning around in wfview though as wfview reads the current frequency and then adds the tuning step in order to obtain the next frequency. If the frequency is read wrong then the next frequency is sent wrong.
Ah, that explains the very rare instances of the rig actually ending up on some random frequency - I was tuning at the time! I had put that down to the unstable connection adding garbage without thinking into it too much.
OK, looking forward to the fix, appreciate the detail, soz for the noise…
flrig is a really excellent program. Its interface library is something unique and written just for flrig. You can see an example here for the 7300. This is a modern c++ implementation. I could be wrong, but I think it does suffer from some of the issues with hamlib such as not contending with unexpected traffic from the radio.
Unexpected rig traffic examples include CI-V Transceive data when the user manipulates the knobs on the radio itself, and spectrum data, which, once enabled, pours over the CI-V interface at regular intervals.
wfview actually handles this data fine, because we check the data from the radio to see what type of information is being sent, and then we send the data to an appropriate “decode” function. It doesn’t matter if we receive data out of sequence or entirely unexpected data.
wfview V2 takes this a huge step further. Phil re-write the mess that was RigCommander into something that supports full abstraction. The radio is then seen as a generic thing with a plaintext descriptor file that tells the program what features and commands a radio supports. This way, rather than maintaining a mess of “if then else” c++ code, we merely edit the radio descriptor files (which are simple plaintext files), and suddenly wfview supports additional radios and features. This also paves the way for other brands, likely Kenwood and Flex next.
