Interpreting CAN bus data from OBD port

arduinocanobd

I'm using an Arduino with MCP2515 and MCP2551 to read data from a CAN bus over the OBD-II port of my car, Honda Jazz 2012. From what I've read on other forums and the OBD wiki, I can transmit the PID query to the engine over CAN ID 0x7DF and should be receiving the data on 0x78E.

I'm transmitting the data in the format described on the wiki:

Number of bytes|01|PID|0|0|0|0|0

The data I'm receiving doesn't contain data from CAN ID 0x78E or any ID nearby. Also even if I'm not sending data to the CAN bus, I'm still receiving the data, so using that I tried to remove noise, but it seems all the CAN IDs are broadcasting all the time.

So, I sampled some STN1110, OBD-to-UART interpreter, and tried to tap the connection between STN and the car ECU. It appears that the STN has a CAN ID of 0x18DB33F1 and the ECU is transmitting the data queried over CAN ID 0x18DAF110. I've put some of the data here: https://goo.gl/zTTIkk.

Do I need to assign my circuit an ID manually. I believe it's done automatically, otherwise I won't be getting any data.
How do I interpret this data? Is there a way or I'll just have to go with reading more data and making sense out of it, removing noise little by little.

I have read that there is a gateway between the OBD port and the CAN bus, so to access data from the bus, I'll need to pass the gateway. How?

Best Answer

It appears that the car ECU was a bit old and it uses raw can instead of diagnostic can. I changed the car and everything is working as it should.

Related Solutions

Electronic – What do chips like ELM327 and STN1110 do

PIC Microcontrollers (and others) contain hardware serial blocks for speaking OBD/CAN protocols. You can buy a PIC yourself and implement the protocol engines, which amounts to programming the register space, clock dividers, handling interrupts etc. If you are then sending the data to a PC/mobile you also need a UART and transmission buffer.

This becomes quite a lot of work if you are making an adapter cable - hence the popularity of off-the-shelf OBD-to-UART adapters such as ELM327/STN1110. They are both PIC chips (ELM327 is implemented on the PIC18F2480, STN1110 on the PIC24HJ128GP502) loaded with software that does rx/tx buffering, filtering, power management etc.

Microchip has reference designs if you want to design your own:

AN738 - PIC18C CAN Routines in 'C'                                     05 Nov 2001
AN853 - PIC18XXX8 CAN Driver with Prioritized Transmit Buffer          09 Sep 2002
AN816 - A CAN System Using Multiple MCP25050 I/O Expanders             04 Nov 2002
AN873 - Using the MCP2515 CAN Developer?s Kit                          02 Sep 2003
AN877 - DeviceNet™ Group 2 Slave Firmware for PIC18 with CAN           06 Oct 2003
AN916 - Comparing CAN and ECAN Modules                                 05 Mar 2004
TB078 - PLL Jitter and Its Effects in the CAN Protocol                 15 Jun 2004
AN930 - J1939 C Library for CAN-Enabled PICmicro® Microcontrollers     16 Jun 2004
AN733 - Using the MCP2510 CAN Developer's Kit                          27 Jul 2004
AN878 - PIC18C ECAN C Routines                                         28 Feb 2005
AN228 - A CAN Physical Layer Discussion                                16 Sep 2005
AN713 - An introduction to the CAN protocol key features.              16 Sep 2005
AN754 - Understanding Microchip's CAN Module Bit Timing                16 Sep 2005
AN945 - A CANopen Stack for PIC18 ECAN Microcontrollers                12 Oct 2005
AN247 - A CAN Bootloader for PIC18F CAN Microcontrollers               15 Dec 2008
AN1249 - ECAN Operation with DMA on dsPIC33F and PIC24H Devices        13 Feb 2009
TB3017 - dsPIC30F CAN Interrupt Management                             27 Feb 2009
AN212 - Smart Sensor CAN Node using the MCP2510 and PIC16F876          04 Nov 2010
AN215 - A Simple CAN Node using the MCP2510 and PIC12C67X              08 Nov 2010

Electrical – OBD-II bus – emulating the car side

I've done this recently, without needing an ODB-II "simulator" device.

Grab yourself an Arduino CANbus shield and the associated DB-9 to ODB-II cable, and hook it into a car. Write up some code to read CAN messages and transmit them out via serial. Dump this data from serial to a file on your computer. You can then invert the process and transmit the CAN messages over serial back to the device, in a loop, to simulate the vehicle idling.

If the device under test just passively listens into CAN messages, you may need two CAN shields: one to loop the transmission, and the other to actively receive the messages on the other end, while your device under test hooks into the CAN lines in the middle. I'm not sure why this is necessary, but it was for me; the transmitting CAN shield would not initialise the transmit buffer unless I had something explicitly "accepting" the messages at the other end.

Related Topic