Outernet Inc broadcasts free digital content from the Web via geostationary transponders. Anyone with satellite coverage can assemble a receiver kit and receive about 20 MB of compressed data per day, even in areas without Internet access. Feeds include world news, weather data and APRS messages.
The service has attracted a community of end-users and radio hobbyists, but some open-source enthusiasts have been reluctant to endorse it because it relied on a closed-source software-defined demodulator. In 2016 Daniel Estévez, EA4GPZ, reverse-engineered the signal and published an open-source Outernet receiver for the gnuradio framework ([ESTEVEZ2016]). This clarified that no encryption or intentional obfuscation was involved.
At the same time I was developing [LEANDVB], a lightweight software-defined DVB-S demodulator for amateur radio applications. It turned out that the Outernet signal is very similar to DVB-S, and only minor additions were needed to receive it with leandvb.
As an Outernet demodulator, leandvb brings the following benefits:
It compiles easily on any Unix-like platform with a C++ compiler.
It runs on low-power embedded platforms, including the Outernet receiver kits.
It reads IQ samples from standard input and writes HDLC frames to standard output. This allows easy interfacing with various SDR receivers, streaming across networks, off-line demodulation of recorded samples, fine-tuning of parameters, etc.
It has auxiliary outputs for displaying demodulator status and constellation patterns in third-party user interfaces.
It supports a wide range of trade-offs between sensitivity and CPU usage. Users with a high-gain antenna, a tight analog bandpass filter or a favourable location within the satellite footprint may be able to reduce power consumption.
Subsequent sections of this article discuss technical details of the Outernet modulation, signal characteristics at the input of the SDR receiver, issues when selecting and configuring a RTL-SDR dongle, and operation of leandvb. Readers who only want to test the software can skip to Section 6, “ Testing leandvb on Outernet C.H.I.P-based and Dreamcatcher receivers ”.
The work of Daniel Estévez revealed that the modulation is a combination of BPSK, convolutional coding, energy dispersal, HDLC framing and Ethernet encapsulation. These are textbook techniques from the 1990s for satellite communications. Furthermore, the specific symbol mapping and convolutional coding parameters happen to comply with ETSI TR 101 198 ([DVBS_BPSK]) which specifies a BPSK variant of ETSI TS 300 421 ([DVBS]), the popular standard for digital satellite TV. The only deviation is a tighter roll-off factor of 0.2 instead of 0.35.
On top of the convolutional coding, DVB-S transmits fixed-size interleaved Reed-Solomon-encoded MPEG packets. Instead, Outernet simply broadcasts variable-length HDLC frames with a 16-bit CRC.
The DVB-S energy dispersal function involves a repeating bit-flipping pattern aligned with MPEG SYNC bytes. Instead, Outernet uses a self-synchronizing scrambler; this is what ETSI TR 192 ([SES]) recommends for non-packetized data.
Note that all these techniques were designed more that 20 years ago and are published in publicly-available standards documents.
The Outernet application-level protocols apparently include a time-and-date service and file downloads with LDPC error/erasure correction. This is beyond the scope of this article.
Outernet receivers are intended to run 24x7, unattended, in all weather conditions, preferably on solar power. This raises challenging installation issues, even for seasoned amateur radio operators. This section will only focus on the topic of shielding.
Bare computer boards such as the Raspberry Pi and the C.H.I.P do generate RF noise which can be picked up by the antenna. At the very least, all digital electronics should be positioned behind the antenna. Adding a wide metal plate between the antenna and the computer helps a lot. Shielding the computer in a proper enclosure is better (but will interfere with WiFi functionality).
LNAs usually do not contain local oscillators nor other sources of RF noise. They should be kept away from the digital electronics and shielded independently.
Note that any slot in the shielding longer than a few centimeters may leak radiation at 1500 MHz, regardless of its width. This may even include non-conductive gaps created by layers of paint or aluminium oxide. In industrial equipment, removable covers are commonly shielded with copper foam gaskets.
L-band Outernet receivers are typically based on RTL-SDR dongles. Tests were conducted with two popular models.
Table 1. RTL-SDR dongles tested
| Model | Outernet | rtl-sdr v2 |
|---|---|---|
| Enclosure | Aluminium | Aluminium |
| RF input | SMA | SMA |
| Local oscillator | TCXO | TCXO |
| Tuner | E4000 | R820T2 |
| Max gain setting | 42 dB | 49.6 dB |
| Bias tee | 3.3 V | 5 V (disabled) |
For comparison purposes both dongles were connected to the same air-gap patch antenna and LNA via a SMA splitter. This causes a 3 dB loss in signal strength. There is also a risk of signal leakage between the two tuners, but no such problem was observed.
The antenna was pointed toward the satellite at 25°E.
Receivers were tuned to 1545.900 MHz. This is 40 kHz below the signal, in order to avoid artifacts around DC. The signal was sampled at 240 kHz, 300 kHz, 960 kHz, 1440 kHz and 2400 kHz.
$ rtl_sdr -f 1545.900e6 -s $RATE -n 24e6 -g 50 /tmp/samples.u8
Spectra were computed with 65536-point Fourier transforms averaged over 24 M samples. No attempt was made to convert levels to dBm because the sensitivity of RTL-SDR dongles at 1545 MHz is poorly understood and may even vary between individual units.
The R820T2 dongle was tested a second time after patching librtlsdr to remove an arbitrary gain limitation in the third analog amplification stage (VGA).
Figure 2, “ Outernet signal vs sampling rate and RTL-SDR dongle type ” reveals several unexpected properties of the receive chain.
The Outernet signal at the output of the LNA is weak. With the E4000 dongle at maximum gain, its modulation amplitude is about 1/128th of the 8-bit dynamic range, i.e. -42 dBFS. This is not apparent when looking at averaged spectrum plots. Since the 240 .. 2400 kHz wide capture contains other transmissions and noise, the overall signal amplitude is higher, but at least 10 dB of analog gain could still be added without saturating the analog stages.
There are reports that the signal is much stronger in other geographical areas, especially in the U.S.A. within the footprint of I4F3 at 98°W. This may explain why the LNA gain cannot be higher.
Demodulation is possible because oversampling increases dynamic range by 35 dB and SNR by 18 dB, even at the lowest sampling rate. Relying on oversampling is not inherently bad; it is conjectured that the RTL2832U uses this technique internally to achieve 8 bits of dynamic range. But oversampling implies higher CPU usage than necessary for software-defined demodulators. 240 k samples/s would be largely enough to capture the 4200 baud Outernet signal if is were stronger; here we have to sample at 960 kHz or more to reach optimum SNR.
The R820T2 dongle at maximum gain outputs an even weaker signal, 16 dB below the E4000 dongle. This is dangerously close to the level of ADC quantization noise. Long coaxial cables between LNA and dongle should be avoided in this configuration, as they may degrade not only RSSI but also SNR.
Patching the hard-coded R820T2 VGA gain setting in librtlsdr adds 24 dB of analog gain for free (14 dB in AGC mode) and makes the R820T2 more sensitive than the E4000. It is unclear why this limitation exists in the source code, or why two distinct VGA gain values are used for AGC mode and for manual mode. See librtl-maxvgagain-pabr.patch. P.S. It turned out that a patch to expose individual gains has already been submitted.
The typical tuning accuracy of the E4000 dongle is 0.1 ppm, i.e. ±150 Hz, which is excellent.
The tuning accuracy of the R820T2 dongle is much worse at about 1 ppm (±1500 Hz). This is consistent with advertised specifications and good enough for many SDR applications, but the discrepancy is worth investigating. Presumably both types of dongles use similar TCXO modules; accuracies should not differ by one order of magnitude.
Note in Figure 2, “ Outernet signal vs sampling rate and RTL-SDR dongle type ” that R820T2 frequency offsets exhibit a systematic component which depends on the sampling rate. This suggests a possible explanation: E4000-based dongles are zero-IF designs, whereas the R820T2 tuner outputs an analog signal at an intermediate frequency and relies on the RTL2832U to downconvert to baseband digitally. Maybe the DDC has a granularity of a few hundred Hz, or maybe librtlsdr fails to configure it correctly. Under both hypotheses, with software workarounds, R820T2 dongles would possibly yield the same tuning accuracy as E4000 dongles.
At the slower sampling rates (240 kHz and 300 kHz), the noise floor is higher. It is unclear whether this is merely a consequence of the lower oversampling gain. The librtlsdr source code suggests that the RTL2832U resampler uses distinct operating modes for 225 .. 300 kHz and for 900 .. 2400 kHz. Maybe its digital anti-aliasing filters are significantly less effective when resampling from 28.8 MHz to 240 .. 300 kHz than when resampling to 900 .. 2400 kHz.
If this is confirmed, then inserting a 240 kHz analog bandpass filter between the tuner and the RTL2832U may reduce aliasing and yield optimum SNR even at low sampling rates. A 10 kHz wide analog bandpass filter would reduce CPU requirements dramatically, as the signal could be decimated rather than FIR-filtered. For R820T2 tuners, this filter should be centered near the intermediate frequency. For E4000 tuners, two matched filters near DC would be needed.
Further tests were conducted with a high-gain antenna (see Figure 3, “ 60 cm prime-focus dish vs air-gap patch ”). CNR values up to 15 dB were obtained. This indicates that the signal is clean: any noise originating from the modulator or from the transponder would have been amplified by the dish. Instead, the dish apparently lowers the noise floor by 2 dB. This suggests that a significant portion of the noise comes not from the LNA but from external sources such as other geostationary satellites (this is known as ASI - Adjacent Satellite Interference), or the Sun. Other tests would be needed to confirm that this effect is not caused by e.g. an undocumented AGC function.
leandvb should be configured as follows:
-f 960e3 --tune 40e3: These baseband parameters must match the RTL-SDR settings. Tuning 40 kHz below the signal is recommended with E4000 dongles, but not needed with R820T2 dongles.
--anf 0: The auto-notch filter is not recommended for narrowband signals.
--const BPSK --sr 4200 --roll-off 0.2: This matches the parameters of the Outernet signal.
--sampler rrc: This is required for narrowband signals with adjacent channels.
--viterbi: This is required at low SNR.
--fastlock: This is useful at low symbol rates, and the CPU overhead is acceptable.
--hdlc: We expect HDLC frames, not DVB-S packets.
--packetized: Preserve frame boundaries on standard output.
--cnr -v -d --gui: For troubleshooting.
--fd-info 2 --fd-const 2: Optional, for status reporting on stderr.
The following command should work with E4000 dongles. Adjust -f 1545900000 for other satellites (tune 40 kHz below nominal).
rtl_sdr -f 1545900000 -s 960e3 -g 50 - | leandvb -f 960e3 --anf 0 --tune 40e3 --const BPSK --sr 4200 --roll-off 0.2 --sampler rrc --rrc-rej 5 --viterbi --fastlock --hdlc --packetized -v -d --gui > /tmp/hdlcframes.bin
After a few seconds, stderr will show a sequence of '_' symbols, one per valid HDLC frame. Frames are written to standard output with a 16-bit length prefix. Presumably they can be fed into free-outernet to obtain files (not tested).
With R820T2 dongles, the frequency offset may be too high. Try --tune 42.4e3 (this seems to match the systematic error), or --tune 39e3, or --tune 41e3, or --tune 38e3.
With non-TCXO dongles, add --drift and provide the initial frequency offset with --tune. See Section 10, “ Perspectives ” about automating these steps.
leandvb should compile easily on Raspberry Pi, Dreamcatcher and other embedded platforms running full-featured Linux distributions such as raspbian or armbian. There is a special make target with ARM-specific optimizations:
git clone https://github.com/pabr/leansdr.git cd leansdr/src/apps make leandvb.embedded
Run without --gui to reduce CPU usage:
rtl_sdr -f 1545900000 -s 960e3 -g 50 - | leandvb.embedded -f 960e3 --anf 0 --tune 40e3 --const BPSK --sr 4200 --roll-off 0.2 --sampler rrc --rrc-rej 5 --viterbi --fastlock --hdlc --packetized -v -d > /tmp/hdlcframes.bin
Setting up a cross-compiling toolchain for the Skylark OS can be frustrating. It is easier to compile natively on a compatible ARM platform as follows.
On a raspbian or armbian host, compile leandvb:
git clone https://github.com/pabr/leansdr.git cd leansdr/src/apps make leandvb.embedded
This will link statically if static libraries are available, for maximum portability. If the shared libraries match between the build host and the target, -static can be removed from the Makefile.
Compile a tool for interfacing with the Outernet software:
wget http://www.pabr.org/radio/leandvb-satmodem/uncat.c gcc uncat.c -o uncat
See Section 10, “ Perspectives ” about alternatives.
Transfer leandvb.embedded and uncat to the C.H.I.P or Dreamcatcher, for example in
/mnt/conf/.The rtl_sdr command-line utility and librtlsdr are needed. Note that binaries from raspbian will run on Skylark.
Stop the stock demodulator:
/etc/init.d/S90sdr stop
Run leandvb and forward HDLC frames to the Outernet software:
rtl_sdr -f 1545900000 -s 960e3 -g 50 - | leandvb.embedded -f 960e3 --anf 0 --tune 40e3 --const BPSK --sr 4200 --roll-off 0.2 --sampler rrc --rrc-rej 5 --viterbi --fastlock --hdlc --packetized -v -d | uncat /var/run/ondd.data
The tuner status interface will show ongoing transfers, but the other status lines will not be updated. New files will appear in
/mnt/downloads/. CPU usage will be about 25 %.To reduce CPU usage:
- Reduce the sample rate: rtl_sdr -s 300e3 ... | leandvb -f 300e3 ...
- Use weaker filtering: --rrc-rej 3
The Outernet Skylark OS image is read-only with a non-persistent writable overlay. There is no easy way to make permanent changes.
However, /mnt/conf/ is writable and persistent. All files required by leandvb can be installed there.
Besides, /etc/init.d/S99user will execute /mnt/conf/bin/user.sh
if it exists and is owned by root. This can be used to spawn leandvb at boot time. Output will be logged to /var/log/user.log.
Alternatively, a pre-up directive
can be added to one of the active interfaces in /mnt/conf/etc/network/interfaces.d/
(after replacing the symbolic link with a plain copy)
in order to run a user script at boot time.
DVB-S has fixed-size packets, interleaving and Reed-Solomon error correction. This makes it easy to define and measure error rates.
Variable-length HDLC encapsulation is more problematic. A symbol error can corrupt the content of a frame; this will be detected by the 16-bit CRC. But symbol errors can also remove and add HDLC flags. Even though most frames in the Outernet signal have the same payload length, the number of symbols per frame is not constant because of bit stuffing. This makes it difficult to reliably identify frame boundaries and count errors.
To avoid these ambiguities, for benchmarking purposes, I simply count valid frames received in 10 minute intervals, over several hours. Figure 5, “ SNR requirements ” has some outliers because the number of transmitted frames per interval is not fixed and because SNR fluctuates within each interval. Still, it suggests that leandvb has acceptable frame error rate down to at least 3 dB. It is unclear how much frame loss the application-level Outernet protocols can tolerate.
leandvb has also been benchmarked in DVB-S mode with simulated signals and AWG noise; see [LEANDVB].
At the time of writing all tests were conducted from a single location in western Europe, with a single satellite (Alphasat at 25°E), with only a few combinations of hardware components, and with reasonably careful RF engineering (good antenna pointing, proper shielding and cooling, short cables, WiFi disabled).
Performance may be affected by:
Weaker signal strength at the edge of satellite footprints
Temperature (a hot receiver may fail to tune)
Daily fluctuations in man-made RF noise in urban locations.
Seasonal fluctuations, such as increased noise when the Sun transits behind the geostationary belt
L-band channel allocation on the other two satellites (if a satellite operator allocates neighbouring frequencies to other users, stronger filtering may be needed)
Variability in individual component performance (1545 MHz is out-of-spec for some RTL-SDR dongles).
For troubleshooting, consider recording 20 seconds worth of signal with the rtl_sdr command-line tool and making the samples available online.
leandvb now has better support for weak signals and unusually high sampling ratios (200 samples/symbol and higher). Note that its original use case was HamTV reception at only 1.2 samples/symbol.
The little-known BPSK variant of DVB-S has been implemented.
HDLC framing has been implemented as an alternative to RS-encoded MPEG packets.
A possible systematic tuning error has been identified when using RTL-SDR dongles with R820T2 tuners and librtlsdr.
An arbitrary gain limitation in librtlsdr for R820T2 tuners has been removed, yielding 24 dB of analog gain in manual mode and 14 dB in AGC mode, with no apparent detrimental side-effects for this application.
Write a wrapper, leanscanserv, that would merge the functionality of:
leansdrscan (auto-detecting frequency offsets and modulation parameters)
uncat (forwarding HDLC frames to a UNIX SEQPACKET socket)
Storing frequency offsets across invocations (for non-TCXO dongles).
Parsing the auxiliary outputs of leandvb (status/constellation/spectrum) and making them available for web-based monitoring interfaces.
Implement --fd-spectrum.
Optional JSON syntax for --fd-info, --fd-const and --fd-spectrum.
Test with non-TCXO dongles and patch antenna.
Profile memory cache behaviour.
seteuid, chroot.
Test Luigi Tarenga's custom FIR coefficients for the RTL2832U at 240 ksamples/s.
[ESTEVEZ2016] Reverse-Engineering Outernet . 2016. http://gnuradio.org/blog/reverse-engineering-outernet/.
[DVBS] Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for 11/12 GHz satellite services . 1997. ETS 300 421. https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=5316.
[DVBS_BPSK] Digital Video Broadcasting (DVB); Implementation of Binary Phase Shift Keying (BPSK) modulation in DVB satellite transmission systems . 1997. TR 101 198. https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=5393.
[SES] Satellite Earth Stations and Systems(SES); Modulation and channel coding of 34,368 Mbit/s and 44,736 Mbit/s digital television contribution links via satellite . 1995. ETR 192. https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=2105.
[LEANDVB] leandvb: A lightweight software DVB-S demodulator . http://www.pabr.org/radio/leandvb/leandvb.en.html .