"Steve, the alarm service is on the phone. The alarm at the office just went off! They called the police. Shall I say you’re on the way to meet them?"

As I grabbed my coat and keys, I cast a quick glance back at Jeannette. Her expression said far more than any verbal exchange.

The gist of it was that if anyone was going to play hero tonight, it wasn’t going to be her. She’s happy to run a business with me, but gunslinger is definitely not in her job description.

There was a time when sharing the "business experience" might have prevailed, but after a real break-in at our office when the police actually dragged a burglar out in handcuffs, she decided this was one event she’d rather stay away from. Besides, anyone stupid enough to break into a building attached to a courthouse and surrounded by a half-dozen TV cameras probably isn’t bright enough to listen to reason anyway.

As I ran for the car, I heard her yell, "Be careful…! Call me…!"

Like most businesses, we have a commercial alarm system. The reason isn’t as much to deter crime as it is to qualify for discount on insurance rates. That’s the good news.

The bad news is that, because I live closest to the office, I’m first on the call list when the alarm goes off. I get to greet the police and walk around a building with a lot of dark hiding places.

There really aren’t a lot of options. If you want the police to treat the call seriously, you better meet them there. And, you also have to watch the false alarms.

Everyone had a sense of humor when someone set the alarm while Ken was still working on the third floor. Since then, the last one out is supposed to page the building or check the parking lot. There has to be a bit of seriousness. After all, the police did nab somebody that one time.

As I pulled into the parking lot, the lights from state and local police cruisers greeted me. All I could think was, please, let them find Jeffery Dahmer or someone, not another false alarm.

After the appropriate introductions, we trooped into the building—they with their guns drawn and flashlights blazing. I don’t know why they didn’t just turn on the lights, but they preferred to search each room in the dark.

I still don’t understand the tactic. Maybe they presumed someone this dumb would invariably use tracer ammo or something else that’s easy to see in the dark. Needless to say, I waited until the lights were on before roaming anywhere unescorted.

The results of the search were less than spectacular and somewhat embarrassing. Apparently, workmen had left an outside door to the furnace room unlocked and nobody checked it.

Besides the lock, the door needs a 3½² thick wooden bar across the inside to keep it from opening. Of course, when someone leaves the door unlocked and only puts in a standard 2 ´ 4 (1¾² thick) instead of the usual 4 ´ 4, the door can open almost 2². Guess what happens when someone pulls on the door from outside? An unlocked door is an embarrassing predicament.

Needless to say, I apologized profusely. It was a false alarm. If we’d nabbed Charles Manson, wasting their time wouldn’t be an issue. I probably could have even gotten away making police and donut-shop jokes. Under the circumstances, however, my only recourse was to thank them, tuck my tail, and return to the car.

I dialed the cell phone. When Jeannette answered, I said in a disgusted tone, "Someone left the damn door open! The only thing worse would be if they didn’t set the alarm at all!"

"Well, Steve, I wasn’t going to tell you, but I’ve had reports from the people who come in early that occasionally the alarm hasn’t been on."

Next morning, I called everyone with alarm codes together and asked the pertinent who and when questions. I got back mostly blank stares, to be interpreted as, "Not me, man." Given all the people with independent access to the building, that was hardly reassuring.

The obvious answer was the alarm company. We pay them $30 a month to monitor the system and call the appropriate people if the alarm goes off. When it was first installed, we got a monthly opening/closing report that listed the date, time, and access code (these days I suppose we’d call it a PIN) for every alarm set or reset. This was the obvious answer.

Calling the alarm-monitoring service is an experience. They’re contracted by your alarm installer and not typically selected by the alarm owner. And since they answer the phone "Monitoring station" and use the installer’s name once you give them your account number, you might think they’re just down the block. Only when you interrogate the autodialer or otherwise see where the call goes do you realize that your personal monitoring can be 2000 miles away.

Our monitoring company was at the other end of the state, but most large alarm companies deal with centralized service monitors that cover many states at the same time. Regardless of their location, aside from changes to the call list, they’re like talking to a brick! Their pat response is that you should call your installer.

They usually charge the installer a flat rate based on a specific service level for all his customers. If he only contracts for alarm calling and none of the monthly printed reports, it’s tantamount to bringing the mountain to Mohammed to get one from the monitoring company. Yes, I could get a report for a specific day—at $20 each!

Calling the installer reminded me again why we designed our own home-control system. These people have no vision at all.

"What would it take to get daily entry/exit reports?" I asked.

