Advertisement
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.
Advertisement
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.
Advertisement
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
Having worked around the telecommunications industry most of my career and mostly in the field working with interfaces, I learned early on the reality of the phone systems was far different than the standards. This often created problems with a new product that was designed to the standards. So, don’t feel like a the lone ranger on this one. The problem was often the biggest with the myriad of small independent telephone companies that often had things like 10 party lines and ringing to ground. Those were great days when lots of engineering had to be done on the fly to make things work, then report back to the factory so the engineers could make the appropriate design changes or issue field notes on how to make the product work.
I fail to understand why you would hang a opto on a POTS line to detect the Ring signal? You are clearly using a modem on this controller to transmit your collected data. Did you develop your own modem also??? Since the 70’s, all modems that provide a POTS interface had rhe capability of dectecting Ring on a ground loop start line and they provide a signal “Ring Indicator” as a logic signal. It sounds like the lesson here is you got bit in the bud by overengineering.
We did design a simple modem for this project.
Having worked in the telecom industry from 1973 to 2009, I can tell you that just because there’s a standard for something, it doesn’t mean all central office switching systems comply with that standard. In the heydays of landlines, the range of technology in use was enormous. Early switching systems were depreciated over 30-50 years, so you could find post-World War II technology along side 1980s technology. The later technology may or may not have met current industry standards. I suppose if you made a mistake, it was assuming everything met the ANSI standard. There’s no substitute for field testing.