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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Michael Ashley
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 <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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

Heinz-Jürgen Oertel
Am Sonntag, 13. März 2016, 10:47:24 schrieb Michael Ashley:

> 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

Hello Michael,

I know of a device which at least does the measurement you like to have.
http://www.ems-wuensche.com/product/datasheet/html/can-physical-layer-analyzer-error-diagnostics-canwatch.html
As you can see, problem/error signaling is done by LEDs.
Your Idea to transfer the data by the CAN bus itself is good as long as the bus is able to be used by the can nodes and not totally disturbed.

Another approach is building some error recognition in the CAN nodes itself. Each of the nodes should at least be able to read out the CAN controller error counters. In case of CANopen devices the error counters can be available in the object dictionary to be requested by SDOs or to be transmitted by an PDO. Cyclic or by a change, whatever PDO mechanism is implemented.

--
mit freundlichen Grüßen / Regards
  Heinz
--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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

John Dammeyer
In reply to this post by Michael Ashley
Hi Michael,
Interesting project idea.

The first question I'd ask would be who gets this information and how do
they get it?

I'm guessing that one of the CAN nodes has an external connection to the
outside world and there's no way to add functionality to it in the form of
an scope module?  

For example, I have a project that has 3 CAN bus channels, one that talks to
a proprietary battery management system, one that uses CANOpen and works
with a number of both custom and COTS CANOpen modules and finally one that
speaks J1939 for communication to the vehicle.

Access to the controller is via an FTDI USB device into a PC which in turn
is connected to the outside world.  How I've not been told.  Wifi Ethernet?
Remote Desktop?   Doesn't really matter.

My controller has two extra CAN ports so I could add a module like the one
you describe to work independently from the potentially ailing CAN buses.
My controller can be expanded to also have a WizNet Ethernet module so some
sort of Ethernet Scope/Meter could also be used.

Since the client has a PC connected I could even use a USB scope device on a
hub that talks to my controller and the scope.  

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.  

Perhaps you could add some details as to how you would report the bus
information?

Thanks
John Dammeyer




> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Michael Ashley
> Sent: March-12-16 3:47 PM
> To: [hidden email]
> 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 <[hidden email]>

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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

Michael Ashley
In reply to this post by Heinz-Jürgen Oertel
Hello Heinz,

> I know of a device which at least does the measurement you like to have.
> http://www.ems-wuensche.com/product/datasheet/html/can-physical-layer-analyzer-error-diagnostics-canwatch.html

Interesting, thanks. Although I'm wanting to have the detailed waveform so that I can potentially check for things like bad connections, or someone messing up the topology of the bus.

> Your Idea to transfer the data by the CAN bus itself is good as long as the bus is able to be used by the can nodes and not totally disturbed.

Yes, if the CAN bus is dead then obviously my device won't help. In practice, all my problems have been situations where the CAN bus is still working, but is on the verge of failure.

> Another approach is building some error recognition in the CAN nodes itself.

Yes, I can access the CAN error counters. It has been a while since I looked at what these counters can tell you. If the CAN messages get through with no errors, will the counters help you diagnose something like a shorted data line?

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 <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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

Michael Ashley
In reply to this post by John Dammeyer
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 <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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

Bram Kerkhof
In reply to this post by Michael Ashley
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: [hidden email] [mailto:[hidden email]] On Behalf
Of Michael Ashley
Sent: zondag 13 maart 2016 0:47
To: [hidden email]
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
<[hidden email]>

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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

John Dammeyer
In reply to this post by Michael Ashley
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:[hidden email]]
> Sent: March-13-16 1:36 AM
> To: John Dammeyer
> Cc: [hidden email]
> 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 <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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

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

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of John Dammeyer
> Sent: March-13-16 10:38 AM
> To: 'Michael Ashley'
> Cc: [hidden email]
> 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:[hidden email]]
> > Sent: March-13-16 1:36 AM
> > To: John Dammeyer
> > Cc: [hidden email]
> > 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 <[hidden email]>

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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

Michael Ashley
In reply to this post by Bram Kerkhof
Dear all,

I've put a proposed schematic for the "CAN Inspector" here:

http://mcba11.phys.unsw.edu.au/~mcba/canInspector.pdf

Page 1 is an overview.

     2 is the high-speed analog buffer and relay system to select
       which of CANH or CANL to measure. I'm planning to replace R30
       with two resistors immediately after each relay. A DAC is used
       so that the signals can be placed within the range of both the
       THS4304 and the ADC.

     3 is the pulse generator for TDR mode.

     4 is the power supply and CAN transceiver.

     5 is the high-speed ADC with 1 kB buffer.

I would be very interested in comments on the circuit.

Now to Bram's comments:

> What transceivers are you using?

The IL41050TE. I believe that this is reasonably fault tolerant. Most importantly for my application, this part has proven itself through many years of operation in Antarctica with the occasional cold-soak to -80C without any problems. Same with the AT90CAN128. I'm reluctant to move away from known working parts. Some MCUs can loose their flash at low temperatures, but I've never had a problem with the AT90CAN128.

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

I should look into this in more detail.

The detection of a physical failure is the key feature for me. As I mentioned before, CAN's redundancy is great if you have a physically perfect network to start with. But if you already have some physical problems, you may find that all your messages go through without errors, but you no longer have any redundancy left.

This reminds me of a water tank on my father-in-law's farm in Australia - to stop the water tank overflowing he had a switch activated by a float valve, and a backup in case the switch failed. One day the tank overflowed, and it turned out that the backup had rusted away years ago! So, you might thing you have redundancy, but you may not.

> Also: what is your sampling strategy?
> - What are you going to sample? (I would imagine you need at least 2
> channels)

CANH and CANL, with selection by a relay. Also, the CAN power supply with a much slower ADC.

> - When are you going to sample? (There's no way to have a trigger)

The ADC will fill its 1 kB buffer in 5 to 20usec depending on the clock rate. The MCU will then read it out slowly and look for edges, which can then be sent along the CAN bus as packets.

> 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).

Are there MCUs that have 50-200 Msps 8-bit ADCs? E.g., the LPC1102 ADC only goes to 0.4 Msps. Actually, I see the LPC4370FET256 Cortex_M4 has an 80Msps 12-bit ADC - that is pretty amazing.

Anyway, as mentioned above, I would like to stick with our tried-and-tested AT90CAN128 since we already have the software we need.

Cheers,
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 <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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

Bram Kerkhof
I can imagine the "should work on Antarctica" bit on the specification list
can be quite daunting when you think about it ;-).

Without being encumbered by the experience of having to make stuff that
should work when it's that cold, my primary worry would be making sure that
the relays don't malfunction, because if one of them sticks "on" you have a
potential short circuit in the CAN bus, which will definitely render it
inoperable. You are probably in a better position to have information on
component reliability in those conditions, but I would factor in an
interlock (software or hardware) that prevents both relays being on at the
same time.

The second worry is capturing useful data, which is (as far as I am
concerned) mostly clever software. At first glance, the ADC supports a
circular buffer mode, so combined with the CAN interrupt on the MCU you
should be able to implement a triggering mechanism. I would ensure that all
CAN IDs on the bus are regularly sampled, as well as keeping statistics
ensuring that all messages that should be there are indeed present (a split
network can be reasonably healthy on the physical layer, but not on the
functional layer).

I'm mostly a software guy, so I'm not in a position to comment much on the
hardware. I'll leave that for the specialists.

cheers,
Bram

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