Alright – our USRP N210 is still broken, but we managed to draft a blog post about it while it was still working. Covid-19 times means that such drafts gets turned into posts.
SatNOGS is an open satellite ground station network in which ARK has a ground station. We have an antenna, an antenna rotor, a radio and a computer dedicated to the purpose, and anyone on the ground station network can schedule satellites on our system. We also enable use of the antenna for other purposes in our shack by having a basic antenna switch installed. We’ve until now not enabled use of the SatNOGS USRP for other purposes.
Our SatNOGS setup looks like this:
The USRP (the radio) is connected directly to the SatNOGS computer through a USB-to-ethernet dongle, and the SatNOGS computer is connected to the rest of the network through a network switch. Since the USRP connects through the network, we thought it would be fun to see if it was possible for the SatNOGS computer to share the USRP with the other computers on the network by use of network magic.
It is also possible for the USRP to be connected directly to the network switch on the same level as the SatNOGS computer and the shack computer, but we opted out for this in order to reduce the potential points of failures and reduce the network configuration necessary for the SatNOGS computer to access it. This means that the SatNOGS setup is simplified, while USRP access from other computers requires some extra configuration. This is philosophically sound, since its main use is for the SatNOGS setup.
Running ifconfig
on the SatNOGS computer, we get the following (shortened) output:
eno1: (...)
inet 10.0.0.34
enx00e04c6802d9: (...)
inet 192.168.0.1
The SatNOGS computer talks with the USRP through the interface enx00e04c6802d9
, and with eno1
to the rest of the network. Network access works in such a way that applications need not be aware of interfaces, and we can just connect to the USRP IP and expect the USRP to be there. We could find its ip by running nmap -sP 192.168.0.0/24
, or we could just use uhd_find_devices
:
$ uhd_find_devices
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
type: usrp2
addr: 192.168.0.32
name:
serial: EFR1EQ1UP
Letting a different computer access the USRP turns out to not be that difficult. We just have to enable packet forwarding so that packets may be passed from one network interface to the other:
echo 1 >> /proc/sys/net/ipv4/ip_forward
This will let packets from the shack computer be passed on to the USRP through the SatNOGS computer, and vice versa.
The shack computer doesn’t know that this is possible yet, however. Pinging the USRP IP yields no response:
$ ping 192.168.0.32 -c 1 -W 1
PING 192.168.0.32 (192.168.0.32) 56(84) bytes of data.
--- 192.168.0.32 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
By running
ip route add 192.168.0.0/24 via 10.0.0.34
we let it know that IP addresses starting on 192.168.0. can be reached through 10.0.0.34 (the IP address of the SatNOGS computer). Pinging the USRP IP then yields us responses:
$ ping 192.168.0.32 -W 1 -c 1
PING 192.168.0.32 (192.168.0.32) 56(84) bytes of data.
64 bytes from 192.168.0.32: icmp_seq=1 ttl=31 time=1.69 ms
--- 192.168.0.32 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Further, we can run uhd_find_devices
to verify that the USRP drivers are able to find the device. They weren’t able to do that out of the box (which also probably would be a problem if the USRP had been connected to a network switch), we had to specify the IP address, but at least we got some sensible information back in the end.
$ uhd_find_devices --args addr=192.168.0.32
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
type: usrp2
addr: 192.168.0.32
name:
serial: EFR1EQ1UP
It didn’t show up as a valid device in gqrx for the same reasons, but by choosing “Other…” and changing the device string to uhd,type=usrp2,addr=192.168.0.32
…
… we managed to make gqrx crash. But this was fine! This was a step forward. Setting the wrong device string makes gqrx default to the first USRP device it can find on the system, and there is already a USRP B210 connected to the shack computer. Getting a crash instead of just the waterfall from B210 meant that we were on the right track.
We tried instead to build a simple flowgraph in GNU Radio Companion, using the same device string:
It worked! The fall from signal to pure noise there is where we turned the antenna switch on the SatNOGS setup in order to verify that we actually were sampling the SatNOGS USRP and not just the shack computer-connected USRP.
gqrx turned out to be fixable by deleting the gqrx configuration in .config/gqrx
and starting from scratch. Might be fun to figure out what happened (left-over configuration from B210?), but maybe not exactly right now.
Job done. Being able to do this can be nice for playing around with the system. It’ll also last only until the next reboot, minimizing some potential for major screwup. There are many roads to Rome, however: X11 forwarding for e.g. gqrx running on the SatNOGS computer would also be a well viable and probably easier alternative, but it is not as fun to figure out.
Leave a Reply