Brief summary of problem (put in title as well): IC-7100 - often wrong frequency displayed over USB-CAT-19200
Radio Model:ICOM 7100
Connectivity (USB/Ethernet/Wifi/Other): USB
Operating System: Windows 10, Linux (Raspbian,Armbian,Ubuntu)
wfview version (press “About”): yes
Checked the wfview manual (Y/N): Y
Checked the wfview FAQ (Y/N): Y
Tried to google it (Y/N/NA): Y
What I did: So far no remedy
Expected behavior: Frequency to stay exact like on IC7300 or 756Pro3 over CI-V
Observed behavior:
Very often, frequency changes from i.e. 3763kHz to 2.32211. It would not be a big deal, but if that happens during a tuning (using a DIAL) frequeny instantly changes to the wrong frequency being displayed. So while tuning through 80m band, I suddnely end up on VHF, UHF or out of band.
I was also running IC7300 - same HW just radio differes, no problems there. I therefore thought it will be USB cabling, changed a lot, no change. So installed FLRIG - doesnt happen. Tried Win4Icom on Windows machine - same , no frq.change but wfview - Windows does. I am thinking possibly some overdrive of poling / not enough time ??
P. S. - I am using rigctld/hamlib instance f wfview - when this happens, f - command display the wrong frequency being displayed by wfview.
We see this behavior only with some older radios. It has to do with the CI-V traffic getting corrupted. Some code went in recently to work against it but from the sounds of things it’s not quite enough.
It is interesting to me that the IC-756 Pro III doesn’t have this issue. That may be very telling. The 7100 has an internal USB port, you’d think that would be the better-behaving radio of the two. But you are saying the 756 Pro III, which you must be using an external CI-V adapter, is more stable in this regard?
What adapter are you using on the 756 Pro III?
I’m keen to solve this issue but it is very tricky.
I just realised that CW keyer isnt usable much on 7100.
I was using it a lot on 7300 - memories, keyboard keyer etc. When using same on 7100, speed changes to 6 wpm, pitch to 350Hz or around. When I manually change, every time I got to main menu and back to CW, it resets to 6 wpm. Also it seems that the CI-V commands are being distorted not only on FREQ but on settings currently being polled.
yes it does seems to relate to older radios, altough 7100 is still being sold as new Maybe they will put new FW in it. What bothers me is that other software running on same setup (RPi4 + OS + radio) oesnt exhibit this. (I tried little script, where I run rigctl, and just keep sending f:
if I get anything else than:
F 3763000
it logs an error. I havent got one over night yet.
Anyway as for IC-756-Pro3 - I was testing it on a PC with Windows 10, onboard SMC Serial port, connected to CI-V level shifter, home made (simple single diode to allow “full duplex hi”.)
I will be reverting to IC7300 as main rig, but I am still using 7100 as VHF,UHF main radio and 23cm using XVRTrs. (Off Topic but I am surprised how well it does in QRM Alley, which JN89DG in centre of EU activity, with everyone running round 1 KW on VHF lol) so having possibility to remote in, use rotator and both 2m / 70cm is just wonderful.
You’re right, I shouldn’t consider the 7100 older!
The difference between your manual testing versus wfview is probably that wfview polls the radio for the s-meter regularly and, at a slower rate, polls other radio parameters. This helps us stay in sync with some things the radio doesn’t immediately tell us about, such as attenuator or preamp selection.
You can adjust the polling in wfview. Try a higher polling interval and see if it helps. You can also try different baud rates. Generally lower baud rates seem to do better. The only thing you may really notice with slower polling is a less-responsive S-meter.
Only a few radios actually will give you full-duplex CI-V. It’s generally half-duplex single-wire, even inside, and even on some USB-connected radios. The 7410 seems to be one of the exceptions, with separate TX and RX lines going from the USB serial adapter to the CPU. I don’t have a 7410 but it does seem like a nice radio.
So I was playing a little with my shack setup… and while doing some work I left the IC7100 , now connected to high performance shack-pc with Windows 10 running and … I see no more frequency hopping. Interesting. I then fire-up my remote laptop (I can do VNC) and I connect WFVIEW 1.64 to the WFVIEW 1.64 running in the shack and - lots of frequency jumping. It seems that phantom isnt coming from the path between IC7100 and WFVIEW over USB Port (Virtual Serial) but it is the CI-V over UDP with combination of low speed CI-V that is causing the issues. i compared the logs:
So possibly some way of enforcing TCP Traffic for the CI-V Port perhaps?
BR Jiri
PS - Server is Beefed up PC… LAN is 1gbps - Fiber to Motorola RFS4000 (fiber) to OpenWRT Router , which goes to Internet using VDSL and PPPoE (250Mbps Down / 100Mbps up) bonding.
At home I have Internet using 1gbps fiber… dedicated.
The server log shows a lot of collisions on the CI-V bus.
Have you considered increasing the polling time interval? I believe you are at 75ms right now. Perhaps try setting the client and server to 150ms? Save settings and re-connect, server-side first, then client side.
Yes I tried. What happens then is that it polls less frequently, but eventually it again displays wrong frequency but this time it takes little longer to correct itself. What I do not understand is that none of the other programs querying the IC7100 using a same port, hardware etc.dont see this issues, but also if WFVIEW is used alone as standalone , no network, it also doesn’t exhibit the issue.
So I guess maybe some way of enforcing CRC? I was even thinking of using a VPN over TCP, rather than UDP and using a self correct protocol to make sure, there is no packet loss - at expense of latency / speed.
I doubt it is network related. It’s probably an issue with how we merge all the traffic down and also how we handle collisions. Collisions are a common thing with CI-V, unfortunately.
This may be something you see improvements for in future versions.
Of course one of the machines doesn’t really have to poll at all. You could set the client to something like 2000ms and leave the server at 75ms. This would result in a lot less CI-V collisions. The client would still receive the result of the server poll anyway.
Maybe they will put new FW in it. What bothers me is that other software running on same setup (RPi4 + OS + radio) oesnt exhibit this. (I tried little script, where I run rigctl, and just keep sending f: