Digital amateur TV on 70cm, 33cm and 23cm

I love my BladeRF! It’s a very versatile SDR transceiver, and I’ve used it to receive and transmit all sorts of signals. Most recently I got it transmitting DVB-T digital television signals on the amateur radio bands, with my trusty NooElec TV28T serving as the receiver. (It is a TV tuner, after all, so why not use it as one for once?) In this post, I’ll show you how to replicate what I’ve done.

First off, you’ll need two laptops running Linux: one to transmit, and one to receive. The transmit laptop needs to have the latest version of GNU Radio installed. If you’re running Ubuntu, the easiest way to get that done is to use OZ9AEC’s package archive. At a command prompt, run the following:

sudo add-apt-repository ppa:gqrx/snapshots
sudo apt-get install gnuradio gnuradio-dev gqrx libboost-all-dev libcppunit-dev swig liblog4cpp5-dev

Once that’s done, you’ll need to install YO3IIU’s DVB-T package for GNU Radio:

git clone https://github.com/BogdanDIA/gr-dvbt.git
cd gr-dvbt
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr ../
make
sudo make install
sudo ldconfig
cd ..

Next, grab my collection of SDR examples:

git clone https://github.com/argilo/sdr-examples.git

Included in that collection is dvbt-blade.py, a script written by W6RZ that lets you transmit DVB-T from the command line using a BladeRF. Since amateur stations typically operate at much lower power than commercial broadcasters, I’ve modified it to use the lowest available bit rate, which should maximize the distance at which the signal can be received. (If you want to experiment with higher bit rates, you can change the “channel_mhz”, “mode”, “code_rate”, “constellation” and “guard_interval” variables. You’ll also need to adjust the mux rate of your transport stream, which can be calculated using W6RZ’s dvbrate.c.) The script is configured to transmit at a centre frequency of 441 MHz, so be sure to attach a suitable 70cm antenna to your BladeRF’s TX port before transmitting.

The script expects to be given an MPEG transport stream as input. Fortunately, we can produce one in real time using avconv. It can record video from the laptop’s webcam and audio from the laptop’s microphone, and encode them into a suitable transport stream. To let avconv and dvbt-blade.py talk to each other, we’ll create a fifo:

mkfifo in.fifo

Then we launch dvbt-blade.py and tell it to read from the fifo:

sdr-examples/dvbt-blade.py in.fifo

You’ll see some output, but nothing will be transmitted yet because no data is arriving in the fifo. To fix that, open a second terminal window and run avconv like so. Be sure to replace XXXXXX with your own call sign, which will be displayed in the lower right corner of the video.

avconv -f alsa -i pulse -f video4linux2 -s 640x480 -i /dev/video0 -vf drawtext=fontfile=/usr/share/fonts/truetype/freefont/FreeSerif.ttf:text="XXXXXX":x=440:y=420:fontsize=48:fontcolor=white@0.6:box=1:boxcolor=black@0.2 -vcodec mpeg2video -s 640x480 -r 60 -b 4000000 -acodec mp2 -ar 48000 -ab 192000 -ac 2 -muxrate 4524064 -mpegts_transport_stream_id 1025 -mpegts_service_id 1 -mpegts_pmt_start_pid 0x1020 -mpegts_start_pid 0x0121 -f mpegts -y in.fifo

You may need to install additional packages so that avconv has access to all the codecs it needs. If all goes well, your two terminal windows should look like this:

dvbt-tx-script
dvbt-tx-avconv

Now, over to the receiving laptop, which will use an RTL-SDR dongle to pick up the signal. Since support for the RTL2832 chip was only recently added to the Linux kernel, you’ll want to be running a recent Linux distribution such as Ubuntu 13.10. Make sure you have vlc installed:

sudo apt-get install vlc

Then launch vlc like so:

vlc dvb://frequency=441000000:bandwidth=6

If all goes well, you’ll see your video and hear your audio!

dvbt-tx-ve3irr

Now that you’ve succeeded on the 70cm band, you may want to try this on the 33cm and 23cm bands as well. Unfortunately, the Linux drivers for the RTL-SDR dongle currently limit its maximum frequency to 862 MHz, a bit below the 33cm band. Until the drivers get updated (I’ve already submitted a patch request), you can work around the problem by patching the kernel modules on your receiving laptop using the dvb-freq-fix.py script in my sdr-examples repository:

sudo sdr-examples/dvb-freq-fix.py

If everything worked correctly, the script should print out “Success!” twice. If you saw that, then reboot, and you should now be able to tune all the way up to 1750 MHz. On the transmitting laptop, change the “center_freq” variable to 913000000 for 33cm or 1279000000 for 23cm, put an appropriate antenna on your BladeRF’s TX port, and fire up dvbt-blade.py and avconv again. On the receiving laptop, fire up vlc again, putting the appropriate value in for the “frequency” parameter.

In my experiments, I found that the BladeRF put out the most power on the 33cm band. I was able to receive the signal all around the house, using a rubber duck 33cm antenna on the BladeRF and the RTL-SDR dongle’s stock antenna. I’ve had a QSO with VA3DGN on 70cm. To get the signal beyond my house, I hooked the BladeRF up to a Down East Microwave 70cm 25 watt power amplifier.

Have fun with DVB-T! I’d love to hear back if you make any contacts.

This entry was posted in Uncategorized. Bookmark the permalink.

19 Responses to Digital amateur TV on 70cm, 33cm and 23cm

  1. drew wollin says:

    Hi. I like your work. I will try to see if I can do it with my BladeRF. I have a DATV-Express, but early days, still waiting for right capture card. I use Hides DAB-T dongles. Very good at minimal cost. They even have a repeater with ID. I just got one of the self-contained camera-modulator, DC-100, going yesterday. Full HD video and SD video in one stream. Able to use good lens. Regards Drew

    • argilo says:

      Thanks for letting me know about that other equipment.

      One thing I can’t do (yet) is HD video. At the moment I’m recording at 640×480, but if I push the resolution higher then my frame rate drops way down, presumably because the software MPEG 2 encoder can’t keep up. A hardware encoder would help.

      • Great info; I’m just working on a gnuradio block for the DATV Express board and this will be great for testing.

        Regarding HD, try a Logitech C920 (not 930). It gives fixed bitrate H.264 encoded by the camera. I don’t know if avconv supports H.264 mode in UVC, but gstreamer 1.2 does very well, see this recent post for an example.

        • argilo says:

          Thanks for the tip! As it happens, a local store has that model on sale, so I might pick one up. Now if only there was one that did MPEG2 as well…

  2. Pingback: Transmitting DVB-T with the BladeRF and Receiving it on an RTL-SDR - rtl-sdr.com

  3. Kameron Larsen says:

    I’m trying to get this working on my system. I’m able to get to the point where it looks like it’s successfully transmitting. In fact, I can run an FFT using the rtl-sdr dongle and see the signal. But vlc just doesn’t display anything. Any thoughts on why?

    • argilo says:

      What is your CPU usage like? It could be that your machine isn’t fast enough to handle MPEG 2 encoding and DVB-T modulation. The Core i5-2520M CPU in my laptop manages it with about 45% utilization.

      • Kameron Larsen says:

        Its about 30%. I’m running on a Core i7-920 @ 2.67GHz. And when I start VLC it doesn’t go up much more.

      • Kameron Larsen says:

        As a side note, I’m using ffmpeg as opposed to avconv. Could that be the issue?

        • argilo says:

          I suppose there could be some difference in the command line options or MPEG 2 transport stream output of ffmpeg vs. the version of avconv I’m using. (I’m using the version that comes with Ubuntu 12.04 LTS.)

          Do your two console windows show identical output to what I’ve shown in my screenshots?

        • argilo says:

          Also, are you running a new enough kernel that it has support for your RTL-SDR dongle to run in DVB-T mode? I believe support was only added last year. The laptop I was using as a receiver was running Xubuntu 13.10.

  4. Adam says:

    Larsen, you can not watch any tv on the VLC or just the the amateur DVB-T ?

    I run the VLC on the small Atom and Win7 without any problems:

    https://www.youtube.com/watch?v=26IrTFR_G74

    Take care about the frequency you are inserting, it is in the KHz.
    I can tune the 70cm and 23cm DVB-T with no problems.

  5. Sergey says:

    What about latency of this solution?

    • argilo says:

      I haven’t measured it exactly, but the total latency including the receiver appears to be around 1.5 seconds.

  6. Sergey says:

    Thank you for fast answer.
    It’s very bad for my idea – DVB-T SDR transmitter for FPV ((
    Can you test only transmitter latency? May be on DVB-T TV?
    Maybe MPEG2 software encoding adding latency? Can you test it at webcam with hardware encoding?

    • argilo says:

      Since I’m using this to contact other amateur radio stations, latency isn’t much of an issue for me, and I haven’t bothered to track down where the latency is coming from. My guess would be that the biggest contribution is coming from the software MPEG2 encoder. Perhaps avconv has some settings that would improve the latency.

      Unfortunately, I don’t have a webcam with a hardware encoder, nor do I have a television with a DVB-T tuner. I do have a television with an ATSC and QAM tuner, and the latency seems to be about the same using those modes, which suggests that vlc is at least not performing significantly worse than a television set.

      I’ll post an update if I learn anything more about the latency.

  7. sam says:

    Hi Argilo,

    Thanks for your excellent work on BladeRF, now i do the same things on my USRP device, but i have a question confuse me in configing the mpeg2ts encoder bit rate.

    question about the sink(USRP) rate and source(mpeg2ts clip file or mpeg2ts encoder output) rate adaptation;

    the sink(USRP) effective bit rate is: (assumption that 2K mode, QAM64, CP 1/32, conv rate 7/8)

    (10MSPS * 64/70 / (1+1/32) ) * (1512/2048) * (log64/log2) * (7/8 ) * (188/204) = 31.67 Mbps
    (interpolation) (cyclic prefix) (data sub-carrier of 2K) (QAM64) (convolution rate) (RS encode)

    it means that the USRP would pull 31.67 Mbit per second from the source, but what if the source rate is 4Mbps, 5Mbps …etc. that
    shoud be need to do rate adaptation between the source and sink, but i did’n saw any block like that exist in the GNURADIO dvbt transmit graph.
    is that some where i misunderstood, pls point me out, thaks :-)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>