How do I disable motion detection on a ADC520IR camera?
How do I disable motion detection on a ADC520IR camera?
You can disable recordings based on motion detection schedules by clicking on the “Video” tab then click on “Recording Schedules”. From this screen you will be able to turn all motion detection recordings off by clicking on the on/off button.
You can simple enable Privacy mode by pushing button on camera…
Or…you can selectively tell it not to VMD record when panel is disarmed or armed stay…(at home settings)
The camera is still recording movement. Around 30 recordings in the last couple of day. Please let me know what y’all can do to fix this.
The camera is still recording movement. Around 30 recordings in the last couple of day. Please let me know what y'all can do to fix this.
Are you using “Tampering” rule on the V520IR? If so, turn it off/pause the Tamper rule.
There is a bug where the tamper if enabled on the V520IR, will somehow enable recording of VMD clips even if VMD rule recordings “At Home” settings are used, (and possibly even when VMD rules are paused).
I have submitted multiple tickets regarding this to matter to no avail. ADC apparently won’t/can’t fix it.
A work around solution to stop it is simply to turn off/pause Tampering capability.
I have submitted this issue to a high level engineer at ADC that we work closely with. Until I can report that the issue has been resolved, please disable your Tamper recording schedule. Stay tuned to this thread for updates regarding the Tamper recording schedule issue.
Thank you gentlemen. I disabled the tampering schedule and will report back if it continues to record.
What is the status of this? Its been a month
Alarm.com stated they will have an update for me by end of day.
Alright, the issue at hand seems to be pixel change. It may not be much of a bug actually, but a sensitivity issue.
Camera tampers are registered through the exact same means as Video Motion Detection: a change in the pixels visible in the camera’s field of view. With VMD, this is limited to the windows you select, with sensitivity that you select. With tamper recording, this is accomplished by a sustained and substantial alteration of pixels in the entire field of view with unalterable sensitivity.
The reason for this is to capture tampers from things such as:
What this means is that if your camera’s image is near completely changed one way or another for a period of time, a Tamper will trigger. This will also be registered as a Camera-Triggered-Event clip in Alarm.com, same as motion detection.
Putting all this together, I would check the following as possible causes:
I was under the impression per ADC that the ADC-V520IR uses a gyroscope to detect tampering…
Sept 10th, 2014
I spoke with ADC and the camera detects tamper with gyroscopes built into the camera. When the gyroscope moves, it triggers the tamper.
So now the story is that it’s VMD based tampering not gyroscope tampering?
They need to fix it in any event. There is a problem If the camera is constantly recording VMD clips from clear across a room when VMD recordings are disabled… Especially if its supposed to be using a gyroscope instead of VMD, and secondly,
A Tamper rule is utterly useless if it is essentually just another VMD rule that is set for recording at “all times”, and one that supercedes other VMD based rules that are using “at home” settings to prevent arming mode based VMD recordings.
If the V520IR is equipped with a gyroscope they need to fix the tamper so its actually uses the gyroscope
If the V520IR uses VMD to detect tamper, Fix it so it doesn’t perform the same function as a VMD rule set for “all times”, as it isn’t actually a “Tamper” at all, but just another VMD rule (which already exists)…which is misleading.
Its like the blind leading the blind over there (alarm.com), and their “Quality Control” sucks.
Bumped…so what’s the status? See above response.
I am scheduled to discuss this with ADC video engineers within the hour.
I have confirmed with a video engineer that tamper is recorded based on a modified VMD algorithm. Roughly 90% of the visual field must change for 15 seconds in order to generate a clip. The biggest issue with this is that ADC tech support does not have specifics on the algorithms readily available, which is why there has been so much confusion.
Since it is firmware controlled, with no user, dealer, or even ADC tech capable modification, it must be handled by the firmware design team with an update. I will be annoying ADC with calls until resolved I’m sure.
Regarding why it functions this way: I believe it is purposely designed as, for lack of a better description, a spare tire that automatically kicks in during a flat. Think of it as protection against visual field occlusion regardless of whether your VMD schedule is currently activated. If the visual field becomes blocked during a time when you would not be generating VMD recordings, you would have no way of knowing aside from visual inspection or checking on the live view. While this would be easy to determine by inspection of the camera, it is easy to overlook.
Roughly 90% of the visual field must change for 15 seconds in order to generate a clip.
90% of the VMD visual field window for 15 sec? Or full camera lense visual field?
If its the latter, I can confirm that it doesn’t work, and will record tamper clips without 90% of the full camera lens visual
Field being changed.
Considering my typical VMD window is approx 1/8" x 1/2" it would not be difficult to make 90% of the visual VMD field change from 15’-20’ away…
The algorithm should be based on the full lens.
I would say it is possible the problem occurring is that the tamper algorithm is being mistakenly applied to a VMD window, but that is just speculation. I presume it is something more akin to mishandled or bugged sensitivity or hue uniformity parameters, but that’s also speculation until I hear more.