Tag Archives: microcontroller

BitScope

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?

avr-with-parallax-reader

Using an AVR as an RFID tag

Experiments in RFID, continued…

Last time, I posted an ultra-simple “from scratch” RFID reader, which uses no application-specific components: just a Propeller microcontroller and a few passive components. This time, I tried the opposite: building an RFID tag using no application-specific parts.

Well, my solution is full of dirty tricks, but the results aren’t half bad. I used an Atmel AVR microcontroller (the ATtiny85) and a coil. That’s it. You can optionally add a couple of capacitors to improve performance with some types of coils, but with this method it’s possible to build a working RFID tag just by soldering a small inductor to an AVR chip:

image

image

The above prototype emulates an EM4102-style tag- a very popular style of low-frequency RFID tag which stores a 40-bit unique ID. I can read my bogus ID value (0x12345678AB) using Parallax’s RFID reader. Below is another prototype, with a larger coil and a couple of capacitors for added range and stability. It is programmed to emulate a HID prox card, a simple FSK-modulated tag with a 44-bit payload. I can read this card successfully with my garage door opener. This one is a little large to conveniently carry around, but a smaller AVR package should help.

image

AVRFID Tag Prototype

So, the shiny electrical tape is beautiful, but how does this thing even work? The power pins on the microcontroller aren’t even connected!

As I said, this makes use of several dirty tricks:

  • The coil actually powers the AVR through two of its I/O pins. Nearly every chip out there has clamping diodes on its I/O pins, which prevent voltages on that pin from rising above the chip’s supply voltage or sinking below ground. These diodes are useful for arresting static discharge.When you first hold the RFID tag up to a reader, the chip has no power- the supply voltage is zero. When the coil starts to pick up power from the RFID reader, these two I/O pins are presented with a sine wave, a few volts in amplitude. Anywhere that sine wave exceeds the supply voltage, some energy is diverted from the coil to the chip’s supply rails, via the clamping diode. The end result is that the chip is powered, and the coil’s sine wave is truncated. The top and bottom of the sine have been chopped off, and it looks a lot more like a square wave now.
  • Power filtering using the AVR’s die capacitance. In the smaller prototype, there is no power filtering capacitor at all. In fact, the power is filtered by the internal capacitance of the power planes in the AVR’s silicon die. This isn’t much, but it makes the power supply stable enough that we can execute code even though the supply is pulsing at 125 kHz.
  • Very low voltage operation. This particular ATtiny85 chip is specified for operation at voltages as low as 2.5v. The extended voltage range version (I didn’t have any of these handy) is specified down to 1.8v. But I’m running these AVRs at barely over 1 volt. At these voltages, the normal AVR clock oscillators don’t work- but I can get away with this because of the next hack…
  • The coil is the AVR’s clock source. The inductor isn’t just hooked up to any I/O pin: it’s actually connected to the AVR’s clock input. Remember the square-ish wave we’re left with after the clamping diodes suck away some power? That waveform is now our clock input. The microcontroller is executing code at 125 kHz, in lockstep with the RFID reader’s carrier wave.
  • Firmware? What firmware? At such low speeds, the chip’s firmware looks less like a program, and more like a sequence of I/O operations to perform in sync with each carrier clock cycle. There aren’t a lot of cycles to spare. In the EM4102 protocol, you could potentially do some useful work with the 32 clock cycles you have between each bit. With the HID protocol, though, you need to output an FSK edge as often as once every 4 clock cycles. As a result, the firmware on the RFID tag is extremely dumb. The “source code” is really just a set of fancy assembler macros which convert an RFID tag code into a long sequence of I/O instructions.

The fact that this thing works at all is quite a testament to the robust design of the AVR. The latest AVRFID source is in Subversion, as usual.

2967929223_cfbfa7ef49_b

Simplest RFID reader?

IMG_0321

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: http://obex.parallax.com/object/549.

IMG_0095

Propeller chip + SPDIF = ???

So, kind of on a random whim, I decided to build a software SPDIF encoder for the Propeller chip. It was an interesting challenge, and the results are pretty cool, but now I have no idea what do do with it. Not an uncommon problem for me, I guess…

Maybe I’ll give my Propeller board an Ethernet port and build a Squeezebox-on-a-chip.

Update: Ok, so maybe that’s not such a crazy idea.. (or is it?) Anyway, I just found this, and I had to order a couple:

Now if only there was a simple way to capture all sound output from a Windows/Linux/Mac machine and stream it over the network… The ESD protocol doesn’t count 😛

2932267038_232feb03f1_b

Hard disk laser scanner at ILDA 4K

I should have blogged about this long ago, as I’ve been working on it off and on for about three months now, but today I reached an arbitrary milestone that compels me to post 😉 I’m still actively working on this project, so I’ll try to make updates occasionally, and if I end up putting together an actual project web page I’ll link it from here.

My latest tinkery hardware and embedded systems project is a homebrew laser scanner. You know, the kind you see at planetariums- sweep a laser beam around on the wall really fast, and draw vector graphics. Commercial laser scanners have been around for decades now, but buying a complete system is still really pricy, even on eBay. Besides, where’s the fun in that?

There are plenty of examples of homebrew laser scanners on the internet. Many people have wired up a pair of loudspeakers, hard disk actuators, or other readily available mechanisms to an amplifier and used them for simple laser graphics. This will make some pretty wiggly patterns on the wall, but it isn’t a real vector graphics display. The best example I know of for a totally built-from-scratch laser projector (not using commercial galvo actuators) actually uses custom hand-wound galvanometers. Very nice.

So, this has been done before, but I still find it an interesting project. This is actually my third attempt at a laser scanner. My first one I built when I was in my early teens, when solid state lasers were first starting to become “affordable”. I pointed my shiny new $40 laser diode module, dimmer than today’s $5 laser pointer, at a few spinning mirrors on cheap DC motors. Instant laser spirograph, with basic speed control over the parallel port of my 8086 PC.

About 4 years ago, in college, I made my second attempt. This one used a cheap red laser pointer, fragments of scrap mirrors, and a couple of old hard disks hot glued together. The mechanical parts were shoddy, but the electronics were worse. It had an extremely low-power open loop amplifier, and it couldn’t draw much more than circles.

This being my third try, I figured I had to get it right. I still stuck to my original goals:

  • Only readily available off-the-shelf mechanical and electronic parts.
  • Simple hardware, powerful software.
  • Performant enough to display low- or medium-complexity vector graphics.
  • Portable.

And, this was the result:

To differentiate it from all the other hobby laser projectors out there, it has a pretty nice set of features:

  • Compact and portable.
  • All digital. In the whole project, no board-level analog signals are present.
  • Based around the Parallax Propeller multi-core microcontroller.
  • Optical position sensors, for closed-loop servo feedback.
  • High-power 30mW green laser, with software-adjustable brightness level.
  • Bluetooth interface. The only external wire is power.
  • Vector graphics virtual machine. To efficiently send graphics data over the relatively slow Bluetooth link, frames can be encoded using a simple instruction set which lets the projector itself perform line and curve interpolation.

The internals:

So, the hardware is really simple. Building this projector involved a lot of cutting, gluing, and soldering- but building a second one could probably be done in a weekend. The complexity is in the software, and especially the firmware. The on-board microcontroller is responsible for reading and filtering the light sensor data, updating the servo loop for each VCM at 40 KHz and generating pulse-width modulation at several MHz, reading the temperature sensors, generating laser brightness control PWM at up to 80 MHz, decoding the vector graphics instruction stream, communicating over the Bluetooth link, and supervising the whole operation so we don’t melt a VCM coil or shear any end-stops in half- all simultaneously. The Propeller, luckily, has 8 symmetric processing cores. This project keeps all of them busy.

I’m just barely at the point where I can start conducting meaningful testing that shows me the projector’s true limits. The hardware and firmware are feature-complete, but the desktop software does little more than provide a pretty wxPython UI for high-level control and calibration. So far I’ve been testing it with simple hand-drawn shapes, which the control software can resample for constant laser velocity.

Today I wrote an importer for the ILDA Image Transfer Format, and tried running the industry-standard ILDA Test Pattern. The pattern is designed for a speed of 12K (12000 points per second), but modern commercial laser scanners can typically run it at 30K or higher.

