SPOKA Night Light controlled from and Android Phone

You people must have been wondering “what the heck was going on” and why haven’t I posted anything for the last 3 months or so… keep reading and you’ll find out more !

Some of you must have already seen something like this:

Ikea Spoka Night Light

It’s an Ikea Spoka night light and my wife really loves them… to the point that a while back she bought several of them, “just in case”…

We obviously only use one, so I’ve gotten her permission a few months ago to open another one up and play with it.

This project started actually back at the beginning of October 2011, but after doing the hardest part of it (reverse engineering the simple circuit) I had to abandon it in favour of the Stanford Artificial Intelligence and Machine Learning courses, which took most of my week-ends !

Then my son was born at the end of November, and here I am, more than 3 months later, having decided that I need to do whatever it takes to finish the project and post it.

I’m trying to do this while waiting for some special “mega servos” that I plan to use to automate my baby’s bouncer (those of you that have babies, know how important it is to rock them while they try to fall asleep, and what is the phonic price to be paid if not careful… :) ).

So here we go…

Originally, the lamp has 2 modes, that you can select with a switch at the top (which can also turn it off):

slowly change between the 3 available colours (blue, red and orange) while dimming the intensity

keep the same colour and intensity

The “obvious” hack would be to be able to customize the patterns of light that it can display. Another one would be to make it able to synchronize to some random music.

However it occurred to me that both this “mods” and plenty of others could be easily achieved by making the lamp controllable remotely, and then “simply” sending whatever pattern we want from the controlling device. This way we offload the logic to some more powerful device.

It could also lead to having more than 1 lamp synchronised, but this would be for another project…

The first idea was to use these 2 simple wireless transceivers and control the Spoka from my PC.

Then it dawned on me that it would be much nicer to control it from my phone, and what better choice than the IOIO to interface Android with the serial transceiver… ?

Not only it’s much cheaper than a IOIO + the RF transceivers, but it’s also quite small and especially, it doesn’t require anything to be wired to the phone (since then the IOIO also supports bluetooth, but then it would mean to integrate one in the Spoka which is not an option…).

However, as you’ll see later in this post (and as Ytai told me from the beginning :) ), this advantages come at a price, as the module seems more fiddly and there’s hardly any documentation out there !

Anyhow, the thought of having this little thing integrated in the Spoka and then being able to remotely control it from my phone, felt worth the effort !

1. Reverse engineer the light

Original Circuits

Thank you Ikea for having easily hackable, through hole boards !

Spoka Schema

2. Replace the IC with a custom one

The original IC was a 8 pin one and I would have really liked to be able to just “drop” in my own ATtiny45 or 85. This however proved impossible due to a different pin layout.

Original MCU removed, wires soldered

There was also the need for serial communication with the bluetooth module and 3 independent PWM for the 3 colours. While I’m sure an experienced AVR engineer could fit all this on an ATtiny 45, the thought of implementing software serial and struggle with the conflicts with the PWM timers, didn’t sound good and hence I opted for a 20pin ATtiny2313 that I had lying around and that provides hardware serial.

ATtiny2313 in place

ATtiny2313 in place 2

The job of the new MCU will be quite simple:

wait for incoming serial data containing the intensity of each colour (and a checksum)

provide some acknowledgement on the serial line

update the PWM values accordingly

And here’s the C code.

Notice that I have actually implemented 2 modes:

if the first character is a ‘#’ then you simply provide the intensity for each colour

if the first character is a ‘*’ then you provide a delay only, and the MCU does the transitioning from one colour to the other (similarly to what the original setup was doing, but with the extra feature of being able to change the speed of transition)

3. Connect the bluetooth transceiver

4. Program the Android phone

I love Android and its ease of programming in Java ! They really make your life much easier by providing everything one needs … Unless something doesn’t work as expected that is !

In my case, it was a matter of hours before I put together a simple view, like a joystick with 3 axes. It’s a simple gray dot that the user can move relative to 3 coloured circles, each corresponding to a set of LEDs on the lamp, which is supposed to update its intensity accordingly.

