The RTL-SDR is a popular little software-defined-radio USB stick -- at its simplest you literally just pop it into one of your computer's USB slots on one end, attach a cute little pre-made antenna onto the other end, and install a GUI based SDR app (I like CubicSDR) and start browsing the airwaves!
So that was cool in terms of direct manual experimentation, but now I want to go a step farther and set it up for ongoing remote operation and logging of signals of interest, without taking up my notebook computer for it. I want to set it up on a Raspberry Pi in the corner and hide it away doing its thing, aside from occasionally connecting over network for troubleshooting or reconfiguration. And not just any Raspberry Pi, but as long as we're tucking things out of the way, let's see how far we can get on this when using just a little Raspberry Pi Zero. (N.B. yes, as you see I mount all sorts of things to Lego pieces - not only do we have a lot of them around my house, but they're strong yet malleable while allowing quick and easy attachment/detachment to different mounting arrangements.)
For my earlier playing with the RTL-SDR, that was plugged directly into my Macbook and I ran CubicSDR on there and everything was good to go. But for this new arrangement, now we must install some software onto this Rpi to allow both a.) writing chunks of data to file and b.) streaming data over network to my same Macbook running CubicSDR, this time receiving the data over network connection rather than USB. Unlike when running via USB directly on my Macbook, both (a) and (b) will incur new limitations on the sample rate and frequency and time coverage of the radio data, because the Rpi is tiny, limited little computer, plus its wifi controller is more limited than larger more standard ones, plus a wifi connection in general has more limits in the streaming rates of data passing over it than say a wired ethernet connection. I expect in advance to run into some pretty stark constraints on the remote streaming via wifi from a Rpi0, but am curious to see, and at same time regardless I'm cautiously optimistic the Rpi0 will be able to handle writing and post-processing chunks of the radio data locally. Let's find out!
Installing the software
Two key software components are of interest here to install; the RTL-SDR library from the Osmocom (Open Source Mobile Communications) project, which provides device handling and the writing facilities, and the SoapySDR tools for streaming to CubicSDR. Other tools do such streaming too, but Soapy was the only one I could get to work for CubicSDR's remote connection. On one hand, theoretically those can perhaps be installed via sudo apt install, but on the other hand, at least in Raspbian Jessie, I just could not get that to work, while the following steps cloning and building the tools worked out just fine. So here's what I did for those. Much of the following was taken from two specific webpages; since I want to make sure I've got the lines I can copy/paste again, and there's no guarantee that any webpage remains up, I paste these here for myself while crediting who they came from:
RTL-SDR
Following steps I saw on this page by Mike Richards:
(I found that git, cmake, and libusb-1.0-0-dev, required here, were already installed on the system, but if not you can sudo apt install them first.)
mkdir ~/src
cd ~/src
git clone git://git.osmocom.org/rtl-sdr.git
cd rtl-sdr
mkdir build
cd build
cmake ../ -DINSTALL_UDEV_RULES=ON
make
sudo make install
sudo cp ../rtl-sdr.rules /etc/udev/rules.d/
sudo ldconfig
# creates a new /etc/modprobe.d/blacklist-rtl.conf file
sudo cat > /etc/modprobe.d/blacklist-rtl.conf << EOF
blacklist dvb_usb_rtl28xxu
blacklist rtl2832
blacklist rtl2830
EOF
sudo reboot
rtl_test -t # just a convenient way to verify everything is working
However, while that webpage talks about streaming data onto the network with rtl_tcp, and setting it up for auto-start on reboot, in this case we won't use those particular features. We'll however use some of the other rtl_* tools for the automated/scheduled signal recording later.
SoapySDR
The following steps I saw on a page by PrimalCortex. We'll install the abstraction layer SoapySDR, the remote access server SoapySDR-Remote, and the driver for this particular SDR SoapyRTLSDR.
Build the Soapy abstraction layer:
cd ~/src
git clone https://github.com/pothosware/SoapySDR.git
cd SoapySDR/
mkdir build
cd build
cmake ../ -DCMAKE_BUILD_TYPE=Release
make -j4
sudo make install
sudo ldconfig
SoapySDRUtil --info # just to check no errors so far
Build SoapySDR remote:
cd ~/src
git clone https://github.com/pothosware/SoapyRemote.git
cd SoapyRemote/
mkdir build
cd build
cmake ..
make
sudo make install
and build the RTL-SDR driver:
cd ~/src
sudo apt-get install librtlsdr-dev
git clone https://github.com/pothosware/SoapyRTLSDR.git
cd SoapyRTLSDR/
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make
sudo make install
sudo ldconfig
Then verify all works via these (ensure no errors):
SoapySDRUtil --probe
SoapySDRUtil --info
Finally start the remote serving via:
SoapySDRServer --bindWe see a warning that DNS device discovery was not compiled into Soapy but that's ok - myself I'm manually setting things.
######################################################
## Soapy Server -- Use any Soapy SDR remotely
######################################################
Server version: 0.6.0-gf7dca6e6
Server UUID: 66e14986-164e-1716-8567-0e3a007f0101
Launching the server... tcp://[::]:55132
Server bound to [::]:55132
Launching discovery server...
Connecting to DNS-SD daemon...
[WARNING] SoapyRemote compiled without DNS-SD support!
Press Ctrl+C to stop the server
Then at this point we can kick up CubicSDR on the Mac, which importantly must be on the same LAN -- e.g. same wifi network.
And in CubicSDR under
File | SDR Devices, if we click on Local Net and click Refresh, after a moment it should automatically update and show Generic RTL2832U OEM: 00000001 under Local Net. This is the RTL-SDR. I click that to select it and click the Start button, and waveforms start showing up on the CubicSDR screen.Limits in running the software
I'll gradually add more over time as I experiment further... but meanwhile so far I find:
- while with direct USB connection I had no problem running at 2.5MS/s sample rate in CubicSDR, when hooked up over network to the Rpi like this that's definitely a no-go. if I choose the minimum 250kHz under CubicSDR's Sample Rate menu, I can hear the radio signals but even then they're periodically chopped up a bit - it's clear this 250kHz sample rate is right at the limit here. even still, if my main use here for remote-stream-to-CubicSDR is just to verify the stream/audio when troubleshooting/configuring the auto-saving, then maybe this is a sortof acceptable state for starters here.
- hmm, SoapySDR doesn't appear to be the most stable software - after playing/experimenting for a while it crashes -- and then CubicSDR crashes! And then I start them both back up again.
- The
rtl_sdrtools seem to work just fine -- and ultimately it's really the writing of chunks to file that I'm interested in, and could verify receptions thru those files, or I may experiment with using thertl_tcpstreaming server in lieu of SoapySDR after all. - For next step experimentation with those files, webpages like this, this, and this have useful pieces i'll take advantage of.