solarwind wrote:
> I don't know. Why would it get lost?

I haven't followed this thread, other than a casual look at random posts, but
this statement caught my eye as being so antithetical to engineering
methodology that it deserved a response. Don't bother wondering about the
genesis of all the mechanisms that may ruin your design approach, other than to
identify test cases. First, simulate (on paper, on the bench, etc) every
combination of disaster that might occur. Lost nodes, noise, lines pulled high,
 pulled low, and so on, even if you don't think it will ever happen. This is
especially important in architecture or protocol design.

Many a recall has occurred because the designer didn't think a certain pattern
of environmental effects would or could happen. Many others have become just
failed products.

The best way is to start big - lost nodes, non responding nodes, nodes that
have freq. drift, etc. If possible, given that you have software involved, have
'the other end' try to determine the problem or set an error code. This will
help in problem solving later. Some failures may be so big later on that you
may need to look at everyone's error codes to get a picture of the whole
system! Figure out what the system looks like if the one producing the error
code goes bad... Bad events can trigger worse events, so it isn't necessarily a
static exercise.

If you think about it, most people who have experience building things in the
physical realm out of wood, steel, etc have a sense about this and do it. They
reinforce critical parts, even more so if a life could be lost, and they
purchase stronger materials for other areas that might fail if, all by looking
at failure modes.... It just takes a more structured and meticulous approach in
the EE realm because we can't 'see' what's going on directly. It's just a giant
maze where the electrons will play, and we need to know what will happen if
they all end up on one side of our maze, or such. ;)

AFTER taking all the cases into consideration and accounting for them, THEN
look at the 'why', especially for the more disastrous cases. THEN you can
implement things that would reduce the chance of that happening. You'll never
reduce it to zero though, but then you'll have a multi-level protection against
such happening.

Your engineering skill and experience will also come into play. There WILL be
cases you'll miss. If you approached it in the beginning without trying to
counter everything, you won't have any cognitive feedback loop to develop your
engineering skills. IF you do try, then you can slap your forehead and say "how
could I have missed that one!". This gives you an opportunity to develop your
thinking as well.

-Skip
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist