scanlime:020 – TSG95 Color Bar Generator Teardown

Little teardown and exploration of an old bit of NTSC / PAL television test equipment, the Tektronix TSG 95. We’ll poke around with the oscilloscope and analog TV, and we even stumble on some helpful documentation.

Please consider supporting me on Patreon so I can keep making these vids!

Subscribe to YouTube notifications or follow for live streaming announcements.

Simple Optical Microphone/Pickup

This is another mini-project that began, like so many have, in a discussion with Scott over some beer. We wanted to build a new kind of speaker amplifier, which used mechanical closed-loop feedback to position the speaker cone exactly where the audio signal says it should be. We figured that, if done right, this could yield higher audio quality from cheaper speakers.

So, that idea is pretty crazy, but it seemed just barely plausible enough that I had been thinking about the component parts of such an amplifier. The most important seemed to be a sensor that could accurately supply feedback on the speaker cone position without loading the speaker or distorting the cone. The first method we considered was a capacitive pickup. Paint the back of the speaker cone with conductive paint, then position two copper plates behind the cone, just barely not touching when the speaker is at its maximum throw. This acts like two capacitors in series, and gives you a capacitance that varies along with the audio frequency, without any mechanical connection to the speaker cone.

We also considered magnetic feedback, using something like an LVDT, but where one coil is the voice coil itself. This would involve modulating some kind of high-frequency carrier into the speaker drive signal, then placing another fixed coil around or behind the voice coil to pick up that signal.

The next method, and I guess the simplest, is optical. This would work a lot like a fiber optic microphone or an optical guitar pickup. You can measure vibration by detecting changes in light intensity caused by changes in distance or angle of some reflective thing that’s vibrating.

Whereas the capacitive and LVDT ideas require a high-frequency modulated signal, that’s optional with the optical method. You can measure absolute intensity, or you can modulate your LED with a high-frequency carrier that can be detected on the receiving end. This modulation can help reject ambient light (including hum from fluorescent lights) but it isn’t required.

So, to see if this project has even a tiny chance of working, I thought I’d prototype the optical sensor by building an optical microphone. The end results were rather mediocre. I’m posting it here only because:

  • I was honestly surprised that it worked at all
  • It could be useful for other applications, like a drum or bass guitar pickup
  • Maybe one of my readers has hints on making it more sensitive and lower noise? 🙂

The Circuit

This is a really simple back-of-the-envelope sort of transimpedance amplifier, high-pass filter, and gain stage. Disclaimer: I hate doing math for analog circuits when it’s just a quick hobby project, so I did no math in designing this. Take it with a few shakes of salt. My breadboard was humming pretty badly due to incoming EMI, so I built it dead-bug style in a mini Altoids tin. If you build this, definitely use a suitable amount of shielding.

  • Power supply range is about 3-6v, but it seems to work best at 5-6v. (If you listen to the op-amp data sheet, max voltage is 5.5v.)
  • The op-amp should be a low-offset, rail-to-rail, high-bandwidth type. I used the OPA2350 because that’s what I had handy.
  • The IR LED I used is pretty generic. I’m operating it at fairly high current, because I wanted a strong light source. You might consider using multiple LEDs, though, to make it easier to position the pickup properly.
  • The photodiode should be a PIN diode with an IR filter. I used an SFH229.
  • Keep the leads short, especially power and photodiode.
  • They aren’t on the schematic, but remember some decoupling capacitors. (I used 0.1uF and 22uF)
  • I put a bit of black heat shrink tubing around the photodiode as a baffle. This seemed to help.
  • I used a stereo 1/8″ audio jack for ground, audio out, and power in. It would be neat to build one with a built-in battery, but this tin was a bit small for that, and the IR LED is kind of power hungry.
  • Make sure to ground the Altoids tin! These smaller tins are harder to solder to than the larger tins, but it can be done. Just use a hot setting if your iron has adjustable temperature, and be patient.



