Moteino with RFM69HW 915MHz
Works OK with separate 5v supply to the PIR HC-SR501 sensor, but when I use the Moteino 3.3v supply transmit created a motion event. Any ideas?
Setup: the HC-SR501 PIR Motion Sensor:
Power: Moteino 3.3v to 3.3v bus on HC-SR501 skipping the power chip on the HC-SR501 (IC17133-1) & the need for extra 5v.
See: http://techgurka.blogspot.com/2013/05/cheap-pyroelectric-infrared-pir-motion.html (http://techgurka.blogspot.com/2013/05/cheap-pyroelectric-infrared-pir-motion.html)
PIR Sensor out to pin D7 Moteino
GND to GND on Moteino
Sensor power requirements: I measured 0.04mA (quite) and 0.30mA (active) so the 30mA on the Moteino should be enough.
Test: False "motion" after transmit. When the transmit code is commented out of the sketch there is no false trigger.
// radio.sendWithRetry(GATEWAYID, payload, sendSize)
I thought this was RF interference, but it does not do this with the 5v supply so it must be something else with the 3.3v supply when transmit occurs.
Any ideas welcome.
The PIR sensors offered at the LowPowerLab shop are about 250uA while active and 60uA when inactive. The MotionMote sketch uses D3 not D7.
Could you please post photos of how you wired it?
Also source code will help.
Which parts did you source from LowPowerLab?
Hi Felix,
I get about the same current (I was measuring milliamps with my voltmeter). My measurements were using the 3.3v connection.
I don't have a direct picture but here is how I connected the 3.3v Moteino to the sensor (picture attached).
I did do the following experiment yesterday:
Remove the PIR output to the Moteino completely & measure the output via a voltmeter.
Result: PIR still output goes high when Moteino transmits.
(Also when the transmit occurs the Moteino 3.3v drops to approximately 3.2v)
Guess: Maybe the PIR with the 3.3v supplied is sensitive to supply voltage fluctuations? Note I am using the high power transmitter. Is there an easy way to test this using the RFM69 library to change the power setting? Maybe using the setPowerLevel() function?
PS:
For code: I started with what is now called "Node" code from the RFM69 library. I am using this for other sensors too so not building the MotionMote
I believe you're wiring it differently than what the PIR sensor is typically wired. I don't modify or hack the PIR sensors.
I can guarantee if you are wiring the PIR right and use my low power sketch it will work as expected.
I asked if you are using hardware made/sourced through LowPowerLab?
The idea was to be able to use the PIR with no extra power supply since my Moteino already can provide the 3.3v.
After a bit of coding I got it to work!! I inserted a 2 sec delay after transmission so the 3.3v supply settles (skipping the false trigger time). Works just fine now.
The HC-SR501 Motion Sensor I got long ago, it is not a LowPowerLab device, but has the same specifications.
Thanks for your help.
Hi,
I came across this thread because I was having a similar problem with my SR501's false triggering, and I though it might be useful to confirm your theory. I'm also using the SR501, but with an ATmega328p & nRF24L01+ module, powered by a li-ion cell, but I think the issue I've seen is the same as yours.
I was also hoping to supply the battery voltage to the SR501, bypassing the onboard 7133-1 regulator. However, whenever the nRF24L01+ RF module is woken up from power down mode, it's current consumption jumps from a few uA to something approaching 15mA, which in turn pulls VCC slightly lower. This sudden drop in VCC causes the SR501 to false trigger. It seems to be very sensitive to such dips in VCC when bypassing the onboard regulator. I tried leaving the nRF24L01+ powered up, continually drawing ~15mA, so that VCC is continually at that slightly lowered voltage, and the SR501 stopped false triggering i.e. it is not the absolute value of VCC being low that causes the false triggers, but the sudden small drop in VCC that does it.
Note that if you supply VCC into the proper VCC pin, on the SR501, there's a protection diode before the regulator. This means the VCC you supply must exceed 3.3V by a diode drop as well as the regulator drop, otherwise you start getting false/repeated triggering due to the supply voltage just being too low. At the lower end of my li-ion cell voltage range, I was starting to see this effect, which is why I wanted to bypass the onboard regulator in the first place. However, if you short out the onboard protection diode, so that you're only dealing with the regulator drop, a li-ion cell can happily supply the proper VCC pin over the whole of its practically useful voltage range. The down side is a slightly higher current consumption because of the regulator, but the big up side is obviously the voltage regulation which adequately deals with those sudden drops in VCC, and stops the SR501 false triggering. Sorted.
See this section for what I did to avoid the drop of the diode+regulator: http://lowpowerlab.com/motionmote/#pirsensor
Maybe I'm being too simplistic here, but this sounds like the perfect case for adding bypass capacitors at the power inputs of the radio module and the PIR. It seems like a model scenario for voltage sag / ground bounce.
First of all, since this is my first post here, thanks to Felix for sharing this nice piece of software!
I am using it on a 868MHz HCW and Arduino Nano with a selfmade Power-/levelshifter.
Since some days, I am trying to get a PIR sensor (SR-501 from Ebay) to work with it. The sensor worked fine on a Nano without the radio module. After connecting the radio as well, it started to false trigger a lot. I also thought about problems with the supply voltage and bypassed the Arduino voltage regulator. The PIR got stable 7.5V on it's input pin after this. Still it showed the false triggers. So I added capacitors: Tried it with some nF and µF on the radio as well as on the PIR (which has them anyway on board) ... no change.
Next, I thought about interference from the radio and added a longer cable between the Arduino and the PIR ... BINGO! One meter solved the problem. No more false triggers.
When I move the PIR, with the long cable connected, close to the radio, it false triggers again. Move it away and it's fine. So there's definitely a radio interference in my setup.
Maybe this observation helps somebody else.
Regards!
This is probably EMF noise induced on the PIR wiring or circuit. Maybe an inline bead/inductor on the PIR VCC might help.
Not to brag but to give another example ... i know someone who tried running a CNC on Arduino and it was too noisy and unstable and when they tried Moteino it worked fine :P
Hi Felix,
thanks for your answer!
I agree, it's definitely EMI. A bead inductor could help in case the interference is on the VCC. It wouldn't help in case the EMI is somehow disturbing the PIR's IC or other parts of the circuit on the board directly. Unfortunately I do not have an inductor at home to try. Also, for my use case, a longer line to the PIR is acceptable and solves the false triggers reliably.
I also did some experiments on SW side: If I comment the line with "radio.send" out, the PIR works well. All other software is unchanged. Therefore I think, the interference is really caused by the transceiver and not from the Arduino board. (Moteino could of course be more stable as well. My Nano board is only a clone. Probably it's not as nicely designed as your boards but I had some of those at hand)
Maybe a shielded case would also help for those use cases where the PIR needs to be close to the radio. But I do not need them closely together, so I won't try that ;)
Regards!
I ran into this exact same problem when I set up my weather station. I have a project box with an LCD display, a moteino and a PIR. When you approach the weather station monitor the PIR detects the motion and turns on the LCD back light. The back light would come on every time the moteino would receive data from the weather station outside. I figured out that it was the ACK sent by the moteino inside the project box that was causing the PIR to turn on the back light. What I wound up doing was to turn down the power setting on the radio, that took care of the problem. I was not sure how to go about shielding the PIR.
How about shielding the RF components with some tinfoil connected to GND?
Quote from: Explorer on August 16, 2014, 08:54:49 PM
After a bit of coding I got it to work!! I inserted a 2 sec delay after transmission so the 3.3v supply settles (skipping the false trigger time). Works just fine now.
THank you! solved my problem as well, running a buono at 3.3v with RFM69HW and a cheap HC-SRT501. Seems a voltage sag indeed, which falsely triggers the PIR. I have the PIR on 10cm long cables, no EMI related false triggers noticed.
thanks
Hi,
has anyone got any other solution to this? I have the Moteino R4 with 433Mhz RFM69W (no HW), and it makes PIR sensor trip practically every time any radio msg is sent or ACK'd. The PIR sensor Vcc is connected to 4xAA batteries (same as Moteino Vin).
I have tried following things without any progression:
- 10uF, 1uF and 10nF capacitors along PIR Vcc and GND.
- half meter distance between sensor and Moteino (not ideal, I like to keep the whole thing in one case) but even that distance wasn't enough.
-Tried tin-foiling the sensor and connecting the foil to GND
- Thought about bypassing PIR voltage regulator, but then measured the voltage inside PIR after its 7133 regulator, and it stays the quite stable, and is actually more flat than voltage of Moteinos 3.3v rail (32 mV fluctuation vs. 70-100mV during transmission).
Only thing that solves this is the ignore period (2 seconds) presented by Explorer earlier. But it seems the false trigger it is NOT caused by voltage droops but by RF interference, or has someone actually observed the voltage fluctuation with fast oscilloscope and managed to improve it with extra caps?
The thing is, I'm making a "clap sensor" to turn on/off lights, and it seems that the (RF/electrical) noise is seeping into the input of op amp (LMV324) used to amplify microphone output, and the amplified noise is then on the same level as the cut-off level for detecting clap... :/ Here the GND shielding of mic input wire dampens any other noise tremendously (especially 50 Hz current noise) but doesn't help with the one induced by radio. Of course I can implement "ignore period after radio tx" for the clap sensor as well, but if someone has any other tips, I'm all ears :)
Did you try another PIR sensor?
Hi Felix,
yes I tried another one, identical from the same batch I guess. They are those cheap, generic chinese PIR sensors, but I guess the chip, components and the layout are almost the same in all of them.
Tested the prototype of clap sensor and it seems to work ok when I ignore it's output following the radio transmit. It's really sensitive to voltage fluctuations though, but what to expect from op amp gain of 1000. But with lower gain the microphone output is not high enough to sense clap from across the room. But then I bumped into another problem when trying to enter sleep mode: when Moteino is put to sleep there's a slight overshoot in 3.3v rail voltage (around 60-70mV), caused maybe by the sudden lower power consumption of 328p that the MCP1703 cannot react fast enough. The blip lasts around 2ms but is slow enough to cause the biasing voltage to electret mic to fluctuate by a dozen mV or so. And with a gain of 1000 the voltage threshold is passed and sensor is triggered, which causes Moteino to awaken again, so it cannot really get any sleep :)
I have again tried so many combinations of capacitors everywhere to dampen that fluctuation but nothing seems to help. Next step would be to isolate the op amp board with a separate regulator, I guess.
I'm having the exact same problem with the following PIR:
https://www.adafruit.com/products/189
Happens every time the radio activates, even if they are completely on isolated circuits. Moving away resolves. Haven't figured out an effective way to shield the sensor yet. Could any of you save me some time? What were your ultimate solutions?
Try resuding the power of the radio by calling radio.setPowerLevel(N) with N=[0,31] (default is max of 31).
Cross reference to a post that describes how I solved a similar issue:
https://lowpowerlab.com/forum/index.php/topic,1478.msg10313.html#msg10313