Table of Contents
- 1. Motivations
- 2. Related work
- 3. Features
- 4. Limitations and known problems
- 5. Installation
- 6. Usage
- 7. Performance
- 8. Notes on security
- 9. Troubleshooting
- 10. Implementation details
- 11. Development
- 12. Future work
- 13. Intellectual property issues
- 14. Acknowledgements
List of Figures
DVB-S was developed in the 1990s for digital satellite TV broadcasts. In recent years it has been adopted by the amateur radio community for Digital Amateur TV (DATV). Inexpensive hardware-accelerated DVB-S receivers are available in the form of set-top-boxes, PCI cards and USB dongles. Unfortunately not all receivers are suitable for DATV for the following reasons:
Their RF stage is typically optimized for an input signal in the 950 .. 2150 MHz range (downconverted from 10.700 .. 12.750 GHz by a satellite LNB), whereas DATV experiments are also conducted in the 70 cm and 13 cm bands (possibly even 2 m and 6 m). Frequency converters add unnecessary cost, complexity and noise.
They are designed to provide a plug-and-play experience for non-technical users, whereas radio amateurs may prefer to have control over as many settings as possible in order to make the most of propagation conditions.
Some receivers do not support the very low symbol rates that amateurs are required to use due to bandwidth constraints.
Some prominent DATV transmitters, such as the ISS HamVideo system, generate a slightly non-compliant MPEG stream which some receivers fail to decode.
With custom drivers it is apparently possible to tune out-of-spec, support non standard symbol rates, control internal settings and retrieve raw MPEG packets: see http://www.vivadatv.org. But this approach only works with specific chipsets
Software-defined receivers avoid these problems entirely. SDR front-ends are now available for many frequency bands with various trade-offs between price, bandwidth and dynamic range. The popular RTL-SDR dongles cover 10 m, 6 m, 2 m, 70 cm and 23 cm.
A software DVB-S receiver also brings all the benefits of software-defined radio:
One can capture raw I/Q samples from the air and demodulate them later. There are fewer opportunities for non-recoverable operator error during the recording phase. This is especially useful for transient signals such as those from the ISS.
Demodulation can be attempted as many times as necessary with various combinations of parameters until the final error rate is minimized.
Waveforms can be examined and pre-processed prior to demodulation, e.g. to eliminate spurious signals or correct unexpected frequency offsets. Computationally intensive algorithms can be used in an attempt to remove non-random noise.
Coherent I/Q captures from multiple receivers could be combined to achieve array gain, diversity gain or better directivity.
Perfectly identical signals can be injected into multiple software demodulators for benchmarking purposes.
A SDR receiver doubles as a crude spectrum analyzer. This is useful for troubleshooting many problems, e.g. detecting in-band interference.
Software demodulators are future-proof because all SDR front-ends have essentially the same interface: configure center frequency, sample rate and gain; receive raw I/Q data. Actually, as computer performance increases, a given software demodulator will become capable of supporting faster modulation rates or processing larger numbers of channels simultaneously.
gr-dvb has great value as a reference implementation and as an educational tool, but it is too slow to demodulate DATV signals from the ISS in real-time, even on a fast desktop PC. Besides, it requires the whole gnuradio infrastructure including Boost, SWIG and Python; this is impractical on embedded platforms.
By contrast, leandvb is written in plain C++ with barely any dependency, and is 10 times faster on a single core than gr-dvb running on two cores. The speed-up comes at the cost of receiver sensitivity; for some applications this is an acceptable trade-off. More specifically, leandvb does not currently implement the Viterbi algorithm. It performs deconvolution on hard symbols instead.
DVB-S, QPSK, code rates 1/2, 2/3, 3/4, 5/6, 7/8.
Detection of conjugated I/Q signals (for downconverters with L.O. above the signal).
Tested at low sampling rate (2 Msymbols/s at 2.4 Msamples/s).
Automatic filtering of "birdies" (useful with low-cost SDR hardware).
Default input format is unsigned 8-bit I/Q (compatible with the rtl_sdr command-line utility).
Also supports 32-bit float I/Q format (compatible with gqrx).
No band-pass filtering. In crowded bands, consider reducing the sampling rate so that only the signal of interest is captured.
Presumably leandvb does not meet the error correction requirements of the DVB-S standard. Therefore it cannot formally claim DVB-S compliance.
leandvb requires only a C++ compiler and standard libraries. It is developed for Linux and may compile on other UNIX-like and embedded platforms as well.
git clone http://github.com/pabr/leansdr.git cd leansdr/src/apps make
Usage: leandvb [options] < IQ > TS Demodulate DVB-S I/Q on stdin, output MPEG packets on stdout Input options: --u8 Input format is 8-bit unsigned (rtl_sdr, default) --f32 Input format is 32-bit float (gqrx) -f HZ Input sample rate (default: 2.4e6) --loop Repeat (stdin must be a file) Preprocessing options: --anf N Number of birdies to remove (default: 1) --derotate HZ For use with --fd-pp, otherwise use --tune --fd-pp NUM Dump preprocessed IQ data to file descriptor DVB-S options: --sr HZ Symbol rate (default: 2e6) --tune HZ Bias frequency for demodulation --cr N/D Code rate 1/2 .. 7/8 (default: 1/2) UI options: -h Print this message -v Output info during startup -d Output debugging info --fd-info NUM Print demodulator status to file descriptor --gui Show constellation and spectrum --duration S Width of timeline plot (default: 60) --linger Keep GUI running after EOF Testing options: --awgn STDDEV Add white gaussian noise (slow)
Note: The --gui option is only available on platforms with X11.
For HamTV signals at 2395 MHz downconverted to 397 MHz by a MMDS LNB with 1998 MHz LO:
$ rtl_sdr -f 397000000 -s 2400000 capture.iq $ ./leandvb --gui < capture.iq > capture.ts $ ffplay capture.ts
Conceptually, a live receiver and decoder would be started as follows:
$ rtl_sdr -f 397000000 -s 2400000 - | ./leandvb --gui | vlc -
However, this ignores known problems with real-time multimedia streaming:
Some MPEG players insist on scanning their input stream prior to decoding. The resulting latency can sometimes be reduced by specifying formats and codecs manually on the command-line.
Most MPEG players will pace video playback by using the playback rate of the sound card as a time base, regardless of the actual input data rate. This will unavoidably cause buffer under-runs (leading to audio artifacts) or overruns (causing leandvb to stall due to a blocked output pipe and lose synchronisation). This can sometimes be mitigated by manually specifying a frame rate slightly higher that the real value.
For interactive applications such as videoconferencing, sources of latency must be understood as well.
MPEG has provisions for transmitting frames out-of-order, which implies latency. Encoders should be configured to not use backward prediction, i.e. B-frames.
DVB-S interleaving causes an unavoidable latency of 2244 bytes, i.e. 300 ms at 64 Kbit/s.
leandvb tends to process data in fixed-size chunks (but the resulting latency should be less than that caused by interleaving).
Most MPEG decoders will buffer data to ensure a smooth playback.
This script was successfully used to display live video from the ISS and simultaneously record I/Q samples:
$ while true; do rtl_sdr -g 22 -f 397000000 -s 2400000 - | tee $(date +%Y%m%d_%H%M%S%z.iq) | ./leandvb --gui | mplayer -demuxer mpegts -tsprobe 1 -vid 256 -aid 257 -vc ffmpeg2 -ao null - done
Explicit caching of the transport stream may also help the decoder identify the MPEG stream, e.g.:
$ ... | mplayer -cache 128 -
leansdrcat can be used to play back a file at a constant bit rate. This is useful for testing whether a MPEG decoder can handle real-time streams.
$ ./leansdrcat --cbr $((2400000*16)) < capture.iq | ./leandvb --gui | mplayer -
The DVB-S symbol rate and code rate must be supplied to leandvb on the command-line. A companion tool, leansdrscan, can help detect these parameters automatically.
The following command will spawn leandvb with six combinations of symbol rates (250 kS/s, 500 kS/s, 1000 kS/s) and code rates (1/2, 7/8) until MPEG packets are obtained.
$ ./leansdrscan -v --rewind ./leandvb -f 1024000 --sr 250000,500000 --cr 1/2,7/8 < capture.iq > capture.ts
For live streams the --rewind option is not needed. Besides, the --tune option could be used to scan multiple narrow-band channels within a wide-band capture:
$ rtl_sdr ... | ./leansdrscan -v ./leandvb -f 2400e3 --tune -500e3,0,500e3 --sr 250000 --cr 1/2,7/8 | ...
Note: This may not work on crowded bands because leandvb does not perform bandpass filtering yet.
leandvb can provide status information on an auxiliary output channel specified by --fd-info.
$ rtl_sdr ... | ./leansdrscan ./leandvb --fd-info 2 -f 1024e3 --sr 250e3,500e3 --cr 1/2,3/4 | mplayer -cache 128 - CR 1/2 SR 250000.000000 LOCK 0 FREQ 4047 SS 66.660774 MER 19.8 LOCK 1 FREQ 4062 SS 65.118179 MER 18.7 FREQ 4047 ...
This should allow leandvb to be used as a plugin for other applications. For example, leandvb_tui.sh displays the status information on one line:
$ rtl_sdr ... | ./leandvb_tui.sh ./leansdrscan ./leandvb --fd-info 2 -f 1024e3 --sr 250e3,500e3 --cr 1/2,3/4 | mplayer -quiet -cache 128 - [SS 68] [Offset +4047 Hz] [MER 18.7 dB] [LOCKED] [SR 250000 Hz] [FEC 1/2]
CPU usage depends on the input sample rate, on the symbol rate and to a lesser extent on the error rate. Note that the --gui option increases CPU load.
leandvb can demodulate 2 Msymbols/s digitized at 2.4 Msamples/s in real-time on a 1.33 GHz Intel Z3745 tablet. This makes it possible to receive HamTV from the ISS with a low-cost portable setup, which was the original goal of the project.
leandvb is also known to work on Raspberry Pi platforms, but at slower symbols rates.
Table 1. Benchmark between platforms
|Dataset||samprate/symbrate/dur||Intel Core i7||Intel Atom Z3745||Raspberry Pi 2 Model B|
|gqrx_20151211_204746||2.4M / 2M / 23||2588 KiB in 4 s||2588 KiB in 13 s||2639 KiB in 50 s|
leandvb can demodulate a HamTV signal captured during an overhead pass of the ISS with a linearly-polarized 24 dBi dish, MMDS downconverter and RTL-SDR R820T2 dongle.
leandvb successfully received the ARISS HamTV contact on 2016-05-09 at 67° maximum elevation with a shoulder-mounted dish (see [HAMPADS]).
Demodulation was extremely poor during another pass at 47° elevation with wet weather.
Table 2. Benchmark between demodulators
On Intel Core i7.
|Dataset||samprate/symbrate/dur||leandvb||gr-dvb without Viterbi||gr-dvb|
|gqrx_20151211_204746||2.4M / 2M / 23||2588 KiB in 4 s||2579 KiB in 8 s (17 s total)||2648 KiB in 37 s (58 s total)|
Any software component that processes third-party data is a security risk. This rule applies to web servers and software-defined radio receivers alike. In theory, if software-defined reception of sophisticated digital modes becomes popular, a malicious transmission on a HF band could target software vulnerabilities in a large number of receivers worldwide.
As a mitigation strategy, it is a good idea to run leandvb with minimal privilege, under SELinux, in a virtual machine, on dedicated hardware, etc.
This section lists symptoms, diagnostics and workarounds for common problems.
Figure 3. Excessive oversampling
The SDR front-end is capturing a larger bandwidth than is necessary.
This would cause problems if there was another transmission nearby.
Decrease the sampling rate.
Figure 5. Internal saturation ?
The I/Q ring pattern suggests that SNR is good (left and middle).
Actually, the distribution is abnormal: amplitude is bounded, and the four symbol clouds are not round (right).
This could be caused by saturation inside the RTL-SDR dongle, before the DDC stage.
Until this is better understood, consider setting the gain manually if this happens.
Figure 6. In-band interference
Here a birdie (top right) is automatically filtered (bottom).
This restores the ring-shaped I/Q pattern (bottom left).
Increase --anf if needed.
Figure 7. Frequency offset
SNR is good but tuning is slightly wrong (top right).
The spectrum is re-centered with --derotate -50000 (middle right).
Note: The demodulator would have tolerated this offset anyway.
Figure 8, “ DVB-S demodulation flow-graph ” illustrates the demodulation process.
The auto notch filter block performs a Fourier transform about once per second to identify spurious signals. Then it tracks their phase and amplitude in order to filter them.
Subsequent blocks follow the DVB-S standard closely. See [DVBS] for details.
The QPSK demodulator performs timing recovery and interpolation. It outputs soft symbols because DVB-S encourages Viterbi decoding, but the current implementation thresholds them immediately into 2-bit QPSK symbols.
The deconvolution block reverses the inner (convolutional) coding and puncturing, but the current implementation does not correct errors.
The synchronizer handles conjugation, constellation rotation (0, 90, 180 or 270°), alignment of puncturing patterns and alignment of byte boundaries. Synchronization is achieved when the stream contains MPEG start codes every 204 bytes. One in eight start codes is inverted.
The deinterleaver reverses the byte shuffling that is performed during modulation. (This is done to spread burst noise over a large number of packets so that Reed-Solomon can be more effective.) By design, start codes are not shuffled.
The Reed-Solomon block uses the last 16 bytes of each 204-byte packet to detect and correct errors.
The derandomizer reverses the bitwise obfuscation that is performed during modulation. (This is done for "energy dispersal", i.e. to flatten the RF spectrum.) It also de-inverts the inverted start codes.
Sensitivity benchmarks with simulated noise.
SIMD optimizations on x86 and ARM
Viterbi. Dynamic demodulation trade-offs for optimal performance on all platforms
Allow leansdrscan to run several demodulators in parallel.
Modulator (for testing purposes; there are already several software-defined DATV modulators)
leandvb is developed primarily for non-commercial research and experimentation in the context of amateur radio. Irrespective of opinions about the legitimacy of software patents, anyone contemplating other uses should probably seek legal advice about the following issues.
The DVB-S standard was originally published in 1994 as ETS 300 421. There is hope that any applicable patents have expired or will expire shortly. However, even after a standard has become patent-free, some implementation details could still be subject to IP rights.
A complete software DVB-S receiver would typically include a MPEG-2 decoder. The MPEG-2 standard was finalized around 1995 and published in 1996. This article estimates that it will become patent-free in 2018.
Related standards such as DVB-T (1997), H.264 (2003), DVB-S2 (2005), DVB-T2 (2008) and HEVC (2013) are probably covered by patents.
Edmund Tse published a reference implementation of DVB-S for gnuradio as early as 2010 ([GRDVB]). This provided a proof-of-concept and initial motivation for this project.
Early users F5OEO and K4KDR contributed I/Q recordings from a variety of modulators, transmission channels and receivers. This helped debug and fine-tune leandvb.
[DVBS] Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for 11/12 GHz satellite services . 1997. https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=5316.
[GRDVB] Software Radio for Digital Satellite Television . 2010. http://www.edmundtse.com/wp-content/uploads/2009/04/treatise.pdf.
[SOFTDATV] SDR reception of Digital Amateur TV from the ISS . http://www.pabr.org/radio/softdatv/softdatv.en.html .
[HAMPADS] HAMPADS: HAM-Portable Affordable Dish for Satellites . http://www.pabr.org/radio/hampads/hampads.en.html .
About | | Share: