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
cd gr-dvbt
mkdir build
cd build
sudo make install
sudo ldconfig
cd ..

Next, grab my collection of SDR examples:

git clone

Included in that collection is, 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 talk to each other, we’ll create a fifo:

mkfifo in.fifo

Then we launch and tell it to read from the fifo:

sdr-examples/ 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:


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!


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 script in my sdr-examples repository:

sudo sdr-examples/

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 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.

35 thoughts on “Digital amateur TV on 70cm, 33cm and 23cm”

  1. 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

    1. 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.

      1. 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.

        1. 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. I tried DVB-T transmission using BladeRf with RTL receiver as suggested by you in th web page. I am able to run avconv and in two terminals.

        But i get problem when I say vlc dvb://frequency=441000000:bandwidth=6.

        It is reporting an error saying

        Your input can’t be opened:
        VLC is unable to open the MRL ‘dvb://frequency=441000000:bandwidth=6’. Check the log for details.

        VLC media player 2.2.2 Weatherwax (revision 2.2.2-0-g6259d80)
        [000000000067b148] core libvlc: Running vlc with the default interface. Use ‘cvlc’ to use vlc without interface.
        [00007f0414000e88] dtv access error: cannot access adapter 0: No such file or directory
        [00007f04180009b8] core input error: open of `dvb://frequency=441000000:bandwidth=6′ failed
        QObject::~QObject: Timers cannot be stopped from another thread

        Please help me to rectify this problem. I am struggling for past four days in this experiment.

  2. 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?

    1. 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.

      1. 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.

        1. 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?

        2. 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.

  3. 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?

    1. 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.

  4. 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 🙂

  5. Hi argilo ,

    i just receive my ettus b200 board, when i inspect the and, i found that bladerf use fifo file(in.fifo) as mpeg-ts source, but use a tcp socket( as mpeg-ts source, how can i feed the /dev/video0->convert to mpeg-ts stream to this tcp socket? thanks.

  6. Hi Argilo,

    Hope you everything goes well. Sorry for bother you again. in the, there is a block call blocks_multiply_const_vxx, is it be use to constraint the IFFT output vaule to the DAC dynamic range? and how it’s valule 0.0022097087*2.5 compute/come from? I guess that multiply with 0.0022097087*2.5 is used to constraint the ifft output value range to [-1, 1], and then use the uhd/convert to convert this float32 to sc16 by multiply the scale factor 2^15-1 = 32767, witch match to the 16bit DAC dynamic range. in other to prove my guess, i compose the matlab script below, and find that ifft output value’s real/image is no larger than 0.11(QPSK constellation), so 0.11 * 0.0022097087*2.5 = 0.000060767, this multiple result is more less than 1, but not approximate to 1. is there something wrong i have made in this guess?

    %constraint the ofdm output to [-1.0, 1.0]
    %then (sign short)(constrainted output * 32767) ->otw -> duc -> DAC

    %QPSK for example
    REAL_MAX = 1;
    IMAGE_MAX = 1;
    SUB_CARRIER = 2048;

    reality = randi([0, REAL_MAX], SUB_CARRIER, 1);
    image = randi([0, IMAGE_MAX], SUB_CARRIER, 1);

    reality = 2 * (reality – (REAL_MAX/2.0));
    image = 2 * (image – (IMAGE_MAX/2.0));

    complex = reality + j * image;
    fcomponent = ifft(complex);

    fcomponent_real = real(fcomponent);
    fcomponent_image = imag(fcomponent);

    [fcomponent_image_max, fcomponent_image_index] = max(fcomponent_image);
    [fcomponent_real_max, fcomponent_real_index] = max(fcomponent_real);

    %fcomponent_real_max < 0.11
    %fcomponent_image_max < 0.11

  7. Hi Clayton. I love your work, I wish I could still program, the last time was 30 years ago in Fortran! I would like to pose a challenge for you, 4K UHD, DATV TX on the BladeRF. From what I have read, it could be difficult, but possible. I briefly describe how I achieved my goal of Full HD DATV live, using multiple digital cameras (HDMI and SDI): I then ponder the possibility of 4K: The device supplier I use, Hides and ITE are working dedicated chips, for 4K for release next year. I have a BladeRF and wonder if it can do 4k TX and RX on multiple bands. Other suppliers of DAB-T TX use similar FPGA systems. Very challenging? Regards Drew VK4ZXI

  8. Hi argilo,

    First, thanks for you work !
    I have to try to transmit at a center frequency of 177 MHz but with a BladeRF i can’t.
    So I tried with a HackRF One with the script : dvbt-hackRF to transmit a file .ts but i got some errors.

    ” Traceback (most recent call last):
    File “./”, line 123, in
    File “:/”, line 31, in main
    port = int(args[0])
    ValueError invalid literal for int() with base 10: ‘video.ts’

    I think I have to type a number port but i don’t know which one. Do you know how to fix it, please ? Or maybe is there an other way to transmit at 177 MHz ?



  9. Hi Clayton ! I have tried to convert your experiment into a GRC flowgraph, but I haven’t been successful. A few hints / tips from you could prove invaluable to me..



  10. Hi I followed your instructions and everything seems to be working great on the transmitting machine, however the issue is with getting vlc to work. This line:

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

    gives me the error:

    [00007f4ddc000ff0] dtv access error: cannot access adapter 0: No such file or directory
    [00007f4df4000950] core input error: open of `dvb://frequency=441000000:bandwidth=6' failed

    when I plug my sdr in, I get:

    [56346.317362] usb 3-1: new high-speed USB device number 14 using xhci_hcd
    [56346.513920] usb 3-1: New USB device found, idVendor=0bda, idProduct=2838
    [56346.513932] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [56346.513937] usb 3-1: Product: RTL2838UHIDIR
    [56346.513942] usb 3-1: Manufacturer: Realtek
    [56346.513946] usb 3-1: SerialNumber: 00000001
    [56381.320921] usb 3-1: USB disconnect, device number 14
    [56388.083462] usb 3-1: new high-speed USB device number 15 using xhci_hcd
    [56388.279926] usb 3-1: New USB device found, idVendor=0bda, idProduct=2838
    [56388.279936] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [56388.279941] usb 3-1: Product: RTL2838UHIDIR
    [56388.279945] usb 3-1: Manufacturer: Realtek
    [56388.279948] usb 3-1: SerialNumber: 00000001

    in dmesg, and GQRX works with it, so I dont think thats the problem, I think the problem is it doesnt recognise its a dvb device. Any tips?


  11. Hi, I tried to get this to work using the standard GNU Radio distribution for Ubuntu, since I think the DVB-T block was added to the standard distribution. It failed on “import dvbt” when I tried to run or

    Any hints on where to get the missing dvbt module from?

Leave a Reply

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