NOTE: The modifications I'm about to describe have certainly voided my X10 warranty and could cause irreparable harm to the X10 Ninja unit and anything connected to it. Who knows? They may even create a fire hazard! I'm only reporting what I have done and not advocating that anyone else try it. If you do, and things go badly, it's your responsibility. I make no warranties or accept any liability for others trying these modifications. So, if you decide to emulate my actions, proceed at your own risk!

The X10 "Ninja" pan & tilt unit is designed to pan and tilt a small video camera by remote control. It consists of a plastic-housed base with two stepper motors and associated electronics, along with a camera platform that the motors can move. One motor pans the platform horizontally; the other, tilts the platform up and down. The electronics consist of an EM78P156ELP microcontroller, with a 4MHz ceramic resonator, a 24LC08 EEPROM, a 7805 voltage regulator, NPN open-collector drive transistors for the stepper coils, a centering sensor for each axis, and an RF receiver for remote control commands.

In typical use, a button is pressed on the handheld RF remote for left, right, up, or down. As long as the button stays pressed, the platform will slowly move in the commanded direction. Movement is along one axis at a time. X10 sells a software package (PanTilt Pro) that includes a USB-connected transceiver (CM19A) for controlling the Ninja from a PC. However, the software is tightly bound to Microsoft NetMeeting, and the hardware accesses the Ninja via the same RF link as the handheld remote. Not much room for experimenting here!

Nonetheless, a friend whose webpage I'll link to when he posts the information (hint, hint!), came up with a very clever approach to directly controlling the Ninja from his computer. This was done without making a single modification to his pan and tilt unit or reverse-engineering X10's software. He has linked the RF remote to his PC's serial port via a Ubicom SX18 microcontroller. The SX18 accepts RS232 commands and sends the proper corresponding bit sequences to key the handheld remote's RF oscillator. This technique bypasses the remote's onboard microcontroller altogether, using the unit simply as a dumb transmitter. The beauty of this modification is that it requires but a single pair of wires going into the remote, requiring minimal trace-cutting and soldering.

When I looked at the pinout of the EM78P156E in the P&T unit, I realized another approach was possible. You see, the EM78P156 is a Chinese PIC knockoff with an identical pinout! I could just unsolder the thing and throw it away, replace it with an 18-pin PIC or SX, then program the unit from scratch to behave the way I want it to. This is assuming, of course, that I could figure out a way to connect it to my PC.

First, though, I had to figure out how the 13 port pins on the micro were being used. Here is what I found (using the PIC/SX port names):

RA.0 - RA.3 (output): These drive the bases of the four transistors that drive the "tilt" stepper. Pulsing any one of these outputs high energizes the corresponding motor coil. X10 drives the coils one at a time (wave drive) to move the motor, de-energizing them all when the motor is stopped. By sequencing the pulses, the motor can be made to raise (RA.0 -> RA.1 -> RA.2 -> RA.3 -> RA.0) or lower (RA.0 -> RA.3 -> RA.2 -> RA.1 -> RA.0) the platform. X10 uses back-to-back pulses about 15ms wide, giving a step rate of about 66 steps per second.

RTCC (input): This is the demodulated pulse input from the RF receiver, which exists on a separate board from the main printed circuit. RTCC isn't a real port input on either the EM78P156E or the SX and low-end PICs, though it can be "read" with some effort. On high-end PICs, this pin can be addressed as RA.4.

RB.0 - RB.3 (output): These drive the bases of the drive transistors for the "pan" stepper. The sequence for clockwise rotation is RB.0 -> RB.1 -> RB.2 -> RB.3 -> RB.0; for counter-clockwise, the reverse.

RB.4 (input): This is the input from the "pan" center sensor. As the unit is panning clockwise, this input will go from low to high when it passes through the center position.

RB.5 (input): This is a multiplexed input for both the "tilt" center sensor, and the "mysterious third wire" that comes from the wall transformer. More on this later.

RB.6 (open-drain I/O): This is the I2C shift clock (SCK) for the EEPROM and also a multiplex selector for RB.5. When RB.6 is pulled low, RB.5 tracks the "tilt" center sensor, going high at the center position as the platform rises.

RB.7 (open-drain I/O): This is the I2C data line (SDA) for the EEPROM and also a multiplex selector for RB.5. When RB.7 is pulled low, RB.5 tracks the state of the extra wire coming from the wall transformer.