RRC Just Unusable Over Wireless ISP at Radio Side

[K3TN]

We've been doing remote contesting for 4 years, using Remote Rig for controlling a K3 and VNC/RemAud/Wkremote to control remote shack PCs controlling FT5000s at two other positions. This started at K4VV back in 2014 or so and in 2017 transitioned to W4AAW after Jack's death.

There is no wired Internet connectivity available at W4AAW's Round Hill VA QTH and the RemoteRig connection becomes unusable quite often - lots of audio dropouts, loss of N1MM synch/connectivity, etc. The problem is short periods of high latency and essentially high level of jitter overall.

The VNC/RemAud approach works fine over these conditions. Have posted a number of times over the years to this forum and tried all the various settings and tweaks, make some progress but the dropouts never go away completely and overall improvement is minimal.  Usable for casual QSOs, but for contesting (or even trying to work a DX pileup) it is just not usable.

We finally gave up and have switched the K3 postion over the VNC/RemAud and PC remote control approach. Lose the ability to do the K3 Or K3/0 twin approach and remote paddle keying using Wkremote is far from as good as via the Remote Rig - but it works reliably.

I hate to give up completely - especially since free software solutions like VNC and RemAud seem to be able to work fine over the same Internet connection. Anything coming from Microbit in the future that might help?

73 John K3TN

[dj0qn]

John,

I am trying to understand your situation; are you saying that there is no way to wire ethernet at the
station location for the RRC's to connect to the router and need to use WiFi, or what exactly do you mean?

73,
Mitch DJ0QN / K7DX

[K3TN]

Hi, Mitch - the RRC at both ends are wired Ethernet. However, at the radio end the Internet Service Provider is a wireless ISP - there is no wired Internet service to any houses where the W4AAW QTH is.

So, on one of the towers we have a small dish aimed at the wireless Internet Service Providers.  When we do the simple speed tests, it is a pretty fast connection, and when you do one or two ping tests, the ping time is usually 30 ms or less.

However, if you do long term ping tests you see short periods of 100, 200, 250 ms latency. The RRC audio does not tolerate that very well and the data connection with the N1MM contest software also gets interrupted - loss of connection happens a lot, even when there are only minor blips to the audio.

This connection works fine for remotely operating the other positions using RemAud for audio and VNC for remotely running N1MM on a PC at the remote shack. It also works fine for Skype, Youtube videos, etc. - but RRC to RRC audio and data communication does not tolerate it as well.

Does that help explain the scenario?

Thanks and 73 John K3TN

[dj0qn]

Hi John,

Yes, now it is clear. I agree that RemoteRig is not that tolerant on higher latency connections. I assume that has something
to do with the SIP protocol used.

I really can't think of a solution beyond changing the internet provider. In a couple of stations I am involved in, we use Ubiquity
Bullets to bridge the stations to a solid provider. That works great as far as 50 km. I am not sure if that is an option in your case,
but I would think that even using 4G would be a better choice.

73,
Mitch DJ0QN / K7DX

[n6ldj]

I will echo the Ubiquity product comment above.  We originally had a very poor WISP connection (it was free, but signal was off the side of this ISP's distribution antenna; packet loss due to poor margin).   We then purchased internet from a different WISP, located at a different site, about 22 miles from our desired (radio RRC) site.  This new ISP obtained his internet from a large data center, one (licensed) microwave hop away, so he was solid.

We then installed a Ubiquity 3.5 GHz Rocket product between his site and our radio RRC site.  38 dB margin (using 26" dishes) and it has only dropped for about 3 minutes in three years (better than 99.999% availability).   10-30 Mbps, TDD.  $850 total.  Just works.   

There are no open 2.4 or 5.6 GHz channels in the San Fransicko Bay Area region, so we used the clear 3.5 GHz band and worked hard to get 3.5 GHz international radio models.

Do you have a place you could connect to, line-of-sight, within about 22 miles?  We were lucky as the ISP site was 1450' AMSL, and our radio RCC sites was 2200' AMSL, no obstructions.       

[sm2o]

There is only one way to increase tolerance against jitter, it's by increasing buffering. We did a lot of tests in the beginning and ended up with the buffer sizes we have today. As this is a real time system where we want audio and tuning to be syncronized increasing buffering will not work. Even with todays small buffers, max settings will make tuning difficult. Systems like Skype adjust the buffering automatically if the connection is bad. The data channel can also be made bullet proof by using TCP instead of UDP (we tested that also) but again this will affect the real time feeling. So with this kind of system a good internet connection is mandatory. So improving the 4G link by external antennas, changing ISP or using a radiolink if it's possible are the alternatives. I use a Ubiquiti Powerbeam M5-400 5GHz link for a 21 km jump to my own remote station, or eg two links to have redundancy.

73 de mike