标签: switch

I just got a rather interesting email from a member of the EETimes community who prefers to remain anonymous. This message was as follows:   Hello Max, I've got a fun project idea. Since I know I will never get around to making this thing, I'm giving you the idea and the rights to the idea, so maybe you'd enjoy making it -- not that you need any more projects! This is a practical joke idea. You have a: 10" x 10" x 10" wooden box With four short rubber feet With a power cord going to a wall outlet And with a toggle switch with the two positions labeled "Off" and "On" The switch is in the "Off" position The box is sitting on an end table Next to the table is a chair where a bored person might be sitting (think "lobby") Here's the scenario: The bored person can't help but wonders what the box is for Curiosity gets the better of him (or her) and he flips the switch to "On" The box immediately starts emitting a moderate, yet annoying, tone that is a little too loud and disruptive for an office environment The startled person immediately flips the switch back to its "Off" position But to his or her surprise, the tone doesn't stop In fact, it goes up in pitch, up in volume, and starts beeping Further attempts to cycle the switch only make noise that is higher in pitch, louder, and with faster beeps Nearby people pop up like prairie dogs out of their cubicles to see what is causing the disruption Not wanting to disrupt the office, the person leaps to his or her feet and unplugs the device from the wall But, to his or her surprise, the beeping doesn't stop In fact, it goes further up in pitch, further up in volume, and the beeping grows faster and more frantic The person turns the box around and over, but cannot find any other controls By now this person is really panicking At this point, the nearby prankster steps out and silences the box, plugs it back in the wall, and resets it for the next victim And here's what the victim didn't know: The on/off switch is not an on/off switch The switch connects to GPIOs on a microcontroller, to detect switch position The power cord does not power the box It charges the large-ish battery inside the box, which provides the real power to the always-on microcontroller And the powerful audio amplifier, which is connected to a strong speaker camouflaged into the base The rubber feet space the base of the box up from the table, allowing the loud sounds to escape One of the rubber feet is actually a rotary switch to cut the power Another rubber foot is a rotary reset switch to the microcontroller Which also synthesizes the audio tones, and sends them to the amp Fun, huh? If you ever get out to my neck of the woods, the beers are on me.   Well, he certainly closed on a good note (LOL). I must admit I'm tempted to build something like this. We have a sort of sitting area just outside my office that would be perfect for this sort of thing, but it will have to wait until I finish up some of my current projects.   Actually, this reminds me of those "Do not push this button" videos. You know the type of thing, like this one or this one .       What can I say? I'm a weak man. I really would like to have something like this lying around to break up the monotony of our visitors' days. Deploying it would almost be a public service when you come to think about it. What do you think? Would you modify the system discussed above in any way, or would you implement it as described?

I have always been an advocate of a rock-solid power supply sub-system, based on my design and debug experience. A good supply—regulators, rails, physical distribution, and ground returns—means a headache-free foundation for the ICs, the circuitry, and the software that operates in the product. I was reminded of this yet again when I had some odd behaviour in a low-cost (i.e., cheap) MP3 player I use to take music with me when bike riding; it was only $20, plus it has a digital FM broadcast-band tuner, handy for listening to the local college jazz station. (Yes, I could use my smartphone and stream, but this unit is smaller and I worry about it less on the road.) The Coby unit (see photo) has a "scroll wheel" for the user to select tracks, adjust volume, and perform other functions. Although it looks like a circle, the implementation actually has four switches under the disc, at the left/right/top/bottom pointers.   This MP3 player has an interesting idiosyncrasy: when the battery is at half or below, it doesn't sense two of the four scroll-wheel switches. Occasionally, the left and right switches would not sense that they were being pushed. I attributed this to dirt or similar—especially as this MP3 player actually went through the washing machine once (unintended, of course!) and amazingly, it worked fine after I opened it and dried it with air flow from a fan. The switch problem seemed to be one of those intermittents you just learn to live with, especially as this is not a mission-critical application. But then I noticed a pattern. The switch problem only occurred when the battery-charge indicator showed the unit was at half-charge or below. In fact, I could consistently clear the switch-sensing problem simply by charging the player to full. Apparently, there is some sort of interaction between the state of charge, the IC that manages the switches, or resistance in the switches themselves, and it only affects two of the four sensed switches. If I was on the team doing product development for this player, I might have spent time chasing software bugs when the switch wasn't sensing, yet that may not be the problem at all. Since I don't have a schematic of the unit, nor the time or tools to investigate further, I'm dropping this issue; let's be real: it is only a petty annoyance. Plus, experience teaches us that these sorts of problems can be very hard to diagnose and are generally unfixable. After all, if the problem is that the IC has some internal sensitivity to a low-power rail at its digital I/O, there's not much I can do, nor can I get into the switch-contact areas to clean them. The lesson here is that the power supply can have subtle interaction with functions that seem far removed from the supply rail. It's not just battery-sourced DC supplies, either. Several years ago, I visited a major analogue semiconductor company. While we were chatting informally, they told me they had a batch of desktop PCs that were about six months old, and which had random crashes (the Blue Screen of Death—BSOD) ranging from every few hours to days. Naturally, they first assumed it was some bug in the Windows operating system. But they were also smart enough to know that the assumption was an easy way to rationalise and dismiss the problem. Since they had the necessary equipment and expertise, they did some more poking and probing. Long story short : The real cause was that the AC/DC supplies were marginal and unable to handle some load transients that occurred during regular PC operations. Digging deeper, they found the problem was not the supply's design itself, but the substandard and very likely counterfeit bulk capacitors in those supplies. These capacitors would be good enough to make it through final test at the factory, but would then age and dry out within a few months, unlike the quality capacitors that should have been there. Have you ever had power supply and power rail issues that caused subtle circuit and performance problems that appeared elsewhere, and took some serious digging and debugging to uncover? How did you figure this out? How long did it take for you to find the problem?

