Motion Sensor v2

Here it is, Motion Sensor v2. Not much different from v1 really, the only thing that has changed is that the PIR output has moved to an interrupt pin. And the sketch looks somewhat different here and there. Later this week i’ll build my 2nd motion sensor and start using it right away; i’m very curious about the results! I’ll also change my 1st motion sensor that’s already in use, to an interrupt driven model. Don’t want to wait for what will happen with those batteries…

The JeeNode is completely powered down most of the time. It only gets woken up by the Watchdog timer every 8 seconds or when motion is detected. But even when motion is detected, it’s powered down most of the time, cause a ‘blip’ sent to my Domotica System every 4 seconds during continuous motion is more than enough.

When the motion interrupt is triggered, the ‘blip’ is sent to my system, followed by a power down for 4 seconds without interrupt trigger set. When those 4 seconds have passed (wake up is done by the watchdog timer) a power down is done with interrupt trigger and the whole loop starts all over again. Capice? It doesn’t get much easier than this :-)

And of course there’s a heartbeat sent every 64 (8 times 8 ) seconds.

Adding Sense Control

While i was quite happy yesterday with the new way i’m going to handle things on the JeeNode regarding the motion sensor (PIR), i already knew i wasn’t finished yet; this was nice, but only a first step.

Cause what i had created was an IRQ being fired when the input becomes low. Well, the PIR output becomes high when there’s motion detected, so this is unusable, actually. For a brief moment i considered using a transistor as a NOT gate to invert the PIR output, but there had to be an easier way. Why would you only be able to activate an External Interrupt when a pin becomes low?? I read some topics on various forums, but those were very contradictory; some said i could, some said otherwise. OK, in that case, i’ll sort it out myself .. cause i really need interrupts based on a rise or a change!

Page 71 of the ATmega datasheet learned me that INT0 and INT1 indeed have Interrupt Sense Control and it’s only a matter of setting the right bits in the External Interrupt Control Register A, aka EICRA:

Bit 3 and 2 of EICRA

So it can be done, only thing is to figure out how…

The Arduino attachInterrupt() function has a 2nd parameter with which you can control what triggers an interrupt; the values are the constants LOW, CHANGE, RISING and FALLING (found in wiring.h). So why didn’t that nice Sleep library i found earlier have this feature? All i can do is call this function:

void SleepClass::powerDownAndWakeupExternalEvent(uint8_t interruptNumber)
{
 attachInterrupt(interruptNumber, SleepClass::external_event_handler, LOW);
 set_sleep_mode_and_sleep(SLEEP_MODE_PWR_DOWN);
 detachInterrupt(interruptNumber);
}

OK; changing things in the library depending on the kind of Sense Control i need for a specific sensor type is not an option of course, so i added a 2nd parameter to that function:

void SleepClass::powerDownAnd...Event(uint8_t interruptNumber, int mode)
{
 attachInterrupt(interruptNumber, SleepClass::external_event_handler, mode);
 set_sleep_mode_and_sleep(SLEEP_MODE_PWR_DOWN);
 detachInterrupt(interruptNumber);

}

That’s better; now i can choose whatever Sense Control I want; I’ve checked all of them right away:

Sleep.powerDownAndWakeupExternalEvent(0, RISING);

What a surprise, its working, all of them! RISING is just what i need right now for the PIR; CHANGE is what i would need for a door sensor.

Now i’m already modifying libraries and I can even understand what

EICRA = (EICRA & ~((1 << ISC00) | (1 << ISC01))) | (mode << ISC00);

does… i wonder where or when (if ever) this will end…

But I’m still not finished! Cause with all this powering down going on, it has become increasingly hard to keep a notion of time; millis() has become useless cause how can i determine the time that has passed since the last power down? On the other hand, do i really need to know that? Time will tell :-)

Really powering down this time

Having a first set of batteries empty wasn’t  funny.. they lasted only 7 weeks! Way to short. And i kept on thinking that it might not have been caused by a bad battery.. what could i do next? Wait another 7 weeks to find out that I’m wrong? Neh.. that didn’t feel the right thing to do; Power down as much as possible and use an external interrupt would possibly give the best results anyway, so why not start with that right now!

I started with attaching a push-button to an Arduino, using a pull-up resistor to keep the input high when the button isn’t pressed:

Arduino with push-button

After that i started reading about interrupts. Here’s a table that shows the Wake-up sources that are available in the various sleep modes:

ATmega48PA/88PA/168PA/328P Wake-up sources

Both things i need are available: INT0 and/or INT1 and the Watchdog Timer, so it was time to start sketching :-)

After 5 different sketches with all the same miserable results (freezing Arduino), i finally found a sleep library that did exactly what i wanted. I combined this library with code i had found earlier regarding setting up and using the Watchdog Timer, and what i have now, is just what i need. Below a sample of the Serial Monitor output and here is the sketch that produced it.

