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

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 <[email protected]>