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

Sorry.  Typo.  Should have said 50 lamps on the last 10m of a 35m cable and
500kbps.
John

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of John Dammeyer
> Sent: March-13-16 10:38 AM
> To: 'Michael Ashley'
> Cc: [email protected]
> Subject: RE: [CANLIST] CAN Inspector: a CAN node to sample the CAN bus
> waveforms
> 
> 
> 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]>

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