Slow Scan TV Gadget

A few months ago, I started thinking about what I wanted to do for my next balloon launch. Getting live pictures back was at the top of my list, but I didn't want to commit expensive ATV gear to the launch and I didn't want to deal with lots of FEC and a high-speed data link to transport JPEGs. That got me thinking about SSTV. It's relatively simple, it degrades gracefully in the presence of noise, and it'd get a picture through fast enough to be useful.

I did some research and found that the Kenwood VC-H1 was pretty much the only compact, stand-alone SSTV device ever made. It was introduced at around $600, and still sells for around $300 on eBay on the rare occasions they come up for sale - they were discontinued some time back.

So I set out to build my own device. The first thing I needed to do was to figure out how the signaling actually worked and see if I could do it on the 8-bit microcontrollers I usually work with. Finding reliable information turned out to be a nightmare. Seems like everyone who's ever worked SSTV has felt compelled to put up their own explanation of how it works, based on everyone else's fragmentary explanations and misinformation.

Just finding exact line timing was nearly impossible. I found a site that showed line times to several decimal places, but it turned out to be the same inaccurate garbage presented in a different form. I finally got in touch with Jim Barber, N7CXI, and found out that he'd presented a paper on the subject at Dayton back in 2000, but hadn't gotten around to publishing it online. Turns out there were some quirks to the Scottie modes I was using that I'd never seen documented elsewhere. Once I had that, generating a test image was easy enough.

The next step was getting an image from a camera. I found a source of suitable digital camera modules - not high-end optical instruments by any means, but good enough and easy to interface, stupid communications glitches notwithstanding. Rather than build everything onto a development board, I started with one of my simplex repeater prototypes. It already had all of the hardware I needed, aside from a serial port.

I grafted the camera and a debugging serial port onto the processor using 30 gauge wire wrap wire, and soon had it dumping frames into flash memory. Getting the timing right to fill up the width of the frame was a little annoying, but I got it, to within a reasonable degree of accuracy. I also added a character generator to use the top 16 lines for text display.

The real challenge was getting it to do everything at once. It's got to start transferring data from the camera, storing that to flash every 256 bytes, reading back a line of data at a time (each line gets scanned 3 times for red, green, and blue), and sending samples to the PWM module every 1/38,400 second. Writing a page to flash takes about 3 milliseconds and it can't read while it's doing that. It also can't do line reads during the sync interval because of the idiotic line sequence in the Scottie modes.

It's some of the ugliest code I've written in recent years, but it works, at least for S1 mode. It's almost there for S2, but the faster scan rate is still causing problems. Once I've tackled that, I'm going to try Robot 36. I'm not looking forward to it -I'll have to convert on the fly from RGB to YCbCr color, with an odd interleaved chrominance subsampling scheme. I've got a few kilobytes to spare for lookup tables, though, and the HCS08 has a hardware multiplier. I'm sure I can come up with something.

Worst case, it'll have to wait for version 2. I'm working on a new design that'll have enough SRAM for a proper frame buffer, with an NTSC/PAL/SECAM decoder for external video input. The same hardware should work for a larger selection of digital camera modules. I'm going to have to learn some VHDL for the CPLD I'm using to tie it all together. Might also make the switch to a 32-bit ARM7TDMI processor. I was planning to use an Atmel part, but NXP has some really nice devices that are considerably faster for about the same price.