SOFTWARE DEFINED RADIO IMPLEMENTATION OF A DVB-S

TRANSCEIVER

Ashwin Amanna, James Bohl, Zachary Goldsmith (ANDRO Computational Solutions,

LLC, Rome, NY, USA; [email protected], [email protected],
[email protected]); Michael Gudaitis, Benjamin Kraines, Robert DiMeo, William
Lipe, Richard Butler II (Air Force Research Lab RIT, Rome, NY, USA;
[email protected], [email protected], [email protected],
[email protected], [email protected])

ABSTRACT FPGA products, which results in closed systems, longer

development times, and inability to adapt waveform code
Most waveforms operating on Software Defined Radios on-the-fly. Recent improvements in general purpose
(SDR) are actually ‘firmware’ defined implementations with processors (GPP) to accommodate graphics processing
significant elements operating in the FPGA on closed allow GPPs to handle more DSP functions and thus enabling
platforms. This diminishes the full potential of SDR in terms the original potential of SDR. As a case study for this GPP-
of rapid development time cycles, accessibility to waveform based software approach, we present a 100% software
code, and adaptable rapid reconfiguration. We address the implementation of a Digital Video Broadcast Satellite
challenges of rapid waveform development on SDR using (DVB-S) standard transceiver on low-cost hardware with all
the Digital Video Broadcast Satellite (DVB-S) standard as a I/Q processing performed in a general-purpose processor
case study with a true software defined implementation [1].
where all I/Q processing is performed on an Intel processor A practical challenge for affordability was to limit the
in conjunction with low-cost Ettus B205mini and Nuand total hardware costs to less than $3000 for a laboratory
bladeRF SDRs. We distill the waveform to core functional demonstration. This affordability constraint encouraged
components and sequence the implementation into “sprints” developers to seek innovative technical optimizations while
while maintaining end-to-end functionality at each iteration. working within the constraints of the low-cost hardware and
Innovations include strategic use of machine code for processing-intensive operations of forward error correction
computational intensive operations and efficient multi- (FEC) with the GPP. Government waveform efforts typically
thread management. Our approach yielded a full transceiver follow a traditional requirements-based acquisition cycle.
implementation within 2 man-weeks using only the We overcame this slower approach by adopting an agile-
published specification for reference. The transmitter was based development approach.
tested for interoperability with a consumer satellite receiver. Our methodology to waveform development starts by
CPU usage on an i7 processor was approximately 22%, with distilling the waveform into its core functional components.
a memory usage of 16MB out of the 8GB available. The We then simplify or eliminate blocks to implement an initial
mean latency of the system is approximately 50 minimal functional prototype. From here, we incrementally
milliseconds. A similar test showed that the system latency add components and adapt existing elements to match the
is affected by symbol rate and decreases as the rate is configurations defined in the waveform specification.
increased. When the symbol rate is set to 15 To achieve efficient operations on a GPP platform, we
Msymbols/sec, the latency drops to 17 milliseconds. implement targeted functions in assembly code. Similarly,
we divided the waveform code into multiple threads to
1. INTRODUCTION equalize multi-core utilization. The Viterbi decoder, filtering
and carrier recovery proved to be the most difficult to
Early promises of software defined radios (SDR) included optimize. Interoperability was demonstrated using our
accelerated development timelines, greater accessibility to transmitter with an off-the-shelf Coolsat DVB-S satellite
waveforms, and ease of modification. However, the general- receiver. We quantified bit error rate performance, CPU
purpose processors of the 1990’s were not powerful enough usage of transmitter and receiver signal flows, and measured
to support complex waveforms that have demanding digital latency.
signal processing (DSP) algorithms. This led to We have shown that the GPP platform can achieve
implementations with firmware emphasis where most performance previously reserved for firmware
complex processing was performed in a FPGA. A drawback implementations. Our agile-based development process
of this FPGA trend was lack of portability across different yields waveforms significantly faster than a traditional
requirements-based approach and proven through the first MPEG2 frame of each randomizer frame is inverted
interoperability with off-the-shelf devices. The structure of to indicate the start of the randomizer frame.
this paper is as follows: we summarize existing software
implementations of the DVB family and present our DVB-S
implementation. Interoperability validation is described
followed by benchmarking performance tests.

2. BACKGROUND

A literature search indicates several SDR implementations Figure 1. DVB-S Transmitter Block Diagram
of DVB-related waveforms [2-4]. Most of the papers focus Each 188-byte MPEG2 frame is Reed-Solomon
on DVB-Terrestrial (DVB-T). DVB-T is like DVB-S with encoded producing 204-byte frames. Frames are interleaved
similar data framing and error correction. Modulation is using a convolutional interleaver. The byte stream output
more complex with orthogonal frequency division from the interleaver is converted to a bit stream, most
multiplexing (OFDM) in DVB-T compared to QPSK in significant bit (MSB) first, and convolutionally encoded.
DVB-S. The output of the convolutional encoder is punctured by the
Our implementation shares several similarities with [2] selected rate, either 1/2, 2/3, 4/5, 5/6, or 7/8. The encoded
including 100% software implementation, leveraging bit streams are QPSK modulated, RRC filtered, and
multiple threads to optimize performance, and use of SIMD transmitted by the radio.
code to parallelize some functions. A key difference is in the The DVB-S receiver is shown in Figure 2. The system
multi-threading model. We are breaking up the processing first removes DC offset introduced by the transmitter and
into separate threads that pass data between each thread. receiver. This is performed twice, before the carrier
They are using a thread pool with a main thread directing the synchronization to remove the receiver induced offset, and
individual threads to awaken when there is input available to again after carrier synchronization to remove the transmitter
process. In our approach, there is no main thread. Instead, induced component. The process is performed on blocks of
the inter-thread buffers manage blocking/unblocking thread 4096 consecutive samples. The average is calculated and
execution when an input/output buffer is available. Our then subtracted from each sample.
approach should simplify waveform development as there is
no need to set up the main thread and implement the logic
for determining when data is ready for the threads. This
logic is effectively implemented locally by the inter-thread
buffers. The thread-management code is contained in a
library that never needs to be modified by the waveform
developer.
Their use of an older processor in [2] most likely limits
SIMD to SSE while our more modern processor enables
Advanced Vector Extensions (AVX). They are using multi-
threading functions. We have only employed this technique
for more complicated waveforms and found it unnecessary
Figure 2. DVB-S Receiver Block Diagram
for DVB-S. Finally, we implemented a complete real-time
receiver, while they created an offline receiver. Automatic gain control (AGC) is similarly performed
on blocks of 4096 samples to normalize the amplitude of the
3. IMPLEMENTATION received signal. This is required to prevent a variation in
carrier synchronization and symbol synchronization
The transceiver is based on DVB-S standard EN 300 421 response time with the received signal level. Each sample is
V1.1.2 (1997-08). The transmitter block diagram is shown in divided by the root mean squared (RMS) amplitude of the
Figure 1. A video file is encoded by VLC producing entire 4096 sample block.
MPEG2 transport stream frames. Null frames are inserted in Next, a phase-locked loop (PLL) removes the
this stream as needed to adapt the bit rate of the video phase/frequency offset from the signal. The phase/frequency
stream to the bit rate of the DVB-S transmitter. The error is calculated by taking the 4th power of each input
randomizer operates on 8 MPEG2 frames at a time. The first sample. This produces a strong impulse at 4x the frequency
byte in an MPEG2 frame is a synchronization marker. These offset. This step initially showed high computation cost.
synchronization markers are used directly by DVB-S for its Originally, this PLL was calculating the phase error and
own synchronization purposes. The synchronization byte in updating the feedback loop on every sample coming in. This
resulted in an update rate of 25 million samples/second. 5. TEST PLATFORM
Since the frequency offset is minor compared to the sample
rate, it is not necessary to update the PLL feedback loop for We have tested the DVB-S transceiver on software defined
every sample. The PLL was redesigned to calculate the radios in cabled RF and over-the-air (OTA) wireless
phase error on a block of samples and then update the configurations. To demonstrate interoperability, we
feedback loop for each block. The block size is currently set transmitted a video file to a commercial off the shelf
to 8 samples. (COTS) Coolsat receiver connected to a television. Table 1
The same technique was applied to the symbol timing lists configuration parameters necessary to recreate the
PLL. In this case, the maximum sample rate offset is smaller system model.
than the maximum frequency offset. Therefore, the block Note that the bladeRF [5] is operating at 1GHz which is
size can be made larger resulting in a greater reduction in the intermediate frequency (IF) of the Satellite TV receiver.
computations. The block size is currently set to 1024 A label on the Coolsat receiver states that 950-2150MHz is
samples. the IF range. In a real system, there would be an
A similar approach is used for symbol synchronization. upconverter to the KU band (to 11.7 to 12.7GHZ) at the
By squaring each sample, a strong frequency component is transmitter. At the receiver (Coolsat), there would be a Ku
identified at the symbol rate. A PLL locks onto this downconverter. In this case we are only operating at 1GHz
frequency and optimal symbol timing is determined based which is directly received by the Coolsat.
on the phase of the PLL numerically controlled oscillator The low noise block (LNB) downconverter input also
(NCO). A Root-Raised-Cosine (RRC) filter is again used to has 18 volts DC component. This DC voltage powers the
interpolate at the optimal time. Here, the RRC filter dot downconverter when it is used. It is important to disable this
product operation is implemented in assembly code. DC voltage or use a DC blocking capacitor when directly
At this point, the symbols are QPSK demodulated connect this to the bladeRF SDR. At one point, we directly
producing two bit streams. These bits have the values +1/-1. connected an attenuator to the LNB input and then
The two bit streams are de-punctured which inserts 0 connected it to the SDR which led to the attenuator getting
wherever a bit was punctured. The de-punctured bit streams hot to the touch. There is an option to disable the 18V DC
are Viterbi decoded producing a single output bit stream. which would allow direct connection.
Since a QPSK constellation is symmetric over a 90-degree The RF out of the satellite receiver connects directly to
rotation, there may be a 90-degree phase ambiguity in the an old television. The LNB Input port of the receiver is
received symbols. To correct for this, the constellation is connected to a coaxial cable. Soldering was required to
rotated periodically until synchronization is detected by the connect the coaxial cable’s center wire and ground to the
Viterbi decoder. Also, the de-puncturing must be correctly antenna connector. We have found that the receiver
aligned with the incoming bit streams. To obtain the proper sensitivity is good enough that the system receives video
alignment, the de-puncturing is periodically shifted with without the antenna on the Coolsat receiver.
respect to the incoming bit stream until the Viterbi decoder
detects synchronization. The output bit stream from the Table 1. Components Used in Demonstration System
Viterbi decoder is searched to locate the MPEG2 sync bytes.
Once found, the bit stream is converted to bytes and passed Item Description
into the de-interleaver. De-interleaved code-words are DVBS receiver Coolsat 5000 Platinum
decoded by the Reed-Solomon decoder and de-randomized. DVBS specification EN 300 421 V1.1.2 (1997-08)
The de-randomized code-words are sent to VLC to display SDR platforms Tested with BladeRF [5] and
the video. USRP B205MINI [6]
Linux distribution Ubuntu 14.04.3
4. LIMITATIONS
Linux kernel version 3.13.0
Software dependencies • VLC 2.1.6-0-gea01d28
This DVB-S implementation has several limitations related
• libbladerf
to synchronization stability. Synchronization loss occurs
• libuhd
intermittently with data transfers exceeding approximately
Antenna OmniLOG 70600 Antenna
900,000 MPEG2 frames. When synchronization loss occurs,
frames are dropped and bit errors are incurred in some Receiver gain Between 20dB and 40dB
received frames as synchronization stabilizes. Furthermore, Transmitter gain Between 20dB and 35dB
these low-cost SDR platforms have limited hardware Samples/symbol 2.25M
automatic gain control (AGC) functionality. To compensate Sample rate 33.75M
for the limited AGC, calibration of transmitter and receiver Frame size 188 Bytes
gain is consequently sensitive and requires frequent tuning.
 6. RESULTS BER tests were conducted by measuring bits in error from
