Electronicdesign 9386 Rogerwatkins

How To Dumb Down Smart Electronics.

Jan. 21, 2015
In our generation of microcontroller-enhanced everything, it has been frustrating at best to see how often the capability of smart hardware has been foiled by the design of poorly purposed software.
Image courtesy of Thinkstock.

In our generation of microcontroller-enhanced everything, it has been frustrating at best to see how often the capability of smart hardware has been foiled by the design of poorly purposed software.  We have image sensors at intersections, automobiles with computers many times faster than the operators’ reflexes, computer answering systems that can even recognize speech, smartphones with built-in everything, just to name a few.  However, in my experience, too much of this capability is wasted or countermanded by software/firmware having malformed purposes. We as engineers and programmers need to carefully consider the ramifications of what we are doing as we design our computer “enhanced” systems. A few examples:

1. As a child, I spent a few years in Bryan, Texas, which had installed a timed light system on its main through-town road in 1965. This system allowed drivers who drove about 2 mph below the posted speed limit to travel completely through the town on that road without ever being stopped at a (second) stop light.  As an adult in Peoria, Ill., I saw the city “upgrade” to new image sensor stoplights. These were programmed to prefer the larger of the two roads at the intersection (default green was to main road), and to not change unless a car was sensed waiting on the smaller road. The program had weighting so that the longer the main road green light had been active, the quicker the side road sensor would switch the light. A couple of minor points were (A) the lack of coordination among lights on main roads, so that one could literally be stopped at every light on the major street depending on the sensor activations, and (B) the inability of the sensors to detect motorcycles. 
One of the funniest exchanges on the local public radio-produced Peoria Town Council meeting was between a councilman who had ridden his motorcycle to Chicago for a concert, returned to Peoria late at night, and been held at a light downtown for over 30 minutes until he gave up and turned right just to get to where he could get across the road by turning left.  The Chief of Police explained that he could have just walked the motorcycle across the intersection legally, to which the councilman exclaimed how ridiculous walking a Harley-Davidson across an intersection was for someone his size and age. It seems odd to me that modern sensor lights do not “perturbate” an intelligent and coordinated schedule in response to traffic abnormalities, rather than simply awaiting sensed vehicular presence.  This would fix many issues with motorcycles, bicycles, and pedestrians, while improving the stop-and-go traffic that “smart” sensors have returned our streets to.

2. Automobile computer software designers have gone awry in numerous areas. Take, for example, my hybrid (brand hidden to protect the guilty, but a very common vehicle) that treated me to yet a new level of excitement about a month ago. I was on an entrance ramp to a U.S. highway near Madison, Wis., at night, where there was black ice. The tires started to skid, the ABS kicked in to try to control traction, a loud alarm sounded, and the dash had a bright flashing indicator. The ABS system, in pretty typical fashion, did much worse than a driver trained in ice and snow, but better than a southern fair-weather driver (sorry to readers who might take offense at this). However, the “features” that included un-needed noise and flashing lights were distractions that were totally inappropriate when the driver’s undivided attention was needed pointing the vehicle. The same vehicle sounds a loud beeping sound whenever placed in reverse, doing well at blocking the driver’s ability to hear impacts or playing children during a vehicle backing evolution. Back when I was learning to drive, the instructor always required that the driver-side window be lowered and both visual and audible clues checked prior to and during a backing evolution. Removing a non-deaf-driver’s sense of hearing by sounding an alarm tone loudly (maybe even quietly) does not enhance safety during backing.

3. We all hate the answering machine that asks a hundred questions (I only exaggerate slightly), then puts us on hold when we called to report that the computer site for that company had just locked up with our attempt to purchase $150 in tickets for a concert.  Many of us yearn for the days when a human actually answered a phone, but that is expensive (my workplace still has a paid receptionist to answer phones). Instead of that expense, or angering customers, a better approach might be to take incoming calls into a voicemail, tag the voicemail to the appropriate person to handle, get the caller’s phone number and email address, provide that person with a case number, then promise (and deliver) a return call to address the issue or report correction of the problem.  If the return call has not been made at the promised interval, the case number would quickly connect to a human who could at least inform the caller of the status and expected time of resolution of the issue. Such a system could radically streamline what is now standard in the industry and uniformly frustrates and angers customers, where a call is first filtered by a digital system often to about three layers of Q&A, then to a marginally trained and paid phone-answering crew, then eventually to a technical or administrative representative capable of taking real action or actually providing answers. The key here would be setting in place a scheme where the call back is timely and can address or fix the problem reported. Few things are as exasperating as an hour-plus hold waiting for help when a cell-phone battery dies.

4. One of the things we can actually laud is the responsiveness of the cell-phone code developers. Although arguably slow in responding, there has been movement in the right direction in numerous areas including actually putting the GPS required by law to use for the user also, implementing schemes for wireless headphones including noise-canceling features, providing zoned-emergency-calling, and numerous other advances. With all of this forward motion, some very critical issues remain. One good example is an open and interactive means of silencing or at least quieting noisy ringing sounds. Some locations actually have jamming installed to prevent cell phones from connecting to prevent ringing noise. I am not aware of efforts (if they are ongoing) to provide features that let a smartphone be self-aware enough to go to “stealth-mode” in certain locations or at certain times. One simple solution would be an app that would schedule changes in the ring tone manner and volume coinciding with the user’s scheduled activities. A similar solution would be a standardized interface, that could be opted-out, where when within some physical zone the ring mode would become vibrate-only, and perhaps the phone could even be turned off (for meeting rooms, movie theaters, and such).

We must remember that a microcontroller or larger computer is not always the best solution to a low-tech problem. I still grin when I remember people trying to sell Internet-enabled toasters. I have yet to see a car with ABS that can compete with a well-trained driver in extreme conditions (especially black ice or heavy, patchy ice conditions). Let us, as engineers and designers, carefully evaluate what we should be doing with products and features to truly add value.  We need to consciously avoid creating more traffic jams with poorly executed or planned “feature-rich” products.

Sponsored Recommendations


To join the conversation, and become an exclusive member of Electronic Design, create an account today!