Rubber Band Pickup

The first successful test I had of this pickup was with a rubber band. I’d like to try this with a guitar string, but I don’t play 🙂

It’s actually pretty forgiving about the positioning of the pickup relative to the rubber band, and it’s very sensitive even when the rubber band is a few inches away. This circuit can pick up very low-frequency vibrations well, so you hear very deep bass notes that you don’t normally notice in a rubber band pluck.


Speaker Surface Pickup

This is the application I originally hoped the optical microphone would work for: picking up sound off the front or back surface of a loudspeaker cone. If I could do this really well, the closed-loop amplifier might have a chance. The results certainly weren’t hi-fi, but I guess I was still surprised it worked at all.

Unlike the rubber band, this test was extremely finicky. I had to position the pickup just right, and I used some Kapton tape to make the surface of the speaker more reflective to IR light. I also had trouble getting a good reflection off the curved surface of the cone, so I stretched a flat section of tape between the center dome and the middle of the cone. This gave good signal strength, but the tape itself also acted as a mechanical filter, giving kind of an odd frequency response to the whole system.


And that is all.

Hopefully this will allow me to have some closure on a completely mediocre mini-project that was nonetheless interesting enough that I couldn’t just forget about it without sharing. 🙂 If anyone reading is a real electrical engineer, I’d be interested in hearing about what I did wrong.

Self-contained TED receiver

My previous entry introduced a homebrew receiver for the powerline-based data protocol used by The Energy Detective. I just designed a second revision of that receiver. This one is self-contained: It gets power and modulated data from a 9V AC wall-wart transformer, and decoded data leaves via an RS-232 serial port at 9600 baud. Best of all the circuit is very simple: Just an 8-pin microcontroller and a single op-amp.

Major changes in this version:

  • DC power for the circuit is now provided by the 9V AC input, instead of a separate power supply. Previously this would have caused unacceptable levels of harmonic distortion in the input signal. In the new design, this is mitigated by an inductor (which forms an LC low-pass filter), and by the lower power consumption of a single modern op-amp versus three ancient op-amps.
  • By using a simpler filter design and a modern op-amp with a gain-bandwidth product of at least 10 MHz, the bandpass filter and amplifier can be built using only a single op-amp.

Note that the MAX475 op-amp I’m using has been discontinued by the manufacturer, and it’s now hard to find. I just used it because I had one handy in my junk drawer. I’ll verify this design with other op-amps as soon as I can, but it should work with just about any op-amp which can operate on a single-ended 5V supply, and which has a high enough GBW.

Firmware and schematics (PNG and EAGLE formats) are in Subversion and more info on the theory of operation was presented in my previous blog entry.

Interfacing with The Energy Detective

I recently bought The Energy Detective (TED), a pretty inexpensive and friendly way to keep tabs on your whole house’s electricity usage. It’s a lot like having a more featureful version of your utility company’s power meter, sitting on your kitchen counter. It can estimate your utility bill, and tell you how much electricity and money you’re using in real-time. The resolution is pretty good- 10 watts, 1 second.

As a product, I’ve been pretty happy with it. It does what it claims to, and the measurements seem to be fast and accurate. Of course, being the crazy hacker I am, I wanted to interface TED with other things. I don’t have a home automation system as such, but I did want to get real-time graphs of my electricity usage over various time periods. I also wanted the possibility to use TED as an information feed for various other display devices around the house. (But that’s a topic for another blog post…)

The stock TED package consists of two pieces: A measurement/transmit unit (MTU) and receive/display unit (RDU). The MTU has a pair of current transformers, and it installs entirely in your house’s breaker panel. It takes the power readings every second, and transmits them over the power lines to the RDU, which is just a little LCD panel that plugs into the wall. The RDU has a USB port, which you can use with TED’s “Footprints” software.