All the “back end” needs to do, is to measure the distance between the gray circle and the other 3 “reference” ones, transform this into a percentage and send it across the serial bluetooth line to the MCU.

Hey.. great project !!!
m a student in India…
m planning on making a bluetooth tag kind of something …which is to b controlled by a smartphone….after pairing it up with a application which ill develop on the smartphone….if the tag is taken apart say about more than 5m from the phone….it should trigger a alarm on the phone……can u plzzz guide me on that …….i wud love to b guided by u….

I don’t think the PCB’s are so different because you have the taller SPOKA model, but simply because you bought it at another time (mine was bought several years ago !) and they must have updated the design… I could check as I have a tall light too, but I don’t think my wife would let me hack the other one too … :)

Hi,
Sorry this is a bit off-topic, but:
Does your modified (or virgin) SPOKA stay on during a power-cut?
If mine is on and mains-powered, and then I turn off the mains power at the wall, the light goes out (rather than automatically switching to battery power): I wanted a nightlight for my son that would stay on during a power cut (he is badly scared of the dark), so the out-of-the-box functionality is no good for me.
I loved your hack by the way, I’d love to see a row of those responding to music at a party:)

Yes it does.
Funny, I had never noticed that before, the fact that when you unplug the power the original Spoka goes off.

Yeah, this idea of having several of them connected to the same phone and lighting up in sync seems to be one of the most interesting… However, I don’t feel like going through all the soldering again several times… :)

2nd, went to IKEA got one of the lights myself to try this nice mod :-)
Reverse engineered the PCB and asked myself: what the heck do they do with Q1??!!
Do you have any idea what this piece of circuit is for?
How did you connect IC.3 and IC.4 to your uC?

Have no idea about Q1, I haven’t spent too long understanding everything, I simply assumed all the transistors were there to drive the LEDs.
ALL I did, was to connect 3 of the pins of my new MCU to the lines controlling the LEDs (1 per colour) and 1 extra pin to the switch button at the top of the Spoka.

For pins 3 & 4, as you can see from my little diagram (the only one :) ) IC3 was connected to the switch which is now connected to PB1 on the ATTiny2313 and the old IC4, is not connected to anything, I think it just pulls up IC3.

YES, indeed, now the battery only lasts for a couple of days, even if the lights are off ! You can see that my simple hack doesn’t deal with any “sleep mode” for the ATTiny, so it keeps running in the background all the time… worst probably, is the bluetooth module though.

Normally, I should have a mode where both the MCU and the bluetooth board go to sleep (I think it’s supported by both, but I couldn’t be bothered… lol… :) )

Judging from the circuitry surrounding Q1 my first thought was that it is some sort of switch. The idea is that it shuts down power to the µc when it is put into off mode. Pressing the pushbutton turns q1 on for the time of the button press. the µc then initializes and pulls an output-pin to ground level so that Q1 will remain conductive after the button has been released. I might be wrong about this, as i did not verify this yet. I’m putting some more time in improving the C code which is quite difficult as i never did anything in C before, only Perl. I thought about porting to the atmega8, including obdev.at’s v-usb stack and add some features like RFM12-radio relay support(so you can control multiple lights wirelessly from one master light that is controlled by usb or bluetooth) but this is easier to do in asm than in C (at least to me it is :) )

Initially the switch had 3 modes (so NOT only on /off) : off, on and constant light, on and changing colours… so I’m not sure about the Q1 used to put the uC in off mode… but I’m really not an expert…lol…

Awesome job Ytai, before we know it everything will be Android controlled!

I have had pretty much exactly the same problem while making my Android controlled LED shirt (www.youtube.com/watch?v=DcY8FnuDObA). I ended up only using unidirectional SPP communication on my Android HTC INC2 using the BlueSmirf modules from Sparkfun, so you can feel good that spending more money wouldn’t have solved the problem. Most of my BT code came from the example from the SDK.