"I suggest you install a new alarm system," he answered matter-of-factly.

"Would a new system be better than our present ten-year-old hard-wired system?"

"Well, sir," he continued. (Subconsciously, I noted that people generally called me "sir" when they were trying to sell me something. Sometime I’ll have to test the financial limits of this theory. Do they start at $100, $500, $1000…?) "It would have the latest technology and use wireless sensors."

"And after I replace the $2 battery in every sensor each year, would it do more than provide a contact closure to an alarm horn and autodial a digital code to the monitoring station like the present one?" I already knew the answer.

"It would use the latest technology to close the contact and autodial the modem, sir…and we could get you one with a printer output." Finally, he mentioned something we wanted!

I continued, "Do you know if it’s a standard serial printer port? Do you have a schematic?"

"Well, I’m not sure what it is, sir, but I can supply you with the printer (extra cost). There are never any schematics of any equipment, sir. I guess they’re concerned about liability."

Liability, schmiliability. The only reason there are no schematics is that the alarm manufacturers don’t want competition.

In the end, it’s just a cost decision. "How much?"

"Well, sir, if we do just the same as your present system and add the printer, probably about $3500–4000."

I knew this "sir" thing was going to cost me. "Thanks, I’ll have to get back to you."

My next stop was Jeff’s desk.

"Jeff, this alarm guy is nuts. You can’t believe how much it costs for an alarm-code printout. Worse yet, it only records successful entries. It can’t tell who punches in a bunch of numbers, never actually sets the alarm, and then just walks out without checking. That’s the guy I want."

I knew telling Jeff about such a ridiculous obstruction would be a technical challenge he couldn’t refuse. They may not know how to produce a daily event record, but somehow we would. We gathered up the ’scope and headed for the furnace room and the alarm-system controller box.

There was nothing surprising about the system. It was your standard ten-year-old Silent Knight alarm system. Documentation was strictly at the installer level. Motion detectors and sensors connect to these terminals, the alarm horn connects here, the phone line goes in here.

The PCB hardware included two microcontrollers that shared the control tasks. Because they had house numbers, Jeff and I concluded they were probably ROM-programmed 8051-family devices. And because it was ROM coded, we didn’t have a prayer of changing any internal operation. The best we could hope to do was monitor the external signals.

It would have been great if the alarm designers had taken a traditional engineering approach. Even a predictable approach would have been welcomed. In the world of high-volume consumer-quality electronics however, nothing works the way you expect it to, and "cute" is a term frequently used to describe the design technique.

The methodology is quite straightforward. Take a circuit that works the way you’d normally design it, throw away half the parts (or parts cost), and then make it do all the same control tasks. These are the guys who make a fine art of cycle-stealing, multiplexed operation, and hairy-edge qualification. Want them to design your next medical product?

This unit was no exception. The user interface consisted of a 3 ´ 4 keypad with a green LED (ready), a red LED (armed), and a single 7-segment LED display (zone). The keypad labels were 0–9, Door, and On/Off. Pressing any button makes an internal beeper sound. Photo 1 shows a close up of the alarm’s keypad.

Photo 1—The alarm system PIN is entered via a keypad. The ASDL system monitors and records the time and date of all key presses.

Similar to the operation of most alarm systems, the user looks for a green light indicating the system has no open doors and punches in a four-digit code followed by the on/off button. The alarm goes on, the red LED lights, and you have about 45 s to vacate the building. The process is reversed to shut off the alarm.

Jeff and I concluded the way for us to monitor entry and exit times and codes was to attach a circuit in parallel with this user interface and tap into its communication with the system box. Punch in 6637 and On, and we’d log it to a printer. The only sticky part was guessing where all these signals were so we could tell which key was pressed.

The keypad in the entryway connects to the system via an 11-wire parallel cable. The 3 ´ 4 keypad has four rows labeled 1–3, 4–6, 7–9, and Door, 0, and On/Off.

Electrically, we determined that the keys are scanned in two separate groups of six. Two opposite and alternating signals drive the two groups. Pressing none of the keys results in a logic 0 on the three column inputs back at the system board.

Pressing a key diode ORs one of the phases with one or more of the column inputs, like this: 1 = 001, 2 = 010, 3 = 011. A 7 also creates the 001 combination but in step with the opposite phase. The system knows which key is pressed based on the column inputs and the phase of the input signal.

Other signals to the entry panel enable the red or green LEDs and drive a piezo beeper when any key is pressed. All signals are at the 12-V level.

