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

"Bram Kerkhof" <[email protected]> Sun, 13 Mar 2016 17:29:45 +0100
Newsgroups gmane.comp.hardware.bus.can
Message-ID <[email protected]>
What transceivers are you using?

High-speed CAN performs really well in an environment with a lot of
potential electromagnetic interference (the ATLAS detector at CERN is
stuffed with CAN nodes) but has only limited redundancy for physical
problems. Fault-Tolerant transceivers (like the TJA1054) are designed to
deal with a lot of physical failure modes and (more importantly) should be
able to detect and report degraded operation in every node of the network.

A CAN health node could certainly be an interesting addition to the network,
but as John says it has to be able to report back to be useful.
Also: what is your sampling strategy? 
- What are you going to sample? (I would imagine you need at least 2
channels)
- When are you going to sample? (There's no way to have a trigger)

My gut feeling is that this will be simpler and more performant to implement
on a dedicated MCU with CAN controller(s) and ADC(s) (a Cortex-M0 would be
plenty powerful). Sample to a ring buffer and use the CAN controller
interrupt (and message reception) to validate how good the signals are
looking for the data you receive. Or store the samples somewhere when an
error message passes by.

cheers,
Bram

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Michael Ashley
Sent: zondag 13 maart 2016 0:47
To: [email protected]
Subject: [CANLIST] CAN Inspector: a CAN node to sample the CAN bus waveforms

Dear CAN bus gurus,

I've been thinking of a design for a CAN node that is able to digitize the
waveform on CANH and CANL and then transmit the waveform as multiple CAN
messages. The device would also be able to report the CAN power supply
voltage. I'm interested in your opinions on this concept.

The design is based around the Texas Instruments ADC08B200 ADC, which
digitizes to 8-bits at up to 200 Msps. Its key feature is a 1 kB data buffer
that can be read out slowly, so there is no need for the MCU to keep up with
the data in realtime.

The motivation for wanting such a device is that I'm using a CAN bus for
some remote experiments in Antarctica, and there have been several cases
recently where the bus has operated in a degraded mode (CANL shorted to
ground, missing terminator - this is on a 70m long bus running at 100 kbps)
without anyone being awareof it. The people who are servicing the equipment
do not have the expertise or the time to connect up TDRs or oscilloscopes or
even multimeters to diagnose problems. The physical environment can be very
tough, e.g,. -40C in summer (-80C in winter) and high altitude (over 4000m),
so asking someone to connect an oscilloscope and make measurements is asking
a lot. The personnel are only on-site for betwen 5 and 21 days over summer
each year; the rest of the time the equipment is entirely remote.

A "CAN Inspector" node that could be simply placed on the bus would be very
valuable. I could remotely monitor the bus, recognise when problems occur,
and give repair instructions. An alternative approach could be a small
USB-accessible oscilloscope.

One of the big advantages of CAN is its fault tolerance. However, if the
fault occurred some years ago, and you are already running in a degraded
mode, then you have already used up all your tolerance.

I will post a link to a draft schematic for the CAN Inspector in a
subsequent message.

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]>