False triggers

[mariusb57]

I used this sensor with a esp8266 and i have a lot of false triggers. Seems to be strongly affect by the wireless network , in general , by strong electromagnetic fields . I tried to place him at a considerable distance from esp8266 and I used a lot of decoupling capacitors. Sure that the false switching operations were far fewer . I would like to know if anyone met this problem and how to solve it . If I mount a metalic shield on the back of the sensor, may this affect its detection properties ? Thanks .

[barewires]

I think discussions other than the RCWL-0516 should be moved out of this forum.

[syedamerali]

@barewires Absolutely correct and noted. particulary after the reprimand!

[ym58]

It is this: https://www.fibaro.com/en/products/universal-binary-sensor/

Thanks, syedamerali

;-)

[syedamerali]

cute ......

[syedamerali]

Any thoughts on elevated moisture levels in the atmosphere effecting the RCWL triggering? The reason I ask that it is raining outside RH is at 81% and the false triggers have restarted.

[ym58]

Watch the end of this video (after the cat) ... https://www.youtube.com/watch?v=0HYRD35F570

[syedamerali]

Got my PCB's for the RCWL-0516 yesterday. Have tried one for about 24 hrs and another for about 8hrs. No false triggers. I now how a repeatable, consistent and economic solution for motion detection. I can more confidentally state now that layout is critical - all the wires flying around in a hobbyist's prototype give inconsistent results. Further, the pi filter is of no significance only a capacitaence is required near the RCWL board on the power feed. @barewires comment "The only time I had false triggers / sluggish response was when the detector was both flat and perpendicular to a breadboard." Confining myself to the false triggers part of this comment. My new setup with the PCB the RCWL is parrallel to the ESP and is about 60mm apart. Both the ESP and RCWL are at right angles to a PCB with a ground plane - no false triggers. I cannot figure out a way to measure sluggish responce - any ideas? regards

[barewires]

I use multiple sensors, one packaged in target enclosure, others within 5 cm nearby in the clear and log each activity in the Pi Zero. Also used a 6 pin multifunction logic gate to AND OR the signals to another GPIO. Any variation or non-response T&D activity is easily seen. Also have used a PIR for physical motion detection.

I don't think that the big cap and resistor are necessary. They have never been needed in my circuits. I believe that the ESP IO is 3.3 volts so is compatible with the RCWL-0516, and I still question the need for the logic level converter. The 'ground plane' also bothers me as it appears to be a mass of useless metal.

The ESP is also a modem using the AT command set from 1981...ah the good old days are still with us.

If USB micro power in is not a concern then I would highly recommend a Raspberry Pi Zero W (for WIFI / Bluetooth) headless operation (no HDMI monitor, no KB/Mouse) if needed, node-RED GUI for remote HTML design, monitoring, SSH for remote access. Does an ESP do all of this? For under £10

Anything Arduino related is now so turn-of-the-century.

Raspberry Pi Zero W (Wireless) Details: BCM2835 (same as Pi 1) but up-clocked to 1GHz, so 40% faster 512MB RAM Mini HDMI USB On-The-Go port Micro USB power HAT-compatible 40-pin GPIO header Composite video and reset headers CSI camera connector 802.11b/g/n Wireless LAN Bluetooth 4.1 Bluetooth Low Energy (BLE)

[ym58]

I think discussions other than the RCWL-0516 should be moved out of this forum.

just kidding ... ;-) ... !!!

[barewires]

cute ......

[jeraymond]

Hi. Thanks for all the great info on this thread.

In my setup I have the RCWL close to the ESP8266. They are about 10mm away from each other and are parallel on opposite sides of a PCB.

The ESP is definitely causing interference with the RCWL in my setup. I probed PIN 12 on the RCWL and see the voltage wiggle with movement. Over a certain threshold the RCWL output pin triggers high indicating movement detected. WiFi activity on the ESP also affects the wiggle. Most noticeable for me is on WiFi connect. The interference is large and causes the RCWL to trigger due to the interference. When WiFi is already in a connected state I do not see a much interference. Sending data over WiFi also seems OK.

