Monday, October 4, 2010

Hacking Your Car

In this post I will report about my experiences and studies about vehicle electronics.


Last edited on jun 27, 2012



CAVEATS: I found that the generally available informations about this subject on the internet is quite poor and not very clear. While I am trying to do my best in verifying, errors and mistakes could be present.
Please feel free to add your critics and comments.

This is going to be a long term project, so this page will be improved over time.




Cars are complex
Cars are getting complex. Car electronics is really sophisticated, and current cars have dozens of control units for managing devices, sensors, and actions.


ECUs: Elecronic Control Units
The Control Units talk on local vehicle networks, which are similar to a common computer LAN, but based on different protocols.
ECUs, Engine Control Units, were the first to be connected to vehicles network, soon followed by others ECUs (generic Electronic Control Units).
To reduce the amount of signal wires among the many electric components of a modern car, digital communication protocols were introduced, and digital electronic interfaces between every electric device and the communication infrastructure.
The most important ECU is the Engine Control Unit.
Here is a non-exaustive list of Engine Control Unit manufacturers for cars:  BOSCH (example: EDC16),   MAGNETI MARELLI (example: 95160), SAGEM (example: 95080), SIEMENS (example: TMS374).

Here is a PDF file from the chinese company UIF Technology (a supplier of car electronics and diagnostic devices) with pictures of many Engine Control Units.


STANDARDS: a terrible headache
There are many standards defining protocols, signals, diagnostics.
Here is a probably incomplete and maybe wrong list
SAE and ISO are the most common standard and documents frameworks, but there are many others
SAE is the Society of Automotive Engineers.
SAE defines Communications Standard utilized in On-and Off-Road Land-Based Vehicles. In this schema 3 classes of communicating devices are explained:

CLASS A: up to 10Kbit/sec, multipurpose, asynchronous, used for non-realtime, smart sensors, wire reduction.
CLASS B: in the range 10Kbit/sec up to 125Kbit/sec, used for intermodule data transfer and non-realtime control. SAE J1850 is a CLASS B protocol, currently used for low-cost connectivity between nodes like instrumentation and diagnostic devices.
CLASS C: critical, high speed, realtime communications between device. For these needs, hi-speed CAN is currently used (up to 1Mbit/sec), but there are also faster alternatives, like Flexray (up to 10Mbit/sec, firstly implemented in BMW X7 X6 in 2008 see here).

SAE J1850 describes two different protocols: a low speed single wire VPW (Variable Pulse Width) protocol running at 10.4Kbit/sec and a faster two wire differential PWM (Pulse Width Modulation) protocol running at 41.6Kbit/sec. This is NOT CAN nor is it compatible with CAN.
VPW is classically used by GM (General Motors) vehicles.
PWM is classically used by Ford vehicles.

ISO_9141-2 is not a signaling protocol, but a diagnostic interface to check vehicle component functionality. It is a serial interface that runs at 9.6Kbit/sec. It is often available in OBD-2 connector.

ISO_11992 is a CAN bus used in trucks for communications between the tractor and the trailers.

SAE_J1939 is a set of specification based on an underlying CAN infrastructure, working with 29bit identifiers and usually with a bit rate of 250kbit/sec. This is normally used in trucks and industrial vehicles. It is a prerequisite for the FMS (see forward) system to work. An introduction to SAE_J1939 by Marcus Junger can be found on Vector site here. Other J1939 infos are on can-cia.org,. See also here, and here.
According to wikipedia, SAE_J1939 supersedes SAE_J1708 and SAE_J1587.

Here is a list of Automotive data buses, by Leroy Davis.


Vehicle Networks
Actually there are many vehicle networks, eventually based on different standards, different criticality, different protocols, and different communication speeds. Currently these networks are converging to the CAN standard, but there are many others. Since CAN is now the de-facto standard for vehicle networking, sometimes it is also identified as VDB (Vehicle Data Bus).
Despite its popularity, CAN bus is not the only network inside any modern vehicle, and in a single vehicle there are usually different networks (multiple CAN networks and NON-CAN networks).


CAN
CAN stands for Controller Area Network. It was originally developed by Bosch, starting in 1983. CAN is used in many automation environments and not only in automotive industry.

In a CAN bus all the communicating devices are connected to the same two wires, labeled CAN-High and CAN-Low. All the devices must use the bus at the same speed. At each end, the two wires are connected with a 120 ohm termination resistor. It is not required to have a common ground signal among the communicating devices. Bus maximum length is dependent from the operational speed, and at 1Mbit/sec is about 40m. Vehicle network bus speeds are usually below 500Kbit/sec. High speed bus vehicle implementation often adopt twisted pair wires.
In a normal situation, the two wires carry a two-level signal, perfectly specular, and whenever one is high the other is low. Here are two nice pictures (source: picoauto.com ) representing oscilloscope reading of the two wires of a CAN bus. The second image allow a clear understanding of the specular nature of the signals.



From these pictures, the different logical values of the signals can be read, and here each signal has a span of about 1V. In the upper picture, a full CAN packet transfer is visible. The overall packet transfer time is about 200ms (320-120).




Actual CAN bus voltages are not usually this neat.
Here is an actual example (this too from picoauto) (Voltage references seem nonsensical in this picture).



The CAN Protocol
Currently there are two main version of the CAN protocol
Standard CAN: 2.0A with 11bits identifiers
Extended CAN: 2.0B with 29bits identifiers
CAN is defined in ISO_11519 and ISO_11898.

ISO 11898-2 defines the high speed CAN, up to 1Mbit/sec
ISO 11898-2 high speed
ISO 11898-2 is the most used physical layer standard for CAN networks. It describes the bus access unit (implemented as CAN high-speed transceiver) functions as well as some medium-dependent interface features.
In this standard the data rate is defined up to 1 Mbit/s with a theoretically possible bus length of 40 m at 1 Mbit/s. The high-speed standard specifies a two-wire differential bus whereby the number of nodes is limited by the electrical busload. The characteristic line impedance is 120 Ohm, the common mode voltage ranges from -2 V on CAN_L to +7 V on CAN_H. The nominal specific propagation delay of the two-wire bus line is specified at 5 ns/m. All these figures are valid only for a 1 Mbit/s transfer rate and a maximum network length of 40 m.
In order to achieve physical compatibility all nodes in the network must use the same or a similar bit-timing. For automotive applications the SAE published the SAE J2284 specification. For industrial and other non-automotive applications the system designer may use the CiA 102 recommendation. This specification defines the bit-timing for rates of 10 kbit/s to 1 Mbit/s. It also provides recommendations for bus lines and for connectors and pin assignment.
ISO 11898-3 (aka ISO 11519-2) defines the fault tolerant (and lower speed) CAN, up to 125Kbit/sec
ISO 11898-3 fault-tolerant

An alternative form of bus interfacing and arrangement of bus lines is specified in ISO 11898-3 (fault-tolerant CAN). This standard is mainly used for body electronics in the automotive industry. Since for this specification a short network was assumed, the problem of signal reflection is not as important as for long bus lines. This makes the use of an open bus line possible.
This means low bus drivers can be used for networks with very low power consumption and the bus topology is no longer limited to a linear structure. It is possible to transmit data asymmetrically over just one bus line in case of an electrical failure of one of the bus lines.
ISO 11898-3 defines data rates up to 125 kbit/s with the maximum bus length depending on the data rate used and the busload. Up to 32 nodes per network are specified. The common mode voltage ranges between -2 V and +7 V. The power supply is defined at 5 V.
Transceiver chips, which support this standard, are available from several companies. The fault-tolerant transceivers support the complete error management including the detection of bus errors and automatic switching to asymmetrical signal transmission.


The preceding two quotes of text about CAN physical layer specifications are taken from here (fetched on dec 4 2010): http://www.can-cia.org/index.php?id=517
Also there are other physical layer standards.

The following section is shamelessly copied from Staffan Nilsson web page
(with some corrections)

-----------------------
ISO 11898-2 voltage levels  (CAN High Speed)










Signal recessive state dominant state unit
min nominal max min nominal max
CAN-High 2.0 2.5 3.0 2.75 3.5 4.5 Volt
CAN-Low 2.0 2.5 3.0 0.5 1.5 2.25 Volt

Note that for the recessive state, nominal voltage for the two wires is the same. This decreases the power drawn from the nodes through the termination resistors. These resistors are 120ohm and are located on each end of the wires. Some people have played with using central termination resistors (that is, putting them in one place on the bus). This is not recommended, since that configuration will not prevent reflection problems.



ISO 11519 voltage levels (CAN Low Speed)










Signal recessive state dominant state unit
min nominal max min nominal max
CAN-High 1.6 1.75 1.9 3.85 4.0 5.0 Volt
CAN-Low 3.1 3.25 3.4 0 1.0 1.15 Volt

ISO 11519 does not require termination resistors. They are not necessary because the limited bit rates (maximum 125 kB/s) makes the bus insensitive to reflections. The voltage level on the CAN bus is recessive when the bus is idle.


Bus lengths
The maximum bus length for a CAN network depends on the bit rate used. It is required that the wave front of the bit signal has time to travel to the most remote node and back again before the bit is sampled. This means that if the bus length is near the maximum for the bit rate used, one should
choose the sampling point with utmost care - one the other hand, one should always do that!

Below is a table of different bus lengths and the corresponding maximum bit rates.












Bus length (metres) Maximum bit rate (bit/s)
40 1 Mbit/s
100 500 kbit/s
200 250 kpit/s
500 125 kbit/s
6 km 10 kbit/s



Cables
According to the ISO 11898 standard, the impedance of the cable shall be 120 +- 12 ohms. It should be twisted pair, shielded or unshielded. Work is in progress on the single-wire standard SAE J2411.


-----------------------


CAN frames
Here are some informations about CAN data frames
the following picture is from http://www.jcelectronica.com/articles/CAN%20bus%20tutorial_2.htm
The Standard and Extended frames are shown, and the different address field length can be seen.





CAN reliability
CAN bus communications are usually very reliable, quite insensitive to external interferences (since external interferences affect similarly both wires, the difference between the voltages remains unchanged), and to single control unit fault. The devices can often work even in case of bus being severely miswired (one cable shorted to ground or to vcc). No need of a common ground also increases robustness. This reliability is among the properties that made it the current standard in difficult environments, with wide temperature ranges, and very varying environmental situations.


Detecting CAN
Since there are many wires, it is not easy to identify the proper ones.
0.CAN signals are usually not present if the key is not turned to power the dashboard. (It is normally not needed that the engine is powered).
1.CAN wires are usually twisted.
2.Checking CAN signal presence without the use of an oscilloscope: A simple test to see if the bus is operating correctly is to use a multimeter and measure the voltage between the two wires. In "perfect" situations, if the bus is active and working it will show a steady 2.5V or 0,5V (in absence of signal changes), or a quick alternance between 0,5 and 2,5V. If not working it will be 0V as one of the CAN controllers on the network is pulling the bus low (known as Bus Off).
3. Operating with a two channels oscilloscope, and using the subtract function between the two signals CAN-H and CAN-L, you should get a constant (because the two signals have opposite phases). Oscilloscope can also help in detecting the speed of the CAN bus signals. (will add details here).
4. An indirect CAN presence indicator could be testing for proper termination. Proper termination of a CAN bus can be easily tested with a multimeter: when the bus is not used, a resistance of 60ohm should be measured between the two cables (the two 120 ohms terminators in parallel at each side give a global resistance of 120/2=60 ohms).
5. As a useful tool for CAN detection check the Würth CANfinder device.
6. CAN signals could not be present where they should be (i.e. in the OBD2 connector) if a proper setting is not performed on the gateway device.


Interfacing with CAN
In term of circuitry, every device connecting to CAN bus usually interfaces via a CAN Controller, which in turn acceses the bus via a CAN line driver (actually a transceiver).


The CAN controller actually speaks with the device in some way (for example via a serial RS232 interface) and on the other Many manufacturers produce CAN line driver integrated circuits, for example Dallas Semiconductors/MAXIM MAX13050 or Microchip MCP2551.or Philips PCA82C250. or Philips/NXP TJA1054 

The following picture shows a generic CAN bus with some devices connected. Proper bus termination should be present at each bus end to damp electric signal reflection (echos). Also it is important to minimize length of the connection between the bus and the transceiver of each connected device (for minimizing undesired echo effects).









Modules are sets of ECUs
In a vehicle, a Module usually identifies a set of two or more Electronic Control Units.
Engine control being the first and most critical, the corresponding Control Units are the most complex. Engine Control Unit (ECU) is supported by Transmission Control Unit (TCU) and the two are sometimes referred as Powertrain Control Module (PCM). Transmission Control Unit, among other things, takes care of gear shift.

User related Electronic Control Units are often referred as a whole with the term Body Control Module or BCM .


