This is a placeholder topic for “Gravity: Microwave Sensor (Motion Detection)” comments.
The microwave sensor applies the Doppler effect to detect moving objects using microwaves. This differs from the method used by a regular infrared (IR) sensor as microwave is sensitive to a variety of objects that are microwave-reflective, and its sensor readings are not affected by the ambient temperature.
Read moreWe’ve had a couple of questions on this product across our Technical Support forum so I’ve merged them all together for one troubleshooting super-thread to combine our discoveries into one spot. Read on and reply at the bottom if you’ve got a question that hasn’t been answered!
Hi Jacob,
I am trying get the SEN0192 Gravity Microwave sensor to work with my Raspberry Pi Pico and Micropython. The issue appears to the sensor is continually firing/pulsing the data pin. I have tried adapting an example Arduino sketch, however, I still can’t get the sensor to correctly sense movement. Multiple false positives. From what I can tell the sensor itself works correctly. the amber led lights when movement is detected. It is just seems to sending high values all the time.
Hi all,
Adrian’s comment seems to align with the comments on the DFRobot forum. Does the serial output behave ‘better’ on sensing movements in the detection zones or does it also fire on any movement like the output pin?
Murray
@Murray125532 I had a lot of issues with the detection ‘zones’ with this device, and also spent a lot of time on the DFRobot forums discovering that I was not alone. My testing concluded that for best results I set the minimum distance to zero, and the maximum distance seemed to work when set to around 3 to 5.
For example:
mmwave.DetRangeCfg(0, 4)
When testing this down a 10m long hallway, the sensor did indeed ignore me once I was around 3-4m away from the device, as expected. However when setting the maximum any further above 5 it pretty much just acted as a full-range motion detector. At least they were my testing results in my environment.
Unfortunately, in my testing, it appears that setting a minimum value of above 0 does not work as expected either - it always triggers if you are anywhere below the maximum distance (also with respect to my comment above). I also found the dead zone to be extremely close to the sensor - around 5cm.
Furthermore, I could not get setting multiple zones to work at all, unfortunately, as the sensor still triggers when between zones. This has also been reported by other users on the DFRobot forums.
With all that said however, I did find that when this sensor did work (e.g. within a 3-5 detection zone, or as a simple full-range room presence sensor), it worked really well - significantly outperforming a PIR in both reaction time and false positives/negatives (or lack thereof). It also accurately detects non-moving human presence as advertised, which is what piqued my interest in the product to begin with.
Hi @Adrian200392,
What voltage are you powering the sensor with? In my testing I found that powering the device from the 3.3V output of the Pico would send the sensor into a firing fit. Try powering the sensor from the VBUS pin of the Pico (if you are running the Pico from USB), or a dedicated 5V power source otherwise. As always, be careful not to create any shorts when hooking anything up to the VBUS pin - it is connected to your computer’s USB port!
Hi Jacob,
I am using a separate 5v 1A 5W power supply. For data I am using pin 2. Not sure if that clarifies anything.
Adrian
Hi @Adrian200392,
Thanks for confirming, my next debugging step would be looking for sources of interference such as nearby metal - the product page and DFRobot wiki doesn’t mention it, but usually with microwave and mmWave sensors you need to ensure you have not obstructed the forward side with anything metallic and the back side should have clearance of more than 1cm from any metal. Is it possible to share a picture of your circuit/project?
Also, have you performed any configuration of the sensor using the Serial interface? In my testing the sensor work best after running a factory reset, setting the range from 0 to 5m, and setting the timing to 0, 0.
I use a dedicated script to run against the sensor to configure it once, after which I can just use GPIO2 on the sensor for its HIGH/LOW detection output just like a PIR sensor.
from dfrobot_mmwave_radar import SEN0395
import time
mmwave = SEN0395(uart_channel=0, tx_pin=0, rx_pin=1, debug=True)
time.sleep_ms(1000)
mmwave.factoryReset()
mmwave.DetRangeCfg(0, 5)
mmwave.OutputLatency(0, 0)
Hi Jacob,
Still trying to get my SEN0192 microwave detection module to work correctly. The code and library are for a for the SEN0395 which to have a different mode of operation. Are you away of any Micropython examples using the SEN0192 as adapting Arduino sketch code hasn’t proven effective.
Hi Adrian,
The SEN0192 is simply a presence (motion) detection module and using a binary digital output unlike the SEN0396.
Since it can detect through walls there can seem to be lots of ‘false’ triggers, water inside pipes, pets and even moving your hand can set off the sensor.
Hi Liam,
Thank you for the prompt response. I understand the SEN0192 is simpler device that the SEN0396. The issue I and others have is the high number of high values being sent over the data line. As mentioned in my earlier post the amber detection led triggers correctly when motion is detected, however, as said before the data pin appears to be permanently high. I am using a separate 5v power supply to run the device with data line being only connection to Pico.
Hi Adrian,
Have you adjusted the potentiometer down?
I’ve had great success with this sensor on the Pico, adjustment is much harder - coming in the form of a capacitor that has to be soldered in but the defaults worked perfectly.
Hi Adrian
Just had a glance through this post. You haven’t perchance set toe data pin high with the INPUT PULLUP setting have you. This will connect the pin to Pos volts via an internal “pull up” resistor.
Cheers Bob
Hi Bob,
Here in my code
from machine import Pin, Timer
import time
timer = Timer()
led = Pin(“LED”,Pin.OUT)
pbIn = Pin(2,Pin.IN,pull=Pin.PULL_DOWN)
state = False
count = 0
def stateChange(pbIn):
global count
#print("-------pbIn.value()={0} count={1}".format(pbIn.value(),count))
count += 1
def timerHandle(timer):
global count
global state
print("Count={0} State={1}".format(count,state))
if count > 1:
state = True
count = 0
pbIn.irq(trigger=Pin.IRQ_FALLING, handler=stateChange)
timer.init(period=1000,mode=Timer.PERIODIC, callback=timerHandle)
try:
#led.value(not led.value())
while True:
time.sleep(.001)
if state == True:
time.sleep(2)
state = False
led.value(not led.value())
print(“Activated”)
except KeyboardInterrupt:
print(“Keyboard Interrupt”)
finally:
timer.deinit()
led.off()
#time.sleep(2)
print(“Finished”)
Hi Adrian.
That was Arduino speak. At this stage Python or any of its derivatives is Swahili to me.
But I note you have
which suggests the input pin should be LOW.
BUT I also note that you have
Which makes me wonder why you have an interrupt (???) activated on a FALLING slope when the pin is already supposed to be LOW.
As I said I am not very conversant with Python or varieties of but there may be something there.
Cheers Bob
I haven’t used that specific sensor, but looking at the DFRobot Wiki page I think their code sample is a bit overkill for verifying the sensor is working and calibrating the sensitivity trim pot.
I recommend replacing the code with something similar to the following to help eliminate if there are issues in the setup of the interrupts. It just loops infinitely and prints the HIGH/LOW value of the sensor as a 1 or 0 to the console every 100ms, as well as setting the onboard LED to on/off, in conjunction with the detection status. Note I have not physically tested this code, but it’s a very common pattern so it should work fine.
from machine import Pin
import time
led = Pin("LED", Pin.OUT)
pbIn = Pin(2, Pin.IN, Pin.PULL_DOWN)
while True:
pbVal = pbIn.value()
print(pbVal)
led.value(pbVal)
time.sleep_ms(100) # 100 milliseconds - increase this number to slow down the logging
After verifying that the sensor is triggering and un-triggering when there is/is not movement, I would start adjusting the trim pot to find the sweet spot for your environment so that it is only detecting valid movement (e.g. not picking up movement, pets, etc on the other side of a wall). Only after that I would try a more complex code implementation to start filtering false-positives using code.
One final tip, I’ve been playing with Microwave and mmWave sensors a lot over the past week or two, and have found that when moving them around a lot (ie when testing & debugging) their readings start to get a bit wild and unreliable. A full power-cycle (e.g. completely unpluging and replugging power sources to the chip/Pico) will get them reading sanely again. My assumption is the onboard chips tries to adapt to the environment, so constant movement messes this up - a power reset fixes this.
Edit: A follow up thought - make sure there are no metal sources in front or at least 1cm behind the sensor - they do not like metal! If you have it on a breadboard (which contain a lot of metal), try connecting the sensor with some jumper wires and bluetak-ing the sensor to a non-metal surface while testing.
Good luck!
Hi Jacob,
Thank you for the code I gave it a try using several delay values. It did’t appear to trigger reliably in a timely manner. Though reducing the delay did seem to improve the responsiveness a bit. Though still not reliably. Also I revisited my original code removing the time interrupt/function. It seems it continually triggers the interrupt whether sensing or not. Just comparing the two approaches. Further acting on your advice I raised the off my desk by about 5cm using a not conducting tube. That didn’t seem to make any significant difference. Finally during testing the sensor did remain still.
Hi @Adrian200392, @Trent5487676 and I just connected a unit to an oscilloscope and can confirm the following:
The following code should print when detecting a falling edge (motion).
The print occurs outside the callback so that the callback remains as brief as possible.
from machine import Pin
radar = Pin(2, Pin.IN)
interrupt_flag=0
def callback(pin):
global interrupt_flag
interrupt_flag=1
radar.irq(trigger=Pin.IRQ_FALLING, handler=callback)
while True:
if interrupt_flag is 1:
print("Motion detected")
interrupt_flag=0
Hopefully the change to the circuit and code helps. We did observe that many edges are generated when motion is detected - probably because movements are being acquired as separate events or perhaps this is even to help with calculating some velocity.
Resources
I pulled the code from a great article on GPIO interrupts
Hi Adrian,
If you needed help making a voltage divider to scale down the logic output level from the microwave sensor this guide explains how under the heading Reducing Voltage.
Hi Trent
Why did you split the replies to these topics.
They are 2 entirely different devices.
I replied to Michael (and Adrian) but this reply now appears elsewhere.I don’t know now which topic I was replying to
I think it was the “mm radar” as this one definitely states “doppler”.
I think Michaels reply belongs in the other one as his reply and my answer to that one now are in 2 separate threads.
Very confusing, to me anyway as I now am not sure what I was doing and will therefor give up on both.
Cheers Bob
And you can get our latest projects and tips straight away by following us on:
