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:

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.

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

Post navigation

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

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

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.

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?

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?

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.

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?

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.

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

The -muxrate parameter of avconv controls the bit rate of the MPEG transport stream. It causes avconv to add as many null packets as necessary to bring you up to that rate. This program can be used to compute the exact muxrate you need: https://github.com/drmpeg/dtv-utils/blob/master/dvbtrate.c

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

Hope you everything goes well. Sorry for bother you again. in the dvbt-bladerf.py， 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?

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): http://vk4zxi.blogspot.com.au/2014/11/my-journey-in-datv-and-future-4k-uhd.html. I then ponder the possibility of 4K: http://vk4zxi.blogspot.com.au/2014/11/achieving-4k-uhd-datv.html. 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