Packaged Solution

Jeff and I now knew there were some logical signals we could monitor. The next task was to decide what kind of data-acquisition system we had to configure. But unlike our lightning device ("Ground Zero," INK 90), this wasn’t just an illustrative magazine project. I wanted to use this thing.

We could have used anything from a PIC to a full-blown PC as the hardware. Our logging system needed a processor board to acquire and analyze the data, a real-time clock/calendar to time stamp the entries, an LCD to view records, a keypad to direct the logger’s activity, and a printer interface for making hardcopies on command.

Beyond the strict hardware necessity, system selection is always a tradeoff of competing ideals:

· time (getting this much software done quickly enough to meet a magazine deadline typically rules out assembly language)

· I/O capability (obviously, we needed a serial port and a lot of parallel I/O)

· speed (just how fast does this thing need to be anyway?)

· cost (are we making a few or is it a volume-production device?)

· political bias (some designers will jam in a PC even if it can be done on a PIC)

This analysis pretty much fits half the board ads in INK. Fortunately, I get to apply a little political bias of my own.

While there’s a little fancy footwork in the interrupt routines, most of the software is a lot of text shuffling among the peripherals (it’s easy for the guy who doesn’t write the software to say stuff like this). When we looked at the requirements, it seemed like a perfect application for a Domino—or more precisely, a Domino2.

As Figure 1 shows, Domino2 is a small encapsulated controller with a built-in floating-point BASIC interpreter and 32 KB each of EEPROM and SRAM. Best of all, it contains a serial port, lots of parallel I/O, and a real-time clock.

Figure 1—Domino2 is a small encapsulated controller with a built-in floating-point BASIC interpreter and 32 KB each of EEPROM and SRAM.

Even if you don’t have a ten-year-old alarm, I’m sure you’ll find that our method of solving the problem provides some interesting examples of using BASIC-52 in control applications.

Alarm-System Data Logger

Figure 2 is the schematic of the alarm-system data logger (ASDL). The circuitry was added to Domino’s proto1 board, as shown in Photo 2. The first task was mating the 12-V level alarm signals with Domino’s TTL input levels.

Figure 2—This schematic shows the ASDL system and how it connects to the alarm signals.

 

Photo 2—The prototype ASDL sytem is physically assembled using a Domino development board with an LCD and keypad attached.

There are lots of ways to do this, but one cute way is to use MC1489 RS-232 input level shifters. These inexpensive inverters can withstand ± 30-V inputs while interfacing directly with TTL on the output side. Six keypad lines connect to the processor.

The next detail is determining when a key is pressed. We had two alternatives. We could create a falling-edge key-press interrupt by NORing the three column inputs together. Or, we could take advantage of the fact that pressing any key caused the beeper to sound.

Ultimately, Jeff chose to use the signal applied to the beeper as a key-press interrupt. The three column lines, two phase outputs, and on/off button are read anytime there’s an interrupt. Together, they determine the physical key combination.

Normal entry and exit profiles run a total of 10 key presses a day. This plus a 7-byte time and date stamp amounts to fewer than 20 bytes of data-logging space required per day.

Our plan isn’t to check this thing daily but to have a record of events available when we need it. If we have a good chunk of data storage space available, how often we dump the records will never really be an issue. Six months of data fits easily in less than 5 KB of memory. We have about 24 KB available.

Program development started with writing the time and date to the LCD. Instead of using a couple I2C peripheral chips to connect the 4 ´ 20 LCD and 4 ´ 6 keypad as typically described for Domino, Jeff chose to minimize external hardware and scan the command keypad in software.

Using this number of I/O bits for the keypad necessitated using the LCD in 4-bit mode rather than the typical 8-bit parallel interface. The 4-bit mode requires two nibble writes to the LCD for each printed character, which entails eight physical operations for each character—set up the control register, raise the strobe line, set up the data register, drop the strobe line. The process repeats for the second data nibble.

The program executes a short initialization routine and then prints day of the week (DOW), month/day/year, and hour/minute/second on the LCD. Using the row and column positioning capability of the LCD (a control register routine), only new data needs to be updated. This makes a great idle screen that also indicates the system is running.

If the displayed time and date is incorrect, as it would be on initial powerup, the user enters the present DOW, month, day, year, hour, minute, and second. Maintaining the time during a power outage is a simple matter of adding a 4.5-V back-up battery to the real-time clock.