I tried some of the WiFi tweaks suggested here and find this helps reduce with the idle wiggle. However this difference wasn't enough to remove the WiFi connect interference. Also the normal wiggle without WiFi setting tweaks weren't strong enough to trigger the RCWL in my setup.

// WiFi tweaks to reduce interference, didn't make much difference for me.
WiFi.setPhyMode(WIFI_PHY_MODE_11G);
WiFi.setOutputPower(8);
WiFi.mode(WIFI_STA);

I assume distancing the RCWL from the ESP reduces interference and looks like has worked for others above in this thread.

@syedamerali I'm curious to know if forcing a WiFi disconnect and reconnect in the code in your setup would cause a false trigger given the distance you have between the ESP and the RCWL. Do you have a scope? I'd also be interested in seeing what the RCWL PIN 12 output looks like for you idle and during WiFi reconnect.

I also experimented with the 2000 uF cap across the RCWL power and ground pins and the 10k resistor from RCWL out to ground. This didn't seem to make any difference in my setup. Perhaps this helps with dodgy power supplies and mine is steady enough. These additional components did not help with the WiFi reconnect interference. I still got false triggering. Probing the power input to the RCWL during the reconnects I saw a constant voltage.

I plan to deal with the false triggers in software. The RCWL seem to pull the output high for about 3 seconds (~2700 millis) after motion has stopped. False triggers I've seen typically show as very brief interference (< 1 second). So I'm ignoring any "motion" less than 2 second in duration (so 5 seconds of the RCWL pin being pulled high). I'm also ignoring triggers when the WiFi is not connected. In my use case I'm sending motion events over WiFi to a server, so if I can't connect to WiFi I'm choosing to ignore the events.

[syedamerali]

@jeraymond Yes I do have a scope but I use it so rarely that I will have to reducate myself how to use particularly the storage and display part, but I will definetly give it a try and will post if I have something.

With respect to the last para in your post. My system for monitoring false triggers is as follows: RCWL trigger ->ESP->WiFi->Virtual Software switch->Record->display selected periods when required. This recording system has latency; another limitation is I cannot record in fractions of a second, smallest unit is a second. Although, this system can indicate false triggers it cannot reliably report the length of a trigger. Also in my ESP software No Motion->Motion is ignored for 4 minutes after a motion event. Motion->No motion is allowed as it happens.

With these provisos in place, after reading your post, I looked at my recorded data at the time I was having false triggers (an excerpt is given below). I could not find a single trigger less than 3seconds. Look at the times in the third column.

Generally after using for radar sensors for a couple of weeks now I am arriving at the following conclusions:

1. Do not use radar sensors inside a house. Placement of the box housing the RCWL and ESP is critical. To give an example I had trouble free operation for a sensor placed on my workbench for over 24 hours. I picked up the box and placed it within one foot of my ceiling (reinforced concrete with steel bars in it) repeated false triggers. Put it on the floor in the cavity under my work bench (where you stick your legs in when sitting) repeated false triggers. Back on the workbench - perfect. I have two radar sensors outside the house in the open - they work flawlessly. Use PIR sensors indoors. PIR sensors outdoors are unreliable.
2. WiFi is too unreliable if you want real security - a mesh network is essential, preferably as far away from the WiFi 2.4 GHz as possible.

