Introduction: Reverse Engineering: RGB LED Bulb With IR Remote
More by the author:
About: I like microcontrollers and LEDs :D
We bought 20 of these RGB LED Light bulbs for a party at work, but I was a little disappointed with the color fading functions they provided. So I decided to take one apart, reverse engineer the IR protocol, and see if it had more functions than those available from the IR remote.
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.
https://www.instructables.com/id/USB-controlled-home-automation-hack/
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.
https://www.instructables.com/id/USB-controlled-home-automation-hack/
Step 1: The Product and Proect Goals
This is a really cheap RGB LED bulb that fits into a regular E27 bulb socket. It has an IR remote that lets you choose between different modes and colors.
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.
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
The first obvious thing to do here is to sniff the IR led on the remote control.
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.
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
Now I have access to the data sent by the IR remote, great. However, IR remotes uses a carrier frequency to transmit their binary data. This creates a whole lot of garbage data in the logic analyzer. See the screenshot.
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.
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 want to poke around in the LED bulb itself to sniff the signal from the IR receiver, however, I dont want to probe this cheap china product while it is connected to 230 Volt 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.
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
Now that the bulb wasn't running off mains power, but on an isolated power supply, I was able to poke around and find the data pin on the IR receiver.
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.
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
I'll share with you a wrong approach that I tried before going into the correct interpretation of the data.
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.
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 googled IR remote protocols and found this document: http://www.vishay.com/docs/80071/dataform.pdf
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.
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 wanted to see if the LED bulb would accept any other commands than the 24 commands corresponding to the 24 buttons on the remote.
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 :(
Bummer.
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.
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 :(
Bummer.
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.
Attachments
Step 9: Conclusion
This product was very hackable in the sense that I could easily get in there and reverse engineer it.
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.
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.