The small red dot in the center of the image above is where the hardware is (the boxed Arduino) with the PIR to the left. It’s hard to make a picture in almost complete darkness – keeping the picture sharp but also getting a result with colors that match with what my own eyes see is not that easy.. But the picture above resembles what I see when I get out of bed during the night well enough – and it’s exactly what I wanted! The LED strips (1.5 meters on both sides of the bed) light up the floor well enough to spot any obstacles, but it doesn’t light up the whole room. And the 15 seconds turn out to be the right amount of time to light up the floor; and the LDR takes care of unnecessary lighting during daytime; so in one word, the only conclusion can be: perfect!
One small glitch though, which points out the difference between a clean testing environment and usage in real life: some days ago, when I had to change the alarm clock, I switched on the bedside lamp so I could see the buttons on the alarm clock. This triggered the LED strips to go on!
This means that the switching of the 230V lamp resulted in a ‘spike’ on the PIR sensor input on the Arduino… hmm. I think I’ll have to redo some wiring and use shielded cables instead of the unshielded & untwisted ones I’m using right now. My bad…
Perhaps another solution would be to watch the incoming PIR signal on the Arduino more closely and detect whether it’s a short ‘spike’ or not and decide not to turn on the LEDs on a short ‘high’; but that just doesn’t feel right – cables first!
This evening I wrote a sketch to protect my toes better. The sketch switches the LED strip on and off based on motion detection by 2 PIRs. It works 😉
The blue LED on the Protoshield indicates when there is motion detected by the PIR. The motion detection turns the LED strip on and it will stay on until a period of 15 seconds with no motion has passed – only then, the LED strip is turned off again.
The sketch takes care of the “soft on/off” feature, by gently raising or lowering the brightness during a configurable time-span.
All that’s left to do is cleaning up the code, solder some wires, wait for the enclosure to arrive and give the LED strip, PIRs and Arduino enclosure a place under the bed.
Last week I had some trouble getting out of bed during the night without hurting myself. So this evening I decided to do something about that; I need something that can light the floor while someone is walking through the bedroom at night. So I made a list of things with which I could make something useful for that:
An Arduino Duemilanove;
2 PIR motion sensors;
a IRLZ34N MOSFET to drive the LED strip;
a 12V power adapter;
about 2 m. of white LED strip;
2 LEDs (one for power and the other for motion detection);
an Arduino enclosure.
There it is… our automatic bedroom floor lighting is being tested at this moment. The 2 PIR motion sensors will be mounted under the bed in a way that they will only be able to detect motion caused by moving legs, the LDR will be used to detect whether it’s dark in the bedroom or not and the white LED strips will be glued to the bottom side of the bed and will light the floor when motion is detected.
The fun thing is that this floor lighting is almost completely built from spare parts (except the enclosure). The 2 PIR motion sensors were the first motion sensors I ever bought, but the lenses were too big for my taste to actually use them. Under the bed the size of those lenses doesn’t matter. The Duemilanove is one of the many Duemilanoves I have laying around for testing/experimenting, so I can easily do with one less – I could also have picked an RBBB, Teensy or JeeNode. The number of unused protoshields made me decide for an Arduino. And all the other parts were all purchased in the past with the thought they’d be handy to have around for when you suddenly need them 😉
No RF, Zigbee or Ethernet this time – this will be a solution that doesn’t need any other external input, nor do I think I’ll use the fact that someone’s walking through the bedroom in the rest of my system. Nevertheless, I’ll reserve some space on the Protoshield for a XBee Breakout board cause this would actually be a very good place for a Zigbee router on the 2nd floor!
The sketch will be a collection of code from other sketches I’m already using, so I hope that at the end of this week I can finish this and never hurt my toes again 😉
The motion sensor i finished yesterday needed some last tests; namely, what resistor should i use? Internal? External? And in the case of external, what value? Now the internal pull-up resistors of the Arduino are 20 k. But why not try to use a higher value, cause even with this resistor the rule V = I * R applies, right? When the JeeNode is in power down mode, i measure 1.36V over the external (100 k) resistor I used till now. That means there’s a current of 13.6 μA going through the resistor. With the internal 20k resistor this would be 5 times more: 68 μA! Yuck! And all that in power down mode, no way!
OK; i bought a huge case with an assortment of resistors a few years ago, ranging from 12Ω to 1 MΩ. Hey, let’s try that last one, 1 MΩ. This will add an additional factor of 10 to the external resistor value, resulting in the current dropping to 1.36 μA. And guess what; with this resistor the behavior of the PIR didn’t change; this is very nice! I hope I’m not overlooking or breaking any electrical laws or rules by doing this, but this seems the right thing to do..
Programming the XBee and placing it in the breakout board is all there’s left to do; I guess you could say this 3rd sensor is finished! 🙂
This evening I started building the first ELV PIR13 based motion sensor. Looking at the time right now, I think it took me 2.5 hours; during that time I soldered a JeeNode, attached a cable to the PIR13, soldered a XBee breakout board, soldered the wires to the JeeNode, drilled some holes in the enclosures, … well here’s the result:
With each sensor that I build, it’s becoming less time consuming to build the hardware. With the sketch compiled and uploaded in debug mode, i wanted to see if everything was working OK, and it did. One last thing has to be resolved before i can move this sensor to it’s final location, and that’s if I can enable the internal pull-up on the interrupt pin. I probably can, but maybe that’s not such a good idea. I mean, a pull-up resistor consumes power, so it matters if it’s 100 Ω or 100 kΩ, right? What if the resistor can have a higher resistance (and the PIR still working well) than the internal pull-up? Would that save me energy? And how much? An issue to spend the next evening with, cause this is all to new for me to decide based on experience or knowledge…
So that’s why i added a header on JeeNode port 2 (click the image and you’ll get a more detailed view) and put a resistor in there, between P and I; so I don’t have to rely on the internal pull-up if I don’t want to but can also discard that external resistor – based on what I think is best based on my findings.
Although i came home rather late this evening, i had about an hour left to proceed with the ELV PIR13-based motion sensor. Let’s see if I can get the PIR13 working on an interrupt pin…
I took the sketch from motion sensor v2 as a start, changed some minor things and uploaded the sketch to the JeeNode. Bummer, I forgot that now the PIR13 output pin is attached to an interrupt pin, there’s no more internal pull-up enabled. That’s why the thing isn’t working! Adding an external resistor between + and the PIR output solved this as you can see by looking at the output:
The changes that had to be made to the sketch to get the PIR13 running were minimal, so I will change the Motion v2 sketch in a way that it can be used with the Panasonic PIR as well as the PIR13; just to keep the number of sketches used to a minimum.
Two PIR13’s arrived yesterday. I immediately unpacked them to see if they would fit in the enclosure I want to use for them. It fits, but there’s not much room for error.
The lens is larger than the one on the previous PIR I used; this one requires a 13 mm hole, the previous was 10 mm. And the PIR13 lens sticks out more then the Panasonic version. But still, i prefer this much more than the X10-RF motion sensors i used in my former life 🙂
The PIR13 PCB is glued to the top plate with hot glue. As you can see there’s not much tolerance along the long sides of the PCB; if the hole through the top plate is a bit excentric, you’ll have a hard time to make it all fit right. So pay attention there!
One nasty thing happened to me while preparing the 1st PIR13 to fit in the box; i decided it was wise to get rid of the 3 headers that are sticking out of the PCB; they were much to long! So i took my soldering iron and tried to get those things out. Normally, when you remove the plastic piece of the header and hold the soldering iron against a pin, they automatically fall out, sometimes with a bit of help, or they stick to the soldering iron. This time it was different; as if the pins were rammed into the PCB with a hammer! So i used a pair of pliers to gently pull the pin out; and while doing that, i damaged the PCB in a way that can’t be repaired anymore; aarggh!! First a voltage regulator blown up, now this.. what is this??
With the 2nd PIR13, i just cut off half of the pin length…
I foresee a “battle” for my spare time, between the LED strips and this new motion sensor… 🙂
Now that i have no more PIR sensors in stock, I had to find me an alternative. The requirements: low power of course, it should be able to fit in the PIR enclosure i already have in use and not too expensive, cause I’ll need a lot of them. The ELV PIR13 seems to be the right candidate for the job; this would bring down the PIR power usage from 170 µA to 40 µA. I don’t have to tell you what that will do to battery life 🙂
ELV PIR13: PCB 25 x 37 mm, 13 mm PIR
I’ve ordered a couple of these ELV PIR13’s and will build a 3rd motion sensor with one of these. In the meantime I also changed some things in the code to reduce the JeeNode power usage in power down mode even more: it went down from 20 µA to 6.5 µA. Calculations show a theoretical battery life of 200 weeks… well, i think the internal discharge will have screwed up the battery before that…
BTW, the 2 motion sensors that are currently being used, are still running fine on their first set of batteries.
Exciting… what will be the outcome of the calculations based on monitoring 2 motion sensors during a period of 24 hours and extrapolating this calculated power usage? OK, let’s start with writing down some ‘facts’, taking the worst case of the 2 sensors for each individual measurement:
The JeeNodes active time during a period of 24h is 102.4 seconds, with a current of 6.5 mA;
Power down current is 20 µA;
The XBee sends an average of 120 packets per hour, requiring the XBee to be on for a duration of 34 ms for each packet, using 40 mA current (from the datasheet);
XBee power down current is 1 µA (datasheet);
The PIR uses 170 µA (datasheet) while in standby mode and 270 µA (datasheet) during motion detection; motion detection duration is estimated at 400 seconds.
With these numbers it should be possible to calculate the average power consumption of each component:
JeeNode: 27,68 µA;
XBee: 2,88 µA;
PIR: 170,46 µA.
This adds up to a total of 201,02 µA. That’s the average current the motion sensor is using, based on a period of 24 hours. With 2000 mAh batteries this results in 9950 hours = 414 days = 59 weeks… cool! That will do, for now, lol
However… how about the battery self-discharge?? How much will this influence the time this motion sensor will last on 1 set of batteries? I really don’t know; so, still, time will tell how well this sensor performs in terms of long lasting batteries.
Fortunately, I still have enough options to reduce power usage even more, like
Using the energy saving version of the PIR;
Disabling stuff on the ATmega like brown out detection (how do i change fuses? As i mentioned before, where will this end? 🙂 );
Running the ATmega on a lower frequency.
And now that i have it all in a spreadsheet, i can manually adjust some values and see how it effects battery life. The smartest thing would be to go for the 1st option, cause that would reduce the standby current of the PIR down to 46 µA instead of 170… meaning 3 years !!
Two motion sensors v2 are in use right now, yippee!
I upgraded an existing v1 sensor to a v2 and built a new one. The v2 sensor specs are very different from the v1 but much more promising, yet all i needed to do to was soldering the digital output of the PIR to another JeeNode port (namely ATmega INT1) and use a different digital port for serial I/O with the XBee. Oh, and upload a new sketch of course. Now i have 2 identical v2 sensors:
v1 upgraded to v2
Looking back at how this motion sensor evolved i am wondering, why didn’t i think of interrupts in the first place… not very smart actually..
Or maybe i did think about interrupts but unconsciously thought it would be to hard for me to handle already, cause that’s what you read all the time: interrupts are a tough subject! Maybe it is, but i didn’t notice that yet! 🙂
So now I’ve got 2 motion sensors with the following features:
powered by 3 * 1.2V, 2000 mAh rechargeable batteries;
PIR with digital output, 100µA standby power usage and 5m detection range;
a JeeNode that’s effectively running only a total of about 180 seconds per day (0.2 %), even with 350-400 motion reports and lots of heartbeats. The rest of the time the JeeNode is in power down mode;
it’s ZigBee based which is better than 433 MHz in my opinion, especially when you’ve got a lot of sensors;
relatively small sensor housing compared to commercial (mostly big and ugly) products;
completely DIY so everything is how i want it to be;
interrupt-based, the best you can get I’d say;
need i go on? 🙂
I’m gonna monitor this sensor very closely in the coming months and learn from it. Here you see one of the sensors being used in the kitchen:
Motion v2 in the kitchen
Finished? Almost; some loose ends in the sketch. Maybe it can be made even smaller/faster/less energy consuming. But I’ll look into that when the 3rd sensor is built.
The sketch that’s currently running on these sensors can be found here; the Sleep library i currently use can be found here .