In my continuing efforts to arrange remote operation of a field station, I have had the opportunity to try out the official Icom RS-BA1 software.
I have been testing using essentially the same configuration as I had been testing wfview:
Rig connected via USB (tested with both IC-705 and IC-7300)
Client/server configuration, i.e. two copies of the Icom Remote Utility in use
Connection via public internet (I’m actually testing via a 4G hotspot)
This works absolutely fine. If there are any problems with UDP delay or sequencing it isn’t apparent to the user. So under identical conditions where wfview fails with long drop-outs, the Icom software seems to get the job done.
Unfortunately, although this was an interesting experiment, it doesn’t provide the solution for what I’m trying to achieve. It has two significant disadvantages:
a) Cost - especially for multiple operators
b) Windows only (I need a Pi solution)
So… is there hope for improving wfview performance, or is there a trick I’m missing? Are others succeeding with client/server operation via the internet?
In almost all of my testing, wfview performance has been identical or better than RSBA1 over similar network connections.
It does occur to me though, if you are using WiFi on the Pi, you must disable periodic WiFi network detection as this will cause a dropout (I think) every 60 seconds.
Have you tried RemoteTX which works nicely with RPi? I purchased the ICOM remote app… loaded it, took one look at the dashboard and deleted it. Way too busy for my remote ops preferences. Just need PTT, rec vol and a few features…
I have RS-BA1 that I use in my house and remote locations with a windows laptop and I use WFVIEW with a macbook from the same locations. On my home network with good wifi signal RS-BA1 has far less notcieable audio dropouts than WFVIEW. What I don’t understand is that even when WFVIEW is showing no increase in the lost packet count there are noticeable audio dropouts. The dropouts are short but annoying. As I type this the RX latency is jumping about between 12ms and 30ms, packet loss count is not changing, RTT changes between 1ms and 2ms. But when I hear the audio dropouts the RX latency jumps to about 100ms and RTT jumps up to 40-50ms but at the same time the packet loss counter often doesn’t change. I think it might be MacOS doing stuff in the background. I can make it do this badly by clicking on the WiFi icon in the top bar which drops down to show the wifi signals that are visible to me. While that dropdown is open there are lots of audio dropouts. Try it and you will see what I mean. I never hear this type of dropout with Skype or Facetime so how are they dealing with the odd lost packet? Our radio use is all simplex with changeover that takes half a second so you could buffer 200ms of audio and we would never notice (well until you use up the buffer).
Inherently, UDP is more sensitive to network dropouts than TCP. The only way to make UDP (used by the Icom radios) more robust is forward error correction basically, which is a way of creating redundancy and/or detecting errors with correction schemes. Since the radio doesn’t have that feature, we can’t add it. That said, we do have a way to do this we have looked at when going between two copies of wfview, such as we do with the IC-7300, and you might see that one day if there’s enough demand for it. If RS-BA1 really does handle network glitches better, then we have work to do, which we will do :-). The user experience is really important here and of course glitchy audio is something we want to avoid.
Believe it or not, I have not actually ever used RS-BA1, so I can’t comment on how much better or worse it is audio-wise. I’ve watched enough videos on youtube to frighten me away from it (for example, a one hour video on how to install RS-BA1 which ended with it not actually working properly). And of course, it doesn’t work on other platforms, which is a non-starter for me.
I like how the RS-BA1 supports so many radio controls that wfview doesn’t have yet, but I also find the interface super cluttered and the setup seems unnecessarily difficult. To me, I really do want a UI/UX with just the basics planted front and center – frequency, mode, PTT, etc. Same controls I have on my Yaesu FT-7B please. This is one reason why some of the newer controls we have added are under a dialog box instead of living in the main view tab. One day I hope we can make the interface fully customizable with draggable elements, similar to customizing the microsoft word toolbar or the macOS Finder (a cocoa toolbar):
I love the great work that you guys are doing. I have a spare copy of RS-BA1 that I bought by mistake. I saw recently that there was a new release so I ordered a copy but when the disc arrived it turns out that it was the same version I already had. Silly me! So I am happy to donate it to you. I could send you the disc image and registration code if you want to have a play?
2022 is already here and looking good - well the sun is shining but we won’t talk about Covid.
I though most VOIP systems used UDP as there is no point in inserting a lost packet later in a live audio stream after later packets have already been delivered. I figure VOIP systems must have a small buffer so they can deliver seamless audio. We run 3CX VOIP at my company and it works well until we have network issues than it is horrible. I have used Skype to a friend in the Congo. He has very slow internet. We can’t use video but the audio is really good. So if you can find out what they do that would be a good thing to copy.
I bought the MFJ RigPI two years ago. It is very crude compared to WFVIEW and I could never get it to work reliably so I gave up. They use Mumble for audio which was a hassle to set up but when it was running the audio was excellent with no dropouts so it could be worth investigating how Mumble handles packet loss. Mumble is used a lot by gamers who spend crazy long hours talking and playing and they do not tolerate dropouts.
I have even used wfview across the Atlantic ocean to radios in Europe without much trouble, perhaps 1% packet loss at most. Forward error correction, one way or another, is how it’s done, plus of course a generous buffer. The FEC means the correction is coming down from the stream a priori any loss. For example, MFSK in fldigi has FEC, and this causes the receiving station to be able to, in near real-time, compute missing characters from the FEC data coming in with the original transmission. Anyway, we can’t make the radio do anything it doesn’t do from the factory, but we can of course do our best to handle any glitches as gracefully as possible. And when you do a wfview to wfview connection, such as the IC-7300, then we can implement better protocol protections, such as FEC, which we might do with Opus.
I’d take you up on it but I don’t even have a computer running windows. I just have a single VM that I spin up for automated builds. No USB, audio, or even full internet access from that VM. To me, this is the best way to run windows – in a box, and only as-needed. It’s a tool, I use it when needed, and then close it down.
We had 48 hours of rain here in LA recently, but today the sun came out and I agree, 2022 should be off to a good start.
Mumble latency must be down in the low tens of milliseconds to keep those gamers happy.
The Wikipedia page says;
What makes Mumble better?
Mumble has very low latency combined with good sound quality; it uses OPUS, CELT and Speex, not just the voice compression technology, but also the voice pre-processing to remove noise and improve clarity. Mumble also has positional audio for supported games, meaning the other players’ voice will come from the direction their character is in game.
Many if us would have no problem leaving a laptop (Mac or Windows) running by the radio if that gave better wfview performance. I want to also control my Yaesu rotator. Acom 2000A linear and Steppir antenna. I’ll get there one day.
I read here that the transmission delay is around 60ms.
Both mumble and wfview support Opus, but again, only for wfview to wfview connections. Opus has very low bandwidth and high quality results, and also seems less glitchy to me, although that isn’t something I can really quantify.
For linux users, if you enable the PORTAUDIO build option in the wfview.pro file, then you can build with portaudio and achieve latency around 20-30ms. We are thinking about bringing this option to other platforms, but it’ll need some testing first. On linux, I’ve observed that portaudio builds tend to lock around the selected audio interface and don’t always take to sharing kindly. But that may just be me, we’ll see. On the other hand, the latest version of qt seems to have better audio support. Time will tell which backend is the best.
There would be a commercial demand for software that runs on a mac or PC or Pi that sits beside the radio and does some real horsepower noise reduction. I have tried several software packages but they don’t work nicely with SSB and the best ones are not real time which is pointless for ham radio.
I enjoy working QRP stations who are running a few watts portable. They can hear me running 1KW into my Steppir but they are way down in the noise. I put on headphones, crank the volume up and muck around with noise reduction and receive filter and RF gain but the noise is still high. Imagine a low cost Pi with some software controls to bring the voice out of the noise. You guys are clever enough to do that.
