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:
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.)
git clone git://git.osmocom.org/rtl-sdr.git
cmake ../ -DINSTALL_UDEV_RULES=ON
sudo make install
sudo cp ../rtl-sdr.rules /etc/udev/rules.d/
# creates a new /etc/modprobe.d/blacklist-rtl.conf file
sudo cat > /etc/modprobe.d/blacklist-rtl.conf << EOF
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.
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:
git clone https://github.com/pothosware/SoapySDR.git
cmake ../ -DCMAKE_BUILD_TYPE=Release
sudo make install
SoapySDRUtil --info # just to check no errors so far
Build SoapySDR remote:
git clone https://github.com/pothosware/SoapyRemote.git
sudo make install
and build the RTL-SDR driver:
sudo apt-get install librtlsdr-dev
git clone https://github.com/pothosware/SoapyRTLSDR.git
cmake .. -DCMAKE_BUILD_TYPE=Release
sudo make install
Then verify all works via these (ensure no errors):
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 Netand click
Refresh, after a moment it should automatically update and show
Generic RTL2832U OEM: 00000001under Local Net. This is the RTL-SDR. I click that to select it and click the
Startbutton, 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.
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 the
rtl_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.