Post by thread:[EE]: stupid mistakes

I think communicating and documenting stupid mistakes is more important than communicating successes, so here I go again. I use an IR LED and a TSOP receiver to let a board-under-test log messages on an LCD without a galvanic connection. The board-under-test uses the IR LED to send the message, of course modulated at the frequency appropriate to the TSOP receiver (I use 36 KHz). To check whether the pic-under-test does indeed 'blink' the IR LED I put a normal (red) led parallel (both with their own series resistor). I know the receiver with LCD screen is OK because I use that a lot. A new board-under-test worked somewhat: only at very short distances: 1cm, where 50cm is a more normal distance. Now what was wrong? I suspected that the red LED was loading the PIC output so much that the IR led got nearly 0 current, so I removed the series resistor of the red LED. Now the communication stopped totally! A closer look revealed that the IR LED was wired backwards, so it was not doing anything. The RED led seems to emit enough IR to make communication at a very short distance possible. Wiring the IR LED correctly of course make the setup work like it should. Morale? Don't jump to conclusions, look at the facts. (if you want that worded in another way read Pratchet) Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Wouter van Ooijen wrote: {Quote hidden}>I think communicating and documenting stupid mistakes is more important >than communicating successes, so here I go again. > >I use an IR LED and a TSOP receiver to let a board-under-test log >messages on an LCD without a galvanic connection. The board-under-test >uses the IR LED to send the message, of course modulated at the >frequency appropriate to the TSOP receiver (I use 36 KHz). To check >whether the pic-under-test does indeed 'blink' the IR LED I put a normal >(red) led parallel (both with their own series resistor). > > A very good method for testing IR, is to use a digital camera. cheers, Stef > >

>-----Original Message----- >From: spam_OUTpiclist-bouncesTakeThisOuTmit.edu [.....piclist-bouncesKILLspam@spam@mit.edu] >Sent: 04 January 2006 15:38 >To: 'Microcontroller discussion list - Public.' >Subject: [EE]: stupid mistakes > > >A closer look revealed that the IR LED was wired backwards, so >it was not doing anything. The RED led seems to emit enough IR >to make communication at a very short distance possible. I'm nit-picking, but I suspect it is more likely that the receiver was sensitive enough at the red LED's wavelength. LEDs tend to have a pretty narrow band output, whereas photodiodes have a much broader optical bandwidth which is why IR filters are used on the receivers. Regards Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. =======================================================================

> I'm nit-picking, but I suspect it is more likely that the > receiver was sensitive enough at the red LED's wavelength. > LEDs tend to have a pretty narrow band output, whereas > photodiodes have a much broader optical bandwidth which is > why IR filters are used on the receivers. could very well be. AFAIK LED emission (at least for RED LEDs) is a state change (electron orbit step?), which would result in an almost single emission ferquency. The IR-filtering of an IR receiver is an optical filter, which is by its nature more wideband. I don't think I have the means to distinguish between those two causes. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Radio Shack used to sell those. I don't know if they still do. ----- Original Message ----- From: "Alan B. Pearce" <A.B.PearceKILLspamrl.ac.uk> To: "Microcontroller discussion list - Public." <.....piclistKILLspam.....mit.edu> Sent: Wednesday, January 04, 2006 9:45 AM Subject: Re: [EE]: stupid mistakes > >A very good method for testing IR, is to use a digital camera. > > I have a special test stick, made by Kodak. I do not know the original > purpose of it apart from being designed for detecting IR illumination. It > consists of a piece of FR4 about an inch wide and 4-5 inches long, with a > blob of some sort of epoxy on the end that is sensitive to IR light. > Flashes > quite noticeably when a TV remote is directed at it from a few inches. > > --

Another tale in the category of stupid mistakes: I had a design with a walwart power supply followed by 7805 volt regulator to use in PIC projects. The regulator has small value caps on each end as suggested by 7805 datasheet, enough for transients, but not good for filtering AC after rectifier (1 diode, used as polarity reversal protection). I ordered bunch of 9VAC, 1A wallwarts and plugged them into regulator. Result: strange behavior of the PIC, cannot program it. Tried ICD2, Tait-style homebrew and ICD-U40 from CCS. Nothing works. Then noticed that power indicator LED is not too bright and flickers when load is applied to the regulator. Figured there must be something wrong with the regulator. Hooked up a scope and saw nice rectified pulses on the input of the 7805! Conclusion: It helps to order parts not in a hurry, and read label carefully. Next time I ordered 9V<b>DC</b>, 1A wallwart and everything is fine. So if anybody needs 9VAC,1A wallwarts, let me know.