14/11/2017 21:00:31 | 14/11/2017 21:00:34 | 00:00:03 | Motion | No Motion | -- | No Motion 14/11/2017 20:55:29 | 14/11/2017 21:00:31 | 00:05:01 | No Motion | Motion | -- | Motion 14/11/2017 20:55:26 | 14/11/2017 20:55:29 | 00:00:03 | Motion | No Motion | -- | No Motion 14/11/2017 20:47:08 | 14/11/2017 20:55:26 | 00:08:17 | No Motion | Motion | -- | Motion 14/11/2017 20:47:05 | 14/11/2017 20:47:08 | 00:00:03 | Motion | No Motion | -- | No Motion 14/11/2017 20:41:14 | 14/11/2017 20:47:05 | 00:05:51 | No Motion | Motion | -- | Motion 14/11/2017 20:41:11 | 14/11/2017 20:41:14 | 00:00:03 | Motion | No Motion | -- | No Motion 14/11/2017 20:35:07 | 14/11/2017 20:41:11 | 00:06:03 | No Motion | Motion | -- | Motion 14/11/2017 20:35:04 | 14/11/2017 20:35:07 | 00:00:03 | Motion | No Motion | -- | No Motion 14/11/2017 20:30:13 | 14/11/2017 20:35:04 | 00:04:51 | No Motion | Motion | -- | Motion 14/11/2017 20:30:10 | 14/11/2017 20:30:13 | 00:00:03 | Motion | No Motion | -- | No Motion 14/11/2017 20:25:20 | 14/11/2017 20:30:10 | 00:04:50 | No Motion | Motion | -- | Motion 14/11/2017 20:25:17 | 14/11/2017 20:25:20 | 00:00:03 | Motion | No Motion | -- | No Motion 14/11/2017 20:20:27 | 14/11/2017 20:25:17 | 00:04:49 | No Motion | Motion | -- | Motion 14/11/2017 20:20:24 | 14/11/2017 20:20:27 | 00:00:03 | Motion | No Motion | -- | No Motion 14/11/2017 20:16:22 | 14/11/2017 20:20:24 | 00:04:02 | No Motion | Motion | -- | Motion 14/11/2017 20:16:19 | 14/11/2017 20:16:22 | 00:00:03 | Motion | No Motion | -- | No Motion 14/11/2017 20:11:22 | 14/11/2017 20:16:19 | 00:04:56 | No Motion | Motion | -- | Motion 14/11/2017 20:11:19 | 14/11/2017 20:11:22 | 00:00:03 | Motion | No Motion | -- | No Motion 14/11/2017 20:06:58 | 14/11/2017 20:11:19 | 00:04:20 | No Motion | Motion | -- | Motion 14/11/2017 20:06:53 | 14/11/2017 20:06:58 | 00:00:05 | Motion | No Motion | -- | No Motion 14/11/2017 20:02:47 | 14/11/2017 20:06:53 | 00:04:05 | No Motion | Motion | -- | Motion 14/11/2017 20:02:44 | 14/11/2017 20:02:47 | 00:00:03 | Motion | No Motion | -- | No Motion 14/11/2017 19:55:10 | 14/11/2017 20:02:44 | 00:07:33 | No Motion | Motion | -- | Motion 14/11/2017 19:55:07 | 14/11/2017 19:55:10 | 00:00:03 | Motion | No Motion | -- | No Motion 14/11/2017 19:50:36 | 14/11/2017 19:55:07 | 00:04:31 | No Motion | Motion | -- | Motion

[jeraymond]

This recording system has latency; another limitation is I cannot record in fractions of a second, smallest unit is a second

I was measuring the timings directly on the ESP and logging via the serial interface connected to my computer to get a more fine grained measurement.

Do not use radar sensors inside a house. Placement of the box housing the RCWL and ESP is critical. To give an example I had trouble free operation for a sensor placed on my workbench for over 24 hours. I picked up the box and placed it within one foot of my ceiling (reinforced concrete with steel bars in it) repeated false triggers. Put it on the floor in the cavity under my work bench (where you stick your legs in when sitting) repeated false triggers. Back on the workbench - perfect. I have two radar sensors outside the house in the open - they work flawlessly. Use PIR sensors indoors. PIR sensors outdoors are unreliable.

I think my strategy to discard any motion event less than 2 seconds (5 seconds of RCWL out pin high) would also discard other forms of short interference similar to what you describe here. I'd be curious if your issues would go away if you did the same. I discard the short events on the ESP so the server never sees them.

PIR sensors outdoors are unreliable.

I've noticed this as well. My outdoor PIR motion lights trigger randomly all the time.

WiFi is too unreliable if you want real security - a mesh network is essential, preferably as far away from the WiFi 2.4 GHz as possible.

Thanks for the advice. I'm currently just playing around so the WiFi is good enough but will consider something different for a more serious system.

[syedamerali]

