Proper way to probe CAN buses (passively or active?)

[bigredcustoms]

So long story short, I acquired a vehicle that utilizes a CAN bus, 22 nodes or modules are in the loop from what I've been able to deduce from the service manual. My question is, I have a Rigol 1054Z with all the options, is there a way to view these communications without triggering any errors in the system to check for corrupt packets or latency? Ever since I've worked with this vehicle, I've had weird anomalies with various functions that either do not engage or requires a double press of a button to initiate. It's also very sensitive to cheap power supplies or LED drivers so maybe a noise component and lack of shielding in certain areas. Any direction on this would be hugely helpful. I know enough to be dangerous, but by no means an engineer or software guy. I just really enjoy digging in and learning all I can. My goal is to record this information, copious research, and try to find what module or wiring is causing the issue because the techs for this platform do not poses that deep of a level of access to that info with their equipment. Thanks again.   

[Hypernova]

The loading from the scope probe shouldn't be significant enough to disturb the bus, so just probe the CAN_H line and clip the probe ground to CAN_L since your car ground is electrically floating.

[bigredcustoms]

Thanks for the quick reply! I appreciate the info, going to do some data logging over the weekend and see what I can find. I also forgot to ask, is there a best practice regarding where to probe, or given the topology it doesn't matter? I don't recall which module carries the originating clock signal to that should be fun to locate. Again thanks.

[JPortici]

You can do as suggested because the scope and the veichle does not share the same ground... but anyway the 1054z does not have CAN decode. Also, what do you mean by latency?

And a scope is not a good tool for this.
I suggest you download something like busmaster and get an OBD <-> usb interface and start logging (busmaster should have a third party plugin to support the dirt cheap elm327 clones)

[bigredcustoms]

Latency I have is mainly from a delay in application of fuel via the go pedal and and the time to see subsequent increase in RPM from the engine, also buttons to activate certain features or modes are very slow to respond or require multiple presses to activate. The problems could also be related to noise due to lack of shielding, but before I disturb any wiring, I figured I'd take a peak at the data on it's own. I thought maybe I'd be able to get some sort of serial data with the scope, but I will look into the software/hardware specifically for OBD. I'm aware that this system usually has fairly good error correction, which is why I'm stumped there are no codes or indications of anything considering the symptoms. We use ARINC 429 for flight systems on aircraft I work on, but the test equipment involved is pricey and proprietary, even the way information is presented on the bus is different. I don't know if the same rules apply to automotive, but I'm trying to get my head wrapped around the system. I'll check out busmaster. Thanks

[JPortici]

busmaster + a kvaser interface is what i use at work to log and eventually reverse engineer can networks
i asked what you meant by latency because depending on the node importance / rate of change it may be sending new data every 10,100,1000 or more milliseconds.. things like buttons may very well be on a separate LIN network that would have even more inhirent latency

having a look at the actual signal is always good but to monitor a can network a scope is not the proper tool. with loggers you will also be able to catch error frames, bus errors and look at how busy the bus is

[bigredcustoms]

Got ya, I'll look at priorities of those nodes and the associated systems, maybe one is waiting for a reply, or like you said, maybe on a separate network that's the hitch in the data transmission, awesome!

[JPortici]

Hm... let me give you an example. In my fiat punto (actually all fiat) there are two can networks: fast (powertrain) and slow (radio, steering wheel and body computer link) plus other things like windshields in a separate lin bus.

Anyway, the steering wheel buttons are on the slow lane, 50 kbps no termination full swing as per low speed fault tolerant can specification. Message sent every 250 or 500 ms, all non latching buttons (volume) have their bit set one when they are pressed, 0 the next and until you press again. But at some point you'll never see anything because the rotating contacts wear out. Change your contact block on you may steer the wheel but keep going straight.

This is a common failure in these cars, after 200k km or so, anothe warning sign, as it happened in my car, can comm with steering wheel airbag was lost and the light was always on

[Jeroen3]

busmaster + a kvaser interface is what i use at work to log and eventually reverse engineer can networks

This actually works. The scope is to detect electrical anomalies. Which you can see as error counter in busmaster.

[tiger99]

If you do choose to use an oscilloscope with CAN decoding, I would suggest using two probes differentially and differencing them on the scope (usually summing the two channels plus inverting the low side probe). You may get a more reliable data stream that way, and avoid temporarily corrupting vehicle systems. The probe loading, as stated already by someone, is not a concern at all at CAN speeds. If you do it the other way, with the scope floating at CAN low line potential, you are adding massive unbalanced capacitance to the CAN pair, which despite appearances, are supposed to be balanced at AC. (Somewhat like a phone line, where there is about 50 V DC across the pair, but usually very good balance at AC to avoid mains frequency hum pickup).

On my most recent vehicles, access was/is possible via the OBD port and there are often separate high and low speed CAN busses there, one of them being on non-standard pins. It is fairly routine to modify the CAN to USB adaptor by fitting a double pole changeover switch to enable one or the other bus to be selected. Google may find the details for you.

I would venture to suggest that CAN is a mediocre interface at best, not helped by the liberties that vehicle manufacturers take with the wiring. Some use screened twin cable of the correct impedance, but have long gaps with screen pigtails at connectors, others think that they can get away with plain unscreened twisted pair, with very little care to keep the pair tight at connectors. At least one vehicle manufacturer does it fairly well, and their standards are available somewhere on the web. Others always claim to have followed the standard. I work for a major ECU manufacturer, and take great delight in ensuring that our specifications clearly state what is required of the CAN wiring. We test new designs properly for standards compliance too, while the vehicle wiring is, well, perhaps not tested at all. And don't get me going on the truly crude, vile and horrible LIN bus, or the extreme inadvisability of using the SENT interface for anything that needs to be reliable.

The ARINC 429 mentioned above is delightful, by comparison, and is only expensive to implement when you use the expensive chipset made by a certain semiconductor manufacturer. Most people use a small portion of their FPGA or DSP processor and a few op amps and comparators to make a cheap but still standards-compliant interface nowadays. But as stated, the external test equipment may well be hideously expensive. A small but enterprising and innovative manufacturer could easily corner the market with affordable equipment.