fully synchronized MPEG2 frames at the receiver. Mock
Benchmarking tests included CPU usage, bit error rate, and MPEG frames 188 bytes in length were transmitted in 2ms
latency. The Linux utility, htop, was used to monitor CPU bursts with 10 frames/burst over a wired and wireless link.
usage of the transmitter software alone, the receiver alone, Under stable synchronization, 13 repetitions of 90,000
and both the transmitter and receiver running bursts (900,000 total frames) were received with no
simultaneously. CPU usage was measured on an Intel Core measured BER. In tests where synchronization was
i7 and i3, as indicated in Table 2. unstable, measured BER was on the order of 4.5E-5.
Commercial DVB-S strives for BER on the order of 1E-10.
Table 2. htop DVBS CPU Usage Results To statistically measure levels that low, approximately 1E12
HTop Reported CPU bits needs to be transmitted continuously. We were unable to
Laptop Features Usage out of 100% transmit that much data at one time and maintain
Tx/Rx Tx Rx synchronization.
Dell Intel® Core™ i7- System latency is defined as the time between
Precision 4610M CPU@3GHz 22% 8% 16% generating a MPEG2 frame and decoding a received
M2800 8GB RAM, 4CPUs MPEG2 frame, as shown in Figure 4. Table 3 shows the
Intel® Core™ i3- mean latency in the DVB-S transceiver in a wired
Lenovo environment (coaxial cable connecting the Tx and Rx RF
2348M [email protected] 50% 24% 35%
L530 ports) with increasing test burst sizes and a constant period.
4GB RAM, 4CPUs
Table 3. DVBS Transceiver Latency (Wired)
Note that for quad-core processors, htop typically reports
results out of a maximum of 400% based on the utilization Standard Deviation
Bursts Period Mean Latency (µs)
of four cores. Here, results are normalized to 100% (µs)
maximum. On average, the overall CPU usage for the entire 100 49172 284
system is relatively low. On a Dell Precision M2800 with an 1000 100 49117 196
Intel i7 processor with 4 CPUs, the lowest usage percentage 10000 49242 188
we achieved was 22% for the transceiver, 8% for the
transmitter only, and 14% for the receiver only.
Additionally, the RAM usage on the same platform
remained constant at 0.2%, which is a total usage of 16MB
out of the remaining 8GB.
Processor usage increases with symbol rate as shown in
Figure 3. Normalized CPU usage increases as the symbol
rate is increased from 5.5 to 15.5 symbols. Note that the
transmitter usage is shown in blue and the receiver usage is
shown in orange.

