RE: CAN Inspector: a CAN node to sample the CAN bus waveforms

"John Dammeyer" <[email protected]> Sun, 13 Mar 2016 10:38:18 -0700
Newsgroups gmane.comp.hardware.bus.can
Message-ID <[email protected]>
Hi Michael,
It's possible, depending on the environment and failure modes, that you will
get a warning that something is wrong.  Putting the Error counter
information or whether a node is Error Passive as part of periodic status
messages will certainly help. 

Like the other's though, I lean to an external device.  Here's why.

I just purchased 3 sets of 50 ring lights from the BC Government Asset
Recovery.  
http://www.autoartisans.com/rings/Barge1a.jpg

Each came with a cable that had 50 connectors Tee'd off in the last 35m of
cable.  I laid 50 out on my deck over Christmas and re-addressed lights so
they had the ID's 2 .. 51 and connected them to a small dsPIC based
controller I designed for a number of different kinds of lights.

Once January 1, 2016 arrived I set the intensity output to 0 but left them
powered.  

About two weeks ago as we were driving away I noticed the string of lights
was all a dim green.  That's the value I'd programmed the lights to be if
they lost CAN communications.  On the Rings Project regardless of the
default colour every lamp was a dim white so we'd know if a lamp filled up
with water or failed in some other way because it would either be dark or
dim white while the others were coloured.
When we got back that night the lights were all off again.

A few days later it happened again and this time it stayed.  We'd had a lot
of rain so clearly either  a lamp or a connection had water ingress along
with temperature changes to cause the CAN bus to die.

To eliminate the controller I connected a lamp in place of the long cable.
It worked so it wasn't my controller. I measured the resistance of the cable
connections and found around 10 Ohms to ground on the CAN_H line and about
130 Ohms to ground on the CAN_L so clearly there is a short on CAN_H that
disabled CAN communications.

I removed all the lamps, after I pulled back the insulation on the
termination resister for inspection.  No luck.  The defect is somewhere in
the cable. Next I replaced one lamp at the end by the termination resistor
and it was still green when it should have been off.  I then started flexing
the cable one connection at a time and about halfway down the system started
working again so I have a rough idea of where the problem lies.  It's now
been functional for a week.

My next step, once it stops raining, is to bring out my R&S 3GHz spectrum
analyzer and try the TDR feature to see if I can see anything. The problem
will be a long 25m cable with no defects and then 50 T connections.  I'm not
sure I'll be able to detect a short circuit that has vanished.

I could add software to the master to periodically query nodes error status.
The protocol is master/slave so the nodes don't send unless queried.
Perhaps there will be a hint of problems to come with one or two nodes that
have problems but a 35m bus with a problem in the middle isn't easy to fix.

John Dammeyer



> -----Original Message-----
> From: Michael Ashley [mailto:[email protected]]
> Sent: March-13-16 1:36 AM
> To: John Dammeyer
> Cc: [email protected]
> Subject: Re: [CANLIST] CAN Inspector: a CAN node to sample the CAN bus
> waveforms
> 
> 
> Hi John,
> 
> Thanks for your comments.
> 
> > The first question I'd ask would be who gets this information and how do
> > they get it?
> 
> My CAN bus connects to a Linux computer that has an Iridium modem, so
> this gives me contact from the outside world.
> 
> > and there's no way to add functionality to it in the form of
> > an scope module?
> 
> Well, I could add a scope module. Maybe that is the smart thing to do. I
just
> like the idea of a simple CAN node to do the job. And our CAN nodes (based
> on the AT90CAN128) survive cold-soaking to -80C.
> 
> > The problem you face is if your CAN bus is crippled due to a physical
issue
> > any scope device that is on the same CAN bus becomes useless.
> 
> Yes, that's true, but so far all my issues have been loss of redundancy,
not
> outright failure.
> 
> > Perhaps you could add some details as to how you would report the bus
> > information?
> 
> After grabbing 1 kB of bus waveform, the CAN node could be instructed to
> download it across the CAN bus 8 bytes at a time. The CAN node would need
> some moderately clever software, e.g., perhaps repeatedly grabbing 1 kB
> samples until one of them happens to contain the leading/trailing edge of
a
> bit. I'm also thinking of incorporating a high-speed pulse generator to
make
> a "poor man's TDR" (or perhaps it should be called a "crazy man's TDR" if
this
> project gets out of hand!).
> 
> Regards,
> Michael
> --
> Professor Michael Ashley                   Department of Astrophysics
> University of New South Wales       http://www.phys.unsw.edu.au/~mcba

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[email protected]>