I have a DCS-2132L that is installed as the primary camera in a flash flood/debris flow monitoring and warning system. Here are some lessons learned and workarounds for issues that came up during design, build and installation.
On-board infrared is always going to cause false or unwanted motion events. Examples are snowfall, rainfall, flying insects, bats, owls and blowing organic debris. Turn off the on-board infrared. Use external infrared illuminators, and mount them far from the camera. Close-in extraneous objects will never cause a night-time false motion event again. When snowing at night and with remote illuminators, no falling snow is visible whatsoever. Note that this installation applies to implentation for a distant target, about 120 feet away from the camera. I am using multiple infrared illuminators made by SuperCircuits and they are superb.
Use a light-colored motion target, and draw your motion windows on the target. This will further reduce false motion events.
FTP and the writing of a single snapshot is by far the fastest and most reliable method for getting a motion flag to a computer or server. Use of FTP allows for a network configuration that avoids many of the security hazards in Windows networking, such as NetBIOS. There is no useful utility in D-ViewCam for programmatically using an event flag, i.e., to run an executable when a motion event image or video is output by the camera. Pity. Surely D-Link will address this someday.
When using FTP to write images triggered by motion events, sometimes a text file notification is sent as well. I have not been able to figure this out, because the text file is very rarely sent. It may be because true motion is very rare, and the event triggers right now are almost always the result of aperture perturbations, not real motion.
Aperture perturbations. I'm using this as a generalized term to apply to camera hardware changes that are picked up as undesired and uninteresting motion events. Examples are the persistent flips at dawn and dusk between night and day modes until the quantity of light allows the camera to settle into one mode or the other. I had to develop programmatic algorithms to create and respect consecutive-event thresholds that must be met before triggering sirens. On the setup page for Event Setup/Event, there is mention in the right help panel: "Video motion detection: select the windows which need to be monitored." I have not found that this is implemented, and it sure would be handy. An example is spider webs that appear overnight, and that then blow in the wind to cause false positives. Until a long hike can be made (every day in the summer?) to remove the webs, they cause false events/alarms. If separate motion windows could be drawn and managed, and each could deliver uniquely identifiable motion flags, this type of extraneous motion could be handled easily be refining the motion criteria that trigger events, i.e., if windows A (critical), B and C all detect motion, ignore the event. If only window A (critical) detects motion, trigger event.
The camera is mounted in a custom-built enclosure for protection from weather. The enclosure is then mounted to a very heavy platform at the edge of a high cliff. The lesson here is stability: nothing ever moves in the wind. Otherwise, even the slightest mount-oriented movement can cause false motion positives.
The system is wireless and offers live streaming video to client computers up to 1/2 mile from the 2132L mount location. A yagi antenna is used to reach 1000 feet from the wireless access point to the 2132L. On the 2132L, 30 fps is nice, but causes excessive jitter when motion quantity is high. Examples are snowfall, rainfall and streamflow. Bandwidth is not the limitation, nor is the server - an 8-core machine with ample video RAM. I have not been able to identify the source of the high-motion video jitter, but dropping down to 15 fps allows the camera to better-handle large amounts of viewed motion without impacting utility and purpose.
D-ViewCam is being used as the video server. No client is allowed direct access to the camera, eliminating any possibility that clients could overload the camera-side of the wireless system - which is mission critical. In the camera, Advanced/Access List allows for limiting direct camera access.
The remote 2132L installation (including illuminators) is battery-powered, and charge is maintained by a solar module/charge controller system. For stress-testing, adaptation to and recovery from power outages is critical. Thus, the camera is always on and never loses power. However, a power interruption at the server/network system that causes loss of the wireless signal for more than 5 or 10 minutes causes an issue at the camera when server power, and hence wireless access point power, is restored: the camera cannot relocate the wireless network. The only solution has been a long hike and climb to manually reboot the camera (power cycle it). I have found no resolution. It would be nice if the camera could again join the newly-energized network without manual intervention. Fortunately, in this installation, sustained power loss beyond the capacity of backup power are very rare events. 942Ls do not have this issue - they will rejoin the network no matter how long the wireless access points have been de-energized.
On the camera, in Setup/Image Setup/Image Settings/Exposure Mode, the ability to customize exposure settings has been very useful, particularly for high-contrast nighttime conditions.
For the sharpness setting on the same configuration panel, any sharpness setting greater than zero increases video image size and hence bandwidth requirements. What you get out of this depends on your needs. Unsharpened image quality from the 2132L is so good, there is no point in using sharpening that can put pressure bandwidth in this application. Also, as inherent to the nature of greyscale vs. color video, the higher bandwidth pressure is meaningful during daylight hours, not at night.
Audio-in gain settings are very limited - there are just two options. This does not matter in this application, but it may matter for other uses.
Accurate time is mission-critical. A slow client computer, when accessing D-ViewCam/RemoteView on the server computer, will experience delayed video playback so that what is viewed is history, rather than real-time. In benchmarking, a slow computer could easily be showing video that lags by 20 seconds or more. A time server is installed on the computer server. All hardware, including cameras and client computers, refer to the the time server to keep accurate and, most importanty, uniform time. On the 2132L, point the camera to a time server in Setup/Time and Date/Automatic Time Configuration.
To address this so that client computer owners understand if they have a video delay issue, they move a digital bar clock under the display of date and time delivered on the video stream by the camera. If the time on their own system clock is ahead of the camera, i.e., the camera video is lagging, they know they have an issue and what they are seeing is not in real-time. The same computer hardware issue will be impacting their client software that monitors the server for qualified motion events - their sirens may be delays. Bottom line - consider using a time server in networked applications. This also solves camera time synchronization issues for time-critical matched video comparisons.
Setup/Event Setup requires study to understand. Time invested is worthwhile. It is a very flexible utility and truly useful.
SD Card: I've never found this to be useful because images can be saved on a computer. I might change my opinion someday, particularly in regard to having a secondary backup image repository.
Maintenance/System/Save Configuration: don't delay. Backup your settings. A lot of work can be invested in configuring the camera. If a problem occurs and the camera must be reconfigured, your backup will save much time.
An example. In Setup/Network Setup/LAN Settings, QOS Settings have been configured to ensure that Event/Alarm (mission critical) and Management have the highest priorities. Thinking that COS Settings would then be a useful companion to prioritizing traffic, I changed COS settings. The camera freaked out, required a manual power cycle to reboot (a 1-hr roundtrip task, which is problematic), and all settings were lost.
That saved configuration saved a potential great deal of additional hassle.
The best route for client computer owners to access live streaming video delivered by D-ViewCam is with MS Internet Explorer because it is simple.
The inability of RemoteView to provide multiple camera views, when the software is written to do so, is silly.
Two workarounds...
Open multiple Explorer windows, and access the same user account in each window. Open a different camera in each window. Turn off toolbars that cause clutter. This is actually more useful than being stuck with multiple camera views in fixed-size windows because they can be overlayed, one window on top of another.
Alternatively, when using D-ViewCam or RemoteView, open different instances of the program in different sandboxes (Sandboxie, etc.). Bingo, different cameras are viewable simultaneously.
But because D-ViewCam is written to graphically overtake the monitor screen (full-screen application), the advantage of having sizeable windows is lost. To address this, use a windows utility such as WinSplit Revolution. The approach is not perfect, but it does the job and gets rid of the Explorer junk that can clutter the view with the first method.
The sandbox/Winsplit method is going to be too complicated for many casual users, so have them stick to the browser/RemoteView/multiple windows method. For admin folks and those that will take a little time to understand their system, it may be worthwhile.
The 2132L has operated flawlessly to -15F. It has been manually turned off for colder temperatures, because -15F was the limit that I needed and I did not want to cause unnecessary stress too far beyond design limits.
Finally, two 942Ls are also connected to the warning system. They are being used strictly for delivery of live streaming video at two important locations, and not for motion events. The configuration options on the 942Ls are fairly crude compared to the 2132L - which is why I jumped at the opportunity to buy, try, and ultimately use the 2132L as the primary monitoring camera. The 942Ls have little flexibility for detecting and using motion events, are of lower video resolution, and are significantly inferior to the 2132L.
As the price point for the 2132L declines, I will likely replace the 942Ls with 2132Ls in the monitoring and warning system.
Author
Topic: DCS-2132L experiences, lessons and workarounds (Read 20724 times)