Since the alarm system is normally battery-backed and may be needed during a power outage, we decided to battery-back the whole Domino2 circuit. Besides keeping the RTC alive, it maintains any collected data that hasn’t been printed yet. Figure 3 gives an overall view of how the complete system was integrated.

Figure 3—The ASDL attaches in parallel with the existing alarm keypad. The Domino2-based monitor program registers and records keypad activity and outputs the data to an LCD and printer on command.

 

Fancy Footwork

As I mentioned, it’s easy to say it’s just a matter of software when you don’t have to write it yourself. One of the more challenging aspects of the software was catching the key presses while doing all the other system functions.

This task was accomplished via the BASIC-52 ONEX1 command. This interrupt command temporarily redirects the normal program flow to a special subroutine.

ONEX1 is triggered by a high-to-low transition on Domino’s INT1 input pin. Obviously, it should be reserved for a high-priority function. Listing 1 illustrates the high points.

The piezo beeper output connects to INT1. When ONEX1 is triggered, the routine samples the I/O port where all the row and column data is connected to the Domino. This beeper interrupt can occur during either phase of the row drivers.

To ensure the sample is valid, the program checks whether there is a high level on at least one column input line. If none of the first three bits are high, we assume it’s the wrong phase and take another sample. Once there is a valid sample, the row driver levels (indicating the two phases) can be compared with the column inputs to determine which of the 12 keys was pressed.

Before leaving the interrupt routine, there are two more tasks. First, save the key-press code into the data-logging buffer and increment the buffer pointer. If the on/off key was pressed, a time/date stamp is added to the log.

Finally, we need to make sure the physical key-press action has ended (to prevent interrupt on the same key press). This is accomplished by repeatedly sampling the port and looking for invalid data (columns all low) on both phases of the row driver outputs. When RETI is executed, the program resumes where it left off.

Getting the Goods

Displaying and dumping the stored data log is a secondary function chosen from the command menu. The ASDL LCD can show a command list, the time and date, or the data. The data is printed to the LCD in blocks.

When the log is dumped, all the blocks up to and including the present time and date are dumped. We didn’t see the necessity for individual date interrogation.

You want the data log? Here’s everything, a block at a time.

While the data is being sent to the LCD, it is also sent out the console serial port. Although this could be connected to a PC and logged to a file, Jeff mounted a plain-paper 12-VDC–powered serial printer (measures only 5² ´ 5² ´ 3²) next to the Domino, so a hardcopy of the data could be printed and retained if necessary.

A short pause between each block lets the printer keep up with the data and provides time to study each block on the LCD before the next display. The final menu selections enable the user to clear all data from the data buffer and return from the menu screen to the idle screen (displaying time/date).

Since the capturing and logging of alarm codes is a security risk, it would be foolish not to try to prevent unauthorized use. Accessing the menu screen shouldn’t be open to just anyone.

Any ASDL entry prompts the user for a PIN. An incorrect entry simply returns to the idle screen.

We also specifically chose to store the data log in SRAM rather than EEPROM. If the Domino is removed from the system, the data log disappears.

Gotcha

While solving the problem this way gave me the satisfaction of not having to buy more useless equipment from an alarm company, it turns out there was no better alternative.

The monitoring station and a commercial alarm printer could only give me a list of successful alarm operation. But, my major irritation was with people who didn’t look for a green LED (indicating that the building was clear) before blindly punching in a code (that the alarm doesn’t accept) and blowing out the door.

The ASDL stores every key pressed. It only adds the time/date stamp when the on/off key is pressed. If the alarm isn’t set, a quick review of the record should show what code was being entered, even if unsuccessfully.

All of our work may have been in vain. We haven’t had any false alarms, and interestingly, there haven’t been any mornings with an unset alarm.

Either everyone has become educated by involvement in publishing this article, or seeing Jeff and me constantly playing with the alarm system has made them aware that something is going on.

Regardless, they seem to recognize the seriousness of it all. Jeff and I just have to be careful that we don’t let on that we really have fun.

Steve Ciarcia is an electronics engineer and computer consultant with experience in process control, digital design, and product development. You may reach him at steve.ciarcia@ circuitcellar.com.

Jeff Bachiochi (pronounced"BAH-key-AH-key") is an electrical engineer on Circuit Cellar INK’s engineering staff. His background includes product design and manufacturing. He may be reached at jeff.bachiochi@circuitcellar.com.

---

SOURCES

Domino2
Micromint, Inc.
4 Park St.
Vernon, CT 06066
(860) 871-6170
Fax: (860) 872-2204
www.micromint.com