HC-SR501 3.3V randomly sends tripped when radio is on

[Yveaux]

@burningstone the biss0001 chip on the pir is rated for 3..5V operation. If you use it outside its allowed range you can expect undefined behavior, e.g. false triggers.

These sensors are very sensitive to power supply. Even with a good supply within spec behavior is sometimes strange, to say the least...

[burningstone]

@Yveaux
So what would you suggest? Adding a third AA-battery?
I just can't understand why some people got this pir sensor working on 2 AA batteries and without false triggers.

[Yveaux]

@burningstone pure luck? It's all about tolerances. Let's see if it still works for them once the environment temperature changes, the pir ages, the battery levels drop, the radio sends more data, etc, etc.
A simple fix is to power the pir from 3xAA and the arduino and radio from only 2xAA.
Search the forum, I've already explained it in another thread.

[burningstone]

@Yveaux
So i would need 5 batteries in total??
Seems like overkill to me, and the sensor would become quite big :(

[Yveaux]

@burningstone no, just 3xAA.
Power the arduino and radio from the first 2 only.

[burningstone]

@Yveaux
I found your other post here in the forum regarding the 3AAA batteries. Could you please explain how I do this?
Do I need to buy a battery pack for 3 batteries or is it possible do modify the battery pack I already have?
Sorry for bothering you with this type of questions, I just recently started with this.

[Yveaux]

@burningstone Here's a schematic representation of what I mean:

The red wire w.r.t. ground (black wire) will supply max. 4.5V (3xAA), the yellow one w.r.t ground will supply max. 3V.
The load of the Arduino and nRF24 are small, so all batteries will more or less drain equally fast.

It can easily be implemented by soldering an extra wire (the yellow one) to a 3xAA battery holder:

Try it, and verify the output voltages with a DMM!

[burningstone]

@Yveaux
Thank you very much.
I'll order a battery pack for 3 batteries, currently I have only a pack for 2 batteries.

How long does it take approximately till the batteries are empty? I know that it depends on how frequent the sensor gets triggered, but maybe you can tell me some average values.

[Yveaux]

@burningstone I have one next to my front door for exactly one year now, which triggers many times per day.
Battery has only decreased from 100% to 89% ! :+1:

[burningstone]

@Yveaux
That sounds like exactly what I want :)

Would it be possible to add a dht22 or would this interfere with the pir?

[mfalkvidd]

@burningstone if you don't want to wait for the 3xAA holder you can do like this

[burningstone]

@mfalkvidd
Awesome! How do i connect the wires to the battery? Solder them or what?

[mfalkvidd]

@burningstone the ugly way is to solder :) It works, but becomes a quite permanent solution.
I prefer using scotch tape. Or, if you have an extra 2xAA holder you can do like this (skip the fourth battery):

[burningstone]

@mfalkvidd
And how can i tape the wire on the side of the battery holder? My battery holder package already has two wires connected like in the fritzing pictures.

[gohan]

Or put the wire between the battery and spring/contact

[Yveaux]

@burningstone tape a wire directly on the battery, or solder to the battery or the holder.
Look what you have lying around and be creative!
That's what MySensors is about!

[burningstone]

@Yveaux
Sorry I have been a long time away due to exams.
Now I finally have time to spend for mysensors :)

I tried your approach with the three batteries. My setup looks like this:

I modified the HC-SR501 as shown below:

The sketch is pretty simple, it sends the motion and the light level and then goes to sleep with interrupt for 30 minutes. I still get the false positives whenever the arduino doesn't wake up from intrerrupt.

What am I doing wrong?

[gohan]

Try adding a cap on the power of the pir sensor, start from 10uf and try to increase up to 100uf and see if it gets better

[Yveaux]

@burningstone what MySensors version are you running? I did solve an issue with waking from interrupts in 2.2 beta, that's still present in 2.1.x. This might be what's bothering you...

[m26872]

@burningstone You probably want to find the root cause to this but, as a quick fix, have you tried software-blocking the false trip with an additional sleep before the interrupt-activating sleep? Something like sleep(3000); before the last sleep(...). I do it with success for my mini-pirs.