Many ask where the idea for the ps3toothfairy originated and how it came to be. The first unit was designed just for myself and was nothing more than a fully functioning prototype. I got some inquiries from various forums about getting one as well and so I redesigned the unit. The purpose of the redesign was to make it easier to assemble (remove all the wires) and make the device more reliable. I'll walk through the 3 iterations of the ps3toothfairy and its nameless predecessor. The silk on the prototype reads BTIR which obviously stood for bluetooth to ir. I plan on adding posts walking thorough the thought process, prototype design, build, test fixture, etc. Feel free to email or leave comments and ask questions.

Rewind to December 2007 -- The goal is to figure out how to get IR control of the PS3.  I found the Nyko, but it was too slow.  Stated simply, take the existing PS3 remote control and add some IR function to it.  Opening the PS3 remote, yields litltle more than a bluetooth radio / controller PCB and the (obvious) makings of a matrix keyboard.  A more detailed exam reveals that Sony just uses the Broadcom BCM2042 as the brains in an MCM build by Alps. Note that the BCM2042 reference designs show a Bluetooth keyboard and mouse for a PC.  Documentation and/or an SDK for this part is near impossible to obtain.  So the information here is gleaned by observation / probing the board and a small fact finding mission.

The module consists of

• BCM2042 -- This is brains of the remote.  It is a HID on a chip.  It has an integrated keyboard / mouse decoder, 8051 core, a couple of peripherals and most of the firmware in ROM.  This part has provisions for "patching" the firmware and including custom code in an external EEPROM (also on the MCM).
• An EEPROM for containing patches to the code as well as any custom code for the BCM2042
• Oscillator
• Many passives

The module does not contain the antenna.  It is on the main sony board along with the simple power circuit, the FFC connector, and battery terminals.  The main board has NO logic on it at all.  for the keyboard.  The keyboard connector on the PS3 remote board is 20 scan and 8 sense lines (or 20 outputs and 8 inputs).  IIRC, this exactly matches the reference design configuration ofthe BCM2042

Initially I thought I would hack a CSR Bluetooth dongle to do my bidding.  The CSR USB dongles are easy to reconfigure such that you can control them via their serial bus.  However, they do NOT have a HID in the firmware so that would have been some extra effort, though cheaper to do.  However, since it was supposed to be a one-off, cost is really engineering time vs productization cost.

It was clear that the easiest thing to do quickly is just build a circuit to emulate the keyboard and attach a smart circuit to the FFC connector on the radio.  I evaluated a couple of ways to do this. 

1. Build a custom CPLD based circuit.  The CPLD would run at the full speed of the Alps module and provide the keyboard interface.
2. Use a logic anayzer to determine the scanning order of the scan lines and use a micro to provide the 8 outputs.  Then use a scan line as a "trigger" to tell the micro to pulse the sense lines appropriately. 
3. Fully control the sense lines and input the scan lines in a micrcontroller.
4. Use a bigger CPLD and implement a microcontroller (such as a PicoBlaze) in HDL.

I decided to use a combination fo 1 and 3.  I used a CPLD to fully decode the sense and output the scan lines.  The microcontroller provides all the brains and uses a simple control protocol to read/write the mapping registers in the CPLD.  You can think of the CPLD as a matrix of buttons.  The micro tells the CPLD which buttons to close and open. 

The CPLD was chosen mainly because I figured Sony/Alps could at some time alter the scan rate or perhaps I had not covered all the cases.  The CPLD + small micro was less expensive than a micro that could fully decode the interface.  However it is more expensive than solution 2 where only a subset of the scan lines are input the micro.  In retrospect, this is probably the way I would do it again, but that is after a year of units with no change in the Alps/Sony design.

I used a Xilinx 9536XL CPLD.  It is the smallest one but footprint compatible with a part 2x the size in case I ran out of logic or needed more features.  The microcontroller is an AVR ATTiny2313.  The AVR family is one of my favorites and I have been using these controllers for several years. 

For the prototype stage, many people use schmart boards, a homebrew PCB, or "dead-bug" the parts.  For projects like this, it does not take long to design and spin a PCB.  Cost is ~100 USD give or take, but the reliability of PCB designs is much better than wired boards.  Here is a picture of the first prototype board.  This was done for personal use, so there is no ps3toothfairy marking on it.

Part of the challenge was to find a compatible FFC cable and connector.  I ended up using some costly Molex parts, but it was critical to making a reliable and compact design.  The pitch of the FFC cable/connector is 1mm.  This board is vastly different from what is now sold as the ps3toothfairy.  This board had provisions for many extra components that were not populated (aka no-pop).  Many of them are in case the initial idea didn't work out, an extra resistor was needed, more bulk capacitance was required, etc.  For easier prototyping, this board is lead plated and the vias are not tented.

The CPLD is in the center, close to the FFC connector with the JTAG connector just above and to the left.  The micro is the 20 pin SOIC to the right and a serial debug port is above it.  The FFC connector is at the bottom center.  At the far right on the top is the IR sensor, below that the LED, and at the bottom is the ISP port.  On the far left, top to bottom, is the power regulator, power input connector, and extra bulk capacitance.  A footprint for a crystal oscillator is seen just to the right of the microcontroller.  Some have inquired about the white patch in the middle.  On board designs, that is where I write the assembly revision if needed. The entire board was sized to fit into a Hammond enclosure so it would "fit in" with the rest of my gear.