So, hoping that the USB port would do what I want, I bought the Footprints software for $45. The TED system itself is, in my opinion, a really good value. The Footprints software is not. As a consumer, I was disappointed by two main things:First of all- the UI lacks any polish whatsoever. It looks like a bad web page from the 90’s. Second of all, the data collection is not done in hardware, it’s implemented by a Windows service. This means you can’t collect data to graph unless you have a Windows PC running. Not exactly a power-efficient way to get detailed power usage graphs.

As a hobbyist, a few more things frustrated me about Footprints. The implementation was pretty amateurish. Their Windows service runs a minimal HTTP server which serves up data from an sqlite database in XML. The front end is actually just a Flash applet masquerading as a full application. Energy Inc, the company behind TED, has an API for Footprints: but you have to sign a legal agreement to get access to it, and I wasn’t able to get any details on what the API does and doesn’t include without signing the agreement. So, I opted not to. It would be much more fun to do a little reverse engineering…

So, I did. The end result is that I now have two ways of getting data out of my TED system.

Using the USB port

The TED RDU’s USB port is actually just a common FTDI usb-to-serial adapter. The RDU sends a binary packet every second, which includes all of the data accessible from the Footprints UI. This includes current power usage, current AC line voltage, utility rates, month-to-date totals, and anything else you’ve programmed into your RDU.

There has been some prior work on reverse engineering this protocol. The Misterhouse open source home automation project has a Perl module which can decode the TED messages.

Unfortunately, the Perl module in Misterhouse won’t work with more recent versions of the RDU like mine. The recent RDUs have a different packet length, and they require a polling command to be sent before they’ll reply with any data.

I found the correct polling command by snooping on Footprints’ serial traffic with Portmon. I also noticed a packet framing/escaping scheme, which explains some of the length variations that would have broken the module in Misterhouse.

The result is a Python module for receiving data from a TED RDU. It isn’t terribly featureful, but it should be pretty robust.

Direct from the wall socket

Now for the more exciting method: What about reading data directly from the power line, without using the TED receive/display unit at all? This could provide some exciting opportunities to embed a small and cheap TED receiver inside of other devices, and it would provide some insight on what exactly is being transmitted by the box in my breaker panel.

The TED RDU is pretty simple internally: A Dallas real-time clock, PIC18 microcontroller, chip-on-glass LCD, some buttons, and the TDA5051A, a single-chip home automation modem from Philips. This chip can receive and transmit ASK modulated signals at 1200 baud, with a carrier frequency of around 132 kHz.

Digi-key carries the TDA5051A, but I figured it would be more educational (and more hobbyist-friendly) to try and build a simpler receiver from scratch using only commonly available parts. The result is the following design, with an 8-pin AVR microcontroller and three op-amps:

Update: There is now a Revision 2 of the schematic, which uses only a single power supply and one op-amp.

  1. The power line is sampled via a 9V AC wall wart. With this design, it needs to be a separate isolated power supply. So far, I haven’t had any luck with using this same transformer to power the circuit. Any rectifier introduces high-frequency harmonics which drastically degrade the signal-to-noise ratio.
  2. The first stage is a 10x amplifier and 138kHz band-pass filter. This is from Texas Instrument’s “Filter Design in Thirty Seconds” cheat-sheet.
  3. The next stage is an amplifier and high-pass filter, to remove the last remnants of 60 Hz ripple.
  4. The third stage is just for amplification. In a design which used higher quality op-amps, this stage may not be necessary.
  5. After the third op-amp, the signal passes through an RC network which AC couples it, filters out high frequency noise which could cause glitches in the microcontroller’s I/O pin, and limits the current into the micro’s clamping diodes.
  6. At this point, we have an amplified digital signal which is still ASK-modulated:

The rest of the work happens in software. The ATtiny85 keeps itself quite busy:

  1. The AVR first applies a narrow digital band-pass filter, to strip out any ringing or other noise that remains after the analog band-pass filter.
  2. Next, a digital low-pass filter. This passes the 1200 baud serial data, but rejects higher frequency glitches.
  3. A threshold is applied, with hysteresis, to convert this data into a stream of ones and zeros.
  4. Next is a relatively typical software serial decoder, with majority-detect. The ASK modulated data has 8 data bits, 1 start bit, and 2 stop bits. Polarity is slightly different than typical RS-232. “1” is the presence of an ASK pulse, “0” is the absence of a pulse. Start bits are “1”, stop bits are both “0”.
  5. Using this serial engine, we receive an 11-byte packet.
  6. The packet is converted from TED’s raw format into a more human-readable (but still machine-friendly) serial format.
  7. The reformatted data is finally output via a software serial port at 9600 baud.

The end result, as viewed from a PC connected to the serial output pin:

HC=245 KW=001.324 V=121.138 CNT=023
HC=245 KW=001.335 V=121.135 CNT=024
HC=245 KW=001.348 V=121.072 CNT=025
HC=245 KW=001.345 V=121.021 CNT=026
HC=245 KW=001.345 V=121.044 CNT=027
HC=245 KW=001.324 V=121.152 CNT=028
HC=245 KW=001.314 V=121.280 CNT=029
HC=245 KW=001.314 V=121.306 CNT=030
HC=245 KW=001.311 V=121.297 CNT=031
HC=245 KW=001.349 V=121.232 CNT=032
HC=245 KW=001.347 V=121.228 CNT=033

The “KW” and “V” columns are self-explanatory. “HC” is my TED’s house code, and “CNT” is a packet counter. Normally in increments by one. If it skips any numbers, we missed a packet.

But wait, what’s wrong with this picture? The power and voltage readings have too much precision. The standard TED display unit will give you a resolution of 10 watts for power, and 0.1 volt. As my data above shows, the TED measurement unit is actually collecting data with far more precision. I can only guess why TED doesn’t give users more precision normally. I suspect they removed it because the extra precision may imply extra accuracy that may not exist.

So, what is TED actually sending? Once a second, it broadcasts an 11-byte packet over your power lines at 1200 baud:

  • Byte 0: Header (always 0x55)
  • Byte 1: House code
  • Byte 2: Packet counter
  • Byte 3: Raw power, bits 7-0
  • Byte 4: Raw power, bits 15-8
  • Byte 5: Raw power, bits 23-16
  • Byte 6: Raw voltage, bits 7-0
  • Byte 7: Raw voltage, bits 15-8
  • Byte 8: Raw voltage, bits 23-16
  • Byte 9: Unknown (Flags?)
  • Byte 10: Checksum

Pretty straightforward. I don’t know the actual A/D converter precision in the measurement/transmit unit, but both the power and voltage readings are sent on the wire as 24-bit raw numbers. I’m still not sure what byte 9 is. In my measurements, it hovered around 250, sometimes jumping up or down by one. It may be some kind of flag byte, or maybe it measures power line frequency? The checksum is dead simple: Add every byte in the packet (modulo 256), and the checksum byte ensures the result is zero.

To figure out what to do with these raw measurements, I collected data simultaneously with my circuit and with the TED RDU’s USB interface. Both sets of results went into a spreadsheet. After removing outliers, I did a linear regression. The resulting linear function is what you’ll find in the current firmware for my homebrew receiver. The following plots from the spreadsheet are a pretty striking illustration of the additional precision available via my raw interface:

The top graph shows power line voltage as recorded by the TED RDU. The second graph shows the raw values I’m receiving from the TED MTU. The bottom graph shows the correlation between the two, in blue, and my linear regression, in red.

I plan to keep improving the circuit. Hopefully there’s a way to get both data and power from a single supply, without dealing with any annoying high-voltage circuitry. If there is any interest, I might make a kit available. If you’re interested, post a comment and let me know what features you’d like. USB port? Serial port? Display?

Simplest RFID reader?