I think we’re onto the right track on concatenating the results of different read operations. I had my best results reading one byte at a time without a timeout in a separate thread, and padding all transmissions with a start string (say ***) and an end string (say &&&). This way I would keep reading until I saw an end string and the length was correct. This got pretty close, but still wasn’t perfect.

And as the Halloween party I was going to wear the shirt to came closer, I came to the same conclusion as you that ACKs weren’t really necessary.

I hope sometime in the future someone figures this out and shares the code. If I do, I’ll keep you up to date, and I hope you’ll do the same.

So you’re saying that you have the same problems with the BlueSmirf module from Sparkfun… interesting…
Ytai mentioned that his does indeed uses bi-directional SPP over bluetooth for IOIO, and it works OK without him having done anything special …

I’ll definitely be interested if you find a solution, and will obviously post an update here if I find one myself !

Ooops, yea I meant “Awesome job, Dan”. That will teach me to stay up late posting comments. I am planning on upgrading the shirt soon to sync with music using the Android mic. Hoping I can adapt the code from here (http://code.google.com/p/moonblink/wiki/Audalyzer) I’ll take a look at Ytai’s code when I do.

I picked up your project on heise.de and was fascinated as i am building led lights for quite some time and this seems like a perfect device for starting something new. I think you can replace the LEDs with red, green and blue ones. As the voltages of typical blue almost matches the built in purple and typical green almost matches the built in orange, this shouldn’t be too much of a problem. I also thought about replacing the mcu with something similar to http://davehillier.wordpress.com/2009/03/30/building-the-cube/ . But your project is even better as it can be used as a wireless notifier, even from a pc :) However i’d still prefer the wireless transceivers (RFM12, about €5 each on various sources). They have a much greater range than bluetooth.

Wow, the light cube you link to is quite nice… I like the minimalistic approach, small MCU that must be doing the USB in software, etc. … I was too lazy to implement even software UART, even less USB… hence the ATtiny2313 as opposed to a an ATtiny45 (which was also my initial idea).

Regarding you wireless transceivers, again that was my initial idea, and I had even got 2 of them (see this post https://trandi.wordpress.com/2011/10/24/simple-serial-transceiver/) specifically for this task…
However, bluetooth is so much cleaner on the phone side… otherwise I would have had to have the transceiver AND a IOIO or similar hanging from the phone.
With bluetooth, you can use ANY phone, no need to attach any extra hardware…

Thank you.
For the schematic, I don’t have any formal drawing (and I won’t open the lamp again now to draw it retrospectively… lol… :) ) but it’s quite simple.
You can find some more details in one of the other comments…

Thats a really nice project. While I know my way around electronics a little bit I never created an app on Android. Can you outline how to create an app using your source code? Do I need additional tools like an SDK?
Kind regards from Munich, Germany, Andreas
PS I came to your site by the http://www.heise.de portal

Yes you don need an Android SDK.
Here is really not the place to go into details about how to get started with Android, if you do a search on the internet you’ll find literally thousands of articles about it…

I started working with the SDK and Eclipse. I created an AVD for Android 2.2 , API level 8. In Eclipse i have the 4 java files under src/trandi.spokalightbluetooth, the 4 XMLs under res/layout and strings.xml under res/values. I got errors for BTDeviceListActivity.java and MainActivity.java and exclamation marks for the other 2 java files as well as for custom_title.xml, main.xml and strings.xml.

Could it be that with Android 2.2 I use the wrong version and this beeing the reason for the errors?

Done, I’ve just sent you a zip with all the code.
Actually it has one little improvement: a button that if toggled will automatically generate random movements of the “joystick” and hence random colours, every 1 seconds.

Dan

P.S. also, it’s never a great idea to post your e-mail in clear on a blog as you’ll receive plenty of spam from web crawlers… hence I’ve deleted it from your comment…

ahh I forgot. I just have errors in BTDeviceListActivity.java
I had to import the R.java. in the MainActivity.java, because it was not imported there, but needed. My first Error in BTDeviceListActivity.java is in line 68 following.
” private OnItemClickListener _deviceClickListener = new OnItemClickListener() {
@Override”

HOWEVER, let me make this clear: the code bits in this post are “snippets” and are not meant to be directly “compilable” ! It’s meant to give you an idea (and serve as a reminder for myself :) ) but it does require some work to put together.
The post itself is NOT an instructable where you follow some exact steps and voila you get the final result… it’s provided as information only, and you are supposed to provide some extra work to have a functioning prototype…

In any case I’m curious to see if you guys can get other working Spokas, do let me know or send me photos as soon as you get to something !!!
Dan

I’m a totally Android beginner but after I got the source and upgraded JAVA to 1.6 (or 6) I have been able to create an app and put it on my phone (HTC Desire with 2.2) even if the app is 2.3. With JAVA 1.5 (or 5) the code won’t work.
I go step by step and the first step is completed. I just ordered a bluetooth transceiver from EBAy but that will take some time.
Kind regards from Germany
Andreas

It should be ok. To be honest I don’t pay much attention to the warnings myself, so can’t be sure.

I’ve sent you my .hex compiled binary, in case it helps.

As mentioned, this is experimental code and I’m working on other projects right now(the kind that need their nappies changed every 3 hours and scream when hungry… :) ) so don’t have time to look into the details…

