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?
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.
–Elliott
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:
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
Hello
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.
br
George.
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.
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:
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…
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.
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 - https://addiscombe.club/
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 
Ah OK, that makes more sense 
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.
I’m making progress here, largely thanks to the loan of a 3G router. Here’s what I am trying to achieve:
The VPN connection to the fixed location (which is my home LAN) is working fine. Using wireguard as the VPN, the Pi at the portable station can connect to the fixed location. In classic VPN fashion, they can access the internet via my location (confirmed using “whatismyip”).
The fixed location pi is at 192.168.0.2 (with the router - not shown on the diagram - on 192.168.0.1). The VPN connection appears as 192.168.99.3. Ping works in both directions on these IP addresses.
What I’m now struggling with is how to connect the remote wfview instance. It will be configured to connect to my public IP address (via Dynamic DNS). On my router, port 50001 is then forwarded to 192.168.0.2.
The missing piece is this: how do I connect 192.168.0.2 to 192.168.99.3, within the fixed location pi? It seems to me that this should be an iptables entry (or entries), but I can’t figure it out.
Anyone got any suggestions?
See ” How to communicate between the subnets on this page:
https://www.networkshelf.com/how-to-setup-a-network-with-multiple-subnets/
Solved 
Here are the iptables entries needed:
iptables -t nat -A PREROUTING -p udp -i eth0 --dport 50001 -j DNAT --to-destination 192.168.99.3:50001
iptables -t nat -A PREROUTING -p udp -i eth0 --dport 50002 -j DNAT --to-destination 192.168.99.3:50002
iptables -t nat -A PREROUTING -p udp -i eth0 --dport 50003 -j DNAT --to-destination 192.168.99.3:50003
iptables -A FORWARD -p udp -d 192.168.99.3 --dport 50001 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p udp -d 192.168.99.3 --dport 50002 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p udp -d 192.168.99.3 --dport 50003 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
(where 192.168.99.3 is the address of the VPN destination)
This is now fully working, and I have written up the complete solution here:
Remote Operation of a Portable Station - Part 1: Concept and Design (g4ctp.blogspot.com)
Remote Operation of a Portable Station - Part 2: The Fixed Station (g4ctp.blogspot.com)
Remote Operation of a Portable Station - Part 3: Putting It All Together (g4ctp.blogspot.com)
However, I am experiencing drop-outs in the connection which would make the whole thing unworkable for actual remote operation. These range from momentary drop-outs to extended loss of connection for several seconds. I have also tested locally, and I get the same thing (although perhaps not quite so often)! So it is not entirely due to the additional latency from the VPN link, etc. It seems to be mainly a wfview client/server problem.
Any hints or tips for running in client/server mode? Do others find it reliable?
Hi Russell.
You shouldn’t experience dropouts unless a) your network connection is unable to sustain the required throughput or b) one of the computers in the chain is too busy to process everything “in time”
I would recommend checking the log file which should be /tmp/wfview.log on the RPi and in your default temporary directory on Windows. This will hopefully tell us what is happening.
Live streaming via UDP is very susceptible to network issues as UDP is a ‘connectionless’ protocol and delivery isn’t guaranteed. Wfview does have a retransmission system to compensate for this but it can become overwhelmed with large packet loss.
I haven’t done much testing but I don’t think that running Opus codec at 24Khz sample rate will provide any significant benefit as Opus is optimized for 48KHz, so this is forcing wfview to resample, which is quite CPU intensive (it may actually be worse!)
You can also run wfview in debug mode ( wfview –debug ) and it will then log MUCH more information.
73 Phil M0VSE
Thanks, Phil. I’ll do some more experimenting, and will report back in due course.
I’ve done a bit more experimenting today. I have set the Sample Rate back to 48000, and also tested with other codecs. Opus seems like the least reliable - which may just be coincidence - but they all fail sooner or later.
Note that I am just testing with a straight client/server configuration on my local LAN at the moment. No VPN or internet connections involved. Server is a Pi connected via USB to IC-705. Client is a Mac. Both are on Wifi.
What I am experiencing, regardless of codec, is occasional momentary drop-outs which are reported with a burst like this on the log file:
2021-12-21 10:28:53.652 INF udp.server: "::ffff:192.168.0.101" : got out of sequence ping reply. Got: 47391 expecting: 47392
2021-12-21 10:28:53.654 INF udp.server: "::ffff:192.168.0.101" : got out of sequence ping reply. Got: 1509 expecting: 1510
2021-12-21 10:28:53.832 INF udp.server: "::ffff:192.168.0.101" : got out of sequence ping reply. Got: 56883 expecting: 56884
2021-12-21 10:28:53.833 INF udp.server: "::ffff:192.168.0.101" : got out of sequence ping reply. Got: 1510 expecting: 1511
2021-12-21 10:28:53.835 INF udp.server: "::ffff:192.168.0.101" : got out of sequence ping reply. Got: 47392 expecting: 47393
Sometimes it seems to drop into a state where it is generating a continuous flow of log entries, like this (look at the timestamps). Once it gets into this state, it never seems to recover. Also, note that my latency is set to 500ms.
2021-12-21 10:29:18.544 INF audio: Input Packet 0 arrived too late (increase output latency!) 277 ms
2021-12-21 10:29:18.564 INF audio: Input Packet 0 arrived too late (increase output latency!) 297 ms
2021-12-21 10:29:18.583 INF audio: Input Packet 0 arrived too late (increase output latency!) 316 ms
2021-12-21 10:29:18.603 INF audio: Input Packet 0 arrived too late (increase output latency!) 280 ms
2021-12-21 10:29:18.623 INF audio: Input Packet 0 arrived too late (increase output latency!) 300 ms
2021-12-21 10:29:18.643 INF audio: Input Packet 0 arrived too late (increase output latency!) 265 ms
Sometimes it then completely loses connection for long periods (30s+).
So… where do we go from here?
p.s. Just in case my Wifi is the weakest link, next I’m going to try substituting powerline adaptors. Unfortunately my shack is unavoidably remote from my router.