Wouter wrote regarding 'RE: [EE]: stupid mistakes' on Wed, Jan 04 at 14:09: > > So if anybody needs 9VAC,1A wallwarts, let me know. > > No, but I sure want to read more of those mistakes! I was building some tailpipes for my Caprice Wagon over the weekend (no one makes pre-fab 2.5" mandrel-bent tailpipes, and stockers won't flow enough air to support planned engine upgrades), and was using a large magnet to hold the pipes in alignment. The magnet wasn't strong enough, so a 2 foot section fell a couple feet and konked me on the forehead pretty good. Then I burned several holes in my arm and the back of my neck efore I figured out that my welding jacket is fireproof, but my coveralls are not. But I've got a cool new exhaust now, and it's quiet enough to not irritate the neighbors / my passengers. Oh, and I'll remember to wear the welding coat next time. Probably. Or were you specifically interested in electrical mistakes? :) --Danny, whose forehead is healed but whose burns may take a few more days

Aww heck. May as well throw in my novice mistake. The only thing in my favour is that I am a novice... ! Took a few days getting my home-rolled C18 Code to work for driving an HD44780 based LCD Module (remember that Contrast thread a short while back...). Anyways, I got it all working, then decided to "neaten" it up a bit. I changed the Crystal as well (from a 4MHz to 4.194304Mhz + PLL). One of the neatinging things I did was to migrate from using PORTD to LATD for the LCD pins. Well, everything LCD stopped working even though it all looked good still in the Simulator. Just could not figure it out even though my flashing LED was flashing. Took me a day to realize that using LATD for the setting LCD data lines was fine, just so long as you then use PORTD to read the busy flag! It so happened that because most (all) of my LCD code was writing the low 128 characters, that LATDbits.LATD7 was always "not busy"... even though PORTDbits.RD7 was, so my init routine was way messed up... Rolf Wouter van Ooijen wrote: {Quote hidden}>> Or were you specifically interested in electrical mistakes? :) >> > > I prefer bug-finding mistakes, but of course one sometimes has to debug > his own mindset. > > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: http://www.voti.nl > consultancy, development, PICmicro products > docent Hogeschool van Utrecht: http://www.voti.nl/hvu >

> > I prefer bug-finding mistakes... A _long_ time ago, I was converting a program from one dialect of BASIC, to another. The original dialect had a special keyword 'REMOVE'. Can't remember what it did exactly, but it was important to the program. With the new interpreter, this keyaord was being ignored. It never complained about the keyword being illegal. I was very confused. Just to be sure I wasn't imagining things, I added an X to it: 'REMOVEX'. Still no complaints. I added a whole line of garbage, and still no complaints from the interpreter. After much experimenting, I found that the new interpreter would ignore anything that began with the letters REM. That's when the light went on. Neil -- http://www.pixpopuli.com

> > Or were you specifically interested in electrical mistakes? :) > > I prefer bug-finding mistakes, but of course one sometimes has to debug > his own mindset. > This is a mindset adjustment story... I sometimes find myself asked to help technicians in the production area of our plant. I write the embedded controller code, so whenever anything doesn't work they come find me because they think it's a firmware bug (nevermind that the previous 3,000 units worked just fine!) One of the technicians summoned me after he had spent 2 hours attempting to find out why he could not get the serial link between one of our products and a printer. The printer isn't printing anything. The device seems to be operating normally but no printing. He says he has "tried everything". So I ask about baud rate, parity, blah blah blah. Says he checked all that. I ask if he has tried a new cable - "No, I used this same cable yesterday and it worked just fine". So I went into my standard lecture about how things usually do work just fine right up until the time they quit working. He listened, but was unimpressed. I asked him to humor me and try a new cable. He mumbled something not very complimentary about my family heritage, so I decided to let him solve the problem himself. He tells me later that after troubleshooting for another hour or so he DID change the cable and presto - it works. So the lesson was just because something worked fine yesterday doesn't mean that it is still ok today. I find it amazing how many people refuse to believe that something that worked yesterday quit working today. I'll try to remember some of *my* more interesting mistakes (there are lots to pick from!) -- Mark

I have fond memories of the little "lie detector" circuit I made back in high school. A little cmos 4009 hex inverter configured with two inverters as an oscillator that used a nice PCB pattern to include your finger resistance to help determine frequency, and the remaining 4 inverters in parallel as an LED driver. But it only worked SOMETIMES, depending on how you squeezed it. Turns out that the osc and the LED driver weren't actually CONNECTED to one another. If your fingers were in the right places on the BACK pcb, they conducted enough signal to make CMOS happy. Otherwise; not. An educational experience! BillW

