I tried wfview at home on my lan and it worked great, but not so well from the road over LTE. I heard audio for a moment and the display came alive, but then it locked up. I’m trying to rule out the connection speed and I’m curious what minimum bandwidth and latency work well? This begs the question if the spectrum and waterfall display should have an option to disable?
Thx!
hi Kevin,
the main screen has “enable wf” – you can switch on/off the scope/waterfall.
re the best latency settings – that totally depends on your LTE provider. I’ve had
good results on the same carrier at home and when at work, it’s totally different
as I have a different BTS which may be busy (Rotterdam city in the Netherlands).
latencies may vary well over 100ms from what works at home.
You can see at the main screen what the RTT/latency values are and if they jitter a lot
you need to increase at least the rx and tx latencies if RX shows red a lot.
HTH
Hi Kevin.
To be honest, in my testing, the waterfall data comprised a very small percentage of the bandwidth requirements of wfview. By far the most data bandwidth is the TX and RX audio streams. A single channel LPCM16 stream at 48K sample rate requires 768Kb/s (not including any UDP protocol overhead)
There are a few things that you can do to reduce this:
These simple fixes can dramatically reduce network bandwidth (using the first two will reduce the requirement from 768Kb/s to 192Kb/s with minimal quality difference)
73 Phil M0VSE
Another thing to bear in mind, if using wfview over a VPN, the VPN overhead can cause packet fragmentation which ‘really’ confuses wfview. By using an 8bit codec like uLaw and/or reducing the sample rate, the size of each individual audio packet is significantly reduced so will not require fragmentation.
73 Phil M0VSE
Thanks everyone for the replies. Couple of things… I tried the uLaw codecs but when I reconnected with those settings, I heard highly distorted and loud audio that was unusable. This is on MAC. Any idea what to do in this case? Radio is a IC7610 firmware 1.3 (latest).
Also, in general I’m curious why the radio and software seemed to lock up when I had a poor connection? The radio seems fine when interacting with it in person, but through the remote features it appeared dead to the world until a rebooted the radio. This is observed in wfview as a failed connection that was previously working fine. In my scenario, this occurred on the interstate where there’s usually sufficient coverage (at least around Chicago here). I waited several miles, still no joy… then tried again at my destination with WiFi and the same. Anyone else experience something similar or know what settings might be contributing to it? It’s highly unfortunate if the radio gets hung up easy requiring physically resetting it in order to recover from a poor remote connection. At least that’s my perception of it all. Things to try or confirmation of the same would be helpful. thanks
if you can’t get a connection anymore you should disconnect, xit, wait a minute or two. What happens is that the rig generally keeps the LAN status on and as long as it’s on you cannot reconnect but won’t reset either.
In my experiences with the 785x, 7610 and 9700, found that the "wait a few minutes and relaunch the s/w helps.
hth
Hi Kevin.
What version of wfview? The issue with distorted 8bit/uLaw audio should be fixed in 1.2c.
73 Phil
Version 1.1. I’ll give the newer version a try this weekend as well as experiment a bit with a longer disconnect time period to allow the radio to reset.
thanks
I upgraded to 1.2c on mac and reattempted my connection tests from the road while tethered via wifi to my phone over an LTE connection. In short, the same issue occurs regardless of how long I wait to reattempt to connect. I’ll note I use uLaw codecs now which work fine (at least initially). Receive delay is set around 200mS. My hotspot connection seems fine when I browse the internet from the same laptop when the loss of connection occurs.
I connect successfully and it all works for about 20 seconds, then the waterfall data drops out, then everything else. Attempting to reconnect is unsuccessful and produces no error. I don’t have the other Icom software to perform a side-by-side comparison of remote connections, but I would guess that it’s a bug in the radio software manifested by something that wfview is trying to doing.
I don’t really have a use for local (home) LAN based connections with wfview, but rather true away-from-home operations.
Has anyone else experienced anything similar? Is there a comprehensive log that might have insights as to what instructions were sent from wfview just prior to the loss of connection?
Hi Kevin
Wfview has been extensively tested connecting to a number of different rigs (local, remote and VPN) and this has not been our experience, so it is unlikely to be a specific issue/fault with wfview or your rig.
Unfortunately you can’t really compare web browsing with real-time audio streaming over
UDP, as the two are completely different, some providers can throttle UDP traffic which could be what is happening here?
A few of us have also used wfview connected over a 4G dongle fine so it is likely going to be something specific to your environment which is throttling UDP traffic?
You can run wfview with the -d (debug) flag which will generate a lot of debugging information in the log file. My guess is that excessive data loss is causing numerous retries which eventually exceed the retry limit and the connection fails?
73 Phil M0VSE
WFview Benchtest with IC-705 with USB-cable to PI3B with ethernet and a PI400 with ethernet to a same router.
Linux “Nload” program says 885/840 kBit/s in/out with LPCM 1ch 16bit and
With Opus 1ch only 160/115 kBit/s.
That is 80 % reduction!
Just RX with Waterfall and WFM station.
/ regards Tommy
Phil,
I want to make sure I understand your recommendations right:
The preset of “Opus 1ch” for RX and TX will be the most effective for
remote operation?
When combined with a sample rate of 24K: Will the VAC setting of 48K
have to be changed also?
Are the above mentioned settings compatible with FT8 decoding requirements?
The questions refer to a IC-7300.
Thanks, vy 73,
Willi, DJ6JZ
Hi Will.
Yes when using wfview server, I would definitely recommend Opus 1ch. I have found it works very well with wsjt-x. You can try changing the sample rate to 24k but I don’t think it would make much difference to be honest as Opus is optimized for 48k.
Wfview incorporates a sample rate converter so there is no need to change the sample rate of your VAC.
73 Phil M0VSE
Data speed:
Setup: IC-705 - USB-cable - Pi3B - Router - Pi400.
sample Incoming kbit/s / outgoing kbit/s
rate lpcm-1ch16bit lpcm-8bit Opus 1ch
48000 900/850 500/445 180/100
24000 500/450 315/255 150/90
16000 380/320 250/195 145/82
8000 250/200 190/130 140/70
Measured with “Nload” on Raspbian and RX only.
No difference with rig on FM or CW (!)
/ Tommy SM6NZB
I generally use iptraf instead – does differentiate between sources and destinations too. Maybe nload can do too? I’ll check and see.
Hi Tommy,
The fact that there is no difference in bandwidth usage between modes is because it uses an uncompressed PCM stream, so there are always the same number of bits being sent, regardless of mode. I would expect to see a small difference in Opus though as that should be able to compress a narrower (CW) signal more than it can FM? Maybe worth trying between CW and WFM?
Good to know that I was correct in my assumption that there wouldn’t be a significant difference when using lower sample rates with Opus. I would say stick to 48K for the best sounding audio.
In theory for SSB with a 3KHz passband, an 8KHz sample rate should be sufficient to achieve intelligible audio, but you will hear a significant drop in quality.
73 Phil M0VSE