That’s a Propeller microcontroller board with a few resistors and capacitors on it. Just add a coil of wire, and you have an RFID reader. Here’s a picture of it scanning my corporate ID badge, and displaying the badge’s 512 bits of content on a portable TV screen:

Prototype RFID reader

If you’re into that sort of thing, I wrote a forum post with technical details and pretty oscilloscope screenshots.

Update: The forum link went dead for a while when Parallax switched to a different forum server. I’ve updated the link, but just in case.. A copy of the post is included below.

I’ve been interested in building an RFID reader for a crazy project a friend of mine is working on (automated beer dispensing system 😉 and it was an excuse to do some analog tinkering, so I had a go at building an RFID reader with the Propeller. Why not use Parallax’s fine RFID reader accessory? I wanted to be able to read any off-the-shelf card, including common proximity ID badges.

I just got it working. I’d love to be proved wrong, but as far as I know this is the world’s simplest RFID reader design:

Edit: All capacitances are in picofarads. C1 and C3 should be 1000 pF, not 1000 nF. Likewise, C2 is 2200 pF.

Yep.. just a propeller and a few passive components. To understand this circuit, it’s helpful to know how RFID works first. Here’s the 10-second RFID primer for those who aren’t already familiar with it:

RFID tags work via magnetic fields, like a transformer. A coil in the reader generates a magnetic carrier wave, which is picked up by a coil in the tag or card. This carrier wave powers the card, and provides it with a clock reference. To send data, the card varies the amount of current it draws from the reader’s field, attenuating the carrier wave slightly. This attenuation is usually used to send some kind of modulated signal. The card I’ve been testing with uses a 125 kHz carrier wave, and FSK (Frequency Shift Keyed) modulation. Zeroes and ones are attenuation waveforms with different frequencies.

So, step one: generating a carrier wave with the propeller. I use a counter, naturally, and I generate a differential-drive signal on two pins. This gives me 125 kHz at about 6.6V peak-to-peak. I use an LC tank tuned near 125 kHz to amplify this and shape it into a sine wave. Here’s my carrier wave, measured at the junction between L1 and C1. Note the scale- it’s about 20 volts peak-to-peak! (Also notice that my tuning isn’t quite perfect. Sadness and despair!)

When you bring a proximity card near the reader coil, you can see the attenuation waveform overlaying the carrier wave. This is at the same voltage scale, measured at the same point, but I zoomed out on the X axis so you can see the pattern clearly:

To detect this signal, I use D1, C2, and R1 as a peak detector and low-pass filter, to remove the majority of the high-voltage carrier wave. This is then AC coupled via C3. At this point, the left side of C3 has a “floating” low-voltage waveform that I can position anywhere I want, by changing the bias on C3.

To generate this bias voltage, I use CTRB in DUTY mode. I’ll explain why I call this pin “threshold” later. R4 and C4 are a low-pass filter give me an analog output voltage from CTRB. This signal is usually DC- it’s used for calibration.

R3 “pulls” the floating waveform toward the analog value output by CTRB. Now I take advantage of the Propeller’s Vdd/2 input threshold, and use the “input” pin as a comparator. (R2 is just to limit high-frequency noise.) Now I can use the CTRB voltage to adjust the detection threshold- how much attenuation causes “input” to read 0 vs 1.

Now I have a digital signal, but it’s still really noisy. I use an assembly-language cog to reject as much noise as possible, and time the resulting FSK pulses. This image shows the analog signal at the junction between R2 and C3, along with the digital pulse detector’s output. The amount of time between pulses signifies a “1” or “0” bit. In this case, the detection threshold is at 9 carrier wave cycles. Less than 9, it’s a 0. More than 9, it’s a 1 bit.

End result: I can display the 512 bits of data from my corporate proximity badge. Neat.

I’d include more details on the actual data I’ve captured and the protocol, but so far I’ve only been able to test this with a couple ID badges from the office and I’d rather not share those bits 😉 I have a Parallax RFID starter kit on order, so I’ll let you know if I can read any of those tags successfully.

Source code is attached, but be warned it’s hugely messy.

Update: The latest code and schematics are now have a home in the Object Exchange:

Hardware hackery and the Dual Shock protocol

The hardware-tinkering mood I’ve been in lately shows no sign of subsiding. The theme this time: Everything over cat5.

Backing up a bit… It’s summer! Hooray. So, how does one make the most of the season without actually doing something crazy like going outdoors? Of course the answer is to play video games in a different room which has more fresh air and a better view of the day-star.

Some people would pick up the Playstation and move it to the other room, but my solution is to run the video over inexpensive cat5 cable. This isn’t a new idea, or even a complicated one, but component-video-over-cat5 baluns still sell for around $80 each! I recently made my own pair out of a couple more altoids tins and some parts from the junk drawer.

These work really well. There is a little bit of ghosting visible on a black screen, but during normal use the quality looks perfect, or at least no worse than the quality of the TV it’s connected to. Unfortunately, and I started testing it with a little Megaman 2 and quickly noticed an unrelated problem: the distance is a little too much for our wireless controllers. Time to build a Playstation-controller-over-cat5 extender.

I can think of three different approaches for building such an extender:

  1. Purely electrical: Each PSX signal gets an RS-422 driver and a separate twisted pair. This is very simple, but it would require two cat5 cables per controller! I want at least two controllers running over a single cable.
  2. Low-level multiplexing: Compress multiple signals onto each twisted pair by multiplexing below the protocol level. This would be bit-for-bit identical to plugging a controller in locally, but it has a few big disadvantages. It requires quite a fast clock on the twisted pair, since it requires several bits of information to be sent for every bit in the original protocol. It also doesn’t add any flexibility. You couldn’t, for example, add a crossbar switch for controllers which could let you switch one controller between multiple video game consoles via a button combination.
  3. High-level multiplexing: The console-end of the link includes an FPGA which fully emulates one or more Dual Shock controllers. The controller-end consists of a microcontroller that polls a bank of controller ports and sends updates over an RS-485 link to the FPGA. This is very powerful, and it’s the method used by my old Unicone (Universal Controller Emulator) project. Unfortunately, it’s also relatively complex and it introduces a few milliseconds of latency.

I’m currently working on (3), but I haven’t ruled out (2) completely. First step, I need to know how to emulate a Dual Shock controller. The internet is full of pages that describe the very basics of the Playstation controller protocol, but I couldn’t find a single document that described the protocol in anywhere near enough detail to emulate a controller properly. Time for some reverse engineering…

This was quite a lot like the job I did a while ago to reverse engineer the Nintendo 64 controller protocol enough to build a microcontroller that could emulate a controller. Instead of an HP logic analyzer borrowed from work, this time I have a Saxo board from fpga4fun acting as a real-time Playstation packet sniffer. I should be able to use the same packet sniffer setup to finish reverse-engineering the Playstation 2 memory card protocol so that I can add PS2 support to my psxcard USB adaptor. 🙂

A Verilog core to emulate the Dual Shock controller will hopefully be coming up soon. In the mean time, I published my Notes on the Playstation 2 Dual Shock controller protocol. It’s actually surprisingly more complex than I was expecting. There are several backward-compatibility features, two rumble motors (one with 8-bit speed control), analog buttons… The protocol has several features that the Dual Shock controller doesn’t take advantage of, like support for 254 different force-feedback actuators that you can arbitrarily map into your polling packets. Crazy.

Life at 3.579545 MHz

Well, after an evening of cooking and hacking, I’ve managed to implement my own crazy software-only modulator for NTSC video. It can take an arbitrary JPEG image, turning it into an analog signal representing one field of color broadcast video. This analog signal happens to be playable by displaying a resulting image file on your video card with the proper X modeline.

This is a familiar test image that I photographed myself. The coax cable on my TV is alligator clipped right onto the red channel of the test machine’s video card. The white dots you see are “blind spots” caused by horizontal sync. Horizontal resolution is quite good, but vertical resolution is limited since I’m only generating one NTSC field.

If you care about the source code, you probably already know where to get it. Otherwise, bug me. I won’t bother linking to it from here, since by the time you read this I’ve probably changed it some more. Once I can do this in real-time, I’d like to make it into a library of some sort.

Update: I didn’t end up doing much more with this project. The code is now at

Tempest for ATSC

Recently I have become intrigued by the little 75-ohm coax plug on my plasma TV. To me, television programming isn’t worth nearly what Comcast charges for cable. I mostly watch DVDs, or television shows downloaded over the interweb. After reading about the fairly powerful digital television coverage in the bay area, I decided to plonk down $35 on a little amplified UHF antenna.

It’s a bit finicky at times, but I can receive at least 3 or 4 channels in crisp digital-cable-like HDTV quality. It’s really amazing how much data you can pump over the airwaves with the right compression and modulation. What’s more amazing, though, is that the ATSC tuner gives me a much sharper picture than I get over component video. Sure, HDMI would be ideal, but my TV doesn’t seem content with your average DVI signal.

So, how hard would it be to generate my own ATSC signal? I’d effectively be piping MPEG-2 data directly into the television’s logic board- if it could be done cheaply, it could be a really revolutionary way for HTPC hobbyists to get high quality video into any modern digital television. After thumbing through the ATSC spec, it looks like nearly the entire modulation job could be done by a sufficiently powerful CPU. Indeed, the GNU Radio project already has code for a software-only ATSC modulator and demodulator. All you’d need would be a 3-bit or higher D/A converter at about 10 MHz, a modulator, and a couple oscillators at very particular frequencies. Heck, this could be a $20 USB dongle.

Then, I happened upon what might be the coolest hack I’ve ever seen. Fabrice Bellard, the guy behind QEMU, wrote a software modulator for PAL, SECAM, and DVB-T. Sure, the GNU Radio project has had that for a while. The really novel part about this hack is that it uses the video card as both a DAC and an RF output stage!

Here on the other side of the pond from Fabrice I only have NTSC and ATSC television equipment, but nevertheless I felt like giving this hack a try. No source code unfortunately, but the images that result from the modulation process are available. I set up the PAL test image, and stuck an oscilloscope probe into the VGA port. Hey, this looks like it might be a valid video signal. Then I cart in a little 13″ television and start tuning around. I hit channel 7, and there’s a greyscale rendition of Lena! The vertical hold is almost nonexistent, but it sure ain’t bad for an NTSC television trying to display a PAL signal coming straight out of a GeForce 6200’s VGA port.

Then, I realize I haven’t even connected the other end of the coax cable. This whole time, my cheap scope probe has been acting as a transmitter antenna and the half-connected coax as a receive antenna. Lena has been travelling over about a foot of air. I plug the other end in, and the signal gets a whole lot less noisy.

It’s unfortunate that Fabrice didn’t include source, but I’m sure he has his reasons. The demo has inspired me, though. This isn’t the first time I’ve seen video outputs used in strange and unusual ways: long ago I coerced the LCD controller on a 68EZ328 (2nd generation Palm Pilot CPU) to generate a VGA signal. The horizontal and vertical blanking signals were painted right into the framebuffer. What really tickles me about this demo is that it’s exploiting the EMI given off by the card to modulate the finished RF signal.

Anyway, I think I’ll try my hand at an NTSC version of the demo… and eventually ATSC. I’m curious how much CPU power it would take to play back an MPEG stream in real-time this way. Worst case, it might require pre-processing to turn the MPEG stream into a raw stream of 8VSB codes. Could the modulation process be accelerated with fragment programs? This would definitely be the first time I’ve heard of OpenGL used to accelerate a radio.