automotive CAN access

[dan king]

I'm very new to CAN bus but wanted to know if something was possible. I'd like to design a tachometer for an automobile application where a tach signal is not available. I know I could connect an external transducer to read rpm independently but in my application the car's instrumentation cluster communicates via CAN to the ECU. I'd like to capture the gauge messages to do some signal manipulation, i.e. custom set shift light, red line warning ...

If someone has experience with this and could provide either some insight on the complexity of this, or even examples I'd appreciate it. This is a non-commercial project, more of a request from a family member and a chance to gain some experience with CAN.

Rgds and thanks in advance,

dan

[sjbaxter]

Dan,

Internal CAN buses in light road vehicles (Cars) carry messages which are formatted in proprietory protocols devised by the manufacturer of the vehicle and are not openly available. For this reason, and the liability issues that arrise if you attach a non-certified device into internal buses, it is really a non-starter. Even commercial automotive companies don't have access to these kind of CAN buses, unless they are involved in the development and test of the vehicle.

Thats why you don't find many products out there that will do this kind of thing. The ones that you can get are usually for racing cars, not road vehicles !!

However, if it is just tacho you are after, you can get this information through the diagnostic connector (DLC) via standard ODB/ODBII which uses one of a number of protocols (SAE J1979, SAE J1850, ISO 9141, ISO 14230, ISO 15765, KWP2000). The type of protocol used is dependant upon car manufacture/make/model and data appears on the connector in a number of hardware protocols (K-LINE, PWM, VPW, CAN).

CAN based diagnostics is only available on newer cars and is further complicated by the CAN messages being simple CAN or a layed protocol on CAN called 'Keyword Protocol 2000' which can also be used on a CAN bus.

Do a search on the web for OBDII and you'll find many projects and interface schematics/kit that will will get you started.

Hope this help...
_________________
Regards,
Simon.

[dan king]

Hi Simon,

Thanks for the quick reply.

The schematics for the car in questions show that the CAN bus for the instrument cluster is also directly connected to the diagnostic port. With this being the case, would it still be such a complex task since this would then emulate the commercial scan tools?

I've seen a lot of the commercially available tools for OBDII, but I'm not sure how I could then extract the tach info from that tool. I don't think they have outputs available.

It seems as though the car (Lotus Elise) uses the diagnostic port for distributing the instrumentation signals. I think, correct me if I'm wrong, that this reduces the risk and maybe complexity of the project. If this is the case, then I think I simply need the protocol info for the OBDII CAN diags ??

Thanks again,

Dan

[sjbaxter]

Dan,

If you have schematics, what pins in the 16pin DLC connector are used ? does the document you got the schematics from tell you the communication protocol ? if it is the service manual it should tell you.

I suspect the cluster is the gateway (message filter) to the outside world as the ecu powertain bus which contains time critical information (i.e. ABS, Airbag, Engine Sensors) will NOT be exposed directly to the DLC connector. The messages from the cluster will most likely be a limited subset of those found elsewhere on the vehicle (i.e. the powertrain bus).

Without a copy of the protocol standards, you will find it almost impossible to directly talk to the car. I would suggest you look at a low cost solution, i.e. ELM chips, which do the protocol stuff at one end and are controlled by simple RS232 commands. You can then connect a PIC to on of these via RS232 and get the PIC to process the results and do your gauge/LED thing.

I would reccomend getting your hands on an OBDII scan tool to confirm the protocol before investing time and effort in a solution.

here is a Elise specific link about this topic:

OBDII

and even more specific to your 'project':

Elise CANbus
_________________
Regards,
Simon.

[dan king]

Simon,

Again, thanks for the quick and informative response.

The connections are made to pins 6 and 14 on the diagnostic connector. They are called out in the schematics as also connecting to the IP (instrument panel connector) so i agree this is proably a subset of the entire message protocol.

I will review the elm links you provided and appreciate your input. After I digest the info I'll post more questions if thats OK. I don't want to be a pest.

Thanks again.

Dan

[iso9001]

If I were you I would double check that tie to the diagnostic port.

VERY VERY VERY few cars (if any at all) directly tie the vehicles main CAN bus to the diag port.

Instead they use seperate buses. A bus for the body, one for the powertrain (sometimes these are combined depending on the vehicle) but almost always the obd2/J1962 connector is a separate bus.

This way they can isolate bad scan tools or misc from effecting the vehicles network. Maybe run the vehicle at 125k/250k/1mb while the diag port (and most scan tools) are set to use 500k. The list goes on and on.

I'm sure that they all goto a central hub to be converted into different formats or speeds, but I highly doubt they are on the same physical interface as the rest of the bus.

Then again, we are talking an Elise so..... all bets are off on such a limited run vehicle.

[dan king]

Thanks for the warnings, but I am very sure the scan port is on the same bus as the instrument panel. I have the schematic for the car and it clearly shows the scanport CAN wires leading to the ECU and to the instrument cluster CAN terminals and nowhere else.

I admit it's a bit unusual but since the instrument cluster is the only other device on the CAN bus at that point, the rest of the car is direct connected to the ECU. CAN-- from the looks of it

From looking through several user forums on the Elise, it looks as several brave souls have already captured message frames that contain the info I'm looking for. I even have some of the addressing for the message ID I want.

I think I will attempt to use the microchip can tranceiver and a 18F part to scan and display various filter masks to see if I can capture the same information.

Rgds,

Dan

[tavioman]

[sjbaxter]

Dan,

Be cautious, if you connect a CAN node (PIC) to powertrain bus, I suggest you run the CAN controller in LISTEN ONLY mode. That way the controller won't be sending ACKs on the bus, which, if you are configured to the wrong bus speed will cause a deluge of error frames. That in turn may use sufficient bandwidth as to prevent vital powertrain messages getting onto the bus.

Any node connected onto the DLC connector SHOULD NOT be terminated with the 120ohm resistor between CAN_H and CAN_L.
_________________
Regards,
Simon.

[iso9001]

[sjbaxter]

The correct termination for CAN on the diagnostics connector (as stated in ISO 15765-4 'Diagnostics on CAN' Section 9.1.4.3.2) is a AC termination consisting of a 100ohm resistor in series with a 560pF capacitor between CAN_H <-> GND and CAN_L <-> GND.
_________________
Regards,
Simon.

[dan king]

This is exactly the comments I was hoping for. I'm sure all of your input has saved me hours of debug as far as bus terminations.

I intend to only read messages and not insert anything on the bus so your input re: acks and listen only is noted.

Thanks for all you insight.

Dan

[jma_1]

Greetings,
You might want to double check the termination requirements. If the protocol used is J1939 (specific bit rate, sampling, etc), the main trunk/bus is terminated with 120 ohm resistors only. The separate drops/branches are not terminated (extra capacitance on the bus greatly affects message sampling times).
Cheers

[sjbaxter]

jma_1,

Trust me, the spec I quoted IS the right one ... I work in the automotive diagnostics and test industry !

J1939 is only generally used on Trucks, Buses, Agricultural vehicles and diesil powered boats.
_________________
Regards,
Simon.