David Brown <david.brown@hesbynett.no> wrote in
news:r61klr$369$1@dont-email.me:
On 31/03/2020 20:40, Rick C wrote:
On Tuesday, March 31, 2020 at 12:41:36 PM UTC-4, David Brown
wrote:
On 31/03/2020 17:40, blocher@columbus.rr.com wrote:
On Tuesday, March 31, 2020 at 11:34:44 AM UTC-4,
snip
Also - the FPGA guys and the SW guys will only acknowledge a
problem when it is laid out under their nose. It is never
their fault
That's because it's usually a hardware fault - and it can be
solved by using a bigger capacitor
You laugh, I once used a telephony part that had a PSRR of 0dB
which I had missed. (Who expects 0 dB?) On the customer's work
bench they were getting noise in the audio that turned out to be
from the DSP power consumption. They were using clip leads to
provide power to the UUT and the on board capacitance wasn't
enough to mitigate it. We told them to use better power
connections and also used a larger cap.
I had a smiley, but I have seen more than a few systems
reliability improved by adding a bigger capacitor. There is a
rule in software development that "almost all programming can be
viewed as an exercise in caching". (Yes, it is an exaggeration -
but there's a grain of truth in it.) Capacitors are the hardware
equivalent of software caches.
Mind you, I have seen problems with too big capacitors too. I
remember long ago trying to find why a card communicated find (at
9600 baud RS-232) with some computers but not others. Looking
with a scope, the RS-232 signals were lovely triangle waves -
someone had added 100 nF capacitors to the lines to reduce the
noise...
I have a trusted engineer friend who once said that most failures
occur at power up or power down. He always left his computers at
work and his home up all the time.
Old net and system admin guys usually like keeping systems up and
running at all times too.
The big computer rooms of the sixties would lose thousands and hour
in insurance if the room temperature rose above a preset level like
63°F.
On Tuesday, March 31, 2020 at 4:08:59 PM UTC-4, Phil Hobbs wrote:
On 2020-03-31 14:40, Rick C wrote:
On Tuesday, March 31, 2020 at 12:41:36 PM UTC-4, David Brown wrote:
On 31/03/2020 17:40, blocher@columbus.rr.com wrote:
On Tuesday, March 31, 2020 at 11:34:44 AM UTC-4, blo...@columbus.rr.com wrote:
Another topic that I hope can elicit engineering discussion:
What makes up a good skill set for finding the root cause of a failure that is rare, intermittent or obscure?
Over the past several years I have been more involved in root cause failure than I was when I was doing more design work. In many ways I think it is more challenging than design work. It takes a mindset that is different than design.
Here is my reminder list when doing root cause studies
1. never root for a particular outcome when performing a test. Root for not being fooled by the results of your test
2. Assign weighting factors to everything you believe. Never assign a weighting factor of 1 to anything until you know you have the problem solved
3. Expect to have to do certain tests over again and that you will draw an opposite conclusion when you repeat a test than what you concluded after the first test.
4. Taking guidance from "helpful" outsiders is challenging. On the one had they care and are smart, on the other hand if you go about chasing other peoples ideas (often conceived of to just demonstrate they are concerned in a meeting) you will never get an a clear path to troubleshoot the problem in your own way.
Help is a two edged sword. It is important but can sometimes be problematic.
5. As an aside - I have learned that when I "see something" during the design phase, I no longer look at that as a curse, but as a blessing. It is going to come back and get you later.
6. Get past the notion that having nothing to show for a days work is bad. As a designer you can show a days work for a days pay. In root cause you feel like you have accomplished nothing for a long time. Frequently, though , these problems are the most visible problems in an organization and can make a difference between losing a customer and keeping one.
7. Look for contradictions in your thinking. Use other people to help you find contradictions in your thinking.
OK - enough for now......
Also - the FPGA guys and the SW guys will only acknowledge a problem when it is laid out under their nose. It is never their fault
That's because it's usually a hardware fault - and it can be solved by
using a bigger capacitor
You laugh, I once used a telephony part that had a PSRR of 0dB which I had missed. (Who expects 0 dB?) On the customer's work bench they were getting noise in the audio that turned out to be from the DSP power consumption. They were using clip leads to provide power to the UUT and the on board capacitance wasn't enough to mitigate it. We told them to use better power connections and also used a larger cap.
0 dB of PSRR??? How can you even do that exactly??? CP Clare, what a piece of work they are. The other CP Clare part had a problem that virtually made it unusable, but they didn't point it out in the data sheet. I wonder if they actually use engineers or if they just let high school kids design their ICs?
Are you quoting that WRT the input or the output? PSRR and CMRR are
normally quoted input-referred, i.e. to find out the effect you have to
multiply by the overall gain.
There are lots of parts that can have negative-dB PSRR as referred to
the output.
At higher frequencies aren't there many opamps that cross
0 dB PSRR. At least for one of the rails.
On 2020-03-31 13:59, Tom Gardner wrote:
On 31/03/20 18:17, George Herold wrote:
Hmm OK. I designate two types of problem solving.
1.) Your (prototype) gizmo is not working.
I call this de-bugging. The problem could be somewhere in the
gizmo, or you may have made a fundamental error in your idea.
Those are the hardest types of problems.
2.) You've got several working units but this one from production
has a problem not seen before.
I call that trouble shooting... it's easier because you've got working
units, so you know it can't be a fundamental problem.
It could still be a design problem. Like you didn't spec the spread in
cap ESR on the voltage regulator and the odd high or low esr cap causes
your voltage regulator to oscillate.
Add 3) It fails on some customers' site, but not elsewhere.
Now, is it because the customers' equipment is at fault or
the spec is inadequate (whatever that might mean)?
IME this is usually EMI.
(Courtesy of Palindromic Engineering.)
Taking a perfectly good piece of equipment and having folks connect it
up with BNC cables between two different racks, with nice large ground
loops and a VF drive in the HVAC overhead is one typical way to do this.
Cheers
Phil Hobbs
On 01/04/2020 11:47, Rick C wrote:
On Wednesday, April 1, 2020 at 4:51:11 AM UTC-4, David Brown wrote:
On 31/03/2020 20:40, Rick C wrote:
On Tuesday, March 31, 2020 at 12:41:36 PM UTC-4, David Brown
wrote:
On 31/03/2020 17:40, blocher@columbus.rr.com wrote:
On Tuesday, March 31, 2020 at 11:34:44 AM UTC-4,
snip
Also - the FPGA guys and the SW guys will only acknowledge a
problem when it is laid out under their nose. It is never
their fault
That's because it's usually a hardware fault - and it can be
solved by using a bigger capacitor
You laugh, I once used a telephony part that had a PSRR of 0dB
which I had missed. (Who expects 0 dB?) On the customer's work
bench they were getting noise in the audio that turned out to be
from the DSP power consumption. They were using clip leads to
provide power to the UUT and the on board capacitance wasn't
enough to mitigate it. We told them to use better power
connections and also used a larger cap.
I had a smiley, but I have seen more than a few systems
reliability improved by adding a bigger capacitor. There is a rule
in software development that "almost all programming can be viewed
as an exercise in caching". (Yes, it is an exaggeration - but
there's a grain of truth in it.) Capacitors are the hardware
equivalent of software caches.
Mind you, I have seen problems with too big capacitors too. I
remember long ago trying to find why a card communicated find (at
9600 baud RS-232) with some computers but not others. Looking with
a scope, the RS-232 signals were lovely triangle waves - someone
had added 100 nF capacitors to the lines to reduce the noise...
Yeah, I've gone overboard too. The board I'm making now has a 150 uF
tant on the 12 volt line because I have no real specs on the power
source and there are multiple boards it's used on as a daughercard
for anyway. The original design was for a 1 kHz tone signal driving
a 50 ohm load Âą8 volts. So I used the biggest part I could find not
knowing what else might be on that power rail glitching away. Turns
out 150 uF x 8 daughtercards was a bit much for the supply at power
up! Fortunately the chip they used had a cap you could change to set
the ramp speed and once it was dialed back it worked fine.
After that the only problem was ham fisted installers who shove the
boards into the rack misaligned scraping these tall caps right off
the card!
Ham-fisted installers are always a problem! We made a number of systems
that were used in farming industries, and we'd get boards back for
service that were an incredible mess, with electronics fried and
connectors and sockets broken. The hand-scribbled failure report would
say things like "the socket was the wrong size - I had to use a hammer
to get the plug in". Round plugs and square holes were no hinder to
these guys.
On Wed, 1 Apr 2020 12:58:34 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:
On 2020-03-31 13:59, Tom Gardner wrote:
On 31/03/20 18:17, George Herold wrote:
Hmm OK. I designate two types of problem solving.
1.) Your (prototype) gizmo is not working.
I call this de-bugging. The problem could be somewhere in the
gizmo, or you may have made a fundamental error in your idea.
Those are the hardest types of problems.
2.) You've got several working units but this one from production
has a problem not seen before.
I call that trouble shooting... it's easier because you've got working
units, so you know it can't be a fundamental problem.
It could still be a design problem. Like you didn't spec the spread in
cap ESR on the voltage regulator and the odd high or low esr cap causes
your voltage regulator to oscillate.
Add 3) It fails on some customers' site, but not elsewhere.
Now, is it because the customers' equipment is at fault or
the spec is inadequate (whatever that might mean)?
IME this is usually EMI.
(Courtesy of Palindromic Engineering.)
Taking a perfectly good piece of equipment and having folks connect it
up with BNC cables between two different racks, with nice large ground
loops and a VF drive in the HVAC overhead is one typical way to do this.
Cheers
Phil Hobbs
https://www.dropbox.com/s/iajkj7t0z4orwxq/Acceptable%20Energy%20Level.jpg?raw=1
Both traces are from UV photodiodes. They expect me to time-stamp them
to picosecond resolution.