DVB-S was developed in the 1990s for digital satellite TV broadcasts, and superseded by DVB-S2 in 2005. In recent years DVB standards have been adopted by the amateur radio community for Digital Amateur TV (DATV). Inexpensive hardware-accelerated DVB receivers are available in the form of set-top-boxes, PCI cards and USB dongles. Unfortunately not all receivers are suitable for DATV:
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 regulatory constraints.
Some prominent DATV transmitters, such as the ISS HamVideo system, reportedly 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. Ultra-low-cost "RTL-SDR" dongles cover 10 m, 6 m, 2 m, 70 cm and 23 cm. Products from Analog Devices, Lime Micro and Ettus Research reach 3.8 GHz or 6 GHz.
A software DVB 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.
Soft-symbols from multiple receive chains can be combined to achieve diversity gain.
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 software demodulator will become capable of supporting faster modulation rates or processing larger numbers of channels simultaneously.
Failures can be analyzed extensively, and problems can be tracked down to the level of individual constellation symbols if necessary. By contrast, when a hardware demodulator fails to lock, it is difficult to understand why.
Obviously this flexibility comes with trade-offs in terms of cost, size, power consumption and error performance. In 2005, a 55 Mbit/s hardware DVB-S2 demodulator would fit in 14 mm² of 130 nm silicon. Nowadays a handheld satellite finder can be had for a few dozen euros; this includes a RF tuner, DVB-S/S2 demodulator, HD MPEG decoder, LCD display, embedded processor, keyboard, battery and several I/O ports. By contrast a software-defined receiver still needs a powerful general-purpose computer to provide the same functionality.
Presumably the researchers and engineers who designed DVB in the 1990s and DVB-S2 in the early 2000s wrote end-to-end simulations in MATLAB or similar DSP frameworks; these would be the first software-defined implementations of these standards. Manufacturers of chipsets and test equipment are likely to have developed software-defined demodulators as well. This section mentions only project with publicly-available source code.
gr-dvb [GRDVB] is a complete implementation of DVB-S for GNU Radio. It is valuable as a reference implementation and as an educational tool, but it has high CPU requirements and it depends the whole GNU Radio infrastructure including Boost, SWIG and Python.
The GNU Radio DTV subsystem includes DVB-S2 and DVB-S2X modulators [GRDVBS2]. There are ongoing efforts to add DVB-S2 and DVB-S2X demodulators (Phase 4 Ground project, [GRDVBS2RX]).
By contrast, leandvb is written in plain C++ with very few third-party dependencies. It is developed for Linux and may compile on other UNIX-like and embedded platforms. Emphasis is on achieving useful throughput with real-world signals rather than on reaching theoretical error performance targets.
Table 1. leandvb overview
| Default mode | Highspeed mode | ||||||
|---|---|---|---|---|---|---|---|
| Input format | I/Q: uint8_t (rtl_sdr), int16_t (PlutoSDR, LimeSDR, etc), float I/Q | ||||||
| Pre-processing |
| ||||||
| Sampling ratio | 1.2 - 100+ samples/symbol | ||||||
| Bandpass filtering | RRC (optional) | None | |||||
| Equalization | None | ||||||
| Minimum baud rate |
| ||||||
| Maximum symbol rate | Limited by hardware capabilities. | ||||||
| Maximum symbol rate inaccuracy | TBD | TBD DVB-S2: 5 ppm | |||||
| Maximum carrier frequency error |
| ||||||
| DVB-S constellations | QPSK | ||||||
| DVB-S code rates | 1/2, 2/3, 3/4, 5/6, 7/8 | 1/2 only | |||||
| DVB-S error correction |
|
| |||||
| DVB-S2 MODCODs |
| ||||||
| DVB-S2 frame size | 64800, 16200 | ||||||
| DVB-S2 error correction |
| ||||||
| DVB-S2 mode adaptation |
| ||||||
| Error performance | See Section 7, “ Performance ” | ||||||
Due to various algorithmic trade-offs, leandvb does not meet the error performance requirements of DVB standards.
Signal strength, CNR and MER are estimated on a subset of samples.
At low SNR, MER measurements are not realiable estimators of SNR. This is because the AGC is not suitable for low SNR. Use --cnr instead.
MER readings are overestimated at low SNR. The estimator is biasesd because it performs symbol decisions and does not revise them after error correction.
When using leandvb to measure the MER of a modulator, use a high sampling ratio (e.g. 16 samples per symbol. Otherwise internal interpolation noise will dominate the error vector.
The CNR estimator requires good frequency accuracy. With --drift, CNR values become unreliable when the demodulator loses synchronization.
Roll-off must be configured manually. leandvb ignores roll-off information from DVB-S2 PL signalling.
Download and build leandvb and related utilities:
git clone -b work http://github.com/pabr/leansdr.git cd leansdr/src/apps vi Makefile # For DVB-S2, find and uncomment LEANSDR_EXTENSIONS make
Run the functional tests. This occasionally reveals architecture- or compiler-specific issues.
cd leansdr/test make leandvb-ft
Build an external LDPC decoder for DVB-S2 at low SNR:
git clone -b ldpc_tool http://github.com/pabr/xdsopl-LDPC-pabr cd xdsopl-LDPC-pabr make CXX=g++ ldpc_tool
Run the error performance tests.
cd leansdr/test cp .../ldpc_tool . make leandvb-snr
TBD 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 --standard S DVB-S (default), DVB-S2 (not implemented) --const C QPSK (default), 8PSK .. 32APSK (DVB-S2 only) --cr N/D Code rate 1/2 (default) .. 7/8 .. 9/10 --fastlock Synchronize more aggressively (CPU-intensive) --filter Filter baseband (CPU-intensive) --hq Enable all CPU-intensive features UI options: -h Display this help message and exit -v Output debugging info at startup and exit -d Output debugging info during operation --fd-info NUM Output demodulator status to file descriptor --fd-const NUM Output constellation and symbols to file descr --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)
--inpipe BYTES
Resize the pipe on standard input.
Larger values allow the operating system to buffer more samples when leandvb is busy. This is is useful in live streaming mode, especially with jittery LDPC decoding. Buffering increases latency, but the only alternative when the CPU cannot keep up is losing demodulator synchronization.
--gui
Displays the spectrum and I/Q values at various stages in the demodulation process. This is useful for troubleshooting. Available only on platforms with X11. See --fd-info for an alternative monitoring interface.
-f HZ
Specifies the sampling rate of the I/Q stream on standard input. Typically this should be the same value as in rtl_sdr -s HZ.
--sr HZ
Specifies the symbol rate (a.k.a. baud rate or modulation rate) of the DVB signal. Commonly-used values are 2e6, 1e6, 500e3, 333e3.
--tune HZ, --derotate HZ
Specifies the center frequency of the DVB signal in the I/Q stream.
This option is useful when the carrier frequency error signal is not centered at DC, e.g.:
When Doppler or inaccurate local oscillators introduce a frequency offset.
When the receiver is not tuned to the nominal frequency. This is sometimes done deliberately to work around spurious signals or artifacts around DC from low-cost receivers.
To select a channel from a wideband I/Q capture.
For example a signal at 397.1 MHz can be received either with rtl_sdr -f 397100000 | leandvb or with rtl_sdr -f 397000000 | leandvb --tune 100e3.
--derotate explicitly shifts the specified frequency to DC; this is useful with --fd-pp and for troubleshooting with the GUI. --tune merely biases the demodulator instead; this is more CPU-efficient.
--resample
Enables bandpass-filtering and downsampling.
This is mostly useful with --fd-pp and for troubleshooting with the GUI. Use --sampler rrc instead.
--decim N
Enables decimation of the signal prior to demodulation.
This can reduce CPU usage if the input data is heavily oversampled, but requires a bandpass-filtered signal. If noise or neighbouring signals must be rejected, use --resample or --sampler rrc instead.
When used in conjunction with --resample, --decim forces the decimation factor. --resample --decim 1 will show the effect of bandpass-filtering in the GUI.
--sampler MODE
Selects how symbols are derived from samples.
nearest: Very fast, but requires a bandpass-filtered signal and a high sampling ratio (e.g. 16 samples per symbol).
linear: Fast and works at low sampling ratios (e.g. 1.2 samples per symbol), but requires a bandpass-filtered signal and high SNR.
rrc: Performs bandpass-filtering, interpolation and symbol estimation simultaneously. Best error performance, suitable for all applications, but CPU-intensive. --rrc-rej and --rrc-steps control the filter length and interpolation accuracy. They can be adjusted to improve sensitivity or reduce CPU usage.
--drift
Allows the demodulator to track frequency errors beyond safe boundaries.
This can be useful with inaccurate oscillators (e.g. non-TCXO RTL-SDR dongles) and in the presence of Doppler shift.
By default the demodulator tolerates offsets up to ±symbolrate/8. Beyond that, it will deliberately unlock. This is done to avoid locking onto QPSK constellations ±symbolrate/4 away from the correct frequency. With --drift, the demodulator follows the carrier beyond these limits. It will even wrap through band boundaries if the signal is aliased by decimation. The band-pass filters and CNR estimator will follow the drift.
Note that if the demodulator unlocks after the carrier has drifted significantly from the nominal frequency, it may fail to re-lock, or it may lock at ±symbolrate/4, or it may lock onto a neighbouring signal.
--cnr
Enables estimation of the Carrier-to-Noise ratio (C/N). TBD cnr dans leandvb_tui.sh
CNR is obtained by first measuring (C+N)/N from the spectrum, and then deriving C/N.
--fastlock
Enables more aggressive synchronization techniques.
With this option leandvb will lock on the signal as early as possible. This is recommended with intermittent signals (half-duplex communications) and in offline mode (to recover as much data as possible from a recorded signal). When used with --viterbi, CPU consumption will increase significantly.
--hs
Enables a special high-throughput mode with the following restrictions:
- 8-bit unsigned I/Q input
- No preprocessing (requires a clean bandpass-filtered input signal)
- DVB-S QPSK 1/2 only
This mode is recommended for HamTV with RTL-SDR dongles on embedded platforms.
--ldpc-bf INT
Enables LDPC bit-flipping to correct the specified number of errors.
This is fast but suboptimal LDPC decoder. Useful to maximize throughput at high SNR.
--ldpc-helper COMMAND
Enables LDPC decoding with an external program.
The program will be spawned as COMMAND --standard DVB-S2 --modcod INT [--shortframes]. It must receive concatenated frames on standard input and emit error-corrected frames (including parity bits) on standard output. LLR format is int8_t. Latency must be less than 32 frames.
--nhelpers INT
Specifies the number of external decoder processes.
This improves throughput on multi-core machines. It is a good idea to try one process per core and see how many are actually busy.
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 --hq < capture.iq > capture.ts $ ffplay capture.ts
Option --hq enables CPU-intensive features. It is recommended for off-line use, when the goal is to recover as much data as possible.
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:
At high CPU load, pipes may overflow, in which case the rtl_sdr will silently discard samples. rtl_sdr -b 32768, rtl_sdr -S and leandvb --inbuf 262144 may help.
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 output 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 --cbr16 2400000 < capture.iq | ./leandvb --gui | mplayer -
The carrier frequency, symbol rate and (for DVB-S) 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 | ...
leansdr source code is currently not designed to be linked with other software. Instead, third-party applications can spawn a leandvb process, inject I/Q samples into its standard input, and capture its standard output or redirect it into a MPEG decoder. leandvb will provide status information on auxiliary output channels specified by --fd-info and --fd-const.
$ 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 ...
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]
And leandvb_vt100ui.sh shows the constellation and symbols in a 80x24 VT100 terminal:
$ rtl_sdr ... | ./leandvb_vt100ui.sh ./leandvb --fd-info 2 --fd-const 2 | mplayer -really-quiet -cache 128 -
|
leandvb VT100 UI example |
|
SS: 63 |
x x |
MER: 10.9 dB x x |x x
x#x x | x# x
Offset: +188123 Hz | x x
|
LOCKED |
---------------------+---------------------
FEC: 1/2 | x
x x |
SR: 2000000 Hz x | x x x
x# | # x
x x x x x
x | x
|
|
|
|
These results are taken from simulations with ideal modulators and additive white gaussian noise (AWGN) channels.
TBDReal-world applications involve modulator noise, non-linear amplifiers, multipath interference, oscillator drift, internally-generated "birdies", and digitization noise.
CPU usage depends on the input sampling frequency, on the symbol rate and to a lesser extent on the error rate.
The --gui option increases CPU load.
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 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
The signal contains a strong birdie (top right).
Use --anf 1 to filter it out. This improves the ring-shaped I/Q pattern (bottom left).
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 APSK demodulator performs timing recovery and interpolation for the configurer constellation. It outputs soft symbols.
The algebraic deconvolution block reverses the inner (convolutional) coding and puncturing without correcting errors. Alternatively, the Viterbi decoder block performs errors correction.
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.
The salient feature of DVB-S2 is a framing structure with repeating sequences of predictable symbols (start-of-frame headers and optional pilot bursts). This allows operation at low SNR, but requires dedicated clock and timing recovery algorithms. For comparison, DVB-S2 has modes designed for -2.35 dB Es/N0, whereas the lowest SNR supported by DVB-S is 4.5 dB.
Another feature is physical layer signalling, i.e. auto-detection of the modulation and coding paraameters. This requires tagging of some data flows, which is cumbersome to implement in SDR frameworks with simple data types.
Hence, in leandvb, DVB-S2 symbol sampling and frame synchronization are integrated in the same processing block. This block also decodes the PL header in order to select the proper constellation for payload symbols. Physical layer descrambling is performed simultaneously.
Subsequent processing blocks are a straightforward implementation of the standard.
The deinterleaver block remaps soft-symbols into an error-protected sequence of bits called FECFRAME.
The LDPC decoder (either the internal implementation or an external program) takes a FECFRAME and corrects error. The BCH decoder detects residual errors; it does not correct as many errors as the Reed-Solomon layer in DVB-S. The resulting BBFRAME is descrambled in the same processing block.
The deframer block takes BBFRAMES, decodes BBHEADERs and splits the payload data into 188-byte MPEG packets.
Improve error performance
DVB-S2 GSE
Multi-threading
Cascaded filters to reduce CPU consumption at high oversampling
SIMD optimizations on x86 and ARM
Dynamic demodulation trade-offs for optimal performance on all platforms
Allow leansdrscan to run several demodulators in parallel.
GQRX plugin
Android app.
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. It is likely that any relevant patents have expired or will expire shortly.
A complete software DVB receiver would typically include a MPEG 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) may be covered by patents.
In 2015 the ARISS HamVideo project provided motivation for demodulating real-world DVB-S signals efficiently in software. Edmund Tse's implementation for GNU Radio ([GRDVB], 2010) helped confirm that this would be possible.
Early users F5OEO and K4KDR contributed DVB-S I/Q recordings from a variety of modulators, transmission channels and receivers. This helped debug and fine-tune leandvb.
In 2018 the AMSAT-DL / QARS / Es'HailSat QO-100 project provided an incentive to add DVB-S2 support.
The GNU Radio DVB-S2 modulator, based on code by Ron Economos W6RZ and Charles Brain G4GUO ([GRDVBS2], [DATVEXPRESS]), was used for early DVB-S2 compatibility testing.
Ahmet Inan's LDPC decoder ([XDSOPL_LDPC]) made it possible to benchmark and fine-tune the DVB-S2 clock&timing recovery at low SNR.
The online QO-100 spectrum monitor and chat service operated by BATC helped capture relevant real-world DVB-S2 signals for testing purposes.
[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.
[DVBS2] Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications; Part 1: DVB-S2. 2005. https://www.dvb.org/standards/dvb-s2.
[GRDVB] Software Radio for Digital Satellite Television. 2010. http://www.edmundtse.com/wp-content/uploads/2009/04/treatise.pdf. https://github.com/EdmundTse/gr-dvb.
[GRDVBS2] A DVB-S2 and DVB-S2X transmitter for GNU Radio. 2014. https://github.com/drmpeg/gr-dvbs2.
[GRDVBS2RX] DVB-S2 and DVB-T2 receiver blocks for GNU Radio. 2018. https://github.com/drmpeg/gr-dvbs2rx.
[DATVEXPRESS] DATV-Express GUI source code. 2014. https://github.com/G4GUO/datvexpress_gui.
[XDSOPL_LDPC] Playing with Low-density parity-check codes. 2018. https://github.com/xdsopl/LDPC.
[SOFTDATV] SDR reception of Digital Amateur TV from the ISS . http://www.pabr.org/radio/softdatv/softdatv.en.html .