Saleae for Automotive (OBD2/ISO 15031)

Logic 2 Software
#1

Halo everyone!

I would like to submit to questions for the Automotive experts, using Salae products:

First topic concerns HW capbilty to aquire messurements in the car. I did not understood if the tool or the SW is capable to aquire this differential signals (CAN_H -CAN_L). I do not know if I use the tool corectly: CH1 for CAN_H bus line, CH2 for CAN_L bus line, the GND for signal GND,…or both GNDs… I need the differential signal for measuring CAN signal , so how can I do it, if posible?

Second topic is related to the User posibility to extend, enhance or further develop the protocol analyzers or measurement extensions.
It is not very clear what is the right tool chain needed, for example after I aquire the CAN signal(s), I intend to covert them in OBD2 “significant” format. This means that I intend to create a .dbc file with the conversion rules from HEX(raw CAN signal) to OBD2 one. For this I need to creat my own extention or “Protocol Analyzer”.

Thanks!

#2

CAN is problematic from the perspective of a logic analyzer. As you are aware, it is differential. But, the logic analyzer isn’t. Generally the way you do it is to hook up to just the CAN-Low wire. You reference this to the local ground (the car’s ground in this case) and it works. The CAN analyzer in Logic is meant to work this way. So long as your CAN system is functional this all is perfectly fine. If you have CAN errors or otherwise don’t know if CAN is working then you have a bigger problem. But, if you have Logic Pro then it can read analog signals. So, then you can capture both H and L and see if they are properly opposite and are ranging the proper amount. They should both hover around 2-3v when idle and pull about 1V away (+ for H and - for L) when active.

As for how to interpret the CAN. You can probably capture with Logic and the CAN analyzer then export the raw bytes as CSV. From there you can take the bytes and interpret them. Or, Logic 2 does have high level analyzer functionality that supports CAN so you could write a python script that takes the bytes and interprets them as OBDII messages.

3 Likes
#3

I agree with @Collin. You would want to record CAN-Low due to the requirement for crossing the voltage threshold of our digital channel inputs on transitions. Thanks for suggesting the specific line hook ups!

@balaci.cornel, I wanted to share some additional information below in case this helps. You can navigate to the CAN section for more information on how to hook everything up.
https://support.saleae.com/protocol-analyzers/analyzer-user-guides/decode-differential-and-high-voltage-data

Also, refer to the voltage thresholds of our products below:

Finally, here is a direct link to our extension system (you’ll want to take a look at the High Level Analyzers section).
https://support.saleae.com/extensions

1 Like
#4

Many thanks to you both!

1 Like
#5

Another option for CAN interfacing if you are not particularly concerned about the logic levels and really only care about the data/protocol on CAN is to buy a CAN transceiver, power it externally and connect the RX line to the logic analyzer. In less ideal/noisy environments, going this route will give you more reliable data than capturing single-ended.

Many CAN transceivers come in 8-pin SOIC (or even classic 8-pin DIP), so you could buy an 8-pin SOIC breakout board (look at Sparkfun/Adafruit/etc for such options) and then select a 8-pin SOIC CAN transceiver that you like. Or you can find one of many preassembled CAN transceiver breakout boards from a variety of resellers; some also offer isolation which could be important depending on the application.

As a side note:
Something that could be neat for a next Saleae Logic product is to provide a 5V (current limited) power output at the flying leads. This would mean us users (or Saleae) could develop extension boards for adapting such signals that the main hardware does not natively support. While it is still possible to do this with the existing platform, we would still be faced with supplying power from somewhere else. So for very low power transceivers such as CAN, this would be a more elegant solution.

2 Likes
#6

@Jonathan Thanks for the idea on a current limited power output. No promises, but this is definitely something we’re thinking of for next-gen hardware. Ideally, we’d love to simply support a wider range of voltages and protocols out of the box without need for external hardware (perhaps in the form of completely adjustable voltage thresholds, wider supported voltage ranges, etc).

2 Likes
#7

So if we are wish listing here: differential inputs (completely fixes CAN and other similar stuff), input attenuation (to extend the analog input range - 20V would be good, 50V would be great).

#8

Thanks. We’re keeping this in mind as we brainstorm new hardware!

I just added your ideas below: