Hi Guys,
I have a LED light of IKEA that control by tranceiver using TI CC2500 chip and now want to replicate the control for spare. However, this is a closed commercial product and there is nothing technical information. I just know it used TI CC2500 chip after tearing down the control and receiver.
The problem is that I don't have any experiences with TI CC2500. So that I cannot determine what should I do now.
Pls give me the advices if you knew. Thanks in advance.
Regards,
Here is photos of the control and receiver.
Any comments at least the theory or the way I should go. Please.
You seem to have double posted the same image in #1 and I suspect they should be different. Can you post images of the backs of the boards as well and also can you post an image of the board we can see in the background.
Can you tell us the make/model of LED light your talking about (preferably with links) and describe what buttons are on the hand held device and what they do.
Does the transmitter and receiver need pairing together before use as I wonder what the button on the board image you posted does?
Riva:
You seem to have double posted the same image in #1 and I suspect they should be different.
You're right. I have re-uploaded them on above.
Does the transmitter and receiver need pairing together before use as I wonder what the button on the board image you posted does?
Exactly. The transmitter and receiver need pairing each other before use. The button on the #1 board is used to do that. The button on the #2 board is used to control the light (on/off). I can't get model of LED light now, but the link of product on the web has no much information. At the moment, I want to know is it possible to replicate the transmitter?
Thanks
The system is using the CC2500 radio transceiver chips that work in the 2.4GHz range.
Google shows you can get these on little module boards to make connection to an Arduino possible and someone has written a library for them as well. This is not half of the story though as you will somehow need to determine the protocol they are using and maybe the keys needed for a particular paring.
Another option might be NRF24L01+ modules as they also work in the 2.4GHz range but a very quick look at the datasheet seems to indicate they have 64 byte FIFO buffers where I think the NRF24L01+ has only 32 byte buffers. For something as simple as turning on/off a light I would not expect the full buffers to be used though so they may be an option.
Yet another option is to just replace there entire board/plipper with your own system.
Riva:
This is not half of the story though as you will somehow need to determine the protocol they are using and maybe the keys needed for a particular paring.
What you described is that one I am cosidering but not sure. Assume that already had the keys for paring. So how can I do to get/determine the protocol?
Thanks
paiblaspebill:
What you described is that one I am cosidering but not sure. Assume that already had the keys for paring. So how can I do to get/determine the protocol?
There may be easier ways but my first point to look at would be if the firmware/code can be extracted from the MCU but it may be protected (I have not looked into the details of the TI MCU). The second option would be to capture the SPI data between the MCU and Radio chip using a logic analyser.
This seems to be a quite complexity. Anyway, thank for your time with me.
I've had the same problem as you. I wanted to know how the remote works because I wanted to use multiple remotes for one light.
If you're still interested in some explanation/code see my github (Work in progress):
@NDBCK - A nice explanation and write up.
I would assume there is no CRC to worry about though as the only byte to change in the packet is the level. If it also had a CRC then more than one byte would change.
Have you captured the code sent/received when pairing the remote?
You are right about the CRC, I didn't tought about the brightness changes.
I didn't capture the pairing sequence (my lamp and original remote where coupled before I sniffed the traffic).
I'm going to do some tests (changing some bytes and trying to pair the remote so I could identify the address bytes).
I presumed that the transmitter is dumb and always sends the same sequence. I've read somewhere that the used microcontroller (128K ram) doesn't have enough ram to use the full RX (64K) en TX (64K) buffers. It's always possible that it uses a small part of the FIFO however.
NDBCK:
I presumed that the transmitter is dumb and always sends the same sequence. I've read somewhere that the used microcontroller (128K ram) doesn't have enough ram to use the full RX (64K) en TX (64K) buffers. It's always possible that it uses a small part of the FIFO however.
To check if the transmitter is dumb press button between battery changes. If it works straight away without needing pairing again then it is not generating a new random key on power up (or the batteries need pulling out for a few minutes longer).
With so little data being sent the TX buffer will hardly be used and unless the light replies to the transmitter then the RX buffer will be unused.
I did check that, the transmitter always sends the same code. (I tried unpairing it an pairing again and againm the code remains the same).
All the tests I did, I disconnected and reconnected the batteries.
Now I'm trying to decode the pairing data but it's a little less obvious...
(There's a bunch of data sent witouth toggling the CS signals)
If the transmitter always sends the same code then the receiver (light) might be learning the code or when the pairing button(s) are pressed the light might be sending the key for the transmitter to use.
I've finished decoding the pairing data, I was struggling because the data I've captured was garbage (my ground connection wasn't solid so the sniffed data contained random bytes).
In short: the byte that the remote sends to change the status of the light is replaced by 0xFF.
So we can safely conclude that the remote is rather dumb, and the data that it sends is alway the same independant of the receiver.
Sure makes the job of cloning the remote easier if you only need to send fixed codes all the time.
What would be nice is extra code to allow the clone remote to capture the old remote tx data and use it for it's pairing key (whatever bytes they may be).
That's a good idee and I've done just that, I've written some code to read other remotes.
I didn't test it yet to clone a remote but reading the wireless data from other remotes now works on the arduino.
I've read the data from two other remotes than mine and found out that there are presumable only two address bytes.
So I can read the whole packet data and strip it to the address bytes (and save it in eeprom).