Different Networks
The different criticality of the signaling among the vehicle electronic devices, created a push for insulating the networks of different modules, for security needs, but also due to different equipment interfaces being at different speeds.
These different networks are grouped in 3 main classes:
  1. Body Frame, requiring speeds up to 10Kbps (electric glasses, doors, etc,) [as example of BCM see later references to Peugeot BSI Built-in System Interface]
  2. Dashboard instrumentation, requiring speed range 50-125Kbps (instrumentation, air conditioning, etc.)
  3. Engine and powertrain, requiring high speed (up to 1Mbps)
    Some of these vehicle networks can also be non-CAN. There are other standards used in vehicle networks, like LIN (used for low cost, low speed, non critical use, see also here), FlexRay (used for high speed, critical needs, in BMW SUVs), MOST (Media Oriented System Transport) for multimedia and infotainment.


    Bus Separation

    Engine Control, Airbag, Braking subsystem, Speed control and ABS, are the most safety-critical systems, require high speed, and therefore are usually kept separated from less critical systems.

    The separation between the different CAN buses allow much more resilience of the critical systems in the case a noncritical control unit fails (the car engine still starts if you have a problem in the cd-player or in the cabin lights).



    Gateways between different networks
    In most vehicles, many CAN networks are there, operating at different speed, and that there are gateways allowing data being transferred among the different buses.
    The presence of these gateways allow filtered transfer of information, along with eventual speed change. A gateway could act as a firewall allowing only the propagation of specific packets. Gateways are actually electronic devices connected to more than one bus, and can be programmed to allow packet filtering.
    There is a interesting specification called Pass-Through SAE J2534-1 which is designed to allow a sort of common protocol (!!vendor and brand independent!!) for traversing in-between bus gateways (CAN and not CAN). This standard should be supported on all vehicles manufactured after 2004. Pass-through specification is targeted to reprogramming and re-flashing of individual electronic control units, but allows also read and write I/O, and periodic messages definition. There is also a set of defined APIs (Application to Program Interfaces) thru which the dialogue can be implemented.

    Here is the description of the SAE J2534-1 recommendation document, as taken from http://standards.sae.org/j2534/1_200412/ on sept 22, 2011.


    "This SAE Recommended Practice provides the framework to allow reprogramming software applications from all vehicle manufacturers the flexibility to work with multiple vehicle data link interface tools from multiple tool suppliers. This system enables each vehicle manufacturer to control the programming sequence for electronic control units (ECU's) in their vehicles, but allows a single set of programming hardware and vehicle interface to be used to program modules for all vehicle manufacturers. This document does not limit the hardware possibilities for the connection between the PC used for the software application and the tool (e.g., RS-232, RS-485, USB, Ethernet...). Tool suppliers are free to choose the hardware interface appropriate for their tool. The goal of this document is to ensure that reprogramming software from any vehicle manufacturer is compatible with hardware supplied by any tool manufacturer. The U.S. Environmental Protection Agency (EPA) and the California Air Resources Board (ARB) have proposed requirements for reprogramming vehicles for all manufacturers by the aftermarket repair industry. This document is intended to meet those proposed requirements for 2004 model year vehicles. Additional requirements for the 2005 model year may require revision of this document, most notably the inclusion of SAE J1939 for some heavy-duty vehicles. This document will be reviewed for possible revision after those regulations are finalized and requirements are better understood. Possible revisions include SAE J1939 specific software and an alternate vehicle connector, but the basic hardware of an SAE J2534 interface device is expected to remain unchanged."
    Check also this article by Dan DeMaggio from Drew Technologies: http://www.drewtech.com/support/j2534/intro.html for the story of the development of this SAE recommendation.


    Here is an example of a CAN bus dual interface gateway device: the CAN/CAN Gateway CG-ARM7, manufactured by EMS Dr. Thomas Wünsche: http://www.ems-wuensche.com/?menu=_prod&cont=datasheets/html/cgarm7_e


    Such a device is indeed a firewall with sophisticated packet content filtering and rewriting capacity.
    Here is a document describing a CAN gateway device in a Volkswagen Golf car
    The following two paragraphs are taken from http://www.my-gti.com/2296

    The role of the Gateway (also known as the Data bus diagnostic interface J533) is the exchange of data between the CAN data bus systems (‘powertrain CAN data bus’, ‘convenience CAN data bus’ and ‘infotainment CAN data bus’) and the conversion of diagnostic data from CAN data bus systems to K-cable and vice versa so the data can be used by vehicle diagnosis, testing and information systems like the dealer VAS tools and Vagcom/VCDS.

    For various reasons including power drain issues with third generation head units or the addition of new unsupported modules the CAN bus gateway must be upgraded to a newer revision. This guide covers the replacement of the CAN bus gateway in a 2005 MY06 Volkswagen Golf GTI. The upgrade replaces the 1K0 907 530 E (1K0907530E) with a 1K0 907 530 AA (1K0907530AA).
    Here is a picture of the Volkswagen/Audi gateway (part no: 1K0907530AA), taken from http://www.my-gti.com/1101

    This gateway in Volkswagen terms is called "Data bus diagnostic interface J533". It is used in many car models from this vendor. I found an Audi technical document (from Audi A5 owners group website Audi_A5_-_Networking_en_2.pdf) describing the 4 different version of this gateway component (differences are in terms of its interfaces), for different car models. It is connected to many different buses (different CANs, LIN, MOST). The document states that the "transport mode" can be activated on demand. I guess that this transport mode could allow  flow of information between the different buses thru the gateway itself (that in this mode acts somewhat like a router).
    Check also this webpage about J533 gateway.


    OBD: On Board Diagnostic
    Due to the progressive diffusion of electronic devices in the vehicle industry, also diagnostic procedures started to rely on querying these different pieces of electronics, for troubleshooting, and parameter tuning.
    The On Board Diagnostic (OBD) standards define how these diagnosis can be performed. Each Control Unit has a set of Diagnostic Trouble Codes (DTC) that can help in identifying its status or eventual failures.
    Actual diagnosis is performed by a technician connecting a probing device to a specific plug inside the vehicle, and performing analysis.
    In many vehicles, the OBD connector (currently usually compliant to OBD-2 standard) is within reach from the driver seat, and allows access to at least one of the vehicle CAN buses.

    Over the years, many different versions of the OBD standard appeared, and the most current one is labeled OBD-2 or OBD-II, which uses a female 16-pin (2x8) SAE J1962 connector on the vehicle. Here is the pinout of its female connector (from wikipedia).


    Specific gateway configurations could be needed so to allow specific Electronic Control Units traffic (filtering) to be available on the OBD-2 CAN interface. Also, depending on the manufacturer and model, CAN bus availability on the OBD-2 connector could require a specific configuration elsewhere (maybe jumpers in the circuit breaker panel).
    Being present in many vehicles, the OBD-2 connector usually allows access to many diagnostic signals. Sometimes more than one CAN bus is made available on the connector, on different pins.

    Here is the pinout of the FIAT OBD-2 connector: http://pinoutsguide.com/CarElectronics/fiat_car_obd_ii_pinout.shtml



    Some "rules" about the OBD-2 connector
    (info from http://www.auterraweb.com/obdiipinout.html and http://www.obd-ii.de/tech_conn.html )
    If pin 5,6,14,16 are connected, the pins 6 and 14 are CAN-HI/LOW (ISO_15765-4  /  SAE_J2284), while pin 5 is ground and pin 16 is 12Vcc
    If pins 5,7,16 and optionally 15 are connected, the connector supports access to ISO_9141-2 (aka KWP): pin 5 is ground, pin 16 is 12Vcc, pin 7 is ISO-data (aka ISO_K-line), as well as optional pin 15 which is older ISO_9141-2 (aka ISO_L-line).
    If pins 2,5,16 are connected, the connector supports access to VPW_J1850: pin 5 is ground, pin 16 is 12Vcc, and pin 2 is VPW-data

    If pins 2,5,10,16 are connected, the connector supports access to PWM_J1850: pin 5 is ground, pin 16 is 12Vcc, and pin 2 and 10 are PWM-data

    Connector Pins 1,3,8,9,11,12,13 (if connected) are used differently from different vehicle manufacturers, and the OBD-2 standard does not define their role.

    Contact usage of some manufacturers (table from http://www.obd-ii.de/tech_conn.html):
    PinSAE J1979,
    ISO 15031
    GMFiatOpelSaabIsuzuGM-LAN
    since 5.2002
    1Manufacturer mandatedsecond UARTABS, Brakes, K-LinereservedSaab Instruments (+)SIR (GM8192 Prot.)SW-LS-CAN (33kB)
    or
    DW-FT-CAN (+) (<125kB)
    2J1850 (+) PWM/VPWJ1850(+) VPWDW-FT-CAN(+)n/an/an/an/a
    3Manufacturer mandatedComfortAirbagK-Line, K2, TCM, Sunroof, CDL, Multi-Timern/aABS (KW81-Prot.)MS-CAN (+) (95kB)
    4Chassis groundChassis groundChassis groundChassis groundChassis groundChassis groundChassis ground
    5Signal groundSignal groundSignal groundSignal groundSignal groundSignal groundSignal ground
    6ISO 15765 HS-CAN (+)PCMISO 15765 HS-CAN(+)BlinkcodeBlinkcodeTCMISO 15765 HS-CAN (+) (500kB)
    7ISO 9141 K-Linen/aISO 9141 K-Line (engine)K-Line, K1 (engine)K-Line, K1 (engine)K-Linie, K1 (engine)n/a
    8Manufacturer mandatedCCMn/aK-Line, K4K-Line (Saab 9000/1, KW81/82 Prot.)n/areserved
    9Manufacturer mandatedfirst UARTBody ECUreserviertSaab Instruments (-)ECM/TCM (GM8192 Prot.)DW-FT-CAN (-) (<125kB)
    10J1850 (-) PWMn/aDW-FT-CAN (-)n/an/an/an/a
    11Manufacturer mandatedEVA Controller(Anti-Theft system)reservedL-Line Memory SeatsSIRMS-CAN (-) (95kB)
    12Manufacturer mandatedABSengine compartmentK-Line, K3, ABS, TC, Steering, RTD, OWn/aABSK-Line (KW82 Prot.)
    13Manufacturer mandatedSIRLuggage compartmentreserved f. K-Line, K5n/aECMreserved
    14ISO 15765 HS-CAN (-)E&CISO 15765 HS-CAN (-)reservedn/an/aISO 15765 HS-CAN (-) (500kB)
    15ISO 9141 L-Linen/an/an/an/an/an/a
    16Battery Plus, unswitchedBattery Plus, unswitchedBattery Plus, unswitchedBattery Plus, unswitchedBattery Plus, unswitchedBattery Plus, unswitchedBattery Plus, unswitched


    Accessing CAN bus in cars
    When CAN bus is not available in the OBD2 plug or it is not feasible to connect to that plug, or if the gateway is not "publishing" the CAN signals on the OBD2 port, the bus can be accessed simply connecting to its wires.
    But a disclaimer is needed:
    In most cases, car manufacturers are not disclosing the specifications of their diagnostic systems and there are no easy approaches that are consistant across the different brands. Even if you are able to access CAN signals, it will not an easy task to decode and understand the meaning of the data packets. Here is a guide (prepared by uk company Racelogic) in finding the right wires in different vehicles. Devices like the aforementioned Würth canfinder can also be useful.

    On Volkswagen Golf cars, the following wire color codes apply (from http://www.my-gti.com/991/performing-repairs-on-can-bus-wiring ). All the three CAN networks use cable pairs, and each pair can be identified by the color of the CAN-HIGH wire, being all the CAN-LOW wires of the same color.

    An unshielded two-wire line (1) and (2) with a cross section of 0.35 mm² or 0.5 mm² is used for CAN bus wiring.
    The colour codes of the CAN bus wiring are:
    Powertrain CAN high wire Orange/black
    Convenience CAN high wire Orange/green
    Infotainment CAN high Orange/violet
    CAN low wire, (all) Orange/brown
    On FIAT punto diesel, we found a CAN signal in the connector behind the radio. The CAN wires in this car are pink-black and pink-white.
    the following link describes a project to interface a car CAN bus to a wifi network:
    http://www2.cs.uidaho.edu/~oman/RTCS/Wood-Chroninger-project.pptx

    For Peugeot (/PSA and probably for cytroen) cars, check this site: http://peugeot.mainspot.net/ where you can find accurate information and Complete Wiring diagram for Peugeot307, along with information about BSI (Body Control: Built-in System Interface)
    Peugeot BSI is connected and "coupled" to Engine Control Unit, and there are protections to avoid tampering by non official dealers or auto-repair technicians. Here are a set of warnings related to Peugeot BSI-ECU maintenance: http://www.liontamer.net/forums/index.php/topic,3.0.html
    Here is a picture of a Peugeot BSI.
    Peugeot/PSA cars used to implement their own version of CAN bus, called VAN (Vehicle Area Network Comfort data VAN bus / Body Control Data bus). I found some clever guys who did some awesome job in collecting information about VAN: Graham Auld, and Alessandro Zummo. Check http://graham.auld.me.uk/projects/vanbus/index.html and http://code.google.com/p/van-bus/ I got to these sites via this webpage.


    Accessing CAN in trucks
    Specifically for trucks, there is another standard, to have a uniform access to vehicle data, and targeted for the needs of driving monitoring devices.

    This FMS (Fleet Management System) standard is very important for allowing access to specific truck information like the tachometer and odometer, which are needed to be read in the devices to control the driver activity (digital tachographs). FMS requires a SAE J1939 CAN 29-bit 250kbit/sec underlying standard.

    For european digital tachographs, check http://www.dtco.vdo.com
    In order to be compliant with FMS standard, truck manufacturers implement a specific gateway ECU which reads the informations required by the standard from all the suitable places and thru all the required standard, complying with internal vehicle-brand-specific protocols, and makes all these informations available thru a specific CAN bus to which the tachometer device is connected.
    In this way, an FMS compliant digital tachometer devices can be easily connected to any FMS compliant truck.



    Different connection cables

    (this section needs work and it is partially outdated by what I wrote in the OBD-2 connector section)


    A number of different ready made cables exist to access car diagnostics, usually via the aforementioned ODB-2 connector
    here is a list of their names, but I am far from understanding their differences

    SAE J1850 (can be a dual wire differential 41.6 Kbit/s PWM -Pulse Width Modulation-, or a 10.4Kbit/s VPW singlewire -Variable Pulse Width- ). see this intel document.
    SAE J2534 (this is a PWM protocol used in Ford, Lincoln, Mercury, Mazda vehicles)

    K-LINE and L-LINE (ISO 9141-2) (to be explained: i need to study)
    ISO 14230-4 (also known as KWP)

    PWM CAN
    HS-CAN (iso 15765)

    VAG-COM is not a cable, but a product by Ross-Tech. It is a diagnostic windows software for Volkswagen/Audi. Some cables to be used with this software are labeled VAG-COM

    ELM 32x are integrated circuits, (here is elm327 description), sold by elmelectronics.com and based on Microchip Technology Inc. raw devices. These ELM chips act as generic ODB2 decoders and are able to identify and decode many of the different signals available on the ODB2 plug, converting them to RS232, suitable for connection to a PC. Many different PC diagnostic software are capable of interfacing with car electronics via an ELM based adaptor, like this

    (To Be fixed)



    Arduino and CAN
    It is possible to interface an Arduino 2009 board with CAN bus, via a specific CAN shield
    I successfully used SkPang Arduino CAN-Bus Shield, to connect to an Audi A6 (2003) and I was able (using the provided sample application) to successfully read RPM (revolutions per minute) data from the engine using a polling mechanism.

    This shield uses a MCP2515 CAN controller and a MCP2551 CAN line driver.


    Here is a typical configuration of MCP2551
    We are currently working on improving the code provided with the shield so to have more sophisticated functions.

    Oct 2011 Note: As Rick (in an anonymous comment) said, Sk-Pang shield uses a library taken from Fabien Greif code ( here is the main site: http://www.kreatives-chaos.com/artikel/universelle-can-bibliothek ).The code can be improved, and I hope I will have some time to dedicate to this.


    OBDuino
    This is a project, started in 2009, to use a custom Arduino-like board to interface to car CAN-Bus and build a
    The project is described in this wikipedia page: http://en.wikipedia.org/wiki/OBDuino and the code repository, along with some pictures of prototypes, is in a google-code page, here: http://code.google.com/p/opengauge/wiki/OBDuinoInterface


    MPGuino
    This project is targeted to build a fuel measurement computer, with an Arduino like device, analyzing the impulses to the fuel injectors, and having tables for calculating the specific fuel injected basing on impulse duration. The signals have to be directly read/taken from the main engine ECU connections to the fuel injectors. Data appears extremely accurate. Here is the link: http://ecomodder.com/wiki/index.php/MPGuino



    Teltonika FM4200
    This is a device specifically designed to interface with FMS CAN interface in trucks.
    I am also testing this device, which uses a NXP LPC2368 microcontroller which is (incidentally) the same uc used by the mbed project. Here is some info about the microcontroller which includes a CAN controller (but not a CAN transceiver). The FM4200 circuits utilizes a Texas Instruments SN65HVD234D 3.3V CAN transceiver. I will write more about this device, as soon as I will have performed more thoroughful tests.



    CAN Bus data reverse engineering:
    For a Toyota Prius car, by Attila Vass: http://www.vassfamily.net/ToyotaPrius/CAN/cindex.html
    For a SAAB car by Tomi Liljemark: http://pikkupossu.1g.fi/tomi/projects/i-bus/i-bus.html




    General References and links
    The great CAN-CIA site: http://www.can-cia.org/ which is probably the best and more reliable reference site available.
    The CAN dictionary:  contains a definition of most of the acronyms and abbreviations.

    Staffan Nilsson's great page about CAN: http://www.staffannilsson.eu/developer/CAN.htm
    Bosch CAN 2.0 specifications.
    Mike J Schofield pages: (non working url: http://www.mjschofield.com/ - there is a mirror in Staffan Nilsson site)
    http://www.ixxat.com/can-controller-area-network-introduction_en.html
    http://www.jcelectronica.com/articles/CAN%20bus%20tutorial.htm


    CAN analysis and equipment vendors
    http://www.vector-group.net
    http://www.kvaser.com
    http://www.ems-wuensche.com : I bought an EMS-Wuensche CPC-USB/ARM7 with galvanic optoinsulation and lowspeed transceiver (TJA1054) for automotive. Received the object (2010.dec.10), and first impression is good: seems very well built and reliable. Will soon test it on the field.
    http://www.lawicel.com/
    http://www.peak-system.com/


    CAN bus in motorcycles
    Of course, also motorcycles electronic utilizes digital protocols.
    Here is a page about CAN bus in BMW motorcycles.


    An affordable and cheap Oscilloscope
    Actually I ordered this Rigol DS1052E, but I am still waiting the device to arrive.
    Will be able to report on its features, as soon as I evaluate it.
    Here are informations about the scope: http://marco.guardigli.it/2011/02/rigol-ds1052e-oscilloscope.html


    Software
    FreeDiag: http://freediag.sourceforge.net/
    FiatECUScan is a software for analyzing Italian made cars (fiat/alfa/lancia branded). Comes in free version and in paid version, with different features. http://fiatecuscan.net. Here is a list of the vehicles supported by current version of FiatECUScan.


    FAQ: Q&A 
    Here are some questions I received by email and the answers I sent.

    Q: Is it possible to read value of XXX connecting to the can bus of my car?
    A:
              As quick answer I would just say that it is not possible. 

    But this impossibility is normally not due to physical reasons. Each ECU manufacturer uses its own set of rules & codes to craft data packets on their vehicles networks. These informations and data formats are not readily available, and there are no shared rules followed by different manufacturers.
    Fm4200 is designed to be able to decode FMS CAN, which is a standard data format representation accepted and shared by all industrial vehicles (trucks). The target is to allow tachometer interconnect with vehicle dashboard.
    Tachometers are devices that in many countries MUST be installed on trucks so to monitor driver behavior and work activities. Since there are many tachometer devices, which are built and installed by many countries certified suppliers, a standard was needed, so FMS was born. Non-professional access to tachometer data connection is generally prohibited. 
    Thru car databus reverse engineering techniques, mostly based on trial and error and/or leaked informations, it is theoretically possible to map some of the CAN data packets to their meanings. Generally read only approach is safe. But problems could arise when vehicle software maintenance is performed, because data packet meaning could change, and current manufacturers are not expected to openly disclose these details. 
    Write access to the drivetrain and engine bus is to be considered critical and is generally explicitely forbidden or strongly not recommended. 
    For sure it could be great if all the data was understandable and accessible, but there are important security implications if people irresponsibly tamper with these things. Vehicle security, insurance coverage and road safety could be impacted. 
    So, be careful and play always on the safe side.
    My suggestion is to NEVER connect untrusted devices, unknown or potentially unreliable closed source software to critical systems. 
    Always study, learn and understand before playing. And always share responsibly your discoveries.

    Best,
    Marco


    ------






    Marco (@mgua on Twitter)



    .

    58 comments:

    marcoac14 said...

    Hello Mr. Marco Gaurdigli. First off I'd like to thank you for the detailed and interesting article. I already have an Arduino board and I'm considering buying a SkPang Arduino CAN-Bus shield. Initially I'm interested in reading RPM data. I know there are cheaper ways to read RPM, like from magnetic disturbance in 12v signal but it's not as precise as reading the CAN. Also, learning how CAN works may be really useful for future projects. My concern is that I need to read RPM from different vehicles without having to implement a new code to each car. Is it possible? Regards, Marco Correa

    Marco Guardigli said...

    I agree with you that best way to read RPM data is from vehicle digital body bus.
    On which car models are you working?

    I personally tested SkPang Arduino CAN-shield on on an Audi A6 car and it works exactly like is shown in the video in its website. It went smooth at first try, showing RPM and engine temperature.

    We tried it also on the
    Volkswagen Fox,
    Mercedes E270
    which are cars we have access to, and are equally equipped with OBD-2 connector, but on these cars nothing is output. The device turns on, power is present, displays works, but it fails to communicate with ECU, and does not read anything. We tried to tune the arduino code, and also studied carefully the MC Microchip library, but without results.

    Our current hypothesis is that CAN bus could not be available by default on OBD-2 pin 6/14 of these cars.

    We are going to test this hypothesis with the aid of an oscilloscope.
    I ordered a Rigol scope from DXExtreme, but after 2 months I am still waiting for it. (It seems that it is stuck in the customs somewhere and we are trying to release it).

    As soon as I will have more valid information I will post it.


    @mgua


    .

    marcoac14 said...

    Thanks for your reply. Actually, I'm not working on any cars now. But when I start my project it should be able to work on virtually any car compliant to ODB2.
    I'm not used to ODB2 and I've just begun to learn it.
    I didn't get why it doesn't work on VW Fox, which I guess is assembled here in Brasil.
    I'm also interested in that scope. I regularly buy many stuffs in Deal Extreme and it usually doesn't take that long to arrive.

    I appreciate your attention.

    Marco Guardigli said...

    I think that the reason for which Volkswagen fox CAN bus is not accessible is a setting of a gateway. It could be a J533-like device.

    Before ordering the Rigol scope I did some research, and it seems one of the best deals currently available. Unfortunately I am having the customs issue.

    Let me know if you are luckier.

    m

    marcoac14 said...

    But do you think there is a workaround for this issue using the same SkPang shield?

    Marco Guardigli said...

    At the current level of my research
    I do not think that the inability to access data is due to a hardware problem in the skpang shield.

    I could be wrong, but I am more inclined to think about a software or configuration problem.

    It would be nice to involve the guy who designed the skpang shield in this discussion.


    @mgua

    marcoac14 said...

    Hi Marco,

    I just sent an email to SKPang's support. Let's see if we can get this shield working.

    marcoac14 said...

    Sukkin from SKPang just replied me. He told me that he sent you an email yesterday in which he asks you to get a CAN-Bus analyser to look at the signals. He also said that he doesn't have access to VW Fox and Mercedes E270 and that they might now be fully ODB2 compliant.

    Marco Guardigli said...

    Yes, Mr. Sukkin sent me some hints, and definitely I will try them as soon as possible. I am back from a trip in the Balkans, and will leave on monday for Prague. Please do not expect immediate feedbacks.

    marcoac14 said...

    Don't worry!

    Nice to know you are going to Prague because I'm going there in february. You could give me a few tips. :)

    See you

    Helder Alves said...

    Hello Marco!
    You have compiled lots of CAN related useful information here. Congratulations! :)
    Do you know if it is possible to read other protocols besides trucks' FMS (e.g. Mitsubishi's or OBD2), using FM4200?
    Thanks in advance and best regards,
    Helder Alves

    Marco Guardigli said...

    Helder,

    To my knowledge the Teltonika FM 4200 device is able to connect to FMS compliant truck can-bus.


    In my opinion, other diagnostics coming from OBD-2 interface (whatever the protocol or pin) can be collected thru it, but an interconnecting interface is needed, so to bring specific information on one of the FM4200 analog or digital input ports.

    One of my colleagues in Latvia is working directly with a Teltonika guy who designs the firmware, so I could direct to him a more specific question from you, if needed. Let me know something more about your design.


    Marco (@mgua)


    .

    Larry said...

    Hello Marco.
    I am currently trying to trace the cause of a 00470 code on a 2005 Jetta. I thought that the VW/Audi gateway, the same as the one pictured in your article may have been at fault. I looked at the data on the Comfort System bus and both high and low looked OK, ie. there was no short in either line.
    This does not have directional headlights. I read on IATN that these could be an issue.
    I replaced the gateway today. I bought one from the dealer, but was unable to longcode it. I believe that it was because it has a trouble code. Data Bus Fault, I think it was.
    I checked the three power and two grounds at the gateway.
    I am using a Launch scanner which seems to be capable at doing the long code. I used a Vision II to look at the data signals. The CAN signals don't look very strong at the DLC as they do on the comfort system bus wires. I lost communication to the Launch at one point but it returned soon after so I was able to print out the Long Code data.
    I am lucky that the place where I work is allowing me extra time to solve this.
    The initial complaint was battery drain. I believe that the comfort system was not allowed to go to sleep. I also have an issue with the alarm horn which I found is drawing some current but I so far haven't been able to inplug it since it and it's protective housing is riveted to the body above the right inner fender liner behind the shock tower.
    So. I thought that perhaps you could give me some direction in how to diagnose this not just for this one time but for other times I might run into similar problems.
    Your's truly. Larry.

    Marco Guardigli said...

    Larry,
    I would
    1. disconnect the horn, then check again
    2. check the powertrain can signals
    3. check with ross-tech software for alerts

    Marco

    Anonymous said...

    Hi Marco

    I recently bought the arduino shield that is shown in this article. With it I downloaded some of the sample sketches shown on the SK Pang website.

    I always get compiling errors when trying to upload the code to the board. I have been through the code and have some posible errors, but nothing that seems to jump out at me.

    I must also state that I am no expert at programing. I am just doing this as a bit of side project for some university work. (I study at Oxford Brookes uni, doing Motorsport Engineering).

    Is it possible that you could email me the sketch that you used for your Audi and any library files you used?

    Any help would be greatly appreciated.

    Alex White

    Marco Guardigli said...

    Alex,

    The code should compile and run as it is.

    I suspect you could have a problem in including the NewSoftSerial library.

    Please check
    http://arduiniana.org/libraries/newsoftserial/

    "After you download the libraries, unzip them under your arduino sketch/libraries"


    Marco

    Anonymous said...

    Hi Marco. Thanks a lot for getting back to me.

    You were right! I can now get the program to compile and run!

    However, that has lead me onto my next problem. When connected to my car (2003 Citroen Saxo VTR) I dont recieve any data across the can-bus. I get to the screen 'Can init ok' and then can get no further. I have tried modifying the program quite a few times only to get the same result.

    Do you have any advice?

    Any input would be greatly appreciated!

    Thanks again.

    Alex

    Marco Guardigli said...

    Alex,
    Unfortunately I am not able to help you with a direct hint. You should check with an oscilloscope or with a CAN analyzer if there are the CAN signals on your SAXO OBD2 socket. It can be that CAN packets are absent unless some signal is injected in the car electronics via some Citroen tool. Re-read my notes about gateway devices. Try to get an oscilloscope or a CAN bus analyzer and check if you have CAN data on your OBD2 port.

    Marco

    Diego said...

    Hi Marco, I first apologize for not being into programming at all when I'm asking you the following: Do you think it would be technically possible to convert Canbus data to MIDI data thru the Skpang CB Shield and specific programming? Imagine a live stream of data where a single and identified event running non the Can is translated into a mapped MIDI event such CC or MIDI Note etc.. I know it might sound silly but i'll tell you this would be of great interest for some multimedia project i'm working on with the Plymouth UNI. As i can get from your discussion these opportunities are actually locked to the step of intercepting CB data.. I'm i right? Considering the Arduino abilities for MIDI do you think that a specific programming for the conversion would be a major effort? Thank you for your article a for your attention. Regards. Diego

    Marco Guardigli said...

    Diego,

    If I get it right, what you are asking is to traduce the reading of some variables accessible thru CAN bus in MIDI data. Of course this can be done, but we need to figure out

    1) what to read
    2) how to perform translation
    3) maybe how to "detect" specific events and perform predefined MIDI sound sequences.

    As an example, you could read the data from the engine route per minutes, and also the temperature of the engine oil, or the speed in km/hr. You could then build some translation functions between a variable reading and a corresponding MIDI output. You could generate sound of changing peak creating a correspondance between sound peak and engine RPMs. Or you could have brake lights generate some sound, and maybe have a music "beat" in time with windscreen wipers speed.
    Such a thing would not be easy to debug. And also would be a little risky.

    Feasibility and security issues nonwithstanding, I guess that you can find easier and funnier ways to generate music from reality readings performed by sensors connected to an Arduino.

    Your Arduino MIDI music box could easily read ligh, sound, temperature, humidity, vibrations, compass heading and if you desire even your kitchen sink water level, without having to mess with CAN reading.


    Marco


    .

    Diego said...

    hi Marco, Thank you for your prompt answer. I Got your point. The purpose of my project is to build an "augmented reality" UI experience on the vehicle, performing basically the same thing is done when you, for example, choose the Mac OsX to play a sound when a window is opened or the light level of the screen is increased etc.. Imagine that when you close the side window of the car or turn the starting key etc.. With this idea in mind any possible event running on the CAN-bus could be useful if not necessary. What i'm looking for is a shield/software tool allowing the Arduino to perform the CAN-bus to MIDI translation on a flexible mapping basis. I'm thinking about a tool where a common user is able on a friendly sw interface to route a specific CANbus event/signal to whatever MIDI event/channel he wants. So the example you did: "brake lights generate a sound or play a sample" it perfectly fits the point but this "relation" has to be mapped by the user without operating on the deeper lever of the arduino but on a specific mapping sw interface, so that the system is flexible and can grow as you recognize new logical relations between a car event and a distinctive sound event. I dunno if it's clear maybe it needs some more explanation. Sadly, I'm not even that much aware of typical arduino capabilities.. I do agree that readings could be performed by arduino sensors but i've got too many applications in mind that are strictly related to CANbus data. Sorry for my poor tech competences.. Could you possibly point me to someone who could be interested in help me further with this? thanks a lot..

    Marco Guardigli said...

    Diego,

    My opinion is that Arduino is not a sufficiently powerful platform to take care of efficient event to sound translation, neither it is able to directly drive a good audio output suited for your project.
    Arduino and CANshield could work as an interface to CAN, and maybe re-route on a bluetooth channel the data you are interested in, towards another application, maybe on a tablet or on a smartphone, that could perform sound mapping, drive an interface, a screen and so on.

    I suggest you to think and clarify your ideas as much as possible, before trying the implementation.

    Work to describe your project in a few lines, without too many technical terms, stating what you want to do, and which could be usage target.

    It is not a problem if you are not into hacking or programming, if you know what you want and how to explain it.


    enjoy!

    Marco


    .

    Anonymous said...

    hi don't mean to be ignorant but in an automotive application where does the voltage on the bus come from the modules or the fuse box?.

    Jurriaan Pijpers said...

    Thanks!
    This helps a lot!


    I just like to add one tiny little thing: You write about a BMW X7.
    As far as i know there is a BMW 7 series or the BMW x1/x3/x5/x6.

    Thanks again for the article!

    Marco Guardigli said...

    @Jurriaan Pijpers

    Thanks! You are right! it was BMW X6! Corrected.


    m

    .

    Anonymous said...

    The skpang arduino shield demo code doesn't setup and filters or masks on the mcp2515. On many german cars the canbus on the diag port get tons of traffic as soon as the key is turned on...

    I glanced at the code in the sk-pang example and it looks like it would not properly handle a bus with lot's of messages already on it.

    It seems like VW's diagnostic gateway keeps the obd2 port somewhat quiet compared to the car I tested on (2010 BMW). Hence the demo code worked on my vw, but not on my bmw... even though both are the same 500k 11-bit canbus and the commands and ID's ARE correct.

    It would be best to set a mask and filter in the mcp2515 (which, sk-pang stripped those functions out of the mcp2515 library they modded, so you would need to re-add them) to only allow messages from 7E8 (which the ecu will reply on) and then it will work on many more cars...

    Then there is the issue of 29bit vs 11bit. The sk-pang code assumes 11-bit id's are used... a 2010 honda for example uses 29bit id's and would need the code adjusted accordingly. An auto-detect function would be pretty easy.

    -Rick

    Marco Guardigli said...

    @anonymous Rick
    Thank you for you very interesting comment. I slightly updated the page to reflect your advice. Will take some time to delve into sk-pang code and make the changes you suggested.

    mgua

    Anonymous said...

    Marco,

    No problem... I've used the mcp2515 with AVRs for a while... I do obd requests much differently than skpang does.

    Basically I have 6-7 PID's that I ,by using a hardware timer triggered function, request at different intervals. for example, RPM would be requested 5 times per second, but I only request coolant temp once every 2 seconds. I then use an actual pin triggered interrupt handler (because the filters only allow obd responses) to parse each PID reply as it comes in. The interrupt is triggered when a message from 7E8(on 11-bit) passes the filters, then I just do a switch case on the PID response to parse it and save the updated variable to the globals for those sensor values. This way I can run whatever code I want in the main loop and canbus hums along in the background without missing a beat (and without halting the rest of my program to wait for an obd reply)

    The receive interrupt from the mcp2515 also works nicely to wake the AVR from sleep mode when canbus activity starts up...

    -Rick

    Eduardo Dodge said...

    i needed a can bus system for the electric car project. any suggestions of where i can find one?

    Eduardo Dodge said...

    i needed a cheap can-bus system for my electric car project, any ideas for where i can find one?

    Anonymous said...

    One subject oft the file
    http://www.mikrocontroller.net/attachment/126234/CAN_monitor_with_MAX32.pdf
    is a Volkswagen/Audi gateway which is connected with the Chipkit-MAX32 board.
    Best regards ...

    jose421tal said...

    Hi Marco
    Could you help me with this please?
    I have an audi A6 2400cc model 2004, engine code BDV.

    I have an engine failure , somotime ..when engine hot , doesnt start.

    I wanted to retrieve the DTC but
    The vag diagnostic does not comunicate with the ECM.
    I checked continuity from the vag connector to the ECM connector , found one wire going to the ECM. the second one does not .

    Thank you very much
    Jose

    Marco Guardigli said...

    @jose421tal

    I am sorry I can not help you on that. You guess you need to go to perform complete diagnostic with original AUDI diagscanner.

    Marco

    Debraj said...

    Hello,

    I made a new hack for my car to read the OBD information through CAN bus. Here is the web link for my project -->

    http://sites.google.com/site/hobbydebraj/home/can-bus-based-obd-reader

    It has description, hardware schematic, software description, code and demo video. How do you feel about this?

    Regards,
    Debraj

    Fessy said...

    Mr Marco, Does Peugeot 307cc 2004 has can bus technology or not?

    Thanks

    Anonymous said...

    I am in the process of sourcing LED lighting for automotive aftermarket applications. I see that many European applications require Canbus technology or the use of a load resistor to eliminate hyperflashing or burnt out bulb indications. Can Canbus bulbs be used in non Canbus vehicle applications with out adverse effects?

    Marco Guardigli said...

    @fessy

    Yes, Peugeot 307 of 2004 has CAN bus.

    Marco Guardigli said...

    @Debraj
    Wow! Your project is great! Bravo!
    I would suggest you to publish on your page a diagram showing all the connections, and also the future extensions you are planning, like the datalogging features on sdcard.
    Keep me informed!

    marco

    Anonymous said...

    Hi Marco,

    Great article. I'm considering an arduino based project to make an alternative multifunction display for my Peugeot 307 2003 to show speed, rpm, etc however I was of the understanding that Peugeot uses VAN and not CAN protocol - any ideas either way?
    Thanks, Trevor.

    Toan Nguyen said...

    Thanks Marco for great information on CAN protocol. Do you know the CAN ID of Transmission Control Module in Mercedes or BMW? Are the CAN id standard for all the car manufactures?

    Marco Guardigli said...

    @Toan Nguyen

    No, unfortunately I do not know the codes you are asking. I also think that they will be different, also within the same brand, depending of the specific ECU model and firmware used, which is different from model and model, and also changing over time.

    You can perform tests with an analyzer, and connect it in the right place to be sure to access the right bus at proper speed.

    @mgua

    Rob Weidner said...

    Hi Marco,

    I am just trying to read the basic can messages via obd2 or I can directly tap the can-h and can-l (eventually want to do that) of my 2007 VW Passat which does have CAN. I have an Arduino uno r3 and the can-bus shield mounted on it. Every time I mounted the shield on my uno my serial monitor would freeze up. I tried it again without the reset pin attached and it doesn't freeze anymore but I still don't get what I want.

    1)I read somewhere that you need to attach the reset of the can-bus to 5v. Is that true?

    I can't read anything from my obd2. Should I be running a specific program on my arduino? I tried the analogserialread and the serialcallresponseascii (which seems like the best option) and nothing gives me anything to work with.

    When I try and run the joystick demo with the fixed digitalwrite(up, high) etc... I don't get any serial response when I move the joystick in any direction...I tried changing the pins to the A1, A2, etc and that didn't work either.

    I replaced my atmega microcontroller that's on my uno because I thought I heard that short out when I tried to attach the simple 5v, gnd, canh, canl on the shield...Still nothing...

    I just need some direction as this is my first arduino/microcontroller experience.

    Marco Guardigli said...

    @Rob Weidner,

    Rob, as a first test, I would suggest you to power your arduino and shield with a independent power supply, and not using USB as a power source. Maybe your problem is related to insufficient available power.

    @mgua

    Sandip Padwal said...

    Hey Buddies,
    Thanks for all the info.
    I want to know about the pinout of CAN signals used in TATA buses MarcoPolo buses.

    Anonymous said...

    Hello Mr. Guardigli,

    I am very new to CAN-bus and have very little programming experience. I am trying to use sparkfun's CANbus shield along with the arduino uno micro controller to read the diagnostics(RPM, speed, etc)of my Toyota corolla. Do you have any suggestions to how I should go about doing this or where I should start because I am beyond lost on the subject.

    Thanks for your time,
    Jonny

    Anonymous said...

    Hello Mr. Marco Gaurdigli.
    do you know if it is possible to use CAN-BUS shield to make communication between arduino uno. and plc(programmable logic control )for automation .If you take in your account my own plc has can-bus capapilty already.

    thnx

    SKY said...

    hi,

    Thank you for the information you provide.
    I have a question.

    Is it possible to access other bus (comfort,infotainment)from obd2 connector?
    Does that make it the gateway (J533)?

    thank you


    Marco Guardigli said...

    @SKY
    yes, it should be possible, crossing the gateway device, but every car requires specific packets to be injected to "open the door".

    A polish company called Quasar Electronics produces and sells a interfacing box that is able to read several data from a set of supported vehicles. Depending on what you need, your car might be supported.

    Check http://quasarelectronics.pl

    @mgua


    SKY said...

    hi Mr. guardigli,

    Thanks for the quick response.
    Waiting for activation from Quasar Electronics.

    My car is Seat-Leon (my2012)

    have the information received from the "comfort bus".
    Is it enough to send diagnostic port this code?
    comfort bus is 100kbits.
    diagnostic canbus 500kbits.
    What should be the speed?
    also,
    for example;
    "open door" command is data-frame or remote-frame?

    promise, no more questions. :)

    Thank you again.


    Andrey Smirnov said...

    Hi, Marco. Thank you for the article, i found it very interesting. I'm interested in making device that will "sniff" obd2 traffic & send modified packages to another can receiver. is it possible to do it with CAN-BUS Shield for arduino from skpang? I assume i will possibly need two of them to use as a gateway, but was not sure if it can establish fully functional can line of communication.

    Thiagu's Irrelevant Thoughts said...

    Dear Marco,

    The article is awesome and it gave lots of clarity to me, as I am new to this field.

    I have two specific questions I would like to clarify.

    1. I am trying to use Teltonika FM4200 device to read the CAN data. But as I understood from this article, I might need another device to decode the data. Is this right? Since Teltonika does not tell anything about it in their manual.

    2. I have a Suzuki WagonR car. When I checked the OBD II port I found only 5, 7 and 16 are connected. From this, can I confirm that this vehicle does not use CAN?

    Thanks for the information in article and hope I could get some answer.

    Regards,
    Thiagu

    Marco Guardigli said...

    @Andrey Smirnov, sorry for late reply. Yes it is technically possible, and yes, if you need to perform can to can translation, you will need two serial interconnected arduinos, each with a can shield. Depending on the speed, and of your translation function computational requirements, it can be you would not be fast enough to keep on with the packet rate.

    @mgua

    Marco Guardigli said...

    @Thiagu

    1) Teltonika FM4200 offers a CAN bus interface capable of reading FMS packets over CAN. FMS is a CAN based standard that was developed for trucks.
    CAN is a network layer specification, like ethernet. You do not assume that every packet flowing on a network is obeying the same set of rules (i.e. protocol).
    Translation devices (like aforementioned QuasarElectronic's) allow translations from vehicle-proprietary-protocols-over-CAN to FMS-over-CAN, so that you can use FMS/CAN compliant devices (like Teltonika FM4200) to identify and process them.

    2) The fact CAN bus is not terminated in your OBD2 port does not mean your vehicle does not use CAN.


    @mgua

    Debraj said...

    Hello Marco,

    I did some more trials with OBD commands, this time, writing a python script to emulate ELM327, so that some android apps -- torque/ fun2drive would work..
    My project here: -

    https://sites.google.com/site/hobbydebraj/home/android-obd-scanner-hack

    Diego said...

    Hallo Marco,
    I bothered you years ago with some question on possible CANbus to MIDi conversion. The idea restarted to gain our interest. We prepared a basic note to explain it. The scheme is simple CANbus>OBDShield>Arduino>MIDIShield>PC+DAW software for sound generation.
    We are now looking for someone to seriously try to do the thing for us. Could you help me? How could I send you our note? Would you point me to someone skilled on this matter? Thank you for your kind attention. have a nice day. Diego

    Marco Guardigli said...

    @Diego
    Send me via email the note you prepared, as well as some description about the features you would like to build. I will check then reply to you privately. Also add a brief description of you and let me know where you are based.

    send it at my email mgua00atgmaildotcom

    mgua

    Anonymous said...

    Hello Marco, congrats for yr interesting site. You have explored a lot in car electronics.

    Maybe you can help me with this Project: I need to quantify fuel consupmtion in real time (by sampling) of my Mercedes Diesel car. It has a Electronic Disel System control unit (EDS N39) part # 012 545 45 32. I want to know if the output signals of this unit are pulses or continuous. I can send you many connecting diagrams but don´t have the internal circuit of the unit.

    Looking forward to yr help, José from Chile . jemazabr@yahoo.com.br

    Anonymous said...

    Nice article. I have a couple of questions about the J1850 PWM bus as used by Ford in the early 2000's:
    With the PCM module removed and the vehicle is probed with an ohmmeter from the PCM or DLC connector, what
    should the resistance D+ to D- be, and what about each wire to ground and /or bat+. I can find lots of information on the web about CAN wiring but not much about Ford wiring or SCP bus termination..