Page 1 of 2

ETSI EN 300 744 compliant DVB-T transmitter

Posted: Wed Nov 13, 2013 6:48 am
by MaxX
Since I've managed to get a working ETSI compliant DVB-T transmitter
solution using the bladeRF I thought I'd share my experience.

There are three parts needed to get this to work:

Bitstream:

First one is creating a compliant MPEG-TS with a constant bitrate, even though
the bitrate of the actual contant varies. For this part I've used libav [1].

Example:

Code: Select all

avconv -i somevideofile.avi \
	-bufsize:v 1.4M \
	-c:v libx264 \
	-b:v 2500000 \
	-maxrate:v 3200000 \
	-c:a aac \
	-b:a 128k \
	-f mpegts \
	-bsf h264_mp4toannexb \
	-threads 4 \
	-muxrate 3732353 \
	-metadata service_provider="TV Labs" \
	-metadata service_name="Some Channel" \
	-
The important parameters are:

-muxrate
Which should exactly match what the DVB-T encoder says is the
useful data rate. To get this information you should set up the
modulation parameters for the modulator (read on!) [2] and retrieve
the information from it's output:
...
Useful throughput : 3.732353 Mbps
...
-maxrate:v
This defines the maximum bitrate the stream should have. It should be
lower than -maxrate to leave some space for TS overhead and the audio
part. -b:v defines the nominal bitrate.

-
Instead of passing a file name as output just send it to stdout.

-bsf h264_mp4toannexb
This is only needed if you like to transmit h264 instead of MPEG2
video.

You can also mux multiple video streams together in one TS, just google around
how to do that (-map is the key there). Live streaming from webcams is also
very possible and very easy to do.

Modulation:

The second part is, of course, the preparation of the bitstream and
modulation, resulting in I/Q samples useful to the bladeRF. There is a
software package to do exactly this called gbDVB [2]. Unfortunately it's not
open source but it's free, fast and there are binaries for many platforms.

Example:

Code: Select all

./dvbtenco \
	-i stdin \
	-d t \
	-m 8k \
	-M 4 \
	-b 6 \
	-p 1/2 \
	-D 1/4 \
	-o stdout >bbt.fifo
For dvbtenco the important stuff is:

-i stdin
Reads the MPEG-TS from stdin instead of a file. You could also use
named pipes (mkfifo) if you like without this option.

-o stdout >bbt.fifo
I tried passing the fifo directly as output filename but it just
didn't work. Like this you output the samples to stdout and pipe it
into the fifo afterwards.

-d t
Output time domain samples, very, very important.

The rest of the parameters are modulation specific. To get a grasp on them
wikipedia is a good source for information. This example implements the
lowest, but most robust setting I was still able to receive with all of my
cheap USB DVB-T sticks.

Output

The third and last one is the output stage. Gnuradio [3] is being used for
that with just a very simple flowgraph.

Image

As with the muxrate for avconv you should, again, look at the output from
dvbtenco to get the exact sample rate needed in your case:
...
Output sampling rate : 6.857143 Msps
...
Since the samples produced by dvbtenco are not normalized the gain needs to be set
up properly, just try increasing until bit errors start to accumulate at the receiver
and/or watch the spectrum with another bladeRF or whatever. You can also use a
Scope Plot and check that the I/Q components never go above 1.0. This value changes
with the modulation parameters.

Putting everything together:

Code: Select all

avconv -i ... - | ./dvbtenco -i stdin ... -o stdout >bbt.fifo
When this is set up you can start the gnuradio flow graph or start it upfront
and the encoding+modulation afterwards. The second ordering is needed for live
streaming from capture devices.

Results:

I played a lot with this setup and I managed to get it to work from 3.7Mbps up
to 32Mbps. Also it's possible to transmit 1080p as h264, not just SD in MPEG2.
on the lowest setting the range was impressive and the system
extremely robust.
But not everything is happy sunshine because there are still some quirks I cannot
explain, like the receiver loosing it's lock from one moment to the next but
resycing minutes later. On another machine than the Core-i7 at work those
quirks are much worse, even though there should be by far enough horsepower.
Maybe it's some timing issue connected to power management like dynamic
frequency scaling or dynamic ticks. After turning off DFS stability was
increased a lot.

Have fun :D
Jan

