Other instructables related to reverse engineering:
If you find this instructable interesting, you should have a look at this. It also goes more in depth on the tools used in this instructable.
Step 1: The Product and Proect Goals
I want to use them in the color fade mode, but the color fade in these bulbs suck. For some reason they fade the LEDs to almost white color, which doesn't look that great.
I am hoping to find some hidden modes, or alternative ways of controlling this thing without too much work.
Step 2: Sniffing the Remote
I soldered on some wires to the LED, and put the cover back on, so I could have easy access to the signal while pressing the buttons.
Step 3: IR Carrier Frequency
One important thing I can get from the IR remote, is the carrier frequency. I used the frecuency measurement in my oscilloscope to measure this.
Step 4: Getting the LED Bulb Off Mains Power
I measured the voltage across GND and VCC, 5 volts.
I hooked some wires up to GND and VCC. I also disconnected the VCC from the bulbs power supply.
Now I'm ready to probe around the bulb without exposing myself and my equipment to mains potential.
Step 5: Sniffing the Bulb
I soldered a wire to it, poked my debug wires through the heatsink and put the cover back on the led bulb.
The little LED inside was too bright to work on it with the lid off.. luckily the heatsink had little slots in it for the wires to pass through.
As expected, the IR receiver on the LED bulb removes the 38KHz carrier frequency, leaving me with a much cleaner signal to probe.
On the logic analyzer screenshot, you can see both signals, one with and one without the 38KHz carrier frequency.
The signal from the IR receiver is inverse, so GND is high and VCC is low.
Now I am finally ready to get into the interesting sutff; figuring out how this thing communicates.
Step 6: The Wrong Way
If you look at the second picture, you'll se one packet captured with the logic analyzer.
It starts with a pulse of 9ms, then a pause of 4.5ms, then comes the data bits.
In the voids where there are no data bits, there is room for exactly one data bit. This lead me to believe that this remote just banged out the bits in a regular serial fashion. I expected it to maybe use some sort of variable length pulses to encode each bit, but I didn't see any variable length, so I assumed (incorrectly) that a pulse was a logical 1 and a void was a logical 0.
When doing this sort of thing, I like to capture on of each type of packet, and lay them out in the Gimp (open source photoshop, kinda).
After spending some time analysing the data, it didn't really make any sense, so I figured I was decoding it incorrectly... which turned out to be the case.
Step 7: The Right Way
I immediately recognised the NEC-format with its 9ms initialization pulse and 4.5ms pause followed by data.
The remote did use some sort of pulse length encoding after all..
A logical 0 is sent as a pulse of 560 microseconds, followed by a pause of 560 microseconds. (ca timing values)
A logical 1 is sent as a pulse of 560 microseconds, followed by a pause of 1650 microseconds.
The IR packet consists of a 9ms pulse, a 4.5ms pause, then an address byte and a data byte, and finally a single stop bit.
Each byte is transmitted twice. Once normal, and once with its bits inverted. So 0b11110000 would be transmitted as 0b11110000 and 0b00001111.
As you can see in the pictures, the address byte is always 0x00. Nothing interesting going on there.
I went back to the gimp and painted the logical 0s with a red dot and the 1s with a green line. Then I typed the bits into a spreadsheet. The data looked a lot like a binary count, only in random order. So I sorted the data by the bit columns starting with MSB.
As you can see, only the 5 most significant bits are used, and also some values in the top 5 bits aren't used, leaving me with a small hope that these bits could trigger some hidden features.
Not exactly as hacking friendly as I hoped it would be, but I'll still give it a shot.
Step 8: Introducing New IR Commands
I wrote an arduino program to send IR commands. I used a timer to generate the 38KHz carrier frequency and some functions to turn the timer on and off.
The program loops through all 256 possible command bytes (0x00 to 0xFF) and sends them as IR remote packets.
Turns out, NONE of the command bytes besides the ones from the remote control does anything :(
On the bright side, I was able to control the LED bulb from the arduino without any problems, But that wasn't exactly what I wanted to do :p
Also, the address byte doesn't do anything either. The bulb just ignores it. Any address i tried seemed to work.
If you want to control one of these led bulbs or any other device that uses the NEC IR protocol, you can modify my code to do so. The arduino code is attached here.
Step 9: Conclusion
If what I wanted to do was replace the IR remote that came with the product with an Arduino, I'd call it a raging success. However, I wanted to make the LED bulb do something more or something different.
If you want to have one of these bulbs be computer controlled, you can easily modify my arduino code to make that happen.