> > I prefer bug-finding mistakes, but of course one sometimes has to debug > > his own mindset. > > > > This is a mindset adjustment story... > Here's another story that should probably be filed under mindset adjustment. Back in the early 80's I was a technician for a small company. We had recently hired a new engineer (Steve). He had designed some rather complex boards that were loaded with 74xx chips. One day I am walking through the shop and I see Steve with prints scattered all around on a large bench. Steve also has one of the new boards hooked up and was surrounded by several scopes and a logic analyzer. Being the curious sort I walked over and said "What's up Steve, What're you workin' on". He proceeds to explain how this particular board isn't working properly and he is tracking down why. He then tells me to stick around for a while because I might learn something - Ok sounds good to me. I stood and watched over Steve's shoulder for a minute or two before I asked what he was doing with the logic analyzer (At that time I had never used one). Steve proceeds to start talking about all sorts of stuff that went right over my head. Meanwhile I had noticed something that didn't look right - I tried to point it out, but Steve insisted on giving me a big long explanation about how he was going to use the logic analyzer and the scopes to trace signals and such. My response was along the lines of "Well, yeah I suppose you *could* go about it *that* way". His reply was a somewhat snotty "Well since you're so F'ing smart how would you go about finding the problem". Without hesitation I pointed to one of the ICs on the board and answered, "Well if it was me I'd start by taking this chip out of the socket and turning it around so pin #1 is in the right place". What? Huh? Steve was stunned, pissed and embarrassed all at the same time. Steve knew way more about how that board worked than I ever did, after all, he designed it. I just happened to notice a chip in backwards. So I guess the moral is "Don't overlook the easy stuff". Someone a while back (Wouter maybe?) told a tale of debugging for a while with the wrong PIC chip installed. I've done the same thing myself. Very often I concentrate too much on the complex stuff and overlook the easy stuff. You can learn a lot from your own mistakes... but it's a lot easier to learn from observing other peoples mistakes. -- Mark

Mark Scoville wrote: > So I guess the moral is "Don't overlook the easy stuff". Hear hear! I was Main Geek at a startup around fifteen years ago. I was supposed to be programming but of course helped troubleshoot everything from Solaris workstations to the fax machine. During that period I developed: ---------------------------------- The First Rules of Troubleshooting 1. Is it plugged in? 2. Is it turned on? ---------------------------------- I never found a third rule that applied so often as these. What was most interesting was the variety of *ways* they can apply, especially with a creative enough definition of "plugged in" and "turned on," where you inspect each piece of the system (hardware or software) that can connect to others and/or be enabled or disabled. Mark's story sounds very familiar, though - I guess the third rule might be: 3. Describe the problem to someone unfamiliar with it. A lot of the time, the third party doesn't even have to say anything - just the act of describing the situation reveals some high-level error. -- Timothy J. Weber http://timothyweber.org

On 1/5/06, Mark Scoville <EraseMEmscovillespam_OUTTakeThisOuTunicontrolinc.com> wrote: > So I guess the moral is "Don't overlook the easy stuff". > Here's a recent one. I designed a board where an outside analog input could be connected to the circuit in one of two ways. To select this, I used a three-pin header with a jumper to bridge two of the pins. When assembly of the boards was finished, they worked fine except this analog input was reading about zero voltage no matter what. After half an hour of troubleshooting, I remembered to install the jumper. Then the board worked. So far this isn't a remarkable story. But then I proceeded, for the next four or five of these boards I deployed, to make the *exact same mistake*. For each board I was testing, I would notice the voltage was zero, then start to measure the voltages down the circuit, then realize the jumper was missing. Finally realizing how thick-headed I was, I decided to outsmart myself. I took each of the hundred boards out of their antistatic bags, added the jumper, and put them back in the bag. I haven't run into the issue again. Regards, Mark markrages@gmail -- You think that it is a secret, but it never has been one. - fortune cookie