39171 I'm awake, caused by the WDT
39205 Sleeping...
39327 I'm awake, caused by the WDT
39362 Sleeping...
39484 I'm awake, caused by the WDT
39519 Sleeping...
39640 I'm awake, caused by the WDT
39674 Sleeping...
39796 I'm awake, caused by INT0
Doing some work...finished!
40257 Sleeping...
40377 I'm awake, caused by INT0
Doing some work...finished!
40839 Sleeping...
40960 I'm awake, caused by INT0
Doing some work...finished!
41421 Sleeping...
41542 I'm awake, caused by the WDT
41577 Sleeping...
41698 I'm awake, caused by INT0
Doing some work...finished!
42160 Sleeping...
42280 I'm awake, caused by the WDT
42315 Sleeping...
42437 I'm awake, caused by the WDT
42472 Sleeping...
42593 I'm awake, caused by the WDT
42628 Sleeping...

etc. etc.

Cool stuff! :-) Let’s see how we can change the motion sensor to make use of this!

New batteries !?!

Not long after i noticed the rapid supply voltage drop on my motion sensor, this sensor stopped working. July 23th at 02:02 AM to be precise, cause that’s when the last motion detection was sent and no more heartbeats were received anymore after that. That same day, in the evening, i replaced the batteries:

New batteries installed

A few things i noticed are:

  • The new batteries for the motion sensor start at 3188 mV, which is significantly lower than the voltage on the other sensors;
  • The motion sensor stopped working sooner than i expected based on earlier findings;
  • The sensor behaved like i wished it would, during the time the batteries couldn’t cope anymore (no MS13 nightmares);
  • Replacing the batteries was enough to get it all working again (Yeeha!).

In the meantime, the batteries on my Lux Sensor are still within the same 5 mV range since i started logging:

Constant Supply Voltage on XBR4 (Lux sensor)

So that sensor is still doing OK i guess :-)

This time the motion sensor got 3 brand new and fully charged batteries. We’ll see what will happen this time.

I think i’ll start reading some more about handling external interrupts on the ATMega328… just in case, maybe i will need it.

But first, lets see how these new batteries keep the sensor working and if I’m not satisfied with the results, i will start using the energy saving version of the PIR, or lower the clock the ATMega328 is running on, or increase the sleep period on the JeeNode, use more powerful batteries, optimize the sketch, or …

Dropping fast…

XBee Supply Voltage dropping fast!

Oops… the Supply Voltage on my motion sensor is already down to 3060 millivolts. Suddenly it’s dropping very fast; this sensor has been operational for more then 7 weeks now, with IIRC 2 new and 1 older rechargeable battery of a brand with which i’ve had bad experiences before. I hope that’s what is causing this, cause if not, i have some work to do :-(

The other 2 battery powered sensors are still doing fine, BTW:

Supply Voltages (click to view the realtime values)

New motion sensor in use

After my problems with the MS13 sensors yesterday, i managed to find some spare time (even though, or maybe because it was father’s day) to write a sketch for the new motion sensor i created during the last couple of weeks. Always taking one step at a time, i located the first prototype of this sensor at a place where i can see the enclosure LED from the living room: i want to know how it performs…

New motion sensor

New motion sensor

Now powered by 3 rechargable NiCd batteries and with all hardware nicely put away in the enclosure. In due time the enclosure will be moved out of sight so only the PIR will be visible. I’ve decided to use 3.5 mm jack plugs to be able to disconnect the enclosure from the sensor, so i can easily take the enclosure back to my office, because i don’t think the JeeNode is already running the final version of the ‘PIR’ sketch… :-)

A new class, 2 database records and 1 line of code were enough to get the sensor working in my Domotica system:

procedure TAMN31112.ProcessInterfaceData;
begin
  Pin(1).AsBoolean:= (O.Data[1]='1');
end;

The new PIR can be viewed from my website (it’s called BP PIR):

Battery powered PIR

Battery powered PIR

The sketch is still under development; for instance, how much difference would it make if i change the DigitalRead() into a bitRead()? I’ll have to read more about that on JeeLabs … Other questions are: should i increase the heartbeat interval (currently 45 seconds) or the Motion report interval? Can i create some sort of battery power monitoring with the XBee? But that will all be investigated when i’ve finished building my second motion sensor based on JeeNode and XBee..

No more!

I wonder how Homeseer users deal with this..

Cause this is what you get when the batteries of a MS13 motion sensor are empty:

MS13 jamming

Yep.. last Saturday it happened again, around noon… one of my MS13 motion sensors had empty batteries, causing it to start sending rubbish all the time. Yes.. all the time! Side effect is that all other 433 MHz traffic is being jammed, causing a spike of more than 3600 unrecognized packets being received by my RFXCOM receivers. Fortunately i have 2 of those receivers, so not all data is lost. Otherwise my whole 433 MHz sensor network would have collapsed…

