Wireless Accelerometer Controlled Rgb-LED's





Introduction: Wireless Accelerometer Controlled Rgb-LED's

MEMS (Micro-Electro-Mechanical Systems) Accelerometers are in widespread use as tilt-sensors in mobile phones and cameras. Simple accelerometers are available both as ic-chip's and cheap development pcb-boards.
Wireless chips are also affordable and available in assembled circuits, with matched antenna-network and decoupling-caps onboard.

Hook both wireless board and accelerometer up to a microcontroller via serial interface and you have a wireless controller with nintendo-wii functions.

Then build a receiver with the same type of wireless chip and pwm-controlled rgb-LEDs, voila, you have wireless, tilt-controlled coloured room lightning.

Keep the transmitter-board level with breadboard facing up and the LED is cool blue, only blue led is active. Then tilt the transmitter in one direction and you mix in red or green depending on which direction you tilt it. Tilt all the way to 90 degrees, and you go trough all mixes of red and blue or green and blue until only red or green is active at 90 degrees tilt. Tilt a little in both x and y direction and you get a mix of all the colours. At 45degrees in all directions the light is an equal mix of red, green and blue, in other words, white light.

The parts used are available from internet hobby-electronic stores. Should be identifiable from some of the pictures.

Step 1: Transmitter With Accelerometer

The transmitter is based on the Atmel avr168 microcontroller. The convenient red board with the 168 is an arduino-board with voltage regulator and reset-circuit. The accelerometer is connected to the avr with bit-banged i2c bus, and the wireless board is connected with hardware SPI, (Serial Peripheral Interface).
The breadboard is completely wireless with the 4,8V batterypack strapped underneath.

The wireless board and the arduino wee accepts up to 9 V and have onboard linear voltage regulator, but the accelerometer needs 3,3V from the regulated rail on the wee.

Step 2: Receiver With RGB-LED

The Receiver is based on the atmel avr169 demoboard named butterfly. The board have a lot of features not used in this project. The wireless tranceiver is connected to PortB and the pwm-controlled led is connected to PortD. Power is supplied at the ISP-header, 4.5V is enough. The wireless board can tolerate 5V on i/o pins, but need 3.3V supply which is supplied by the onboard regulator.

The modified header-cable for the rf tranceiver is really convenient, and connects wireless board with power and hardware spi controller on the butterfly.

The shiftbright is a rgb-led pulse width modulation controller which accepts a 4 byte command which is latched in and then latched out on the output pins. Really easy to connect in series. Just shift out many command words, and the first shifted out will end up in the last connected LED in the daisy-chain.

Step 3: C-programming

The code is written in C as I didn't care for learning the "easier" processing language which arduino is based on. I wrote the SPI and rf tranceiver interface myself for the learning-experience, but borrowed the i2c assembler-code from avrfreaks.net. The shiftbright interface is bitbanged in C-code.
One problem which I encountered was small irradic variations in accelerometer-output, this made the led's flicker alot. I solved this with a software low-pass filter. A moving weighted average on the accelerometer-values.
The rf-tranceiver support hardware crc and ack with auto-retransmit, but for this project the realtime, smooth updating of the leds was more important. Every packet with accelerometer values does not need to arrive intact at the receiver, as long as corrupted packets is discarded. I had no problems with lost RF packets within 20 meters line of sight. But further away the link became unstable, and the leds did not update continously.

The main loop of the transmitter in pseudo-code:


Values = abs(get x,y,z accelerometer values());

The main loop of the receiver in pseudo-code:


newValues = blocking_receiveRF());
rgbValues = rgbValues + 0.2*(newValues-rgbValues);
write rgbValues to shiftbrigth;

Step 4: The Result

I was amazed at how smooth and accurate the control was. You really have fingertip accuracy control of the colour.
The pwm-LED-controller has 10 bit resolution for each colour, which makes for millions of possible colours. Unfortunately the accelerometer has only 8 bit resolution which brings the number of theoretical colours down to the thousands. But it is still not possible to perceive any stepping in colour-change. I put the receiver in an IKEA-lamp and took a picture of different colours below. There is also a video, (horrible quality though)



    • Clocks Contest

      Clocks Contest
    • Water Contest

      Water Contest
    • Oil Contest

      Oil Contest

    29 Discussions

    Great Project.

    Is there any way to use my Android Amarino App data of accelerometer or orientation sensor to control the RGB hex?

    the accelerometer you used was off ebay.com

    Hi, what is the name of the RF module board? you told about the RF chip, but I cannot find anything about the module itself, where did you take it?

    Thanks :)

    1 reply


    I bought the rf-module from sparkfun.com; 

    Transceiver nRF24L01+ Module with RP-SMA
    sku: WRL-00705

    Thanks for your interest!

    yes you can use the wiimote if you have the BT arduino or if you have a BT enabled laptop you could via serial send the data back to the arduino and use the data to do what you want

    sounds great, expensive, but great... now is it possible to use a BT arduino and send serial to it from the laptop over bluetooth too? (instead of just a direct usb connection... thanks

    the BT arduino should have all the same functionas as the usb only wirless and some extra capability too.

    sounds good i am definitely familiar with the wii chuck adapter in the link u included, but that site provided some new insight that helped me learn something new thanks

    Hey - do you mind including the actual code you used? I'm curious about the data analysis for your accelerometer. If you don't want to post it, could you e-mail it to me? (PM me for my e-mail) Thanks, -Josh

    1 reply

    I've posted some of the code, but unfortunately I've messed up the code for use in another project. The code posted is low-level routines for radio and shiftbright. It's not very clean, and not the best commented. Some variablenames migth be in norwegian:P I don't have time to change that now.
    The accelerometer post-prosessing is a oneline lowpass-filter in c-code. Look up lowpass on wikipedia.

    avg_value += (read_value - avg_value)/a

    where a is the lowpass filter constant.

    Thanks for your interest, I've bought almost everything from sparkfun.com, the led-boards are from macetech.com

    This is a really cool idea. I saw this a couple of weeks ago and decided to have a go at this as a first project. I am new to this kind of thing, electronics and micro-chip programming. I have just started a blog to document my attempt at this. So just thought I would leave a comment to acknowledge the source of inspiration for my project. Cheers.

    I haven't posted my own code because I don't think it's clean enough for the internet, it's just something I wrote in a hurry to test the concept. I didn't even bother to do the indentation right, honestly, really ugly code. The i2c-code is software-i2c and I found the code for it on[http:// www.avrfreaks.net avrfreaks.net]
    just search for "software i2c", it's an assembly-file named something like i2cmaster.S. If I have some time to spare one day, maybe I'll post a cleaner version of the code, but don't stay around and wait for it.

    The "easier language" for arduino is actually c++ with some preprocessing. Your program would probably compile and run as-is.