[1] https://libav.org/
[2] http://dsplab.diei.unipg.it/software/gbdvb
[3] http://gnuradio.org/

Re: ETSI EN 300 744 compliant DVB-T transmitter

Posted: Thu Nov 14, 2013 12:47 am
by drmpeg
Wow, very cool stuff. As for your glitches, you may be having trouble with the libav TS muxer. There's a good chance it's not very compliant.

As it turns out, I work in the video compression industry and can properly multiplex TS files. I've uploaded a short (1:45) 1920x1080@29.97 fps MPEG-2 clip that you can test with.

http://www.w6rz.net/advtimedvb.ts

It's muxed exactly at 13.572192 Mbps, which is the TS rate for 16QAM, 3/4 code rate and 1/32 guard interval in a 6 MHz channel.

If you need a longer clip or other TS bitrates, let me know.

Ron

Re: ETSI EN 300 744 compliant DVB-T transmitter

Posted: Thu Nov 14, 2013 12:57 am
by drmpeg
I've also played wih the gbdvb software. Here's an FFT plot of the samples from dvbtenco (scaled by 100). This is just file based, not transmitted over the air.

Image

Ron

Re: ETSI EN 300 744 compliant DVB-T transmitter

Posted: Sat Nov 16, 2013 9:46 am
by MaxX
drmpeg wrote:Wow, very cool stuff. As for your glitches, you may be having trouble with the libav TS muxer. There's a good chance it's not very compliant.

As it turns out, I work in the video compression industry and can properly multiplex TS files. I've uploaded a short (1:45) 1920x1080@29.97 fps MPEG-2 clip that you can test with.

http://www.w6rz.net/advtimedvb.ts

It's muxed exactly at 13.572192 Mbps, which is the TS rate for 16QAM, 3/4 code rate and 1/32 guard interval in a 6 MHz channel.

If you need a longer clip or other TS bitrates, let me know.

Ron
Thank you for your TS, I've used it for tracking down the issues I had. The TS isn't the reason though, it's actually much more simple than that. By increasing the buffering in the osmocom sink all the glitches vanished.

Code: Select all

Device arguments: bladerf=0,buffers=128,buflen=65536
My guess is that even small drops lead to shifts in phase and that receivers can't adapt when this happens too sudden.

Jan

Re: ETSI EN 300 744 compliant DVB-T transmitter

Posted: Sat Nov 16, 2013 8:31 pm
by drmpeg
Excellent! Since you're probably using a software decoder with the DVB-T stick, the libav TS muxer is adequate. If you try to stream to a hardware decoder (set-top box, TV with built-in tuner, etc.), it may be less so.

The author of gbdvb recommends this TS muxer.

http://www.avalpa.com/the-key-values/15 ... opencaster

I haven't tried it, but it does seem full featured.

It's too bad gbdvb is not open source. In the higher bitrate modes, it's right around 1x real-time on my Linux box (Intel E5-1607 cpu). Clearly a candidate for multi-threading.

Ron

Re: ETSI EN 300 744 compliant DVB-T transmitter

Posted: Sat Jan 11, 2014 9:19 pm
by drmpeg
Bogdan Diaconescu YO3IIU has just updated his open source DVB-T implementation to GnuRadio 3.7.2.1 at https://github.com/BogdanDIA/gr-dvbt. It builds (I had to add -DCMAKE_C_FLAGS=-mavx to the cmake command line) and the transmitter GRC flowgraph seems to work. I can't test it since I don't have a DVB-T receiver or dongle.

http://yo3iiu.ro/blog/?p=1191

Ron

Re: ETSI EN 300 744 compliant DVB-T transmitter

Posted: Sun Jan 12, 2014 6:18 pm
by drmpeg
To minimize CPU usage, here's a stand alone Python program to run the gr-dvbt transmitter.

EDIT: See http://nuand.com/forums/viewtopic.php?f ... 5125#p5125 for latest.

Ron

Re: ETSI EN 300 744 compliant DVB-T transmitter

Posted: Wed Jan 15, 2014 1:13 am
by drmpeg
Test bitstreams (all have the same content, 1920x1080@29.97 fps video and 448 kbps AC3 audio):

QAM16
8 MHz