Well, it looks like my projector currently maxes out at about ILDA 4K. Compared to a modern commercial scanner, this sucks, but it’s not bad for a couple of hard disks. I’ll have to try tweaking my servo loop some more (or cranking up the VCMs from 12 volts to 24, maybe with liquid cooling 😉 to see if I can go any faster, but this is certainly enough precision and speed to draw words, shapes, and hopefully some simple animated characters. (Kirby, Yoshi, maybe a spinning Parallax Propeller beanie…)

I’ll keep working on the software, and posting new photos as I make progress. The latest firmware (written in Spin and Assembly) and client software (in Python) are available in Subversion, with an MIT-style license.

OLYMPUS DIGITAL CAMERA

R/C helicopter lights, Revision A.5

Atmel is going to personally revoke my electrical engineering license if they ever find out what’s in that yellow heat-shrink blob, but I now have a shiny new 5 gram version of my helicopter light kit =D

This version has all the same remote-control dimming and strobe capabilities of the heavier Revision A. The only practical drawback is that it isn’t quite as bright.

OLYMPUS DIGITAL CAMERA

Hardware sketch: R/C helicopter light kit

As great as it is to finish a professional-looking hardware project with optimum component choices and full design documentation, I love the feeling of sketching in hardware (or as I’ve called it in the past, improvisational electrical engineering). Despite all the faults and rough edges in today’s development tools, we do live in a world now where it’s easy turn an idea into a working prototype with very little time and money.

Flying in the dark

Yesterday’s hardware sketch was a light system for my helicopter, an E-Flite Blade CX2. I wanted:

  • A way to fly at night. Real navigation lights would be nice, but for starters I just want the whole helicopter body to glow.
  • A way to take off and land safely. I’ve flown with only a body light before, and it’s really hard to land when you don’t know quite where the ground is.
  • A bright strobe, for extra visibility and attention.
  • A way to control the lights remotely, using the extra servo channel on the Blade CX2’s radio.

My finished prototype takes the form of a small circuit board that attaches under the canopy with velcro. That board holds the light control electronics, plus a bright white searchlight. It connects to the radio (for power and control) and to the internally-mounted body lights. The body lights are just bare LEDs attached to the inside of the tail and canopy with velcro. One white LED in the tail, one red and one yellow LED in the canopy.

Both sets of lights have full brightness control using a single knob on the BCX2’s transmitter. At the knob’s minimum setting, all lights are off. As you turn it up, first the body lights fade on. Next, the searchlight fades on. Just before hitting the maximum setting, all the lights are on at full brightness. If you turn the knob farther, to its maximum, the searchlight goes into strobe mode.

There are some rough edges, but it works remarkably well for such a simple design. The total weight is about 15 grams. It’s heavier than I’d like, but it doesn’t effect flight performance much. I’d still like some orientation lights mounted on the skids or the sides of the control PCB, but the body light is pretty easy to fly by. The searchlight is incredibly visible at maximum brightness. Even from an altitude of 50 feet or so, the light casts a bright spot on the ground.

Technical details

Skip this section unless you’re a huge dork 😉

The light controller uses an Atmel ATtiny85 microcontroller (kind of overkill) and a pair of NPN Darlington transistors to drive the LEDs. The microcontroller’s firmware is quite simple. An assembly-language loop times the pulses coming in from the radio, then the firmware decides on a corresponding lighting mode and sets up the AVR’s hardware PWM peripheral accordingly.

This hardware sketch was built with whatever parts I had handy. The LEDs are low-tech by today’s standards, the microcontroller was kind of overkill, and MOSFETs would have been better than the Darlington transistors. If I were building a second revision of this, I’d make a few improvements:

  • All surface-mount parts and a PCB, to decrease size and weight.
  • Use a single 1-watt Luxeon LED instead of an array of cheapo white LEDs.
  • To drive the Luxeon LED, I’ll probably want a simple buck converter.
  • Logarithmic LED brightness control, rather than linear.
  • Side-emitting navigation lights, mounted directly on the main PCB.
  • Optimize the firmware for low-power operation when the lights are off. Right now it costs about 8mA to run the AVR in its pulse-detecting loop at 8 MHz.
  • Start mass-producing and selling these 😉 It’s much better than any commercial light kit I’ve seen for the Blade CX2, and the parts are quite cheap.
OLYMPUS DIGITAL CAMERA

Playstation controller extender

The little hardware project I started almost 2 months ago is finally done. Completely finished. Bug free! Well, almost. It is, however, in a fully assembled state with firmware that is actually pretty usable.

P8030108

The Unicone2 is the result of my mini-quest to extend Playstation 2 controllers over long lengths of cat5 cable. A while back I did something similar, extending Game Cube and N64 controllers over ethernet. That was the original Universal Controller Emulator, or Unicone. It used an FPGA, and a pair of Linux boxes. This time the design focus is low-latency, no PC required, and full support for Playstation 2 Dual Shock controllers and the Guitar Hero controller.

The Unicone2 went through a few redesigns before I settled on something I liked. The final version is based on a pair of microcontrollers and an asymmetric RS-422 link over cat5 cable. The remote end, where the physical controllers live, runs a PIC16F877A microcontroller. The base station, where all the consoles sit, uses the awesome Parallax Propeller, an 8-core microcontroller.

The remote unit’s job is pretty simple. It initializes and polls its two controllers, attempting to maintain a constant polling rate. The controller data is streamed over a very low-latency 250kbps RS-422 link. In its spare time, the PIC reads lower-bandwidth data (LED status, force feedback state) over an incoming 19200-baud RS-422 link.

The base station has a much harder job. It needs to emulate four controllers and receive data from two remote units simultaneously. These are all high-speed (250 to 500 kbps) asynchronous serial streams, with no flow control. It’s pretty much an intractable workload for most microcontrollers. I spent a long time trying to solve this problem with an FPGA, just like I did with the original Unicone project. This was working okay, but it was tedious. Playstation 2 controllers are even more complex than N64 controllers, and the problem doesn’t map well to the hardware domain.

When I first read about the Propeller, it seemed like a perfect solution to this problem. Just write one controller emulator, and run four copies of it simultaneously on different processors. The controller emulators and the RS-422 receivers communicate over shared memory, making the whole device quite low-latency. This also leaves plenty of CPU power and memory to emulate other flavours of video game controller, as well as leaving space to implement special effects like controller mixing and synchronized record/replay of controller events.

P8030070

I’ll end the hardware rambling for today. Paul or I might have to post soon with some more info about the gameplay implications of the Unicone2. Besides acting as an extender, it can already act as a controller crossbar switch and mixer, which will let us experiment with improvised multiplayer action on single-player games.

More photos of the Unicone2 are on my gallery. Firmware and schematics are in Subversion.