ETSI EN 300 744 compliant DVB-T transmitter
Posted: Wed Nov 13, 2013 6:48 am
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:
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:
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:
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.
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:
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:
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
Jan
[1] https://libav.org/
[2] http://dsplab.diei.unipg.it/software/gbdvb
[3] http://gnuradio.org/
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" \
-
-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:
-maxrate:v...
Useful throughput : 3.732353 Mbps
...
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
-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.
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:
Since the samples produced by dvbtenco are not normalized the gain needs to be set...
Output sampling rate : 6.857143 Msps
...
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
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
Jan
[1] https://libav.org/
[2] http://dsplab.diei.unipg.it/software/gbdvb
[3] http://gnuradio.org/
Maybe I am not the only one who steps into this trap... 