Remote over Internet

[Benjamin Koe]

Is the HL2 accessible over a remote internet connection using openhpsdr?

[Steve Haynal]

Hi,

The openhpsdr protocol 1 works well for wired home networks, but can have problems if there are high latencies and jitter on the network such as you might see with a remote connection or wifi. I operate a remote HL2 but there is a computer connected directly to the HL2 at the remote site and then I access that computer via VNC. There is no audio and I only operate digital modes.

73,

Steve

kf7o

[Rune Øye]

Hello

I do similar things. Have all my SDR radios in the garage then from my house on the same network I use AnyDesk for remote.

When I go for a visit to my parents 600km away I also use the AnyDesk and surprisingly the sound works well. I do have a fair internet connection on both sides. Even diversity with two RX works when using any desk. Running all my applications, SDR software, logbook ...... easy and works well.

73

Rune

--
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/8cdebe19-c14c-4be3-820a-b46e77cf7558n%40googlegroups.com.

[jose manuel Bernabeu]

I use a raspberry 4 in the remote station and I manage it with vnc, to transport the audio I have chosen to use mumble, which of all the options is the one that I think has the least latency, through a 4G connection

73

[Art]

Hello.

I am using a dual core router with a VPN server. But also tried OpenVPN and SoftEther software. You need to configure broadcast traffic and L2 tunnel. So this configuration worked with 200ms ping and USA to Europe points. There are no problems with connection within the country at all.

пятница, 2 апреля 2021 г. в 12:25:42 UTC+3, ea4...@gmail.com:

[Roger David Powers]

Hello, Jose.

I am interested in this kind of configuration especially since it is using open source solutions.

I have done very little research.

Which SDR application(s) do you use on the RPi4?

What modes do you operate (SSB, CW, digital)?

What other audio solutions have you tried?

Does using PulseAudio work well enough over a SSH tunnel?

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

The Metis/Protocol 1 UDP connection to an HL2 seems to only work reliably for Tx over completely wired connections that have a well bounded network latency over the entire network path.  This latency is very hard (if possible at all) to control across a wireless or remote WAN network.

When using my HL2 as a receiver over a remote WAN or WiFi connection, I use hfp_tcp running on a local Raspberry Pi, and an rtl_tcp client remotely.  The RTL-SDR clients usually use large buffers (network and audio) to cover network latency variations.  I wrote an iOS and macOS client app that supports this use case.  Email me directly if you want to try beta testing this.

The other possibility is to use a computer (I use a Raspberry Pi 4) local to the HL2 for the SDR application, and connect to the Pi remotely for just running the user interface, via X, VNC, or other Remote Desktop.

73,

Ron

n6ywu

[Jaroslav Škarvada]

> Does using PulseAudio work well enough over a SSH tunnel?
>

For me it doesn't work reliably over internet and also the latency isn't
good. It may work better through the good internet connection and it
works quite well on LAN.

I also tried lightweight solution by not splitting full PA server/client
through the ssh tunnel, but by utilizing the PA modules
module-tunnel-sink(source)(-new) and by forwarding just the mic/audio
mono channels through the tunnel. It works a bit better, but I
encountered several PA bugs (I reported all to PA upstream) which also
made it quite unreliable (e.g. PA authorization problems, it goes quite
often out of sync, sometimes just garbage is going through the tunnel,
etc.).

I got the best and very usable results with the OpenVPN UDP tunnel and
PA modules module-rtp-send(recv) to tunnel the audio through the UDP as
RTP. With such setup SSB/FM/FreeDV modes works quite well (for me) and
latency is quite good for real-time two-way communication even over poor
internet connections. The other parties usually aren't able to identify
that I am working remote

73! Jaroslav, OK2JRQ

[Roger David Powers]

Thank you for sharing your experiences, Jaroslav.

I too have found PA issues when trying anything other than the mainline use cases.

I will have to do more reading to understand how to do what you are suggesting.

Your email gives me confidence that it can be made to work.

Regards,

RDP

--
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+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/83d69e45-56a3-6c31-c047-cc5ebcf05124%40yarda.eu.

["Christoph v. Wüllen"]

Since it is possible to stream music and even movies over the
internet, not being able to „stream“ the SDR audio means
that one does something wrong.

I do not suspect there is compression missing (one could
resample to 8k if needed for SDR audio). Most likely,
one needs to „insert“ a FIFO filled on the average with
several hundreds of msec of audio
to cope with sample packets arriving at irregular intervals.

Only my $0.02,

DL1YCF Christoph.

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

It's a QoS versus latency trade-off.  Streaming media services compress and buffer large time slices of video and audio ahead of time, and burst at much higher than the average data rates to catch up, which works well for pre-recorded content.  Conferencing services use error concealment strategies (creating fake data on the receive end) with much shorter buffers.  But if you want real-time and valid data, for instance for QSK operation, then neither of these strategies, to conceal QoS and latency variation problems, works well.  If a protocol only buffers 10 to 40 mS of data at the receive end, then occasional network pauses of 100 mS (often several) will cause severe glitches (even if a subsequent high speed burst from channel buffering catches back up to the required data rate).

I've experimentally found that to allow reasonably reliable streaming over a wide range of generic WiFi and WAN networks, my hl2_tcp/rtl_tcp SDR apps have to buffer ahead, up to 800 mS of IQ data.

73,

Ron

n6ywu

[Steve Haynal]

Hi All,

