I’ve been playing recently with the QO-100 high speed modem, its been working well, but one of the smaller issues I’ve been having is that every now and again I get bad packets. I’ve been tweaking all kinds of settings on my SDR Console as per the documentation and while I receive most packets it was still annoying me that I’m getting the few missed ones. My current setup involves using SDR Console with a networked Adalm-Pluto that is sitting on the roof next to my dish.
After re-reading the documentation I found a paragraph about the USB Ethernet Adapter that I’m using could possibly be the issue. Its a USB 3.0 adapter but since the PlutoSDR only supports USB 2.0 the concern is that the adapter doesn’t enumerate properly. I’ve been using this adapter for a while so I was a bit sceptic, but I figured it might be a good experiment to try something else.
Since the PlutoSDR enumerates as an Ethernet/RNDIS gadget when plugged into a pc it is essentially already networked with that pc and I wondered whether we could just port forward outside connections on that PC to the PlutoSDR. In my case I wanted to do this on a Raspberry PI since I already had a Raspberry Pi Zero in my satellite station that controls the PTT and measures temperatures, etc. To test this I removed the USB Ethernet adapter from the setup and plugged the PlutoSDR directly into the Raspberry PI. I don’t have any PlutoSDR drivers or software installed on the Pi, but since the PlutoSDR enumerates as a network gadget I immediately have an extra network device available on my pi.
The basic concept here is to forward PlutoSDR specific traffic coming in on the network port (eth0) to the PlutoSDR (eth1). First we need to know which ports are being used when we connect to the PlutoSDR. On my setup I have the following needs:
- SDR Console for working the Narrowband Transponder on QO-100 (TCP Port 30431)
- I need to be able to access the PlutoSDR via ssh for settings, etc. (TCP Port 22)
- My PlutoSDR runs a custom DATV firmware so I need to be able to access the webserver (TCP Port 80)
- With the custom DATV firmware I need to send a TS stream for DATV transmissions (UDP Port 8282)
That means I have 4 ports I need to forward from the LAN port to the PlutoSDR ethernet adapter. For the port forwarding we will be using Iptables. Iptables is software that allows us to configure the Linux Kernel Firewall. To be able to do port forwarding we first need to enable the port forwarding with the following command:
sudo sysctl -w net.ipv4.ip_forward=1
Now we can start configuring our port forward rules. I sounds daunting but its fairly simple. Lets start with our ssh port forward. Our plutosdr is accessable via ssh on port 22, however our Raspberry PI also has an ssh server listening on port 22. So ideally we want to choose another port for the input. I’ve decided on using port 23. The rule I’m configuring is that I want any connections on the Raspberry PI on port 23 to be forwarded to port 22 on the PlutoSDR. Use the following command to configure this forward rule:
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 23 -j DNAT --to-destination 192.168.2.1:22
eth0 is the LAN port on the raspberry pi, dport is the port we are connecting to and we want it to forward to our PlutoSDR which has the destination of 192.168.2.1:22. Depending on how your PlutoSDR is configured this might be different. To access the PlutoSDR I can now ssh normally but using the Raspberry PI Address and specifying port 23. For example my Raspberry PI ip address is 192.168.0.212 so I use:
ssh email@example.com -p 23
Great, so this works perfect 🙂
Lets fill in the next couple of rules needed. We need a rule for the web interface:
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.2.1:80
We also need a rule for any SDR software connections (by default to port 30431):
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 30431 -j DNAT --to-destination 192.168.2.1:30431
And then lastly I need a rule for my UDP TS feed for the DATV transmissions:
sudo iptables -t nat -A PREROUTING -i eth0 -p udp --dport 8282 -j DNAT --to-destination 192.168.2.1:8282
On most SDR software you can just specify the Raspberry PI Addres (in my case 192.168.0.212), but I had to do the following setup to make it work on SDR Console (it usually autodetects, but it didn’t work for this). You can add it manually using the following settings:
SDR console is now working fine for both receive and transmit. For accessing the web interface I can simply use the Raspberry Pi address in my browser:
And then lastly I configured my FreeStreamCoder for the UDP address by simply pointing it to the Raspberry PI ip address as well.
I’ve tested all the options for a day or so and it seems to be working fine, from an operating point of view I’m not seeing any differences. I’ve tested this both on a Raspberry PI 4, but I’m using this on a Raspberry PI Zero with an ethernet hat and that also works great.
Now that we have it all up and running we need to make sure that our new rules stay persistent between reboots. Firstly lets make sure our forwarding is enabled when the Raspberry PI Boots by editing the /etc/sysctl.conf file and uncommenting the net.ipv4.ip_forward=1 line:
sudo nano -w /etc/sysctl.conf
Next up we can save our rules using the iptables-persistent package which you can install as follow:
sudo apt install iptables-persistent
Normally it then asks you to save the current rules to a file that it uses to reconfigure them on reboot. You can yes here:
If you ever change the rules then you can update the iptables-persistent configuration file with the following command:
sudo iptables-save > /etc/iptables/rules.v4
And that covers everything you need to know to use a Raspberry PI to put your PlutoSDR on your network without using a USB-Ethernet Adapter. More testing is required, but it seems to be a good alternative for the USB-Ethernet gadget for getting the PlutoSDR on my network. The other advantage of having the PlutoSDR connected to a Raspberry PI is that I can now also run software on it that will use the PlutoSDR directly. More experimentation around that sometime in the future.
So I guess the big question is whether this fixed my bad packets on reception with the QO-100 HS Modem? Its only been running for a day, but so far no dropped/bad packets. I’ll more feedback after having it run for a while longer, but so far so good 🙂
Until next time!