Remote operation of a portable station

I’m new to Wfview, and trying to work out whether it can be used in the following situation:

If we have a contest station on a remote hilltop, with no internet connection other than a WiFi hotspot running on a 4G mobile phone, can Wfview be configured to allow remote operators (plural) of the station?

  • What would be the appropriate configuration?
  • How will the remote operators initiate the connection? (Bearing in mind that a mobile hotspot does not have a fixed IP)

Any advice appreciated…

Hi Russell,

What you propose should be possible. The difficulty may be in how to work incoming connections from other places into the cellular connection, through the hotspot, and into the pi. There are definitely plenty of ham radio applications where this has come up (asterisk/allstar comes to mind).

In general, I would think that having the Pi automatically join a VPN would be a good idea, because then you won’t have to fuss with mapping ports or seeing what ports work on your LTE system. However, there can be some issues with UDP on VPNs, in particular if the VPN fragments the packets.

A quick google search yeilds some interesting tricks using ssh to set up a UDP-friendly tunnel, for example:

You could do as above with pre-shared ssh keys to automate the ssh login, and then create a service that runs on startup to do it.

Please let us know how it goes, there will be many that are interested in this sort of system.

de W6EL

Thanks for that response. Yes, that should be possible to initiate the call from the contest station, but if we have more than one remote operator then I’m wondering if the following might be possible:

  1. Contest station running Wfview sets up a VPN call to a known internet location - for example, my house.
  2. At my location, I run Wfview, and connect the two instances. I can now operate the contest station remotely.
  3. An extra operator can set up a connection to my location (not to the remote location). This is a simple internet connection with port-forwarding, and no VPN is required. The extra operator runs Wfview and connects to my instance.

Is this “daisy-chain” configuration supportable and realistic?

Hi Russell.

Yes in theory it should be possible to ‘daisy-chain’ connections in this way although it isn’t something that we have tried. You can also have multiple connections to a wfview server (only the first sends TX audio).

73 Phil M0VSE


I use something similar in my summerhouse. allthough another remote solution. I use a dynamic dns-service. In some 4G Hotspots you can configure them to update the dynamic dns-server when a new IP-adress is received.

They can also have a small linux client which does the update of the reccord in DNS.
You connect to a domainname instead of IP.

I have not taken any security settings into account here. You get a more secure solution with VPN. But a bit more tricky.

A piece of warning: Make sure the mobile operator you choose dont use Carrier Grade NAT. If they use adress translation you will not be able to connect to the device .
That might be overruled if you can start a VPN session from the hilltop to your home. The other way will not be possible if the operator uses NAT.


Good to know - thanks, Phil.

We are a long way from building anything; just playing with concepts at the moment. But I’ll run some experiments over the coming months with the aim of having something operational for next year’s contest season.

Örjan - thanks for your comments, too. I have a feeling double-NAT by the mobile operator will defeat incoming connections, but I’ll certainly run an experiment with dynamic DNS and see what happens.

Check this out. Works a treat over double NAT and it’s free!

I have been progressing this, and now have a “daisy-chain” configuration partly working, but audio is not being passed to the end client.

Here is the configuration:

  1. Raspberry Pi connected to IC-705 over USB. The Pi is connected to the internet using a mobile hotspot, thus simulating a portable station. The Pi runs wfview with a server configured, and also a VPN client, which is connected to…

  2. Ubuntu on a PC (actually a virtual machine) on my home LAN. This machine is running the VPN host (accepting the incoming connection from (1)) and also wfview connected as a client to (1) and also with a server configured. So far so good… this behaves as expected and the rig can be controlled and I have audio.

  3. MacOS running wfview. This is currently on the same LAN as (2) but eventually the idea is that this would be at a third location and port-forwarded to (2). Wfview is configured to connect to the server at (2). The connection succeeds and I have a waterfall display and can control the rig, but audio is not present.

Most settings (audio config, etc) are at default, with just the latency turned up to 300ms on all three machines.

If instead I point wfview client (3) to wfview server (1) and make no other changes I do get audio, so I don’t think the problem is with the MacOS configuration.

My conclusion is that the instance at (2) which is running wfview as both a client and a server is not forwarding the audio.

Any thoughts?

Hi Russell.

This kind of daisy-chain has never been tested so I’m not surprised that it doesn’t work!

It does beg the question, what is the reasoning behind this configuration as even if it does work, latency would be horrific?

I would absolutely recommend using the built-in server on the IC705 as a starting point as this provides a much smoother waterfall compared to the one provided over USB. The server was really only designed for use with rigs that don’t already have a built-in server (mainly the IC7300 but older rigs as well).

You could still protect it with a VPN, there are various VPN servers that could run on the Pi.

73 Phil M0VSE


Thanks for responding, Phil.

The objective of this experiment is to operate a portable contest station remotely. G4ALE -

Our usual rig is an IC-7300, hence I am using USB for the experiment. Also, I don’t currently have a way of connecting a router to the hotspot. That will change soon as I have been offered the loan of a 3G router… but I’ll still be restricted to USB for the IC-7300.

The reason for the daisy-chain configuration is that it isn’t possible to establish a connection “inwards” towards the field station, because a 3G/4G connection does not support incoming connections. So the field station has to establish a VPN outwards to a fixed point.

If we only had one remote operator, that would be fine as they could be the end-point for the VPN. However, I’m also anticipating the situation where we could have more than one operator that requires access. Hence a “middle man” solution where only one location (me) runs the VPN server and the wfview client+server. Also I’m trying to make it simple for the remote operators by not requiring them to set up VPN servers, exchange certificates, etc. Hence the daisy-chain configuration.

I’m open to other suggestions of how to crack this nut :wink:

Ah OK, that makes more sense :blush:

Let me see what I can do with this, a daisy-chain configuration ‘should’ be possible, but as I said, we have never tried it! I will attempt to replicate your setup and let you know how I get on.

73 Phil


I have had a chance to have a quick look through the code and I can confirm that this definitely wouldn’t work in the current setup, as audio from a UDP connected client would not be passed to the UDP server (currently only USB connected clients can do this).

My thoughts on this are that for a ‘daisy-chain’ configuration, the audio settings would be fixed to whatever settings are being used by the ‘first’ client connection. This allows us to simply passthrough the audio packets from client<->server rather than having to decode/resample them. This would achieve the fastest possible connection and (in theory) wouldn’t cause too much of an increase in latency.

I will need to think about exactly how to achieve this but it should be possible.

I would also strongly recommend use of the Opus codec for this as the quality loss is negligible but it achieves something like 10:1 compression when compared to the default LPCM 16bit audio, significantly reducing bandwidth requirements.

73 Phil M0VSE

Thanks, Phil.

I have been playing with the Opus codec, but it doesn’t seem to work on machine (2). I get completely choppy/garbled audio. Running Opus on (1) (using a LAN connection to the IC-705) and LPCM/16/1/2400 on machine (2) seems to work fine.