These issues seem like they might stem from high packet loss on the network. The way wfview talks to the IC-9700, packet loss will be a much bigger issue than with other common network tasks. This is, for one, because the protocol uses purely UDP, which does not automatically attempt to re-send failed packets. There are some provisions in our code to send things multiple times, but we do not receive anything from the radio to acknowledge that packets were received. It’s a very raw protocol.
As for not being able to re-access the radio, this happens when the 9700 does not receive our “log out” at program close. Again, if there are dropped packets, this command could be lost. When the 9700 doesn’t receive a log-out, it will not allow the user to re-connect until some time (around 5-10 minutes). Of course rebooting the radio resets this timer.
If you have a way to measure ping time and packet loss, you might want to give that a go and see if you notice anything interesting. It may be quite different if others are using your network at the same time, for example, watching netflix or youtube over the same wifi.
I’m using Linux Mint here, and both my laptop and IC-9700 are connected using gigabit ethernet over standard off-the-shelf switches and surplussed cat-5 cables. Nothing fancy, but I do not show any dropped packets in wfview, even when running for hours. We’re likely running the same build of wfview, I’m usually on whatever is in the master branch.
Going across the pond to my colleagues’ radios in Europe, I may see about 0.5 to 1% packet loss (just look at the lower-right corner in wfview for the packet loss – it is shown as LOST / TOTAL).
Let me know if you have any ideas after reading over this. I’ve got linux and a 9700, and it should work better than what you’ve experienced so far.
Ok. One more question…
It is (I do not know why) but not so reliable… I am unable to connect from remote location even if trying once per hour… I was able only to connect once.
Is connection more reliable when connecting wfview → lan ic-9700 or wfview → wfview → usb ic-9700?
most of the time channel 1, 6 or 11 (2.4 GHz) is the best to choose from. Also, Everybod near you should only apply the ouptut power required to do the job. I knnow that some people think that more is better but in fact will interfere much more.
Is connection more reliable when connecting wfview → lan ic-9700 or wfview → wfview → usb ic-9700?
a direct connection w/o wireless is probably more reliable but has a major downside – the speed.
The USB connection is pretty clow compared to the scope updates you see now over wifi.
What I’d like to understand is that is “communication protocol” between wfview server and wfview client is the same or different than between ic-9700 LAN and wfview client…
From my “short” testing it looks like the implementation of icom protocol is VERY vulnerable to network quality.
And as I’d like to use it over Internet for remote station… it is of my interest;)
I do not consider WIFI as a problem now, as I’ve a) solved it b) removed wifi from my path
The wfview server uses the same protocol as the server built into Icom rigs.
Generally I have found that the protocol is fairly resilient to occasional network instability but the available bandwidth must be sufficient for realtime audio. This is one of the reasons that we implemented the Opus protocol in the wfview server as it significantly reduces the bandwidth requirement.