h top CPU Usage vs. Symbol Rate

40
CPU Usage (%)

30
20
10
0 Figure 4. Latency Measurement Endpoints
5.50 10.00 15.00 15.50 The mean latency of our system hovers around 50
Symbol Rate (M) milliseconds despite the increase in the number of bursts that
are sent. Although increasing burst size has no effect on the
Tx CPU Usage Rx CPU Usage mean latency, it does reduce standard deviation of reported
latency as more are sent. We further compare the mean
latency of the DVB-S system to the set symbol rate shown in
Figure 3. DVB-S Htop CPU Usage vs Symbol Rate
Figure 5 below.
 mobile processor, and 22% for a fourth generation i7 mobile
Mean Latency vs. Symbol Rate processor. Bit error performance was comparable to the
DVB-S waveform specification requirements when stable
50
synchronization is achieved, with system latencies measured
45 between 50ms and 17ms depending on the symbol rate.
Mean Latency (ms)

40
35 8. ACKNOWLEDGEMENT
30
Approved for Public Release; Distribution Unlimited:
25
88ABW-2017-4648, 22 Sep 2017.This material is based
20
upon work supported by Air Force Research Laboratory
15 (AFRL/RITE) under Contract No. FA8750-15-C-0250. Any
5 10 15 opinions, findings, conclusions or recommendations
Symbol Rate (M) expressed in this material are those of the author (s) and do
not necessarily reflect the views of AFRL.
Figure 5. DVB-S Latency vs. Symbol Rate
9. REFERENCES
The set symbol rate directly effects the mean latency of the
system. As symbol rate is increased from 5.5 to 15.5 [1] DVB-S Specification, EN 300 421 V1.1.2 (1997-08),
Msymbols, the mean latency decreases from 50ms to European Telecommunications Standards Institute,
approximately 17ms. www.etsi.org/deliver/etsi_en/300400_300499/300421/01.01.
02_60/en_300421v010102p.pdf
7. CONCLUSION [2] G. Baruffa, L. Rugini and P. Banelli, "Design and Validation
of a Software Defined Radio Testbed for DVB-T
We presented software implementation of a DVB-S Transmissions," Radioengineering, vol. 23, pp. 387-398,
transmitter and receiver where all I/Q processing is 2014.
performed in GPP. Key elements include taking advantage [3] Y. Jiang, W. Xu and C. Grassman, "Implementing a DVB-
of multiple processors through efficient threading and T/H Receiver on a Software-Defined Radio Platform,"
optimal usage of AVX instructions. Our agile approach to International Journal of Digital Multimedia Broadcasting, vol.
waveform development increases productivity and lends 009, p. 7, 2009.
itself to faster timelines and real-time troubleshooting due to [4] C. Fantozzi, L. Vangelista, D. Vorig and O. Campana, "SDR
the flexibility of an all software implementation. Our Implementation of a DVB-T2 transmitter: The core building
approach has been successfully applied across multiple blocks," IEEE International Conference on Consumer
commercial and military waveforms. Electronics (ICCE), Las Vegas, 2011.
We successfully showed that real-time operation of both [5] bladeRF Software Defined Radio (SDR), www.nuand.com
transmitter and receiver I/Q digital processing is possible on [6] USRP B205mini, Ettus Research, A National Instruments
an i3 or better processor. Benchmark results indicate peak Company, www.ettus.com/product/details/USRP-B205mini-i
normalized CPU usage at 50% for second generation i3