I have always been an advocate of a rock-solid power supply sub-system, based on my design and debug experience. A good supply—regulators, rails, physical distribution, and ground returns—means a headache-free foundation for the ICs, the circuitry, and the software that operates in the product. I was reminded of this yet again when I had some odd behaviour in a low-cost (i.e., cheap) MP3 player I use to take music with me when bike riding; it was only $20, plus it has a digital FM broadcast-band tuner, handy for listening to the local college jazz station. (Yes, I could use my smartphone and stream, but this unit is smaller and I worry about it less on the road.) The Coby unit (see photo) has a "scroll wheel" for the user to select tracks, adjust volume, and perform other functions. Although it looks like a circle, the implementation actually has four switches under the disc, at the left/right/top/bottom pointers.   This MP3 player has an interesting idiosyncrasy: when the battery is at half or below, it doesn't sense two of the four scroll-wheel switches. Occasionally, the left and right switches would not sense that they were being pushed. I attributed this to dirt or similar—especially as this MP3 player actually went through the washing machine once (unintended, of course!) and amazingly, it worked fine after I opened it and dried it with air flow from a fan. The switch problem seemed to be one of those intermittents you just learn to live with, especially as this is not a mission-critical application. But then I noticed a pattern. The switch problem only occurred when the battery-charge indicator showed the unit was at half-charge or below. In fact, I could consistently clear the switch-sensing problem simply by charging the player to full. Apparently, there is some sort of interaction between the state of charge, the IC that manages the switches, or resistance in the switches themselves, and it only affects two of the four sensed switches. If I was on the team doing product development for this player, I might have spent time chasing software bugs when the switch wasn't sensing, yet that may not be the problem at all. Since I don't have a schematic of the unit, nor the time or tools to investigate further, I'm dropping this issue; let's be real: it is only a petty annoyance. Plus, experience teaches us that these sorts of problems can be very hard to diagnose and are generally unfixable. After all, if the problem is that the IC has some internal sensitivity to a low-power rail at its digital I/O, there's not much I can do, nor can I get into the switch-contact areas to clean them. The lesson here is that the power supply can have subtle interaction with functions that seem far removed from the supply rail. It's not just battery-sourced DC supplies, either. Several years ago, I visited a major analogue semiconductor company. While we were chatting informally, they told me they had a batch of desktop PCs that were about six months old, and which had random crashes (the Blue Screen of Death—BSOD) ranging from every few hours to days. Naturally, they first assumed it was some bug in the Windows operating system. But they were also smart enough to know that the assumption was an easy way to rationalise and dismiss the problem. Since they had the necessary equipment and expertise, they did some more poking and probing. Long story short : The real cause was that the AC/DC supplies were marginal and unable to handle some load transients that occurred during regular PC operations. Digging deeper, they found the problem was not the supply's design itself, but the substandard and very likely counterfeit bulk capacitors in those supplies. These capacitors would be good enough to make it through final test at the factory, but would then age and dry out within a few months, unlike the quality capacitors that should have been there. Have you ever had power supply and power rail issues that caused subtle circuit and performance problems that appeared elsewhere, and took some serious digging and debugging to uncover? How did you figure this out? How long did it take for you to find the problem?  

