# Video transmission between ATV and SSTV

I'd like to experiment with amateur video transmission in a setup halfway between ATV and SSTV. 480 lines of B&W image would be sufficient with 10 FPS, and I'm interested in both digital and analog methods.

I'd prefer if I wouldn't have to buy new hardware, I was thinking about using my HackRF as a transmitter and my RTL-SDR stick as the receiver, but that'd probably require building (buying?) an appropriate amplifier for former.

Has there been any similar projects in ham radio? Could DVB-T be used with reduced parameters, thus smaller bandwidth? Any tips and/or links are appreciated!

• If you have the software skill to encode, modulate and decode video using a HackRF and rtlsdr, then your amateur license allows you to transmit it on the air. No amplifier required to go across the lab, but you could legally use many watts. Some restrictions on bandwidth and so on, but above 1 GHz you should find space. As always, I think the software side will be most challenging. Aug 1, 2015 at 7:22
• I'm interested in doing exactly the same, including with DRM. Is it possible with just the HackRF, RTL-SDR and a 'bunch of code'? Sep 30, 2015 at 12:10
• @JonHadley I don't know yet, I'll reply here as soon as I have results.
– dnet
Oct 11, 2015 at 14:22
• @dnet I came across QSSTV today, which looks promising. The config suggests that it can use a number of different radios, but there's nothing (in the default list at least) for HackRF or RTL-SDR. Thought it was worth mentioning :) Oct 21, 2015 at 13:43
• @JonHadley the problem is that AFAIK QSSTV is designed for modes that fit into the bandwidth of the audible spectrum, so it can use different radios, because in all those cases, the radio is simply connected to the sound card inputs/outputs. So in this case, supporting radio models essentially means it's able to switch the radio between RX and TX (PTT), but the whole thing is still limited in terms of bandwidth.
– dnet
Oct 21, 2015 at 20:17

So, a teaser first:

With GNU Radio, you can transmit various DVB standards. Here's Alexandru Csete demoing his DVB-S2 transmission:

As you can see from the FFT Plot generated by the flow graph in the upper picture, some 7MHz of bandwidth would be sufficient for this transmission mode – the HackRF should, like the device Alexandru used, be able to deal with the 10MHz that this flowgraph ran at.

The input is really just an MPEG transport stream file that's compatible with the DVB-S2 specs. You can find a lot of these at W6RZ Ron Economos' website, who's the main author behind gr-dtv. File source doesn't sound that great – but really, MPEG transport streams like this are meant to be streamed, and you can just replace that file in the file source with a named pipe and pipe the output of your MPEG encoder to it, or maybe just the MPEG transport screen you grabbed off the air from another broadcast. Also, because GNU Radio is so flexible, you could just replace the file source e.g. with a UDP source, and let another computer stream MPEG to that, in case your computer isn't up to SDR reception of video, reencoding and SDR modulation. That's is a handful of things even for fast PC workstations!

I'm going to go ahead and shamelessly plug GNU Radio here: If you haven't heard about it, it is a Software Defined Radio framework. It's based on the idea of signal processing flow graphs, in which (as you can see in the upper screenshot) you connect blocks that contain functionality to a bigger, useful application. Such blocks can be simple things like "multiply signal with a constant value", or more complex things like a DVB-S2 modulator, or they can also be hardware interfaces (the osmocom Sink in the screenshot talks to your SDR device). You're also not limited to existing blocks: writing blocks that do things that aren't possible by combining existing blocks is easy, and there's a whole ecosystem of people writing modules for GNU Radio.

Without further ado: GNU Radio's website and the Guided Tutorials, which I strongly recommend. Generating an FM receiver takes minutes from scratch if you went through them, which shouldn't take too long, either.

I'm fully aware that SSTV with let's say 48kHz of sampling rate isn't really comparable to DVB-S2 with Megahertzes of bandwidth, but to answer your original question:

Could DVB-T be used with reduced parameters, thus smaller bandwidth?

You can configure gr-dtv's DVB-T (contained in the standard GNU Radio source code) for smaller bandwidth than what is used in above example, no problem. The lowest standardized (and hence, decodable by anyone) bandwidth is 5 MHz.

DVB-T is an OFDM-based transmission standard, and has a lot of channel coding. That makes a lot of sense, because it's designed to carry high-datarate bitstreams, and thus, by Shannon's Channel Capacity, needs a large bandwidth for a limited SNR. High bandwidth means that the channel response isn't "flat", ie. attenuation and rotation aren't the same for all frequency within that bandwidth. You need an equalizer to counter that at the receiver – equalizers are hard to do right, and even harder to implement fast, and so standards like DVB, IEEE802.11a/g/n/p (WiFi), LTE… take the channel and divide it into small subchannels with a DFT (the frequencies in the DFT don't cross-talk, hence the "O" in OFDM, Orthogonal Frequency Division Multiplex). That way, you get a lot channels, but each of those is flat, so equalization is really just one independent correction factor per subcarrier.

If you reduce the bandwidth of OFDM a lot, you lose that advantage, and also get into SNR problems (signals within a small bandwidth necessarily have less energy than signals of the same spectral density in a larger bandwidth), so I'm not sure that scaling DVB-T below let's say 2MHz would work.