Conflicting Motion Detection configuration.

[AlekssuPandian]

I see a few questions related to this posted on the forum, but I couldn’t find answers to this question. Why are there two potentially conflicting configuration options for motion detection. And how do they work together ?

1. Under Device Settings -> Device Utilities -> Camera Positioning : the following blurb claims effectively “that motion triggers happen in the bottom 2/3ds of the image, the non-shaded part that is.
2. Under Device Settings -> Activity Zones : User can define rectangles (multiple) and I guess the “union” of these user defined rectangles defines the trigger area.

This is such a ridiculous configuration that creates unnecessary confusion in a users mind. What rule applies ? 1. Or 2. Or the intersection of them ? Or does 2 override 1 ? It’s not fair to ask the user to experiment with these settings and reverse engineer how these configs work. Here are my top 3 issues with this (because I got a hundred, and I’ll just stick to these).

• Why allow a user to specify activity zones in the upper third of the image where there is a claim that it’s not optimized for triggers ?
• Why free form rectangles and not just a simple grid of squares of finer grain that users can simply paint by selecting. This is what professional systems do.
• Why is there no UI option for deleting an activity mask ? Such a low hanging fruit.

Given these pitfalls in the flow design,  I am least surprised that in fact these settings don’t stick, and don’t seem to work. I get false alarms from the street all the time (so annoying) even though it’s not part of my activity zone. Please simplify the settings, focus your feature set and make life easy for users. I’m returning my system if I can’t stop the false alarms.

[dcfox1]

They are two sperate functions. The positioning is for general set up for best motion detection. The activity zones are for motion areas you don't want no matter if they are in the top 2/3 or not. Yes activity zones are not  perfect but do work for the most part. There was a problem earlier but has been fixed. 

https://kb.arlo.com/000062452/How-do-I-troubleshoot-problems-with-Arlo-activity-zones

[AlekssuPandian]

I remain dissatisfied. The fact that there are two confusing guidelines aside, it simple doesn’t work. I have played around plenty with the activity mask, even tried applying the inverse of it (placing it where the activity is) and there is simply zero behavioral difference in the amount of false positives I get.

This could be a software issue, I.e., the setting is not getting internally picked up.

or they are using some very naive image processing techniques that rely on pixel level thresholding on an image that is downstream of what the auto-exposure gain is doing in the firmware of the camera (which they probably can’t tinker with). Otherwise I can’t explain how a car driving on the street is triggering a false positive when my activity zone is a solid wall with no leaves or movement,

Further, false positives kills battery life. Game over.

[jguerdat]

Depending on your Arlo Smart settings for the camera, a car could potentially still be a trigger simply because of the amount of IR reflected from the sun or engine heat. The reflected IR would be especially problematic since there's no way of masking it as it bounces around.

Positioning the camera to exclude as much unnecessary view as possible, including the street, could be useful. Post a screenshot of the camera view for suggestions.

[AlekssuPandian]

Observations: False alarms are triggered when cars are passing by (both day time and night time). The visual RGB pixels don’t show any difference (noticeable) in the regions masked by the activity zone. 

If there are no IR blocking filters in these cameras (to facilitate night vision in b/w) and if said IR photons are reaching the sensor (reflected off car onto walls inside activity mask) then that activity has to show up as a pixel value jump on the converted image that is shown ,,, no ? 

so unless what you are saying is a fact, and not just a possibility I find it hard to believe. I will post photos momentarily. Does anyone know for a fact how the motion dectection works ? Is it purely Vision based or is there an additional sensor .

[AlekssuPandian]

Firstly thanks for your suggestions and taking time to debug my problem. Here are two photos that show the issue, one has the car (snapshot of the moving vehicle) from the recorded event and the activity mask set by me.

okay it won’t let me upload the photo because the extension is .jpeg and not .jpg. This is another flow issue that just having a QA person run through these flows with an iPad (or iPhone) would have revealed. It just doesn’t give me the confidence that this is not a software issue (the masking ) and a real physics issue.

i look for the simplest argument for why something is not working, and in this case it seems more and more likely that Arlo has very poor QA as part of their pipeline.

[AlekssuPandian]

Two photos as mentioned above.

[AlekssuPandian]

And the second one.