Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×

Security Watch: Get with the Program

Twenty-five years ago, I landed a job as an installer for an alarm company in Southern California. My job primarily consisted of pulling cable and installing

Security Watch: Get with the Program

Mar 1, 2004 12:00 PM,
By Steve Filippini

Twenty-five years ago, I landed a job as an installer for an alarm company in Southern California. My job primarily consisted of pulling cable and installing door contacts. The art of wiring up a control panel was left for the more experienced technicians; at 16 years old, I did not fall into that category. As my training expanded, so did my responsibilities. Soon I was wiring control panels and conducting service calls on the systems I installed. Soon after that, I hit the big time. I was learning how to program these systems using the various tools offered at the time, which consisted of wire cutters and a pocket screwdriver.

Unlike the sophisticated systems of today, the control panels of yesteryear were quite simple and limited in their feature set. The programming instructions were usually one page in length (two-sided if it included pictures) and relied heavily on the installer not being colorblind. Back then the only things you needed to worry about were the arm/disarm code (unless a key was used), the entry/exit delay times (unless the key was located on the outside of the protected area), and the telephone numbers assigned for the panels to dial into the alarm receiver for police dispatch. Of course, the telephone number wasn’t needed if the alarm system was local in nature and only rang a bell when it detected an intrusion.

Control panels usually had two or three jumpers soldered onto the board. Each jumper was represented by a primary color, and each one enabled or disabled a feature/function. As simple as that sounds, there were problems with that arrangement. Some installers insisted on cutting the jumper at the point where the wire met the circuit board. This was not the preferred manner, because it removed any possibility of reversing an ill-clipped decision. Other installers clipped the wire at the center of the loop, allowing a possible reconnection if necessary. The problem was that unless the tech took the extra second to separate the freshly cut wire, the ends would eventually meet up again and create a sporadic mode of operation.

Another method of programming consisted of the nut-bolt matrix pattern. One side of the circuit board was laced with vertical copper connections, and the other side sported horizontal connections. At the intersection of these strips were predrilled holes that supported a tiny nut-and-bolt configuration. The vertical connections were usually labeled “A” through “O,” and the horizontal connections were usually labeled “0” thru “9.” Where you placed the copper nut-bolt determined the value for that field. So for example, if you wanted the system’s dialer card (almost always a separate circuit board from the main system) to call a long-distance central station number, you would insert the nut-bolt connections in the order in which the system would dial the number. The last three spots (M-N-O) were reserved for the three-digit account number. Under this method, mistakes were kept to a minimum. Programming verification was simple and lasted as long as it took to scan the circuit board from left to right.

WHAT IF?

Then came that dreaded question, “Wouldn’t it be cool if the system did this?” That way of thinking ended the age of simple alarm systems. As the list of features and functions grew, so did the need for a better way to program these systems. Special programmers were developed, and support manuals were created. Now you were required to remove power from the systems before attaching these minicomputers to the data connections. Failure to do so often resulted in scrambled phone numbers and erratic system behavior. Strange hieroglyphic symbols were implemented into the microprocessor with only a few words of explanation provided for each one.

Soon after, Radionics came out with a bar programmer using a special wand for data input. A large book full of detailed bar patterns was given to each field tech with specific instructions not to aim the tip of the wand into your eyes or near your crotch. Blindness and sterility were the demons to fear at the time. The concept was a good one with some minor drawbacks. The wand needed to be disassembled periodically to remove the buildup of paper dust that accumulated at the tip of the red-lit sensor. As if that wasn’t cumbersome enough, large plastic templates with horizontal grooves were provided to ensure accurate and consistent data entry when the wands were dragged across the bar programming symbols.

That went on for about two years until someone developed the bubble-membrane programmer, complete with the entire alphabet, punctuation symbols, and numbers on the face of the device for a more elegant way of entering system information. Care was still needed when attaching or removing the tool from a working system, but the overall design had potential in its simplicity and character range.

During this time, some of the security system vendors developed a series of low-end systems specifically designed for the bare bones, basic-operation applications. You didn’t need a special programmer; all you needed was a system keypad and a booklet to explain what the flashing LEDs and graphic icons represented. I was a fan of these systems for a few reasons. Sure, it took a while to manually enter the information, but if I needed to make any system changes, I didn’t need to wait for a remote download or special tool to be brought out or powered up to complete the task. I could handle it right then and there with results I could count on. I wasn’t just a wire puller; I was a programmer/application designer, with the calluses to prove it.

PC AGE

Then came PC-driven programmers. Whether you were standing next to the system or calling it from 80 miles away, this was the way to go. Versatile and practical, the actual writing of the program for the system took minutes instead of hours. The only complaint I had was that in this age of satellite transmission and data burst technology, transmitting the alarm panel’s data at 300 bps took a long time to accomplish. Soon the PCs grew smaller and more compact. Today there are even systems that use the Palm Pilot and other PDA devices for their programming needs.

There’s all this technology at our fingertips, yet we forgot something important. We forgot to train the old-timers to use the new tools. Wire cutters and pocket screwdrivers were replaced with books, charts, and online support screens. However, a lot of the field techs had never used a personal computer before. Confusion was replaced with frustration and anger. It didn’t matter that you could still hide a bright red wire in a pure white hallway without a trace. If you didn’t know how to download a series of system commands from your laptop to the alarm system, you were given a quick course in software and an even quicker class in PC operations. If you were able to pick it up, you were allowed to continue as normal. If you were unable to grasp the technology, you were replaced by someone who could.

Technology marched onward as the systems grew into multitasking, assimilating entities. More features were developed that required larger logic memory storage and faster microprocessors. Now there are systems out there with flash memory capability. Instead of replacing a hardware chip that stored basic or complex operating instructions, the field tech would provide a data connection with a vendor’s Web site and stand back as the flash firmware completed its download. No more integrated circuits passing each other in the mail, and no more stockroom bins filled with outdated chips collecting dust and taking up room.

But something happened along the way that took me by surprise. The field got soft. More and more alarm companies are centralizing their alarm monitoring facilities and taking the responsibility of panel programming out of the field techs’ hands and into a small group of tech-pool support people. Generic programming templates and cookie-cutter feature sets are prepackaged and sold under the guise of operational enhancement upgrades. I spoke to a tech recently who had difficulty grasping the concept of programming a small alarm system through the keypad. In the end, he informed me he wasn’t allowed to program the systems in the field and that a data download needed to be arranged or scheduled with his supervisor.

In other words, if I were to return to the field as an installer/service technician, I would be doing exactly what I was doing 20-plus years ago: pulling cable and mounting devices. My experience would be used to determine what color the motion sensor needed to be and at what height it would be both effective and aesthetically pleasing to the customer. Yet I understand why this happened. Security companies wanted to be more consistent and accurate with their alarm system’s programming and operations. What better way to control quality than to keep it among a small band of system programmers?

I wonder how many people are in the same boat as the field tech. Are you the one-stop provider of service, or are you the hardware hanger with programming handled by a remote group of PC pushers? You may think a desk job must be better than what you’re doing now, and it might be. As for me, I miss it. It’s where I did some of my best work.

Steve Filippiniis a senior technician with more than 20 years of experience in the security and installation industry. He can be reached at[email protected].

Featured Articles

Close