When a ring isn’t really a ring

Early in my engineering career, I worked with a couple of colleagues on an outside project. We had a concept for a security system for gaming arcades. At the time, arcades were very popular, hosting games like Pac-Man, Space Invaders, and Pinball. One of the business problems, though, was the theft of coins from the gaming machines. Apparently, when staff members were emptying the coin boxes, they would pocket a handful of coins. Theft in these arcades was said to be around 25%.

Do you have a memorable experience solving an engineering problem at work or in your spare time? Tell us your Tale

Our concept for preventing these thefts was a device that consisted of two parts. One micro-based device was installed in each of the arcade games. This counted the coins as they entered the slot. Then, periodically, the total coin count and game ID were transmitted, via the power line, to the back office. In the back office was the receiver. It monitored the power line and collected all the transmissions from the various games. This back-office device was also connected to a telephone landline, and once a day, the central office would call into the back-office device to have the daily data sent to it. The hand count of coins could then be reconciled with the electronic coin count from all the machines.

My colleagues and I divided up the work, with one doing the schematic and PCB prototypes. Another did the enclosures, labeling, etc. I did the firmware for the two pieces of equipment. After many months of evening work, we had a system that performed just as we expected. We also got a test site identified to install a complete system. As the arcade was more than 1000 miles away, we had someone at the other end install the system. After a few days, we got a call from the arcade operator telling us the office device would not answer the phone call into it. The hardware design was rechecked to see if the opto-isolator, signaling the firmware of a high voltage on the ring line, was designed correctly to take into account lower-level ring voltages—no issue there. This issue fell on me as it appeared to be a firmware issue. I tested my firmware dozens of times with various changes using an actual landline—it always worked. After many days of testing, I announced that I could not find any issues.

As a last resort, we had the hardware engineer fly to the arcade site with a raft of test equipment. After only a few hours, he called and said he had found the issue. The standard for ringing for a landline is defined by ANSI T1.401-1988 section 5.4.2, which I followed for the firmware. According to this standard, the ring cadence consists of 2 seconds of ringing followed by 4 seconds of silence. The phone system, in the town where the arcade was, followed this…sort of. During the ring, there was a short dropout ( about 80 ms, if I remember correctly). So, what the firmware saw was about 1 second of ring, no ring for 80 ms, then 920 ms of ring, and then 4 seconds of silence. The firmware, noting that the ring was only one second long, determined that it wasn’t a valid ring and therefore wouldn’t answer. The discovery of the issue was long, difficult, and expensive. The fix was easy to implement in firmware. After updating the firmware, the arcade system worked very well (we never got rich off it, though…another, non-technical, story).

The takeaway here is not how to construct landline phone answering firmware; those days are long gone. But the lesson here is that when you have an issue, suspect everything. We continued to have discussions on why the system would not answer the phone when we knew it was sensing the ring. We never thought that maybe the cadence, defined by an ANSI standard, would not be correct. Why the town’s telephone ring system had an 80 ms gap was never discovered, but it obviously didn’t meet the spec. So, if you can’t find a problem in your device, maybe it’s the other device(s) you’re connecting to. And at that point, the other system needs to be checked against its specs.

Damian Bonicatto is a consulting engineer with decades of experience in embedded hardware, firmware, and system design. He holds over 30 patents.

Phoenix Bonicatto is a freelance writer.

Related Content

• PUT a reset in its place
• Adaptive resolution for ADCs
• A beginner’s guide to power of IQ data and beauty of negative frequencies – Part 1
• Obtaining a patent in a corporate environment

The post When a ring isn’t really a ring appeared first on EDN.