Searching \ for '[EE]: stupid mistakes' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=stupid+mistakes
Search entire site for: 'stupid mistakes'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: stupid mistakes'
2006\01\04@103754 by Wouter van Ooijen

face picon face
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


2006\01\04@110243 by Stef Mientki

flavicon
face


Wouter van Ooijen wrote:

{Quote hidden}

A very good method for testing IR, is to use a digital camera.
cheers,
Stef

>  
>

2006\01\04@110351 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@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.
=======================================================================

2006\01\04@113042 by Wouter van Ooijen

face picon face
> 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


2006\01\04@114518 by Alan B. Pearce

face picon face
>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.

2006\01\04@115504 by TGO Electrónica SA de CV

flavicon
face
Radio Shack used to sell those. I don't know if they still do.

----- Original Message -----
From: "Alan B. Pearce" <A.B.PearcespamKILLspamrl.ac.uk>
To: "Microcontroller discussion list - Public." <.....piclistKILLspamspam.....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.
>
> --

2006\01\04@120246 by David VanHorn

picon face
LED emission isn't purely narrowband.  It's likely that there is some near
IR emission.  I don't think you'd notice it under all the visible, with a
test card or IR sensitive camera.   The fact that the receiver picks it up
is indication that it is emitting something that the receiver is sensitive
to.

The receiver's filter is also not perfect, and there may even be enough
electrical noise to make it through at short distances.

2006\01\04@142524 by Sergey Dryga

face picon face
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.

2006\01\04@150205 by Wouter van Ooijen

face picon face
> So if anybody needs 9VAC,1A wallwarts, let me know.

No, but I sure want to read more of those mistakes!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\04@152216 by Danny Sauer

flavicon
face
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

2006\01\04@154436 by Wouter van Ooijen

face picon face
> 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


2006\01\04@161523 by Rolf

face picon face
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}

2006\01\04@162420 by Neil Baylis

picon face
>
> 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

2006\01\04@165402 by Mark Scoville

flavicon
face
> > 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



2006\01\05@053140 by Alan B. Pearce

face picon face
>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.

Perhaps you need to get some copies of the book from here
http://www.debuggingrules.com/ to distribute.

>I'll try to remember some of *my* more interesting mistakes
>(there are lots to pick from!)

I know that feeling.

2006\01\05@062739 by William Chops Westfield

face picon face
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

2006\01\05@101622 by Mark Scoville

flavicon
face
> > 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



2006\01\05@113905 by Timothy Weber

face picon face
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

2006\01\05@121630 by Mark Rages

face picon face
On 1/5/06, Mark Scoville <EraseMEmscovillespam_OUTspamTakeThisOuTunicontrolinc.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

2006\01\05@122811 by Howard Winter

face
flavicon
picon face
On Thu, 05 Jan 2006 11:39:02 -0500, Timothy Weber wrote:

{Quote hidden}

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


2006\01\05@133353 by David P Harris

picon face
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


2006\01\05@153418 by Wouter van Ooijen

face picon face
> 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


2006\01\05@163939 by Mark Scoville

flavicon
face
> 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



2006\01\05@165642 by Denny Esterline

picon face
> You can learn a lot from your own mistakes... but it's a lot easier to
learn
> from observing other peoples mistakes.
>

I have to learn from other's mistakes, I don't have the time to make them
all myself.

-Denny

2006\01\06@083632 by Alan B. Pearce

face picon face
>> 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.

2006\01\06@085313 by Alan B. Pearce
face picon face
>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.

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...