My NO/NC misassumption reminder

-December 27, 2016

I accidentally kicked and cracked the hidden alarm bypass pushbutton in my car. Fortunately, it's actually accessible and I can reach around it, get at the wires, and replace it. Even more amazing, it's a fairly standard pushbutton style, mounted in a ¼" hole at the edge of the firewall panel. I figured I'd just buy a replacement pushbutton switch, solder the wires, shrink the heat shrink tubing (which I remembered to put on before wiring it), and the repair would be done.

But as I got ready to go out for a replacement at our local electronics store, a question hit me: I assumed it was a basic normally-open (NO) switch, but was it really NO? I had no evidence for that, just my assumption; it could actually be a normally closed (NC) one. In fact, NC switches are quite common in signal loops of alarm circuits, since a break (such as by tampering) activates the alarm.

I tried to measure the switch's NO vs NC situation, but was out of luck, as my errant kick had wedged the switch plunger, so I could not move it in and out to assess the contacts in either relaxed or engaged position. In this case, it was no big deal: I simply bought a switch with both NO and NC contacts for an extra few cents rather than a one with just NO contacts. Problem anticipated and solved, end of story.

But the incident reminded me, in its own small way, of what I call "the engineer's dilemma," especially in the prototype and pilot-run debug phase, which I consider the most difficult part of the entire design and product-development process. On one side, in order to proceed you have to make some assumptions about the circuit and system behavior; on the other side, it's those incorrect or unspoken assumptions that often trip up the debug cycle. You're stuck with having to live with and make assumptions, knowing that they may be wrong. That's why it's important to at least try to state them explicitly, if possible, assign a level of confidence to each, and verify those of which you are aware as you travel down the debug road.

Have you ever been in a situation where you made incorrect assumptions about a design's condition or behavior while you were trying to figure out what was going on and why it wasn't working? Were these assumptions clearly visible to the team or were they just those "we never really thought much about it" types?

Also see:

Loading comments...

Write a Comment

To comment please Log In