by DuaneM on Tue Mar 09, 2010 9:02 am
It's possible to use an SDL in this fashion but the process is cumbersome.
The simplest connection point is the OBD2 connector which is usually located under the steering wheel. This connector connects to the 500kBit/s CAN bus and will have as a minimum the designated OBD2 messaging protocol. In addition it often carries all of the normal CAN traffic from the ECU to the Gearbox ECU and other nodes on the CAN bus.
Firstly you need to ascertain which CAN data is available. This is best achieved using a low-cost OBD scantool based on the ELM protocol, which can show OBD information as well as raw CAN traffic. By logging the OBD and raw CAN traffic together you can see which OBD data channels (known as PIDs) are available, and also see correlations between the OBD data and the raw CAN data. This is not a simple process, but persistence will pay off with high-speed data for free. You should note that the vehicle manufacturer can allow or disallow any of the PIDs defined in OBD2, it's up to them which ones you can read. You'll almost always be able to read RPM, Speed, and possibly Throttle position, MAP, ET, and lambda voltages (not so useful as they may not be wideband).
The second task is to configure an SDL to collect the data you require. Collecting OBD data in an SDL is not possible as math functions are required to filter the OBD response messages and assign the data to relevant channel names. This is possible in ADL / ADL2 / ADL3 but not in SDL / SDL3.
However you can collect the raw CAN data once you have worked out where it is! This would require a CAN receive template to be set up for the SDL, which we can do for you, or you can do in the ADL manager software and we can port it to the SDL for you.
Clearly there's a lot of time involved in this process, as every vehicle seems to carry a different CAN messaging protocol. We are considering writing a tech note on this topic if enough interest is shown.