标签: switch

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