One of the goals of the prototype was to program the CPLD through the microcontroller rather than use the JTAG port.  Just in case that did not work, I put an 8 pin JTAG header in.  The Xilinx parts only need 6 wires, so there are a few unused.  On the original I never populated the JTAG port since I was able to program the CPLD via the microcontroller using PlayXSVF on a PC communicating via the ISP cable to a custom firmware on the micro.  The sequence went like this:

1. Program a CPLD firmware into the micro
2. Use the host PC to instruct the micro which JTAG wires to toggle using playxsvf on the PC along with a couple of mods to communicate to my sp12 programmer.
3. Download the operational firmware to the micro.

This worked as expected.  The drawback of this approach is it is slow (about 1.5 minutes).  The signal integrity of the long parallel cable is probably the biggest issue.  The big advantage is that you only have to attach 1 dongle to the board to program everything, so it is easily scripted.  Ultimately this is how the ps3toothfairy devices were configured and programmed.  None of the current ps3toothfairy boards even have the JTAG header.  It is done entirely via the microcontroller.

Upon receiving the board, I did the normal tests such as power-ground short and inspection for broken/cut traces, lousy drills etc.  Didn't really see any problems and this board had 10mil space/trace so I didn't expect much trouble.  I went ahead and populated the board by hand and found 2 errors.  The first was an incorrect footprint for the power connector.  The mechanicals were correct, but the wiring was wrong.  A 0 ohm resistor between two pins on the bottom fixed that problem.  The next was the lack of pullups on the FFC connector.  I was surprised I'd forgotten this, since it was on my checklist.  In any case, the goal of all prototypes is to get working as much as possible with each spin so as to minimize the number of board spins.  I stood 20 0804 resistors up on end on the 20 pins of the connector and bussed them to the Vdd pin to the left of the bottom left mounting hole.  It was challenging to get them that close and standing up, but it only took 20 minutes or so.  I'll post a picture of that board soon but it is at the parents house so I don't have it with me.

Those 2 fixes are all that was required and the board worked fine.  On this first version I used the PS2 IR commands with my JP1 remote and just implemented a dumb power down macro to turn the unit off.  The functional part of the code was implemented as a software state machine.  The big advantage of those is that they are easy to debug since it is straight forward to walk through all possible combinations.  The design cycle is to draw the state machine on paper and then just label / name the transitions.  Then write the code.  The actual mechanics deserve a post of their own.  One of the main advantages is that it is easy to do things such as timeouts, double presses, hold a key for n seconds, etc when working in a state machine.

The code is straight forward, while idle do the following

1. Upon a timeout send an event to the state machine
2. Wait for IR signal, start timer
3. Decode IR signal (on press), stop decoding on release
4. On press, If it matches my device Id, decode the function Id
5. send key press/release event to state machine

The board fit fine in the chassis and I got the IR blanks for the ends.  One of the reasons for using this power connector rather than the more common CUI is that this one has a shorter mating length, making it more compatible with the adapters I might already have while stilli drilling a reasonable hole in the chassis.

That is all there is to the first device that woudl eventually become the ps3toothfairy.  Some friends were interested and encouraged me to redesign it to integrate with an IR system and sell them if I could.  That led to the 2nd generation device and the first device to carry the official moniker.  The 2nd generation board is shown here.  The changes are the additions of the pull-up resistors, footprint fix for the power connector, removal of the crystal, JTAG, and debug headers.  The ISP header is also not populated on production boards, though it is in this green prototype board.  The regulator was also changed to a National Semicondutor LP series regulator.  The one on the prototype had been end-of-lifed and I was unable to find a footprint compatible part.  Fortunately the LP part had many footprint compatible parts.

The major addition (by request) was for the wired IR as requested by a person that wanted to use it for their Control4 system.  The wired IR resulted in the most changes.  There is a filtered / buffered / protected input that then redrives the signal to the microcontroller.  The input is protected against reverse voltages and also has a transistor amplifier in place to make sure that the analog electronics do not see any impedance changes as a result of different drivers used with the system (i.e. Logitch, Xantech, etc).

This board only had 1 problem and that was there was not a sufficient load on the wired input for the circuit to function correctly.  Adding a reasonable load fixed that problem.  Everything worked on this device.  It did require some firmware modifications to handle the wired input and some of the configuration options that people expressed interest in.   In April of 2008 I started the ps3toothfairy thread on the AVSForums.

Advance to May of 2008.  The production version (shown below) differs only in the addition of the load resistor, no-pop the ISP pins, and a narrower band IR receiver.  The change in receiver was done purely due to availability. The black boards production boards and have a date code in silkscreen on the board.

The production boards are still programmed the same was as the first prototype by loading custom firmware to the micro that in turns programs the CPLD.  The state machine and HDL code are identical to what was in the very first prototype.  The configuration options and some of the IR decode logic are different to handle the different IR addresses.

I plan to continue posts about the device and how it works, in no particular order.  I'll let the comments tell me what people want to hear next.  In the meantime I have 3 new PCBs coming in this week.  There will be an LED controller board.  A high current LED adapter, and a micro programmer for the AVRs.