Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[slickster]

I have had lots of trouble with false alarms using the built-in PIR. Odd that you have more problems on warm days, as these devices are usually more sensitive when it is cold (they sense the difference between a warm body and the ambient temperature). Perhaps my false alarm problem is because my camera is mounted outside. However, I have another camera that uses an external Bosch Iscbpr2wp12 Blue Line G2 Pet Friendly sensor, and it works great outside even without a sensitivity adjustment.

I think my external PIR might also be affected by moving shadows on warm sunny days. To get a better idea about my setup, I included a picture of it ar the following link:

http://i47.tinypic.com/2uj1h1v.jpg

The camera is behind that slot in the window blinds and the external PIR is just under the roof over the entrance toward the upper right of the picture. And because a few months ago you were wondering how much my camera might see at night without its built-in IR turned on, I also included here a video clip showing me driving to the garage at night. As you see, the outside lights provide plenty of illumination for the cam's own sensitive lens with ICR. That barking is from my "electronic dog" and the clicking sound from the relay triggering the digital input of the cam.

http://tinypic.com/r/2m3jmlk/6

Regarding the video motion detection, I believe the sensitivity adjustment reflects how many pixel changes will trigger the alarm (higher sensitivity means fewer changes will trigger the alarm). The percentage adjustment relates to what portion of the defined motion detection area needs to see motion before the alarm is triggered (lower percentage means smaller bodies will trigger the alarm, but only within the defined area). Thus you will get more false alarms with high sensitivity and low percentage. I agree, however, that trial and error is the only way to get this right, and even then there will be problems. I thought I had it perfect, but then we got some bright sunny days -- here in Seattle, that is sometimes rare -- and I started getting lots of false alarms again from the moving shadows. I have another Bosche sensor (only about $15) that I will hook up when I get around to it. Unfortunately it requires 9-12 volts, and the D-Link camera provides only 5 volts, so I will need to use a battery pack.

Thanks. You explained it much better than the cam's Help text.

[slickster]

4) The date and time are always part of the name both in FTP and in SD (it depends on "Event -> Media Type -> "File Name prefix" value).

Joe Public,
I now use the 1.00.02 version from the Italian D-Link web site and the video clips stored on the FTP site still don't use the time stamp in a humanly recognizable format, such as the clips that are sent to the SD card or the snapshots I mail to myself. But now I at least can confirm what I suspected that video clips stored on FTP site indeed contain the unconverted Unix/Linux system date in their name. Here is an actual video clip name from my FTP site: VClip1337019963_1917.avi where "VClip" is the prefix I gave to all my video clips and 1337019963 is the Unix/Linux system time that counts the time from Jan 1, 1970 in secs. I'm not sure what that "1917" part is, but I suspect it's some kind of remainder from the time conversion.
You can easily convert this system time with the converter on the following web site to verify my theory:
<http://www.glassgiant.com/geek/unix-timestamp/>
That gives the date and time as 2012/05/14 11:26:03 PDT, where I am. That also happens to be the time when the video clip ended. Observe the time stamp on the actual clip:
http://tinypic.com/r/2yy5f9x/6

What I don't understand though is why it is only me who gets this unconverted time stamp in the FTP-d video clips even though I do get the converted time stamps in SD video clips and snapshots.