http://www.w6rz.net/adv8dvbt12.ts /* 1/2 Viterbi rate 12.064171 Mbps TS rate */
http://www.w6rz.net/adv8dvbt23.ts /* 2/3 Viterbi rate 16.085561 Mbps TS rate */
http://www.w6rz.net/adv8dvbt34.ts /* 3/4 Viterbi rate 18.096256 Mbps TS rate */
http://www.w6rz.net/adv8dvbt56.ts /* 5/6 Viterbi rate 20.106951 Mbps TS rate */
http://www.w6rz.net/adv8dvbt78.ts /* 7/8 Viterbi rate 21.112299 Mbps TS rate */

7 MHz

http://www.w6rz.net/adv7dvbt23.ts /* 2/3 Viterbi rate 14.074866 Mbps TS rate */
http://www.w6rz.net/adv7dvbt34.ts /* 3/4 Viterbi rate 15.834224 Mbps TS rate */
http://www.w6rz.net/adv7dvbt56.ts /* 5/6 Viterbi rate 17.593582 Mbps TS rate */
http://www.w6rz.net/adv7dvbt78.ts /* 7/8 Viterbi rate 18.473262 Mbps TS rate */

6 MHz

http://www.w6rz.net/adv6dvbt23.ts /* 2/3 Viterbi rate 12.064171 Mbps TS rate */
http://www.w6rz.net/adv6dvbt34.ts /* 3/4 Viterbi rate 13.572192 Mbps TS rate */
http://www.w6rz.net/adv6dvbt56.ts /* 5/6 Viterbi rate 15.080213 Mbps TS rate */
http://www.w6rz.net/adv6dvbt78.ts /* 7/8 Viterbi rate 15.834224 Mbps TS rate */

QAM64
8 MHz

http://www.w6rz.net/adv8dvbt12qam64.ts /* 1/2 Viterbi rate 18.096256 Mbps TS rate */
http://www.w6rz.net/adv8dvbt23qam64.ts /* 2/3 Viterbi rate 24.128342 Mbps TS rate */
http://www.w6rz.net/adv8dvbt34qam64.ts /* 3/4 Viterbi rate 27.144385 Mbps TS rate */
http://www.w6rz.net/adv8dvbt56qam64.ts /* 5/6 Viterbi rate 30.160427 Mbps TS rate */
http://www.w6rz.net/adv8dvbt78qam64.ts /* 7/8 Viterbi rate 31.668449 Mbps TS rate */

7 MHz

http://www.w6rz.net/adv7dvbt12qam64.ts /* 1/2 Viterbi rate 15.834224 Mbps TS rate */
http://www.w6rz.net/adv7dvbt23qam64.ts /* 2/3 Viterbi rate 21.112299 Mbps TS rate */
http://www.w6rz.net/adv7dvbt34qam64.ts /* 3/4 Viterbi rate 23.751336 Mbps TS rate */
http://www.w6rz.net/adv7dvbt56qam64.ts /* 5/6 Viterbi rate 26.390374 Mbps TS rate */
http://www.w6rz.net/adv7dvbt78qam64.ts /* 7/8 Viterbi rate 27.709893 Mbps TS rate */

6 MHz

http://www.w6rz.net/adv6dvbt12qam64.ts /* 1/2 Viterbi rate 13.572192 Mbps TS rate */
http://www.w6rz.net/adv6dvbt23qam64.ts /* 2/3 Viterbi rate 18.096256 Mbps TS rate */
http://www.w6rz.net/adv6dvbt34qam64.ts /* 3/4 Viterbi rate 20.358288 Mbps TS rate */
http://www.w6rz.net/adv6dvbt56qam64.ts /* 5/6 Viterbi rate 22.620320 Mbps TS rate */
http://www.w6rz.net/adv6dvbt78qam64.ts /* 7/8 Viterbi rate 23.751336 Mbps TS rate */

Ron

Re: ETSI EN 300 744 compliant DVB-T transmitter

Posted: Wed Jan 15, 2014 1:37 am
by drmpeg
Of course, a little code can be used to make changing Viterbi rate, constellation, mode and channel size easier.

Viterbi code rate options:

Code: Select all

    dvbt.C1_2        /* 1/2 rate */
    dvbt.C2_3        /* 2/3 rate */
    dvbt.C3_4        /* 3/4 rate */
    dvbt.C5_6        /* 5/6 rate */
    dvbt.C7_8        /* 7/8 rate */
constellation options:

Code: Select all

    dvbt.QPSK
    dvbt.QAM16
    dvbt.QAM64
mode options:

Code: Select all

    dvbt.T2k
    dvbt.T8k
guard interval options:

Code: Select all

    dvbt.G1_32      /* 1/32 */
    dvbt.G1_16      /* 1/16 */
    dvbt.G1_8       /* 1/8 */
    dvbt.G1_4       /* 1/4 */
EDIT(Jan 16): QAM64, QPSK and 8K carrier mode is now working. I've also added LMS6002D filter selection based on channel size.
EDIT(Jan 28): Change symbol_rate to float now that fractional sample rates are supported.
EDIT(Mar 2): Add guard interval selection and move to Github.

https://github.com/drmpeg/dtv-utils/blo ... t-blade.py

Ron

Re: ETSI EN 300 744 compliant DVB-T transmitter

Posted: Thu Jan 16, 2014 4:49 am
by dk5ras
gr-dvbt does not build here. "SSE instruction set not enabled". cat /proc/cpuinfo gives me among many others the flag "sse", so there should be no problem?!

Ralph.

Re: ETSI EN 300 744 compliant DVB-T transmitter

Posted: Fri Jan 17, 2014 1:29 am
by dk5ras
drmpeg wrote:Bogdan Diaconescu YO3IIU has just updated his open source DVB-T implementation to GnuRadio 3.7.2.1 at https://github.com/BogdanDIA/gr-dvbt. It builds (I had to add -DCMAKE_C_FLAGS=-mavx to the cmake command line) and the transmitter GRC flowgraph seems to work. I can't test it since I don't have a DVB-T receiver or dongle.

http://yo3iiu.ro/blog/?p=1191

Ron
"cmake .. -DCMAKE_C_FLAGS=-mavx" was the solution to my build problems with the SSE error. Ron pointed me into the right direction, thanks a lot, just wanted to mention it once again here, to make the relation between the SSE error and the cmake option :) Maybe I am not the only one who steps into this trap...

Ralph.

Re: ETSI EN 300 744 compliant DVB-T transmitter

Posted: Mon Jan 20, 2014 12:12 am
by dk5ras
Just as an update, the gr-dvbt flowgraph runs just fine, and the spectrum analyzer in gnuradio shows a neat spectrum mask as expected - but the bladeRF only spits out some warbling spectrum, and when listening into the frequency with an AM receiver I hear some warbling sounds. Well, for sure some config issue or thelike, guess I will find it out.

Re: ETSI EN 300 744 compliant DVB-T transmitter

Posted: Mon Jan 20, 2014 9:19 am
by drmpeg
For bladeRF, the dvbt_tx_demo.grc flowgraph needs to be changed a little. The rational resampler is not needed (it was put in for the Ettus USRP N210), since the sampling frequency of bladeRF can be set to any number. And of course, the bladeRF osmocom Sink needs to be added.

In Germany, the DVB-T channels are 8 MHz wide, so the bladeRF sampling rate needs to be set to 64000000 / 7 or 9.142857 Msps.

Here's a pic of the modified graph.

Image

Ron

Re: ETSI EN 300 744 compliant DVB-T transmitter

Posted: Sun Mar 02, 2014 8:06 am
by argilo
I've written a blog post about transmitting DVB-T on the amateur bands, and how to receive it using an RTL-SDR dongle:

http://www.irrational.net/2014/03/02/digital-atv/

Re: ETSI EN 300 744 compliant DVB-T transmitter

Posted: Sun Mar 31, 2019 11:40 pm
by tara
I played a great deal with this setup and I figured out how to get it to function from 3.7Mbps up

to 32Mbps. Additionally it's conceivable to transmit 1080p as h264, not only SD in MPEG2.

on the most reduced setting the range was noteworthy and the framework

incredibly vigorous.

In any case, not all things are upbeat daylight on the grounds that there are still a few characteristics I can't

clarify, similar to the recipient loosing it's lock starting with one minute then onto the next however

resycing minutes after the fact. On another machine than the Center i7 at work those

eccentricities are much more terrible, despite the fact that there ought to be by a wide margin enough strength.

Possibly it's some planning issue associated with power the executives like dynamic

recurrence scaling or dynamic ticks. In the wake of killing DFS steadiness was

expanded a great deal.