When I grew up in rural Connecticut more years ago than I care to admit to, the term “bats in your belfry” was a metaphor for being crazy. But with the advent of modern camera and computer systems and the ability to easily merge the two, the phrase has taken a step away from the metaphoric toward the more literal.
There probably aren’t many people these days that literally have bats in their belfry, but many people today find themselves playing the role of landlord to eagles, coyotes, or other wild creatures, and some use camera systems to bring images of these creatures into their home.
Several examples here in the Seattle area come to mind. One example would be two friends in Kent, WA who found themselves hosting a family of eagles nesting in the top of a tree on their property. The homeowners contacted the state’s Department of Fish & Wildlife, and as a result of an agreement between the homeowners and the state, the state provided the equipment (two cameras, servers, DSL service, etc) and the professional services to install the cameras while the nest was empty.
Later that season the camera system heralded the eagles’ return, much to the delight of people around town, around the country, and even a few as far away as Europe.
The video was brought into the home, modulated, and fed into the TV system, permitting the homeowners to view and record the eagles by tuning the TV to the appropriate channel for them, the nest had become just another TV channel.
Eagles at home in Kent, WA
And when on one occasion severe winds brought a tree branch down atop the nest, the video was picked up by a local television station making all of King County aware of the eagles’ plight.
There are a number of reasons why some homeowners find camera systems an attractive option aside from the oft-stated convenience and security. Some, for instance, find their “guests” interesting, informative (especially if there are children in the household), perhaps even entertaining (a friend recently lent me a tape of burrowing owls, they’re really neat, one might even say comical little creatures!).
And if the homeowners choose to share their “guests” with others via the internet, they’ll find a large community waiting to welcome them. The family in Kent chose to host their own eagle cam website and now have a large group of dedicated reader/viewers.
In yet another example, perhaps a year ago we placed a camera in a beaver den in Alaska. Regrettably, the client chose not to place those images online, and so we haven’t any images to share with the reader, but that was certainly one of the more interesting (and fun) applications we’ve worked on.
Yet another interesting application teamed ThermoSight, the Washington Dept. of Fish & Wildlife, Woodland Park Zoo, and the Bonneville Power Administration. With the assistance of a BPA crew, a camera was placed on a transmission tower in a remote area to watch a nest of Ferruginous hawks.
For this application, a relatively inexpensive camera was connected through a professional-grade wireless video link to a receiver several miles away. There, the video was recorded for subsequent study by state biologists and images were uploaded to our website and Seattle’s Woodland Park Zoo.
Since the camera and transmitter were in a remote area where AC power was not available, solar power was used to power both the camera and transmitter. Both systems presented a relatively light load to the solar supply, and since there was no requirement for nighttime viewing and the camera was fixed-view, the usual heavy loads (IR illuminators and P&T stepper motors) were not an issue.
A mechanical timer was incorporated to permit the precise timing of application and removal of power each day. During the daylight hours, the solar panel both powered the equipment and maintained the battery charge. In the evening, the only thing left powered was the timer itself. Further, the precisely-timed power permitted us to synch the video recorder several miles away with the power supply at the remote site, thus preventing recording while the camera was powered down.
A typical configuration
We’ve introduced a number of terms which may be new and alien to many homeowners: server, DVR, P&T, etc. This then, may be the right time to discuss these terms and the system configuration in general.
block diagram – requirements and options.
In the diagram above, some components are drawn in black while others are greyed (or in this case, greened) out. Those elements in black are required, whereas the other elements are options, with a single exception: the server. A server is not required, but it is highly recommended. And of course, I recommend an AXIS server for this or any configuration. While there are many server manufacturers in the marketplace, one cannot help but be impressed by the immense power available in the AXIS server.
With that said, let’s take a look at the diagram:
Let’s begin with the camera icon in the upper left corner. Although it looks like a spray painter, this icon purports to represent a conventional camera mounted on a pan-and-tilt (P&T) mount, but here, the homeowner has several choices available.
The homeowner may select a conventional, dome or bullet camera, or any of several other varieties of camera. If the camera is to be placed outdoors as most if not all wildlife applications would, it is critical that the camera be shielded from the elements.
The important points to remember about the camera are the video output, and optionally, the controlling input (ignoring, for the moment, the requisite power input).
As indicated by the dark lines in the diagram, the video output is a system requirement, and is usually taken directly from the camera. In this diagram, the video is fed directly to the AXIS video server, but while the diagram may indicate that this is a requirement, in actual fact, it is not.
Indeed there are several options regarding video feed: in the simplest configuration, there would be no server at all, and the video would be fed directly to the auxiliary channel of a conventional TV set (see the block labeled TV Aux chan). That’s really all that’s necessary: a $69 fixed-view camera, a few feet of video cable, a sub-$5 adapter, and an ordinary TV set with an auxiliary channel. That’s all!
For the sake of simplicity, let’s forget the more complex configurations requiring a greened out distribution amplifier, and connect the video to the video server, as shown.
At the very least, the purpose of the server is to distribute the video in the original analog format to peer devices (Video Out on the AXIS 2401+), and in digital format to downstream devices. This digitized video output is then fed (usually, but not always) to an Ethernet connection. This network connection may be the homeowner’s LAN router, or something as simple as an Ethernet cross-over cable connected directly to a PC or laptop. From there, it may be viewed on a single PC or shared with the world via the internet.
Sharing the digitized video with the world depends on an internet connection of some sort. Typically this would be via a cable/DSL modem, a POTS (dial-up) modem, or for more remote applications, via a cell phone connected to a laptop or PC (for instance, a Motorola V66 cell phone or Sierra Wireless Air Card).
OK, having followed the video from the camera out to the world, let’s consider the serial option.
block diagram: requirements and options.
Looking at the diagram again, we see an optional, bi-directional serial connection between the video server and the camera. It is over this link that the server may be used to communicate with the camera, and/or PTZ mount. The fact that the link is bi-directional permits us to receive feedback from either device (camera or mount), informing the server of current camera position and/or status.
That feedback may be used to maintain “presets” (predetermined viewing settings), make a programming (scripting) decision, or simply confirm that an instruction has been received or completed.
An example of such a configuration may be seen here. This is an AXIS 2401+ video server which has been scripted to (a) mimic the ThermoSight website “look-and-feel”, and (b) communicate with a camera not normally supported by AXIS (this server, a Linux device, supports PHP scripting, allowing a user to support virtually any serial protocol).
If you visit the camera server and click on “Camera Replies”, (please be patient; it takes awhile to decode the hex strings with which the camera communicates, and our internet connection ain’t all that fast) you will likely see a string of acknowledgement and completion codes, and depending on how recently the camera was queried, you may see a string of replies that provide status information about the camera itself. This status information may be read by a human or a script to assist in controlling the camera or P&T mount.
Serial Control: What’s the big deal?
Now, let’s take a moment to consider what we’ve seen — this may answer your question “why is he making such a big deal out of serial control?”
If you clicked on the link and visited the AXIS 2401+ controlling ThermoSight’s Predator camera, you saw how easy it is to set the camera date and time. From the Predator’s home page, you click on the “Date Time Title” link and move to the date-time-title control page. With a click here and there, you have synched the camera date & time to the server, perhaps entered a new title, and decided whether to display or hide the date, time and title.
Further, you were offered a means of moving the title if it got in the way of some image detail you wished to see. It was all accomplished with a click here and a click there, and it was done from your desk. It could just as easily have been done from the passenger waiting area at Kai Tak international airport.
Now, some cameras have serial control, some don’t, and a very few have it but choose not to use it. ThermoSight has such a camera and you can see it here (retry via refresh button if link fails).
At full retail, this is a very expensive camera: in excess of $5000 without IR illuminators. The camera itself has serial control but the manufacturer has chosen to not make it available in most cases. When (if) you visited the camera immediately above, did you notice that the time was off by an hour?
Without the “click here-click there” serial control you saw a minute ago on the Predator, we will have to follow several steps to set the date and time on this voltage-control camera:
- Carry a TV or other monitor into the basement where the camera?s back box is located
- Find a suitably long extension cord for the TV set.
- Find an 8-to-10 foot-long video cable
- Carry a stool or step ladder into the basement to reach the camera back box
- Connect the video cable to both the video output and the TV or monitor.
- Find the lens controller (you know it’s around here somewhere, you saw it just six months ago) and connect it to the back-box.
- Rummage around the computer looking for the arcane instructions to control date, time, title. This is not as easy as you might think: one must toggle lens-control buttons to modify date and time (how’s this for an arcane procedure?).
One must follow those instructions to set the date and time. Were you able to understand them in the first three readings? Is it any wonder our camera’s time is still off by an hour after all this time? We may just let it stay as is; it’s right 6 months out of the year. It’s just too darn much effort to change it.
So there you have it: a painfully long procedure for that which, under serial control, is a simple, “click here / click there” session. But wait! There’s more! Did you notice that the instructions said nothing about setting a title, let alone moving the title to improve one’s view? The camera inside the housing supports a title, but I’ll let you try to set it.
And it gets worse yet. After all, date, time and title really aren’t all that important for most applications, and for those applications in which it is important, the server can provide that information; but here is an important problem that the server can’t help with: auto-focus.
Auto-focus is an extremely attractive feature for any camera, but it can be a real liability for a fixed-view camera; consider the following:
Occasionally, an auto-focus camera used in a fixed-view application can go out of focus. If power is lost at night, for instance, the camera will try to set focus when power is restored but if that power is restored at night, there is no image for the algorithm to “see” and set focus with. Consequently, the computer inside the camera will hunt around for awhile, driving the focus further off, but finally throws up its hands and says “the heck with it, you do it!” In the morning when you check your camera, it’ll be out of focus, perhaps horribly so.
In such a case, with a serial-control camera and an AXIS 2401+ server, you click on the command “focus”, and voila: again, a click here, a click there. AXIS makes it so easy.
With voltage-control, repeat steps 1-6 above and depress the focus button. But, as if that isn’t painful enough (and at my age, that’s more than painful enough), what if your application is remote and you have to travel quite some distance to get there, or there is no AC power there? The lens controller requires AC power.
Or, what if you have to climb to the top of a 100-foot tree to reach the eagle’s nest while the eagles are home?
(Trust me, that’s exciting!)
Oh, one last consideration regarding auto-focus: with serial control, you instruct the camera to focus itself, and then you instruct it to enter manual-focus mode so that it won’t go out of focus again, a click here, a click there.
With the voltage-control camera, you take it back to the factory to change focus modes. How long’ll that take?
The manual shows this camera has 12 focus modes — pick one — the auto-focus mode alone has 4 different sub-modes (trust me, this and the Predator are very sophisticated cameras); they both have serial-control, but only the Predator uses its serial capability.
That’s why serial control is a big deal.
The 2401+, with its Linux kernel, task management, PHP and shell scripting, and best-in-the-industry tech support makes your life much easier.
block diagram – requirements and options.
OK, so returning to the AXIS server in the diagram, one sees an optional output from the AXIS server to a device referred to as a “Dist Amp”. This is a distribution amplifier and is frequently used where a single input will feed multiple outputs. It prevents the outputs from overloading the video source. (In actual practice, if a distribution amplifier was to be used, the video input would probably go directly to the distribution amp, and the server input would be fed by a distribution amp output, but that produced an image which I thought might be unnecessarily complex for this discussion).
One of the distribution outputs goes to a DVR where the video may be recorded, either by schedule (i.e. from this time of day to that time of day on this or these days of the week), or upon alarm (an alarm such as, say, motion detection). This is a very important feature. Motion detection, for instance, provides a means of avoiding the recording of hour after hour of an empty nest, employing instead a procedure wherein recording is terminated after several minutes of inactivity, and begins again when motion is detected as the bird returns to the nest. An excellent example of such a DVR is the Dedicated Micros DVIP.
Yet another option available to the homeowner is to connect the DVR to the LAN, and possibly the internet, thus sharing the video (recorded and live) and still images with anyone on the network, and optionally, the world. When so connected, the DVIP offers the homeowner yet another option: automatically offloading the video via FTP rather than enduring the heartache of writing 80GB worth of CDs.
Yet another option available to the homeowner is an alternate method of viewing the camera video on television. In this case, the distribution amplifier feeds a modulator which is merged with the antenna, cable or dish signals, and distributed throughout the home. This converts the camera video into just another television channel, making it accessible virtually anywhere in the home by any television fed by the TV distribution system.
Another image from the Kent eaglecam
Another look at the AXIS server.
Essentially the heart of the system, it might be worthwhile to consider anew the 2400+/2401+ server.
While the primary purpose of this device is to digitize the video input and provide that video to the other members of the network, it’s quite capable of much more than simple digitization.
Perhaps the single most important thing to remember about this device is that it’s a Linux server-on-a-chip. That places a huge capability in one’s hands: the Linux file system, simple scripted task management, PHP and shell scripting, I/O including serial, discrete, and Ethernet communications, and utilities such as FTP (client and server), Telnet, and HTTP support make it ideal for application control as well as support.
Furthermore, it’s well suited to forward deployment in wildlife, or other hostile-environment applications. The server is relatively small, rugged, reliable, and runs on 6-30 VDC as well as 120VAC. This enables its placement in remote applications alongside the equipment it supports and controls, as long as it’s sheltered from the elements.
One final thing to keep in mind is that thirty years ago, NASA sent rockets to the moon with less computing power than that offered by this device. Truly.
Shouldn’t this server be controlling your application?
The kids down at the Orting Hatchery – 6 newly-minted owl chicks.
Image courtesy Washington Department of Fish and Wildlife
Forty feet up in a ferruginous hawk nest, a bull snake fights for life, unsuccessfully.
image courtesy Washington Department of Fish & Wildlife
Dr. Jim Watson / Project Manager / Research Scientist / WDFW