It’s also an occasion for you to learn more and debug the code… lol :)

I finished “my” Spoka :-)
I replaced the PCB and put the AVR with SMD5050 RGB LEDs on the same, these give nice colored bright light. Iapplied some “improvements” to the code w.r.t. deep sleep mode and the color change (dynamic) mode.

Thanks again for the nice Idea. I can share my mods and some snaps if you are interested.

It’s really just the bluetooth board and the ATtiny2313 ! And some wires :)
The great thing about the Spoka is that it’s simple but has everything needed to drive the LEDs included… obviously given that the original MCU had to do the same thing.

You’ll have to keep in mind that it runs on 3 AAA rechargeable batteries, so you need an MCU that runs at 3.3 volts (as opposed to 5V).
It’s also good to have and MCU with hardware UART if you want to avoid having to implement it in software, as per my post…

Perfect! – I’ve dissasembled the Spoka some month ago and just finished an microcontroller project ( Competition Pro – C64 Joystick on iPad for C64 Emulator ) and the Spoka has to be controlled with an iPhone soon! :-)

As I am an android beginner I wanted to download your java and xml files and understand them. Unfortunately the syntaxhighligher used on this page scamles the xml files, e.g. some tags and beginings of lines sterting with “<keyword … " are partly removed. In particular the main.xml file and device-list.xml are not usable anymore. Is there an alternative way to post the code? e.g. a link to a zip file which includes all source files unencoded?

This is a fair point, I’ve never made a “formal” schematic given that the circuit is fairly simple :
– connect the 3 LEDs pins to 1 PWM pin of the micro-controller each
– connect the switch to a digital input pin
– connect the bluetooth module to the UART pins
– then all you need is to connect GND and VCC to both the MCU and the bluetooth board and that’s it you’re all settled

In my pictures you’ll see a 6 pin ISP header connected to the MCU, so that I can re-program it at will, but you don’t technically need that.

If you want the exact pin numbers, just have a look at the C code running on the ATtiny.

I was thingking about the same project many times.
I would love to use it as a wakeup light controlled and triggerd from the mobile phone.
but thats now only a software thing! Thanks for that!
the next free time i have will go into rebuilding you project.

You’re right it wasn’t that easy… I haven’t used any tools, just strong fingers ! Same for putting back.
Once you remove the plastic shell from the silicone skin however, you need some sort of screwdriver to open it up. It’s actually glued together so you have to be careful to slowly break the glue without damaging the plastic shell too much…

However you don’t need to glue it back again, as the 2 halfs fit well together and the silicone skin holds everything nicely in place.

