Announcing hl2_relay , a new UDP to UDP buffering relay

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

Announcing the experimental beta test release of :

 https://github.com/hotpaw2/hl2_relay 

This is a UDP to UDP relay server specifically designed for the

Hermes Lite 2 SDR's METIS Protocol 1.

This server could be particularly beneficial for network connections

with severe latency jitter, exceeding the 10 mS to 40 mS buffering

capabilities of the FPGA, and causing HL2 Rx/Tx relay chatter noise

and Tx breakup.  Unlike other methods, this server runs on a Linux or

macOS server with only one accessible IP addresses, and thus does

not require a Raspberry Pi server to have its built-in WiFi enabled.

It’s a command-line utility that is useful for SDR client applications

that allow manual configuration of both the IP address and the port

number used to connect to the HL2.

For example, you can use the following command to start the server:

./hl2_relay -a <IP_ADDRESS_OF_HL2> -p 1026

I run the hl2_relay server on a Raspberry Pi 4 that is co-located

and on the same LAN as my two HL2 radios. However, the Pi is not

connected to any HL2 via any direct Ethernet cable.  I configure

my SDR application to connect to this virtual HL2 server on the Pi

using the IP address of my Raspberry Pi 4 (not the IP address of

the HL2 itself), and the port number 1026. The hl2_relay server on

the Pi then acts as a buffering relay, and relays all UDP packets

from my SDR application to the Pi's port 1026, to the HL2's port

1024, as well as relaying UDP data from the HL2 back to my SDR

application.

The size of the fifo buffering can be configured.

For instance, you can use the following command to change the default

buffering sizes:

./hl2_relay -a <IP_ADDRESS_OF_HL2> -p 1026 -tb 80 -rb 40

These default settings add 200 mS of buffering to packets transmitted

to the HL2, and add 100 mS of buffering to data packets returned

from the HL2 back to the SDR client application. (The parameters

add 2.5 mS of buffering per UDP packet of 1032 bytes in the METIS

OpenHPSDR Protocol 1 format.) This setting allows me to use my HL2

remotely without experiencing significant hiccups, even over a

mediocre WiFi connection that has a varying ping latency from 3 mS

to nearly 200 mS between my SDR app host and either the HL2 or the

colocated Pi 4 server.

I’ve been conducting tests to evaluate the reception and transmission

of both SSB and CW modes using my iPhone’s rtl_tcp SDR app. The app

is available from Apple’s App Store. (Testflight invitations and/or

promo codes for free downloads of the iOS/iPhone/iPad app for HL2

users are available upon request via email. Please provide your

callsign.)

It’s important to note that the added latency will cause significant

challenges in QSO operations due to the extremely slow turnaround

times for SSB and CW signals. Attempting QSK CW type operations

through this relay server is likely to result in a poor experience.

If you decide to try this setup, please send feedback and bug reports.

Thanks and 73,

Ron

N6YWU

[G4ZAL]

Hi Ron,

Is this similar to Jim's 'HL2 wifi buffer' ?

https://github.com/jimahlstrom/HL2WifiBuffer

Nigel
G4ZAL

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

Similar, but Jim's wifi buffer seems to require the Raspberry Pi to provide WiFi access, and for the HL2's ethernet cable to be plugged directly into the Pi, instead of one's LAN.

My UDP buffer is designed to use with the HL2 and Pi plugged into one's LAN, and without the need to run WiFi services on the Pi.  This topology allows both direct high speed access to the HL2 or Raspberry Pi over one's wired LAN.  Plus the option of running the hl2_relay server on the Pi for higher latency (WAN?) connections.

73, Ron, N6YWU

[G4ZAL]

Hi Ron,
Jim's buffer does not necessarily require a wifi adapter, it can use 2 ethernet adapters.
It does require an ethernet port to be connected directly to the HL2.

I made a very quick test of your buffer...

On a R-Pi, downloaded the github zip file, extracted it and ran

make hl2_relay

This produced the required hl2_relay file.

Found the IP address of my HL2 and ran

./hl2_relay -a <my.hl2.IP.address> -p 1026

Running Quisk on my PC, changed the port from 1024 to 1026 and set fixed IP to <ip.address.of.r-pi>

Quisk connects OK and I can Rx and Tx - however, when dekeying from Tx to RX, I get a small amount of the tail end of the Tx buffer played back on Rx !

Jim's buffer used to do something similar in that it 'popped' on Rx after de-keying, but I think that was fixed.

I can see a use case for both yours and Jims buffer application.

Nigel
G4ZAL

[Niklas Nordsjö]

Great job!

I have tested it and it seems to work as stated. No relay-chatter when TX over Wifi. Will try it remote over VPN later.

I run it in an LXC container on my home server. It's easy to choose if you want to connect directly to the HL2 or via the relay, by selecting the appropriate ip in Thetis. The relay does not interfere with direct connection in any way.

I think I will use this alot, thank you!

/Niklas SA5NIK