VNC/Remote Desktop versus VPN for remote HL2 usage

[Steve Haynal]

Hi Group,

Since I had an interesting recent opportunity to use a HL2 in the Ukraine via a VPN connection, I wanted to compare this method with the VNC/Remote Desktop method I use with my HL2 at my sister's house.

With VPN, I saw very consistent network bandwidth requirements. This is expected as it is the raw openhpsdr packets which are sent over the VPN. But it wasn't as costly as I anticipated. There is a constant ~3.5Mbs outgoing to the HL2. Whether or not you transmit, the host software must send the full TX packet which uses a fixed sampling rate of 48kHz. Depending on the number of receivers and width of each receiver, the incoming rate varied from ~6.5Mbs for single RX at 48kHz to 28Mbs for single RX at 384kHz. Note that I can not do multiple 384kHz receivers with my 50Mbs max internet connection, but it should be possible to run at 48kHz or 96kHz even with the second receiver required for PureSignal enabled. I found the VPN setup very usable, although I did not transmit except for a few short low power tunes. It really is as if the HL2 were on your local network. 

With VNC/Remote desktop the required network bandwidth varies with what windows you have displayed. With all windows minimized, I saw <10kbs for both incoming and outgoing. When I just have the WSTJX window maximized, I see network spikes of 11-12Mbs every 15 seconds when the spot window is updated. The WSJTX waterfall requires the most, at 16-23Mbs. The Quisk graph and waterfall require 2-3Mbs. SparkSDR required 26-27Mbs. My VNC connection is setup without audio, so audio would add more. As you can see, a VNC/Remote desktop can require more network bandwidth than a single 48kHz connection over VPN. But you are only paying this bandwidth requirement only when you actually look at the windows. Most of the time I have them minimized. Second, you can skim 10 bands at 192 kHz as all the HL2 traffic is to the local remote machine. This would require around 150Mbs bandwidth on a VPN connection.

So in summary, both methods are usable and have their pros and cons.

73,

Steve

kf7o 

[Pez]

Hi Steve, 

I have also found similar results in my testing. I have found that connecting to my HL2 remotely over a VPN connection works better than expected, providing the sample rates are kept as a sensible rate (96k and 48k). I have found that SparkSDR works well over VPN, and even over the internet with basic port forwarding of UDP port 1024 (no VPN needed at all). Unfortunately, Thetis does not work in this way because it won't pass the directed UDP discovery packets in the required way over "most" VPN's, or via port forwarding, that are needed to wake the HL2 up. I really hope that the Thetis developers will implement the same method as SparkSDR uses! 

 
What SDR software were you using for your VPN connection tests? 

FYI, for "VNC" I use Splashtop Business remote desktop - it provides native audio passthrough, so my remote speakers and microphones just work! It's a very nice all-in-one option (no mumble or anything else required) but it is a paid service. 

73

[ron.ni...@gmail.com]

The issue I've found when using the direct protocol 1 UDP over WAN is that network latency jitter can cause a transmit signal to break up. Using ether a VNC, Remote Desktop, or different network protocol can reduce the likelihood of this potential problem.  So the method I've been experimenting with is hybrid, doing IQ demodulation from a TCP stream on a remote mobile device, but sending commands to synthesize CW or FT8 IQ waveforms on a Raspberry Pi colocated with the HL2.

73,

Ron

n6ywu

[DL1YCF]

Yes I think the size of the TX IQ FIFO inside the FPGA is the problem.

Upon RX, you can simply increase the size of the audio buffer (a.k.a. the audio delay) to something between 100 and 200 milli-sec and will experience
little problems if, say, the stream of incoming packets is disrupted for 80 msec and then the missing ones come in a burst.

However, the TX IQ Fifo is about 80 msec (if I remember correctly) with the HL2, and not much buffering is done inside the SDR programs. So a
„time out“ of 80 msec will disrupt transmission (this occurs if the TX IQ fifo drains).

A larger „UDP“ buffer as an additional software layer will increase the latency (that is, the microphone-to-antenna latency) but make transmission
more stable.

> --
> You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/426794b8-c1f2-4e43-a0f6-924a73b8f131n%40googlegroups.com.

[Kurt V.]

Hi, 

I am waiting for my Hermes Lite 2. I will find a way to remotely control it. Audio wise, I am thinking of combining the audio input with some third party software like Zello. I have used Zello to interface with other radio's and I have been pretty successful. Once I am getting some results, I will keep you all in the loop. Don't expect broadcast audio quality when interfacing with the Zello app, but I am pretty sure I will find some workarounds. 

Kurt de ON7OFF

[Angel Andres]

Hi Ron,

Interested to know a bit more about your remote CW keying.

I have seen a remote CW keying setup via a winkeyer and Astrogeeks COM2TCP software in Windows environment by SM7IUN. I think the Flex system uses something similar too (winkeyer remote).

This is convenient, but doing it with a RPI has other advantages.

Ref your comment - "sending commands to synthesize CW with a Rasberry pi"

Is the CW keying done by the front PTT/CW 3.5mm socket at the front the HL2 or done via SDR software? Are you using a Winkeyer emulator? 

73 Angel

M0HDF