One thing I can confirm - when the RCWL actually registers motion the trigger is always above 3 seconds - it can be as much as 15 seconds. I was about to code your 2 sec blind time, then I said to myself, what am I doing? All my motion sensors initiate a chain of events in under a second; I will have to wait for 2 sec just to know that motion has taken place and then initiate my dependant events. This for me is unacceptable and therefore not a solution.

[jeraymond]

One thing I can confirm - when the RCWL actually registers motion the trigger is always above 3 seconds - it can be as much as 15 seconds.

Right, it makes sense that all events are at least 3 seconds or more. The RCWL seems to keeps OUT high for a minimum of ~3 seconds after it has detected motion has stopped. You can see this in the wave form I posed earlier. The motion wiggle stops but out says high for a while longer.

I will have to wait for 2 sec just to know that motion has taken place and then initiate my dependant events. This for me is unacceptable and therefore not a solution.

Fair enough. You stated you stopped using the sensors in locations where you see they get false triggers and interference. In a false trigger free environment waiting to detect false triggers provides no benefit.

I will have to wait for 2 sec just to know that motion has taken place and then initiate my dependant events.

Yea my wait time is about 5 seconds before I register a real event. Since RCWL out stays high for 3 seconds after motion has stopped I need to wait 5 seconds to see if there has been at least 2 seconds of actual motion. If there are downstream time sensitive events that are based on this trigger than 5 seconds may be too much wasted time.

[syedamerali]

A common situation is that you want the lights to come on in a room once somebody walks into this room. Try doing this with a 3-5 sec delay and see how frustrating this is.

[barewires]

All of my sensors trigger OUT logic high immediately on motion, will stay high if motion continues and turn off after a few seconds when motion stops. Are you guys using the falling edge when you should be looking at the leading rising edge.

[syedamerali]