For special projects, I keep an inexpensive MP3 player handy as I'd rather not tie up or risk my smartphone. Recently, when I pushed the "off" switch, the player wouldn't turn off: in other words, it wouldn't shut up because it wouldn't shut down. It was small-scale version of those scary movies where the killer robot or machine is unstoppable, until someone, somehow, figures out how to get to the unit and shut off the power. I assumed the switch wasn't making proper contract. No big deal, I cracked open the case to see what I could do (one of the virtues of it being a cheap, "don't care about it" player), found the switch on its PC board, and jumpered across the terminals. It still wouldn't quit. Aha ... the problem was apparently not with the switch itself, but some software/hardware soft-failure glitch whereby the unit didn't recognise or respond to the switch closure. I thought to disconnect the battery, but it was soldered in, so that avenue of easy termination was closed off. So I just let the unit run down its battery all the way, then recharged it, which forced a software reset (as I expected it would). I have always been uncomfortable with presumed "on/off" switches and buttons that really aren't, but which actually are soft functions. This is where the system processor must recognise a switch closure, and put the unit into a quiescent sleep mode (and do the opposite to wake up). That is not the same as cutting off the power source. It assumes that everything is working just right, and the switch closure will be sensed and acted upon. I know that these soft functions including power controls are now standard on many products, but they still making me feel a little creepy. Obviously, a stuck MP3 player which won't turn off is not a crisis. But a motor, vehicle, or instrument that won't turn off: well, that's another story. Sometimes you can get to the power source and kill it, by pulling the plug or battery connector, but sometimes you can't. Or perhaps you could, but it would be too late. Many years ago, I worked for a company that made industrial machinery, powered by big electric motors or hydraulic pumps. For many years, everything was controlled by true hardware, such as switches and relays. As software and processor-based controls came into their own, we switched the controllers over, of course. But a big, red, unambiguous, mushroom-topped STOP switch which interrupted primary power was still key part of every system, for obvious reasons. Have you ever had a system which you couldn't get to turn off or stop-but needed to? How did this experience affect your design approach? Bill Schweber EE Times  

OK, it's time to make fun of a patent and I have one with an unassuming name: "Heated eyewear". Yup, you heard that right. In the abstract, the first reason given is to provide heat that may be sufficient to provide warmth to a wearer of the eyewear. Huh – so the double speak starts. Now just in case you are wondering, this is patent 7,410,254 issued in August 2008 – so actually quite recent. I would like to concentrate on description for figure 2 of the patent. It reads: In the embodiment shown, the power source 24 is electrically connected to a voltage protection element 26, such as a fuse. The voltage protection element 26 is in turn electrically connected to an output amplifier 28. The output amplifier 28 is in turn connected to a thermistor 30. The thermistor 30 may function to regulate the amount of heat generated by the heating element 16. The thermistor 30 is electrically connected to the heating element 16 in the frame 14 by a connecting wire 32. According to one embodiment, the connecting wire 32 is permanently connected to the heating element 16 in the frame, while in an alternative embodiment, the hinge 22 is configured to selectively connect the connecting wire 32 to the heating element 16. For instance, in one such embodiment, the connecting wire 32 may be connected to the heating element 16 when the ear-piece 20 is moved to the open position, e.g., the position at which the eyeglasses 10 are worn, while the connecting wire 32 may be disconnected from the heating element 16 when the ear-piece 20 is moved to the closed position, e.g., the position at which the eye glass are stored. So, how is this meant to work? We feed a power source into the input of an amplifier and somehow it magnifies the power. Then a thermistor is meant to control to temperature source but it is positioned so that it will only respond to ambient temperature. The switch (don't you love that description of a switch) is positioned such that power would continue to be consumed and would expose a live connection that is clearly so shocking that it needs a fuse. Oh, and in case you are wondering what 36 and 38 are- well that would be a GPS and a light detector and 40 is your built in memory and 25 is your backup power source just in case you run out of juice. Brian Bailey EE Times