Real-Time Generation of Standard-Compliant DVB-T Signals

,


Introduction
Digital Video Broadcasting-Terrestrial (DVB-T) is a popular broadcasting standard used in Europe and worldwide [1], [2], [3]. Traditionally, DVB-T transmitters make use of hardware-based architectures, either customized or reprogrammable. However, software-defined radio (SDR) solutions are becoming attractive in order to incorporate many software-defined communication standards into a single device, which can be driven by a low-cost personal computer (PC) with multicore central processing units (CPUs) [4], [5], [6].
In the last fifteen years, SDR solutions for DVB-T systems have been investigated by many researchers, using different software languages, mainly C++ and MATLAB. For what concerns the C++ language, [7] proposed a mixed SDR digital signal processor (DSP) platform that uses a host PC and an MDS TM-13 IREF DSP board. A complete DVB-H transmitter and receiver chain that runs in real time on a multithreaded DSP was described in [8]. In 2008, [9] proposed a GNU Radio-based DVB-T modulator that integrates a hybrid C++/Python code with a universal software radio peripheral (USRP) front-end. A C++ receiver was then proposed in [10] to reduce the computational cost with respect to [9]. By means of accurate optimization strategies and a memory-based acceleration technique [11], real-time reception and decoding of TV signals can be achieved. A memory-efficient DVB-T/H receiver has been proposed in [12], using a DSP-based and accelerator-assisted SDR architecture together with multithreading and a parallelized version of the C language. A softwaredefined C receiver implementation for ISDB-T is described in [13]: this receiver can operate on a single frequency segment of the ISDB-T signal, thus allowing to receive a standard definition TV signal in real time. C++ software for DVB-T signal reception has been proposed in [14], [15], [16], [17], which demonstrate the real-time feasibility for the whole receiving chain. In [18], the most time-consuming processing stages (Viterbi decoder and FFT) have been implemented using a graphic processing unit, whereas the remaining stages still run on the CPU and are implemented in C; however, the Reed-Solomon (RS) decoder has not been considered in the reception chain. In 2014, we proposed an USRP-based C DVB-T transmitter that works in real time and makes use of parallelization strategies such as multithreading and vectorization [19]. The Brazilian version of ISDB-T has been implemented in [20] at the transmission side on a regular PC, using GNU radio and C++, achieving real-time processing.
MATLAB software for digital video broadcasting systems has been proposed as well. For instance, [21] develops DVB-T transmission and reception chains, with a subsequent SIMD-oriented pre-compilation step that provides optimized assembly code for specialized reprogrammable processors. Some portions of the DVB-T reception chain have been implemented in MATLAB in [22] for the purpose of localization of GNSS systems: due to the low complexity of the synchronization algorithm, real-time processing was achieved. A MATLAB-based implementation of DVB-T transmitter and receiver is proposed in [23] and simulated in [24], focusing on channel coding and decoding operations. A MATLAB DVB-T receiver is described in [19], including mode detection and time and frequency synchronization. This paper presents and describes a new software implementation of the DVB-T modulator using C++. Differently from previous literature (e.g., [9] and [19]), the designed C++ code is integrated into the Iris SDR testbed developed by Trinity College of Dublin (TCD) [25]. Actually, the Iris testbed and the associated software enclose several features (e.g., runtime reconfiguration, network stack support, embedded systems support, componentbased architecture [25]) and also provide implicit multithreading capabilities. This way, differently from [19], real-time transmission can be achieved without applying specific parallelization strategies to the designed DVB-T C++ code. For the purpose of validation of the designed DVB-T C++ software, we also include the implementation of a MATLAB-based DVB-T modulator: the validation procedure compares the output of the C++ DVB-T modulator with the output of the MATLAB DVB-T modulator. The correctness of the validation has been further confirmed by the correct reception, on regular TV sets and USB dongles, of the DVB-T signal transmitted on-air in a laboratory environment.
In addition to a standard-compliant DVB-T modulator, the designed MATLAB code also includes a DVB-T receiver with channel estimation, equalization, soft-output demapping, Viterbi decoding, deinterleaving, Reed-Solomon (RS) decoding, and descrambling. Differently from most of the previous SDR-based DVB-T systems proposed in the literature so far, an important feature of the designed C++ and MATLAB code is the public availability under the GNU license (at https://github.com/wishfulproject/module_iris/tree/master/dvb-tx-iris), to enable reuse by other researchers and practitioners.
The remainder of this paper is organized as follows. Section 2 presents a brief overview of the DVB-T standard. Section 3 describes the implementation and the validation of the C++ DVB-T modulator, while Section 4 illustrates the MATLAB implementation of DVB-T. Section 5 discusses the impact of the proposed software, while Section 6 concludes the paper.

Overview of the DVB-T Standard
The DVB-T modulator can be summarized as in Fig. 1 [1]. The data to be transmitted are MPEG-2 Transport Stream (TS) packets, each with 188 data bytes containing compressed video and audio. Groups of eight TS packets are scrambled using a pseudo-random binary sequence that produces a scrambled sequence with 1503 bytes. The obtained sequence is then parsed and encoded using a nonbinary shortened RS code with 188 input bytes and 204 output bytes (the additional 51 zero bytes are not transmitted) [1]. These output bytes are convolutionally interleaved using I = 12 delay paths and memory cells with M I = 204/I = 17 bytes. Then, the interleaved bits are convolutionally encoded using a rate r c = 1/2 and a constraint length L = 7. The code rate can be increased up to r c  {2/3, 3/4, 5/6, 7/8} by puncturing (nonequispaced bit decimation) [1]. Successively, bit interleaving and  -bits symbol interleaving is performed using a RAM whose size depends on the DVB-T mode (6048 cells for 8K, 1512 cells for 2K). Afterward, the mapper uses Gray encoding and square quadrature-amplitude modulation (QAM) with M = 2  . The obtained QAM data cells are inserted into a frame adapter that includes signaling information, such as boosted pilots for channel estimation and transmission parameter signaling (TPS). The whole frame is then converted in orthogonal frequency division multiplexing (OFDM) symbols, with cyclic prefix (CP): one frame contains N F = 68 OFDM symbols, and one superframe contains four frames. The OFDM modulator is detailed in Sec. 2.1. If necessary, the DVB-T modulator can include an interpolator that adjusts the sample rate and a spectrum emission mask (SEM) filter. Interpolation and SEM filtering is described in Sec. 2.2.

OFDM
Each OFDM symbol contains K active carriers and N FFT -K virtual carriers as guard frequency bands. N FFT is the FFT size. OFDM performs an inverse FFT that converts the assembled data from the frequency domain to the time domain. A CP (with N G samples) is also prepended to each OFDM symbol. The OFDM baseband signal [ ] s n  can be expressed by where m is the frame index, l is the OFDM symbol index, k is the subcarrier index, c m,l,k is the QAM data cell, G k is a weighting factor that pre-compensates linear distortions caused by following stages (G k = 1 if no distortion), and z m,l [n] is the OFDM symbol in the time domain.

Interpolation and SEM Filter
The interpolator is not part of the DVB-T standard [1] and is required only when the digital-to-analog converter The sampling rate conversion can be done by an interpolating filter with impulse response h I (t), producing as output [19]   The SEM filter (not in the DVB-T standard [1]) is required only when the SEM has to be imposed at the baseband level. This filter also reduces the IF images caused by interpolation [19]. The number of taps depends on the required stopband attenuation and transition bandwidth, and should be low for real-time operation.

C++ DVB-T Modulator
The implemented C++ DVB-T modulator is structured with a modular design that makes the designed software easily embeddable into existing SDR frameworks.

Overview of the Iris Framework
The Iris SDR framework [25], developed by the Telecommunications Research Centre at TCD, is primarily employed to perform cognitive-radio experiments and enable dynamic spectrum access [26], so it is highly suitable for real-time signal processing operations. The Iris framework, written in C++, is intended to run on generalpurpose processors and can be configured to perform many different radio structures. A radio structure is built on basic blocks called components, which perform a particular process of the radio chain. A data buffer is positioned between adjacent components by the framework, thus allowing data to be exchanged between the components. Metadata are passed among components to specify particular information data, such as a time stamp or a data rate. The Iris framework has also the task to perform data safety, that is, one component cannot use data while another component is still producing them, and vice-versa. A useful feature of the Iris framework is its capability of parallelization of sequential tasks: as explained in Sec. 3.1, parallelization can be achieved by assigning group of components (whose tasks can proceed sequentially) to an engine, i.e., an Iris framework environment that has its own data buffers and can run in a thread separate from that of the other engines.
During a typical call to the Iris framework, the host application reads a configuration file and assembles a radio structure through the Iris application programmer interface (API). A component manager is accessed to select the requested components from a library of precompiled components that include the designed DVB-T software. All the selected components are then instantiated and executed by the radio engine, to perform the designed task.

Design of the C++ Code Structure
Each DVB-T basic building block has been assigned to a single serial task that runs inside a unique Iris component. This way, parallelization can be achieved by instantiating different components to separate engines. To achieve the highest degree of parallelization, we choose to fit every component inside its own engine: indeed, this design philosophy permits a pipeline-like execution of the instructions of consecutive engines, thereby minimizing the processing latencies. Hence, we discarded the alternative philosophy that fits all components inside a single engine: indeed, this way the DVB-T data flow would be executed serially and would introduce large latencies in the processing of consecutive data blocks, because the engine would have to wait for the end of the processing of the last component before reactivating the first component. To maximize the number of engines, we split the DVB-T modulator in 12 functional components, i.e., the 12 blocks of Fig. 1. Next, we separately designed each block, as explained in Sec. 3.3. As verified in Sec. 3.4, this design method enables real-time operation of the DVB-T modulator. Clearly, this highly parallel design increases the usage of computing resources, such as RAM and threads, with respect to a slower solution that uses a unique engine shared by all the components.

Design of the C++ Blocks
Every block is designed according to the Iris API in C++ language. Each block is instantiated as a single component in a derived base class of the Iris API specifications [25], thus inheriting all the methods needed for the proper management of that component. Component data processing methods are implemented as specified by the Iris API [25]. Thus, a generic component requests a data buffer to process, waiting in idle mode until input data are provided. The designed blocks are generally unable to request a particular number of input samples or data. All the blocks, except the scrambler and the SEM filter, have their own private internal data buffer, where multiple data input bursts can be stored, until a sufficient number of samples is collected in order to trigger the designed signal processing operation.
The C++ code of the first 10 blocks has been designed by translating the DVB-T standard specifications [1] into lines of code, avoiding the use of existing libraries: this way, we have maximum control of the specific operation of each block. The only exception to this general rule is the use of the FFTW library [27] inside the OFDM block, for maximum performance and portability. The interpolator and the SEM filter have been designed [19] assuming an Ettus USRP N210, whose sample frequency is f s,DAC = 100/n DAC MHz (n DAC is a positive integer). The designed SEM filter uses a Kaiser window with passband bandwidth W = (K + 1) f s,DVB-T /N FFT  7.6 MHz, transition bandwidths of 700 kHz, and stopband attenuation of 25 dB.

Validation of the C++ Code
The code has been validated using the automated testing provided within the Iris framework building step. The command cmake with ctest [28] automatically performs several tests on both code sanity and expected outputs. Concerning the code sanity tests, we performed the following validation actions: (a) smoke tests to verify that the code compiles and links correctly into an executable; (b) crash-proof tests to verify that the produced executable runs without crashes; (c) black-box tests to verify that the number and data types of inputs and outputs match the expected ones, without knowledge of the implementation of the block; (d) white-box tests to verify that the number and data types of inputs and outputs match the expected ones, with knowledge of the implementation of the block.
Concerning the tests on the expected outputs of the DVB-T modulator, we have compared the output data of the C++ modulator to a reference output, for a predefined set of input data. To obtain the reference outputs, we have implemented the first 10 blocks of Fig. 1 in a high-level interpreted language, i.e., MATLAB. For those blocks operating on fixed point data (i.e., the first seven blocks of Fig. 1), we required that the output data samples of the two different implementations (C++ design and MATLAB reference) are bit-by-bit equal. Differently, for those blocks operating on floating-point data (i.e., mapper, framer, and OFDM), we required that the output data samples of the two implementations have a maximum difference below a preselected tolerance. This tolerance depends on the expected quantization step Q, which in turn depends on the characteristics of the adopted DAC. For instance, assuming that the real and the imaginary parts of the signal are in the range [ 1,1]   , a DAC with N DAC = 14 bits gives Note that the last two optional blocks of the DVB-T modulator of Fig. 1 have not been implemented in MATLAB. Concerning the SEM filter output, Figure 2 shows the power spectrum density (PSD) of the generated DVB-T signal, at a carrier frequency f c = 666 MHz, using two Ettus USRP N210 (one as transmitter and another one as spectrum analyzer). Note the flat PSD in the passband and the total attenuation of 35 dB in the stopband. The spike at 671 MHz is generated by the local oscillator carrier, using a frequency offset for near-zero IF configuration (f IF = 5 MHz): this spike can be filtered out with an analog filter during the final amplification stage. If a final analog filter is absent (such as in USRP devices), this spike can be moved into the transition band to avoid adjacent channel interference (e.g., by using f IF = 3.9 MHz).
Summarizing, all the different tests performed for every block of the DVB-T modulator chain have been completely successful, including all the code sanity tests and all the expected output tests. In addition, we have also verified that the generated DVB-T signal, when transmitted in real time by an Ettus USRP (such as N210, B205, B210) in a laboratory environment, is correctly received by both commercial TV sets and USB dongles.

Time Performance
To enable real-time operation of the designed DVB-T modulator, every block should be able to achieve a processing speed higher than the speed (specified in [1]) required to perform the block task. Iris contains dedicated steps for the benchmarking of single processing components, which in our case coincide with the DVB-T blocks.
This benchmarking suite provides the speed of the block, to be compared with the time requirement. For every block, the maximum input data rate R st,max is constrained by [1] and by the input sample rate of the SDR device. For the USRP, we used f s,DAC = 10 MHz (f s,DAC = 12.5 MHz), which leads to R o = 35/32 (R o = 175/128) and to a SEM filter with 19 taps (23 taps). By comparing R st,max with the actual data rate R act measured by the suite, we obtain the speed-up factor F su = R act / R st,max of each block. We assume that real-time operation is possible when, for all the blocks, F su > 1.2, where the 20% margin accounts for additional latencies due to the data exchange among blocks (operated by the engines) and overall thread execution scheduling. Table 1 reports the achieved performance R act , the required maximum data rate R st,max , and the speed-up factor F su of all the blocks. The benchmarks are run on an Intel Core i7-3630QM CPU at 2.4 GHz with 8 GB DDR3 RAM and Ubuntu 16.04 OS, and the programs have been compiled with the GNU C++ compiler v. 5.4.0. Benchmarking is performed adopting input data of large size, thus minimizing the impact of the Iris engine overhead on data buffer management. All the speed-up factors are above the threshold value 1.2: in Tab. 1, the fastest blocks are the scrambler and the convolutional interleaver, while the slowest blocks are the SEM filter and the RS encoder. sider the different DVB-T parameters (number of carriers, CP length, modulation, and code rate) and the absence or presence of the optional blocks in Fig. 1, i.e., the interpolator and the SEM filter. The output of the last block in the chain (either the OFDM modulator or the SEM filter) has been forwarded to a virtual dummy load (the /dev/null device of the Ubuntu file system). In all cases, we obtained a typical speed-up factor of F su = 2.5 in the absence of interpolation and SEM filtering, and of F su = 1.8 in the presence of interpolation and SEM filtering. Since the obtained speed-up factors are greater than 1.2 in all cases, we assume that our C++ DVB-T software can work in real time without problems. This is confirmed by all the realtime experiments we have performed. Note that the speedup factors of Tab. 2 for the aggregate system are significantly lower than the speed-up factors of the slowest blocks in Tab. 1. This means that the latencies due to the data exchange among blocks and the thread execution scheduling times cannot be neglected.
When the software runs in real time, typically the overall CPU load is about 16%. Therefore, the remaining computational resources are sufficient for performing other tasks, such as retrieving or building the transport stream from a local disk, or receiving the transport stream by a remote network connection. The used memory typically amounts to roughly 100 MB and is almost constant for all the configurations. Such computational loads could allow a single modern CPU to run several instances of the DVB-T modulator in parallel, each one allocated to a different TV channel, with the only bottleneck consisting in the limited bandwidth of the communication channel used to convey the generated waveform samples towards the SDR devices.

Modulator
As explained in Sec. 3.4, the first 10 blocks of Fig. 1 have been implemented also in MATLAB, for the purpose of validation of the designed C++ blocks. These MATLAB scripts have been designed independently from the C++ blocks, starting from the DVB-T standard [1]. These scripts have been further validated by comparing their outputs with other MATLAB implementations, such as [23]. This comparison has revealed a minor typo in the RS encoder of [23] (the code generator polynomial in [1] is different from the MATLAB default one used in [23]).

Demodulation and Decoding
The block diagram of a DVB-T receiver is shown in Fig. 3. We assume that a previous subsystem has already detected the DVB-T operating parameters (OFDM mode, CP, and code rate) and has properly synchronized the received OFDM symbols, both in time and frequency. For instance, parameter detection and synchronization could be performed as in [19]. Thus, the MATLAB receiver removes the CP from the received signal, and subsequently performs the FFT. After the FFT processing, the noisy received signal R[k] on the k-th carrier can be expressed by where C[k] is the channel transfer function, S[k] is the data (or pilot, or TPS) signal, and W[k] is the additive white Gaussian noise (AWGN), on the k-th carrier, and k = 0, …, K -1 represents the active carrier index. Then, the data carrier samples are separated from the pilot carrier samples: the information conveyed by the pilot carriers is instrumental to estimate the channel transfer function C[k] on the k-th carrier, for equalization purposes. The channel estimator performs a least-squares interpolation based on the FFT, as in [2]. In practice, the estimated channel Ĉ[k] is a noisy copy of the real channel, as expressed by where W C [k] is the channel estimation error, mainly due to receiver AWGN. The data carriers are then equalized using the zero-forcing criterion, as where Y[k] is the noise-affected equalized constellation point and R[k] is the received constellation point expressed by (4). The equalized data form the basis for the estimation of the log-likelihood ratios (LLRs), which enable the softinput decoding of the convolutional code. These LLRs can be computed using different techniques: in our case, we have adopted a Log-max approximation [29], [30], to achieve a good trade-off between decoding accuracy and computational complexity. For the generic m-th bit carried by the k-th QAM symbol, the Log-max LLR Λ(b k,m ) is expressed as where S m 0 is the subset of constellation points where the m-th bit is 0, and S m 1 is the subset of constellation points where the m-th bit is 1.
The outputs of the LLR block are then forwarded to the symbol and bit deinterleavers, and then to the depuncturer. Depuncturing assigns a null value to the LLR of erased bits, such that the subsequent Viterbi decoder will not consider the contribution of erased bits in the computation of branch and path metrics. The Viterbi decoder uses soft inputs with block truncation, and should use a traceback length l TB several times larger than the code constraint length, in order to take into account the effects of punctured bits. The chosen Viterbi algorithm has a hard-decided output, thus the decoded bits are sent to the convolutional deinterleaver and to the RS decoder. The RS decoder pads with zeroes the input words and follows the usual decoding procedure (syndrome computation, error location, error evaluation, and error correction). The decoded message words are then descrambled and the original TS data are recovered. Figure 4 shows the results obtained by simulations on the AWGN and P1 channel [1], represented in terms of bit error rate (BER) after soft Viterbi decoding versus the carrier-to-noise ratio (C/N). The C/N is defined as     Rayleigh fading. We assume perfect channel knowledge, and soft Viterbi decoding with unquantized inputs and a trace-back length of l TB = 128.

Performance Results
According to [1], the performance should be measured at the quasi error-free (QEF) condition (not more than a single uncorrected error per hour). QEF corresponds to a BER after the RS decoder of 110 -11 , and to a BER after the Viterbi decoder of 210 -4 . Table 3 reports the values of C/N (in dB) for QEF, for different modulation sizes M and coding rates (CRs). The C/N values obtained using the MATLAB modulator and receiver are in good agreement with the C/N values provided by the DVB-T specifications [1]. Note that perfect agreement is virtually impossible, since the DVB-T specifications do not disclose all the decoding parameters, such as the trace-back length. Table 4 shows the BER after the Viterbi decoder, simulated at the QEF C/N value, for different DVB-T configurations and for different channels, such as AWGN, F1, and P1 [1]. The F1 multipath channel (static, line-of-sight) leads to Rice fading. Table 4 explains that the simulated BER is either close to the QEF BER of 210 -4 or lower, thus confirming that the decoding parameters have been selected properly.

Discussion
We discuss the impact of the proposed SDR DVB-T modulator, and we compare the proposed DVB-T software with DVB-T software designs available in the literature.

Impact
First, we explain the advantages of SDR-based DVB-T transmitters with respect to conventional DVB-T transmitters, and successively we list and discuss some useful applications of the proposed DVB-T software.
In the upcoming future, some TV channels located in the upper UHF band will be switched off, since that spectrum will be reallocated to cellular networks for extending their 4G (or upcoming 5G) services [31], [32]. This spectrum reallocation pushes the broadcasting players (operators and equipment companies) to move their technologies towards SDR-based ones. The reason for this change is twofold. First, the profitability of hardware-based broad-casting transmitters will be reduced, because there will be less market opportunities to catch. However, SDR transmitters, due to their easier re-programmability and lower development costs (at least in their digital segment), will allow to accommodate the market uncertainties. Second, broadcasting operators could use many low-power smallcoverage transmitters co-located with cellular network base stations, instead of using few high-power large-coverage transmitters. In this case, SDR systems can be shared between broadcasting and cellular technologies.
Our software can be used for different applications related to DVB-T, such as signal analysis, interference estimation, power resource allocation, coverage issues, and so on. For instance, the designed software permits a statistical evaluation of the peak-to-average power ratio of true DVB-T signal waveforms. As a second example, adjacent channel interference estimation can be performed too, to assess the coexistence with nearby DVB-T (or LTE) channels [33]. In addition, power allocation algorithms can be exploited without changing the DVB-T receiver. Another possibility is the investigation of the effect of impulsive noise [34], non-Gaussian channels, and quantization errors [35], on the DVB-T received signal. Furthermore, by means of our SDR-based design, the DVB-T signal can first be received by a custom DVB-T receiver and then retransmitted to a single destination by a regenerative relay, nearby to the receiver. Coverage issues may be investigated by incorporating the designed software into a transmitting device for trial experiments. The proposed software could be used also jointly with cognitive radio systems that try to exploit the TV white spaces: for instance, in [36], the authors introduce a spectrum-sensingbased system where HDTV signals received via a satellite link can be redistributed in home environments over unoccupied DVB-T channels, using a DVB-T transmitter. Obviously, this mentioned list of possible applications is only exemplificative and non-exhaustive.

Comparison with Other DVB-T Software
Herein we detail the main differences between the proposed DVB-T software and the existing literature. We focus on those DVB-T designs that are closely related to our proposed design: about C++, we consider the solutions proposed in [9] and [19]; with reference to MATLAB designs, we compare with [19] and [23].
With respect to the Soft-DVB in [9], there are four main differences. First, our C++ code is publicly available (at https://github.com/wishful-project/module_iris/tree/ master/dvb-tx-iris/components/gpp/phy). Second, [9] is based on GNU Radio, while our C++ code is based on the Iris framework, which requires less memory. Third, [9] employs a hybrid Python/C++ language, while our software uses the C++ language only. Fourth, [9] produces RF signals with 7 MHz channel bandwidth only (due to throughput limitations of the USB-based interface towards the USRP in [9]), while our software can employ different channel bandwidths, including the 8 MHz one. With re-spect to the C++ DVB-T in [19], there are two main differences. First, the C++ code of [19] is not publicly available. Second, the C++ code of [19] uses vectorization and multithreading, while the designed C++ code uses the intrinsic parallelization provided by the Iris framework. Therefore, although both transmitters work in real time, our non-parallelized C++ code is simpler and more easily understandable than [19]: this facilitates code modification and code reuse by other researchers.
With respect to the MATLAB DVB-T of [19], there are three main differences. First, the designed MATLAB code is publicly available (at https://github.com/wishfulproject/module_iris/tree/master/dvb-tx-iris/scripts/dvbt/ MATLAB). Second, the designed code also includes a validated DVB-T modulator and (F1 and P1) channel generation functions. Third, although [19] includes synchronization, the designed MATLAB code has some improved features not present in [19], such as LLR-based soft-output demapping and FFT-based channel estimation. With respect to the MATLAB DVB-T modulator of [23], there are two main differences. First, [23] does not include frame adaptation, and hence pilots and TPS are not included. Second, in [23], OFDM is not implemented.

Conclusion
We have proposed two software implementations of DVB-T, using C++ and MATLAB, publicly available under the GNU license. The generated DVB-T signal has been validated by the equivalence between C++ and MATLAB outputs and by the correct reception by TV sets and USB dongles. When incorporated into the Iris SDR framework, the C++ DVB-T modulator works in real time. The proposed code can be useful for many applications and can be easily modified. Future work could include DVB-T2 [37], DVB-T2-Lite [38], and DVB-C2 [39].