As part of my duties it is necessary to actually plug in and program various IP-enabled security devices to see how they work and what makes them valuable.

One of the problems of living in a big city is that living space is at a premium, particularly if you’re lucky enough to have a single-family home. So what my daughter thinks is her desk is actually a product test bench.

While she attends elementary school her Daddy is crawling under her desk, connecting network cabling, power supplies, and devices to the switch on her desk. Both the Axis and Honeywell cameras currently connected in the photo provide excellent images over the Internet.

The network switch was purchased for $5 brand new at my local computer store, and it’s connected to another cheap Ethernet switch that is connected to a third switch, which is contained in the Linksys WRT54G router on my desktop downstairs. So every camera or device I connect to my network must pass through three network switches before it reaches the Internet or my desktop computer. I believe that this setup is a good simulation of the type of networks that security dealers will find in residential or light commercial installations.

This brings us to a recent camera test from a Manufacturer Not to Be Named (MNTBN), which was neither the Honeywell nor the Axis cameras in the photo. I connected the new camera to the network switch, and even though I had programmed it properly, the camera would only occasionally allow me to access it with Internet Explorer over my local network. What was puzzling was that sometimes the camera would connect, and sometimes it wouldn’t. Logic tells us that the programming of the camera is correct; otherwise the camera would never work. So what is the problem that causes intermittent functionality of the MNTBN IP camera?

The first step is to use the screwdriver of network testing, the ping –t test from the command line, to test the connectivity. The results were quite confusing.

The ping –t readout indicates a device that is just not working properly on the local network. A functional device on a wired Ethernet network, even passing through three switches, should provide consistent ping round-trip times of less than 5 milliseconds.

By comparison, here’s the ping –t results from my desktop PC for the Axis 1031W camera on the testing desk.

So the usual tests were performed, including changing the connection port, the jumper cable, and I even connected a high-end managed network switch from American Fibertek, but the problems continued.

A consultation with an expert was called for at this point. Ray Coulombe is a noted physical security networking expert who happens to provide classroom training for Slayton Solutions in fiber optics and IP networking. According to Ray, the problem is in the MNTBN IP camera itself. He surmised that the processor in the camera either did not have the proper capacity to both transmit video images and ping requests simultaneously, or the camera’s operating system software was improperly written. Either way, the problem was the device itself.

I have tested other cameras from the MNTBN and had great performance, so perhaps this particular problem may be isolated to the specific camera I was testing. I believe the lesson to be learned here is that as technicians, when things go wrong there’s a tendency to blame the parts of an installation we have control over, such as the cables, connectors, and power connections. And even though the manufacturers in our industry uniformly provide functional products, there might always be a “black swan” device.

It’s a simple and cheap scenario to create your own testing network at your office, which should be used to pre-program and test IP devices. Smart installation companies will bench-test devices before they get tossed into the installation van and driven 50 miles to the installation site. Five minutes of testing might save you many hours of frustration and lost profits on an IP-related installation.