On Thu, 05 Jan 2006 11:39:02 -0500, Timothy Weber wrote: {Quote hidden}> Mark Scoville wrote: > > > So I guess the moral is "Don't overlook the easy stuff". > > Hear hear! > > I was Main Geek at a startup around fifteen years ago. I was supposed > to be programming but of course helped troubleshoot everything from > Solaris workstations to the fax machine. During that period I developed: > > ---------------------------------- > The First Rules of Troubleshooting > > 1. Is it plugged in? > > 2. Is it turned on? > ---------------------------------- > > I never found a third rule that applied so often as these. What was > most interesting was the variety of *ways* they can apply, especially > with a creative enough definition of "plugged in" and "turned on," where > you inspect each piece of the system (hardware or software) that can > connect to others and/or be enabled or disabled. Indeed! Many years ago I had a call from a user of a Datapoint computer (where the screen and keyboard were in one lump with all the electronics inside) that their screen had gone dead. After a minute or so I found that they had the desk pushed hard against the wall, trapping the mains cable for their machine. As they pulled the machine towards themselves to get the keyboard in a comfortable position, the plug at the back disconnected! > Mark's story sounds very familiar, though - I guess the third rule might be: > > 3. Describe the problem to someone unfamiliar with it. > > A lot of the time, the third party doesn't even have to say anything - > just the act of describing the situation reveals some high-level error. This is a very powerful technique which I use a lot - I call it "cardboard cutout debugging", because as you say, they can just sit there and say nothing, it's the act of rephrasing the problem so someone else can understand it that "explains" it to yourself and makes you think of it from another angle. Cheers, Howard Winter St.Albans, England

Howard Winter wrote: >>Mark Scoville wrote: >> >> >>Mark's story sounds very familiar, though - I guess the third rule might be: >> >>3. Describe the problem to someone unfamiliar with it. >> >>A lot of the time, the third party doesn't even have to say anything - >>just the act of describing the situation reveals some high-level error. >> >> > >This is a very powerful technique which I use a lot - I call it "cardboard cutout debugging", because as you >say, they can just sit there and say nothing, it's the act of rephrasing the problem so someone else can >understand it that "explains" it to yourself and makes you think of it from another angle. > > > I agree with this last one, quite remarkable technique! I think you have 95% of the ground covered. David

> Someone a while back (Wouter maybe?) told a tale of debugging > for a while with the wrong PIC chip installed. Yup, that was me trying to get the A/D converter in a 16F629 to work. I also tried to program a 16F877 + 16F877A wired in parallel. For some reason the chip ID I read did not make sense. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

> also tried to program a 16F877 + 16F877A wired in parallel. For some Multiprocessing.... Cool. Ok, Don't anyone accuse me of not making enough stupid mistakes.... I'm busy cranking them out yet today. A couple months ago I realized that the speakers on my PC were inoperative. They used to work just fine. I checked all the usual stuff... plugged in, power lamp on, volume knob turned up, cable going from speakers to the back of the PC. Everything looks ok - they just didn't work anymore. Hmmm, maybe they are broken. I don't usually *need* sound so I just sort of dropped the issue. Fast forward a couple months to today... Speakers still don't work. My speakers have a headphone jack on the side, so today I get the brilliant idea to see if I get any sound thru the headphones if I plug them into jack on the side of the one speaker. I look all over the place for the headphones - they are usually in my desk drawer. I can't find the darn things anywhere. I finally find the headphones under a pile of papers on the top of the desk. I follow the cord to get to the plug so I can plug them in... Guess what... they're already plugged into the speakers. That's why the speakers don't work - The bleeping headphones are plugged in! Duh! I've used up my entire stupid quota for all of January and today is only the 5th! -- Mark

>> 3. Describe the problem to someone unfamiliar with it. >> >> A lot of the time, the third party doesn't even have to say anything - >> just the act of describing the situation reveals some high-level error. > >This is a very powerful technique which I use a lot - >I call it "cardboard cutout debugging", Sounds like a pretty good name for it ... >because as you say, they can just sit there and say >nothing, it's the act of rephrasing the problem so >someone else can understand it that "explains" it to >yourself and makes you think of it from another angle. Yeah, done it many times myself too.

>Ok, Don't anyone accuse me of not making enough stupid >mistakes.... I'm busy cranking them out yet today. > >A couple months ago I realized that the speakers on my >PC were inoperative. ... > That's why the speakers don't work - The bleeping headphones >are plugged in! Duh! I've used up my entire stupid quota >for all of January and today is only the 5th! I remember the apprentices getting one back on the mechanical engineer we had in the factory. The company had decided to bid for assembling telephones for the PO, and had a sample one brought in that could be used for the estimating. The apprentices took the handpiece, and put it on the workshop phone hook, and hid the workshop headpiece somewhere down behind the desk. Then went to another extension and rang the workshop. I think they must have spoken pretty loudly into the phone they were using because when the engineer picked up the hand ice he could here the proper handpiece gabbling away, but obviously couldn't make sense of what he could here. He could get somewhat short fused at times, and probably did so this time before slamming the hand piece down.