I don't think we will ever have openhpsdr protocol1 work well over remote connections with the larger latencies and latency variations, especially given the smaller and less expensive FPGA used in the HL2. But I think a server/client model with a server connected directly to the HL2 will work well. The server can even be an inexpensive Raspberry Pi. This is what n6ywu does with hl2_tcp. It has been done in the past with QR radio. This compressed the audio with the opensource and ham-developed codec 2. I would love to see more use and development of openwebrx. There is initial support by N1ADJ.

73,

Steve

kf7o

[Jim Ancona]

Thanks for mentioning the OpenWebRX HL2 support, Steve! I released the initial support, started work on a more functional release, then got sidetracked by a number of issues (Covid, buying a new house, moving...). We're moved into the new house, although there are lots of boxes still around and no antennas up yet. I hope to return to developing the connector once I make progress on some of those issues. In the meantime, I'm happy to answer questions.

Jim

N1ADJ

--
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/5b10eb60-8afa-4e64-acc3-a3ad4b46ea8an%40googlegroups.com.

[jose manuel Bernabeu]

Thank you all for your responses.

Every day I am more happy to be part of the Hermes family.

How many talented people contributing ideas and work.

I am sorry I am not up to your talent, but I will gladly try any software and will continue working on my project to remote Hermes from my country house.

Thank you very much Ron for your help with the HL2_tcp, Steve for your interest and work. And of course thanks Jim for your work to use the openwebrx, I'm looking forward to trying it.

Thank you so much everyone.

73

EA4CF

You received this message because you are subscribed to a topic in the Google Groups "Hermes-Lite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hermes-lite/LuvENtEnVcU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CAKYY9ALNyFRaf-tcnRUE7h3ZHbcObfUiY8561GuNGSVeH_bxOw%40mail.gmail.com.

[Ramakrishnan Muthukrishnan]

My remote setup is as follows.

The radio is connected to a local switch. The switch is connected to
the ISP provided router. On the switch, I have a desktop and a
raspberry pi. The pi mainly runs Pi-Hole.

I usually travel with a laptop running Debian GNU/Linux. I have got
the free software mesh-VPN software called "tinc" installed on all
these systems including on the Pi and also on an external server on
digital ocean. The digital ocean server runs Debian and the data
center is close (ping times are in 5ms range). For this discussion,
assume that the laptop is outside my home network with another private
IP 192.168.1.100. At home, there is the radio, with an IP 192.168.1.2,
say, and Pi with an IP of 192.168.1.3. The Digital Ocean VPS has a
publicly accessible IP. Now, tinc gives private IPs to all these
(10.0.0.1 to laptop, 10.0.0.2 to Pi, 10.0.0.3 to VPS) and all are
accessible with each other. Now theoretically, SDR software can run on
my laptop and can access the radio sitting at my home. Not so easy.

The problem is, Radio is in another subnet now and VPN is on another
subnet (10.x.x.x). So, the radio is still not accessible. But with a
fixed IP assigned to radio via MAC layer based filtering, I wrote a
small UDP proxy that relays packets arriving at Pi's (10.0.0.2's port
1024) to Radio - 192.168,1.2's port 1024. Similarly, packets from the
radio are also relayed back to the SDR software. The UDP proxy is just
under 100 lines of Go code which is easily cross compiled to Pi or any
other platform.

With this setup, I have made SSB and CW QSOs - CW via a MIDI keyer
connected to the laptop.

There is another problem though. The radio is full duplex, so the
latency matters in the setup like the one I have. Suppose, SDR
software keys CW on. This reaches radio a few milliseconds later and
puts the radio in TX mode. However, the radio Rx is on and picks up
this signal. In the usual circumstances, you do not hear this because
the SDR software is in TX state. However, with latency, the SDR
software is in Rx state, while the remote radio is in TX state, so you
hear part of what you sent. For CW, this is very annoying. I remedied
it with a large QSK timeout value. But that is not always desirable.

Hope this helps. May be the above description looks complicated, but
it is not so! The only complicated part is the tinc setup. I can also
publish the UDP proxy code written in Go if anyone is interested. Have
used it for many hours now without any problems so far.

If anyone wants to replicate this setup, I can offer help, please
email me privately. (I run only GNU/Linux on my computers, I do not
know much about Windows and macOS). Tinc is an amazing piece of mesh
vpn software that makes this possible! It traverses the NAT in most
cases, unless the ISP provided router uses Symmetric NAT (which is a
problem with video calls as well .. and they use STUN/TURN standards
to send/receive UDP packets with or without an external relay).

73
Ram VU3RDD

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CADeq3S8DB-YX3f_KO5mNSD10EEUfyF6Omc6p%3DTuLLT-xA-SpnA%40mail.gmail.com.



--
Ramakrishnan

[Art]

Hello Group. In fact, not everything is so bad with a VPN server. I have done a lot of tests with VPN server.

OpenVPN on a router with the required firmware (for example, Mikrotik) or software VPN servers based on OpenVPN or SoftEther work well with the radio.

Required Internet connection speed:

PowerSDR:

48 kHz - 7-10 Mbps

96 kHz - 15-20 Mbps

SDR Console:

48 kHz - 5-6 Mbps

96 kHz - 9-12 Mbps

Basic VPN server settings:

-L2 tunnel

-broadcast traffic - enabled

-UDP traffic - enabled

-Compression and encryption of data - disabled

When using a router with an OpenVPN server, it makes no sense to keep an additional computer turned on.

вторник, 6 апреля 2021 г. в 09:09:55 UTC+3, vu3...@gmail.com:

[Steve Haynal]

Hi Ram and Art,

Thanks for you posts on using the HL2 over a VPN. They should be very helpful to group members.

73,

Steve

kf7o