yeah, didn’t even know about this German site before, but it seems to be quite a big thing… some of the guys there argue however (they certainly have a point) that it’s not recycling enough stuff to be worth mentioning… lol…:)

just found your project on heise.de. it is awesome!
heise is a great publisher in germany which publishes the c’t-magazine. it is one of the best known technical magazine in germany. (print run about 400.000 pieces)
congratulations for that! ;)

Hey, I’ve used the same bluetooth module here http://microhobby.net/26-06-2011/projects/bluetooth-robot-bt-bot/ but I did not do any android programming though, I used an app which is very configurable, great for testing and prototyping before developing your own. So this is my suggestion to you, download that same app (QkCtrl) and use the terminal window to see if you receive garbage there also, then you know if it’s your app or not.,

Re changing the pinout of your favorite 8-pin micro: just use 2 sockets, one atop of the other. On the upper one, clip all the legs and solder in short lengths of solid core wire. Plug the proto wire into the lower socket. Apply liberal hot glue inside the sandwich and the sides, and you would have the adapter you wanted.

Not that you need it here – the 2313 is more capable and better solution. But you presented the above pinout differences as a barrier.. there’s always a way. :-)

I saw the bat-light :)
I don’t think your problems are Bluetooth-related. From my experience, once the socket is open, the connection is reliable. You’re doing some weird stuff in your reader thread. First, I don’t understand why you’re creating the BufferedIS inside the loop and not once before the look. Second, you’re segmenting your incoming data to Strings according to how many bytes a give read() operation has returned, which is absolutely arbitrary (i.e. if the remote end sends a 3-byte message, it might be received as a 1-byte read followed by a 2-byte read). So your “contains()” call is not likely to succeed in many cases. It is also very wasteful, since you’re checking the last string over and over…
What you really want here just is a read with timeout. For that purpose, you don’t need a thread and you don’t need a buffered IS. You can have a simple loop checking IS.available() and the elapsed time and sleeping shortly. A more elegant and slightly more complicated solution can involve a thread that notify()’s the main thread and an additional timeout timer that notify()’s is too. The main thread can simply wait() until either event occurs. But don’t go there unless you’re super-comfortable with multithreading.
Last, why do you need the ack? Why don’t you just do unidirectional communications?

Anyhow, very neat project. Hope it’ll help your baby sleep and get you some rest :)
Congrats!!!

I totally agree about the “weird” stuff in the reader thread… it’s actually shameful for a Java programmer by day… :) However, here’s the story and why I ended up with that abomination:

– I started with no separate thread, exactly as you suggested, just reading the bytes, but I got crappy characters

– then after looking at the example that comes with the Android SDK I introduced the reading thread. Simply storing the bytes received in a thread safe list. To no avail !

– then after looking on the Internet for a while, I discovered that I had the exact same problem as THIS guy ! For obscure and un-comprehensible reasons, if I was creating the String in the reader thread and store than rather than the bytes, the text would be OK !!!

– however, again as you mention, the generated / stored strings are completely arbitrary, so I then attempted to put them together in one big string / array so that I can do “contains” on that. And then, again completely inexplicably, I stopped working, I get garbled text !!!

– this started to become quite frustrating, so I gave up and currently (as you can see all that code is commented out) I’m doing only unidirectional communication.

The perfectionist in me would have wanted the ACK, for the same reasons why I put that basic check-sum byte… to be able to re-send if necessary, and to have a more “robust” code (euphemism for “over engineering” :) )

So, when you say “From my experience, once the socket is open, the connection is reliable.” were you using SPP over bluetooth, or something else ? If yes, then it might be some obscure problem with the native bluetooth driver on my specific phone model ??? (I know it’s always easy to blame others rather than your own code… :) )

An easy way to check if your phone’s Bluetooth is reliable is to check whether it works OK with the IOIO over Bluetooth. It indeed uses SPP as well.
Either way, as I said, I think the ACKs are completely redundant. The BT stack already takes care of providing a reliable connection, so you can assume that either your message got through, or the connection dropped and you’ll get an exception.