I am looking at the level - it is not interrupt driven on the leading edge. It is a fairly short loop; code is as under: void loop(){ bool state = digitalRead(pIN); if (state) { digitalWrite(pLED,1); } else { digitalWrite(pLED,0); } // determine if ON report to be sent if (!lastON && state && (millis()-elapsedTime)>updatePeriod){ // updatePeriod=240000 (4min) to stop flooding of the control software with json commands // send ON URL lastON=true; elapsedTime=millis(); sendURL(state); } if(lastON && !state ){ // send OFF URL lastON= false ; sendURL(state); } yield(); }

[barewires]

Oh! But why read the level when it is digital on/off?

[syedamerali]

My control software triggers actions when there is change in state of a device. Only then can it be classified as an event. If the time is xx - is an event. If the time is between xx and yy - is a condition not an event.

I do not exactly how long the loop takes to execute but it most certainly is not more than a ms. So I am checking the status of the RCWL output continously. The control software is only sent a URL when there is a change in state of the RCWL output pin connected to the ESP input pin ( last state is held in variable lastON) ( lastON && !state ) for No Motion- ( !lastON && state ) for Motion.

Hope this clarifies matters .... PS Sorry I use C++ for my microcontrollers, including the ESP - you seem to prefer Python. Of course I can have an interrupt routine which fires off the leading edge of the RCWL output and sends a URL to the control software but I felt that this would flood the control software with triggers.

[barewires]

I prefer Boolean, I am a BIT, either on or off, nothing else. https://www.youtube.com/watch?v=BbBqPkdheFg Good luck.

[ortegafernando]

Hi everybody, I have implemented the Pi filter (2x 1000uF and 10 ohm). When I connect it to muy power supply I can see spikes as we need to charge the two capacitors. is there any trick to avoid this? It is not harmfull (sure?), but i don't like it. Could we increse the resistance value ?

Regards,

[phpbbireland]

The false triggering is more likely caused by the momentary drop in the supply voltage as the ESP switches to transmits mode. It's pretty easy to determine, just use a battery (or other supply) for the RCWL-0516 and see if it false triggers... You should only need a decent cap across the ESP supply to prevent false triggering, perhaps one on the sensor supply too...

[phpbbireland]

Just adding a link video which will explain issues in this topic... The link I added was being modified so I removed it... will investigate further... https://youtu.be/wf_msvWv1jk

[ym58]

@phpbbireland : apparently, your link gets to a 404

[gecko9]

In addition to having a clean power supply you need to earth the zero volt line of the power supply. Earthing prevents interferance between modules: transever / radar sensor / arduino greatly adding to stability.

[phpbbireland]

The module works perfectly at 3.2 volts (have tested over an extended period down to 3.0 volts)... I use a LiFePO4 3.2 volt battery for all the testing and no issues so far...

[andrisdru]

Seems that i finally was able to crack mystery with RCWL-0516 false triggers. I tried to make a outdoor lamp with motion sensor. With ESP8266 D1 mini, 100W LED, RCWL-0516 motion sensor, light resistor, aliexpress 700mW power supply and solid state relay. Lamp is connected with WIFI to MQTT server to control light sensity timeouts etc. First i did suggestions here made PI filter, made distance between ESP8266, switched to 11B, but still alot false triggers. Code adjustments for double trigger check not helped. But soultion was also to move WIFI router closer to lamp and false trigger problem dissapeared. I assume that weak WIFI (but still working, also scetch upload via OTA uploaded without problems) may somehow trigger those false alarms.

Dont know yet how it works in different weather conditions, right now here is -15C and clear weather, lets see how it works in rain, snow etc.. but right now for one day motion detector is working perfectly. I still will not trust it for intrusion detection but for lightning it works at least for now very good.

[NeuronTech]

What are you using to power the ESP?

[andrisdru]

Powering ESP with https://goo.gl/ce39R5

[b0b7h3d0g]

I had the same issue with RCWL-0516 connected to a RPi 3 5V GPIO with 10cm breadboard jumper wires. False readings every 5 minutes. I've fixed the problem with a ferrite bead around the wires (VIN, OUT and GND).

[jeraymond]

@danstoian what sort of ferrite beads did you use. Something like these? I imagine even something like the small 3mm ones would be bulky.

[b0b7h3d0g]

@jeraymond I had one of those you mentioned lying around. It's indeed bulky but fixes the problem. I would have also tried with some shielded wires but had none around.

I do have 433Mhz RX/TX, Z-Wave Stick, external hdd, a dual-band router and a 4 module relay within 1 meter of the PI. No false readings for a week now.

Here is my test rig:

[jeraymond]

Interesting. Do you have any experience with through hole mount ferrite beads? I wonder if something like this would have a similar effect of eliminating the noise.

[barewires]

Wikipedia states the following for a Lithium Iron Phosphate LiFePO4 battery. Cell voltage: Minimum discharge voltage = 2.5 V Working voltage = 3.0 ~ 3.3 V Maximum charge voltage = 3.65 V

Any thoughts on running at out-of-spec voltages way out-of-spec from 3.3 volts being back-fed into the device? 3.2 volts may work but is nominal at best. Maybe a low-cost $0.60 Mini Boost Buck DC Board 1.8-5V to 3.3V is the answer.

I put two cat-detectors in my side window to alert me when my neighbours cat intruded with a Raspberry Pi0W and logically ANDed the signals with node-RED which emailed or tweeted me. The RCWL-0516 is so sensitive that any human mousing or motion on my desk 2 metres away will trigger the thing.

[b0b7h3d0g]

@jeraymond I don't have experience with the through hole mount beads but I see no real difference between the one I have and the one in your picture.

This scenario also works (I didn't have enough time to test it though):

[capitalfuse]

Would be good if a ferrite bead attached or twist the 3 cables into one. I adopted the latter.

[theMASTERMINDpK]

You would have to send me a couple to test :stuck_out_tongue: otherwise your guess is better than ours... since you can physically test them.

[mischmerz]

Alright - we have .. 10 or so of theses sensors on our test-devices (Raspberry Pi 3) , 9 of which work flawless no false triggers or any other problem - directly connected - no filters, beads or capacitors. One of the sensors however triggers all the time, within 5 - 10 minutes intervals and for no reason. So - I assume that false triggers may also just happen because of faulty sensors. I will replace the sensor and report back (I put a reliable PIR sensor on the unit for the time being).

[starfish1107]

wonder if anyone else could confirm. Simply using 2 power supplies (1 for ESP and one for the sensor) completely removed the false triggerings here.

[Wirthx]

I use many methods but cannot get rid of false trigger. However, I change idea by turning off WIFI on ESP8266 when it is not required. Whenever sensor trig, ESP will write a note to EEPROM and restart (ESP.restart). After restart ESP8266 will read from EPROM and start WIFI to send data. Then clear EEPROM and restart again with no WIFI.

ESP8266(WifiOff)>>Trig>Code to EEPROM>>Restart>>ESP8266(WifiOn)>>Send Message>>Restart >>(Repeat all)...

It is nearly zero false alarm. I combine it with PIR sensor and let them recheck each other. I test it for 2 days no more false alarm.

You can place ESP8266 anywhere near sensor and no more issue about power supply interference. Also it reduces power consumption of ESP8266 significantly.

[theMASTERMINDpK]

@Wirthx did you feel any delay while doing this thing?? as ESP takes some time to restart!!!

[Wirthx]

Yes it will take few seconds (2-5s) to restart ESP8266 so my method is not suitable for realtime detection but it seem OK for thief detection.

[starfish1107]

Maby an isolated DC-DC converter can help to remove the interferences that come from the ESP to the RCWL over the supply voltage. I suggest some ferrites on the data and power cables to!

that seems to be the best solution. After getting good results with two separate 5V power supplies, I tested this variant (isolating dc-dc converter) with the radar sensor connected to the secondary 5V. Even when connecting the primary and secondary ground pins I could eliminate that false triggers. Additionally I used a "pulldown"-diode at the ESP input as a level shifter. The ESP input must be programmed to use the internal pull up resistor. (some of the radar modules provided 5V output, no real open collector).

[starfish1107]

Edit dec. 8th I am no longer using the diode solution - the double LC filter circuit below showed much better and reproducible results.

but as mentioned above: the ESP-Pin has to be programmed as input with internal pullup resistor activated. I also found that some RCWLs have been damaged when being connected without the diode - and then showing exactly that spurious signals problem. (that happened probably when doing tests with 2 separate power supplies) The power supply I am using is a simple 5V charger with the USB cable connected to the Wemos. Until now I made 4 units - all of them working perfectly. running ESP Easy Mega (www.letscontrolit.com) sending MQTT signals to iobroker.

[jeraymond]

How does the diode help eliminate the false triggers?

[starfish1107]

to be honest, I found it empirically, when replacing another make of radar-sensor. That one had an open collector output driving a LED connected to 5V the result was a 5V signal level at the input of the Wemos. Inserting the diode was eliminating the overvoltage. When connecting the RCWL the same way, I noticed that the false positives have gone - meanwhile stable with 4 sensor setups.

[starfish1107]

@jeraymond - I found another reason for these false triggers. I noticed, that the setup usually works fine at the beginning but getting worse after a while. I took one of the sensor-pcbs from the trash, connected it. As expected it produced a lot of false signals. Then I washed the sensor print with pcb-cleaner spray. Believe it or not, after drying, it worked as the "virgin" new ones - no more false trigger sigs. Could you (or someone else) verify this?

[underwoodblog]

@starfish1107 can't test it but I may have an explanation. There may be some solder flux or other stuff on the pcb that "sucks" up the moist in the air and may get conductive (with high resistance) that leads to these false triggers.

I had build a high impendance sensor a few years ago that didn't worked as expected. After cleaning the pcb it worked perfect. Had this effect on some audio circuits to.

I suggest to use some coating after cleaning. I use "Kontakt Chemie Plastik 70 Super" for high voltage stuff (3000V) that had to work in dirty and wet condition.

[barewires]

I would recommend always twisting power and ground wires together and make them as short as practicable. The diode will drop .7 volts leaving the logic 'low' right at the threshold and it is most unconventional, a simple 3.3 / 5 bi-directional logic converter made with an N-Channel FET and 2 resistors is always highly recommended. If you are briefly back-feeding the sensor output, say on IO power-up should a diode not point outwards? The sensor is active-high. The ongoing false trigger problem in my case is simply that the device is so sensitive that any motion even in the next room will trigger it. I can't detect the neighbours cat coming in a window in one room with an email from a Raspberry Pi Zero and roll over in bed in the next without be detected.