This time it was the motion sensor in the kitchen that had its batteries empty. Away with it! I removed the batteries and didn’t put new ones in. For me, the MS13 motion sensor is over and done with. No more!  This is the 3rd time in 2 years i had to go hunting for an MS13 that was jamming all other traffic. And of course, the faulty MS13 was the 3rd sensor of which i removed the batteries; so now i have to reprogram 2 of them again…Yuck!

I have better things to do… like finishing my own motion sensor, with heartbeat and no reprogramming needed when batteries are replaced… yeah!

Motion sensor in next stage

This weekend i spent some time to make the experimental PIR sensor setup i made some time ago, a bit more permanent. Ingredients:

Enclosure modified with hobby knifeThe enclosure i used this time is a bit different from the enclosure i used on a previous occasion. This one lacks the inner ribs and opening and closing is a bit harder: for opening the enclosure you need to put a screwdriver between the 2 halves and twist it to get the enclosure open.  The first thing i did was making my life easier by removing the ribs that keep the 2 halves together on one side of the enclosure. Some more modifications here and there now make it possible to open the enclosure without any additional tools, but still will not open by accident.

PIR enclosurePIR enclosure

I drilled a 10 mm hole into the PIR enclosure so that the PIR fitted nicely through the top plate; a drop of super glue on the inside did the rest. There was plenty of room for the 100k pull-down resistor inside the PIR enclosure so i soldered it to the PIR there. An extra hole of 4 mm and a cable tie for the wire completed the PIR box.

JeeNode, XBee

JeeNode, XBee

This being my first motion sensor built this way, i added a LED to be able to see what the XBee radio is doing; is it still transmitting or not, when, how often, etc. ? Maybe this is overkill, but when this sensor is placed somewhere in the house with no computer screen nearby, it can be very handy to see if the sensor is still functioning instead of running to and from the nearest screen…
If the flickering of the LED is to visible or annoying in the future, i can always disable it or make it invisible by a piece of tape over it; but for now, this LED seemed like a good idea to have. The LED lights up when the XBee is on and from the duration that the LED stays on i can see what’s happening; whether it’s transmitting (very short durations) or having PAN trouble (long).

The software part of this sensor will be the most time consuming of it all i guess. Since i want it to be battery powered, i’ll have to consider what is relevant information for my Domotica system, and when it is. In fact, the only thing that really matters is one single thing: fast motion detection! All the rest is less important.
Cause what do we Domoticans use this motion detection for? To turn things ON… not OFF; at least, i don’t.

Further more, a quick look in my events history tells me that from 01-04-2010 till today i missed (my 433 MHz RFXCOM receivers, i mean) a total 869 ‘OFF’ transmissions (meaning “no motion”) from my 10 MS13 motion detectors. That’s way to much to be called reliable! So my system already has the capability to deal with this situation of missing ‘OFF’ transmissions; when a MS13 hasn’t reported neither an ‘ON’ nor an ‘OFF’ for a specific time interval, i set the motion sensor back to ‘OFF’ in software.

So.. i could as well do without this ‘OFF’ completely; i don’t use it as a trigger, so why send this non-information anyway?

What i do want to have is a heartbeat, every 90 seconds or so. And i would like to have an ‘ON’ being sent with a specific interval when motion is detected continuously. That’s what I’ll be working on in the coming week.

To be continued.

Testing PIR sensor

PIR sensor on my ASUS TOP

PIR sensor on my ASUS TOP

No, this is not some special add-on for my ASUS TOP.. it’s just a Duemilanove with a PIR sensor attached to it.

And the ASUS TOP, which is used as my Domotica GUI in the livingroom, is only used to provide power to the Duemilanove.

Somewhere in October 2009 i bought 2 PIR sensors, but after some brief testing these PIR sensors were stored in a drawer and nothing has been done with them since then. Since i intend to create my own motion sensor someday, i put one of these PIRs on a breadboard today, attached to an unused Arduino. Finally..

And of course, the most logical place to test this sensor and learn something about how it performs, is the livingroom. The office is to small to learn anything about how this sensor behaves with motion from different angles, distances and the output it provides. A breadboard with the Duemilanove , PIR sensor and LED, stuck to the ASUS TOP with tape, seemed like the best compromise for real life testing without making the livingroom look like it’s an extension of my hobby room. The other members of my family can live with this; in fact, my son is the most fanatic “tester” of all of us :-)

From what i’ve seen so far, this sensor is sensitive enough to be used succesfully, although the digital output is not as stable as i expected. During continuous motion (as in my daughter dancing in front of the PIR for 2 minutes) i still saw the digital output dropping to 0 (meaning no motion) for a large number of short periods. Strange? Well, at least it’s not what i expected..

This means i’ll have to add some debounce logic into the code that handles this PIR to eliminate unwanted transmissions of  these “no motion” events; cause if i don’t, i’m pretty sure i can change batteries every couple of weeks when i create a battery powered sensor with it.

To be continued…