Go Down

Topic: General CAN Bus Question (for OBD reading) (Read 125 times) previous topic - next topic


Jan 16, 2021, 04:04 pm Last Edit: Jan 17, 2021, 07:15 am by 450nick
Hi everyone! I have been working on an instrument cluster design for my car for a while now and part of my PCB and Arduino function (Teensy 3.2) is dedicated to reading the car's ECU OBD data to display to the user. To do this (as I'm away from my car right now) I bought a Can simulator: http://skpang.co.uk/catalog/teensy-obdii-canbus-ecu-simulator-with-teensy-32-p-1506.html

I then did some research and found that I needed to design a translator circuit to run between the Teensy CAN TX and RX pins, and the CAN Hi and Low wires from my car. I was recommended this configuration using an MCP2551 CAN controller. I built up a custom circuit board with this configuration and was able to read the OBD messages no problem from the CAN simulator so I then moved on to testing on a car at the weekend; two of them in fact, but wasn't able to read anything from either of them. I'm now trying to work out where I've gone wrong and after a little searching I'm reading some bits and pieces about ELM327 or STN1110 chips that may be better suited, and in fact the controller I have may not work with OBD (though it does with this simulator...??)

Can anyone help me understand what I've done wrong here, and if I should change my board design to incorporate an STN1110; does anyone have an eagle schematic that could help me understand how it should be configured like the above so I can update my board design and try again? Thank you!

I've done a little more research today and realised why I didn't use a STN1110 or similar (I built it a while ago!); the Teensy 3.2 has this functionality built in so just needs a CAN transceiver, so the use of MCP2551 in this role should be ok.

I just found out how to make a Hex dump to serial of what I'm sending and receiving on the CAN network from my Dash Pod. Here's what I'm sending (several PID requests followed by receiving several PID responses from the ECU simulator I'm plugged in to...

CAN SENT: 02010d0000000000
CAN SENT: 02010c0000000000
CAN SENT: 02015c0000000000
CAN SENT: 0201050000000000
CAN SENT: 0201460000000000
CAN SENT: 02010f0000000000
CAN SENT: 0201110000000000
CAN SENT: 02010a0000000000
CAN SENT: 02015e0000000000
CAN SENT: 0201420000000000
CAN SENT: 0203000000000000
CAN RECEIVED: 01410d4b0818fe43
CAN RECEIVED: 01410c196408fe43
CAN RECEIVED: 01415c8a00e00061
CAN RECEIVED: 0341058000e00061
CAN RECEIVED: 0141463500000000
CAN RECEIVED: 01410f3f4408fe43
CAN RECEIVED: 014111264408fe43
CAN RECEIVED: 01410a8400600061
CAN RECEIVED: 01415e027f600061
CAN RECEIVED: 014142397f600061
CAN RECEIVED: 02430000f9ffffff


I am not sure you did anything wrong. There are two types of OBD II diagnostic trouble codes: generic "P0" codes and enhanced "P1" codes. All vehicles use the same basic definitions for the generic codes, but the enhanced codes are vehicle-specific and may vary from one model year to the next. As far as being compliant 1996 or newer model year vehicle sold in the United States. United States legislation requires all cars and light trucks model year (MY) 1996 and newer to be OBD2 compliant. 2001 or newer model year gasoline vehicle sold in the European Union. 2004 or newer model year diesel vehicle sold in the European Union. Because OBD was found in cars manufactured before 1995, mechanics rarely have to deal with it anymore. This is good because OBD scanners were manufacturer specified, meaning one car brand, one OBD scanner. OBD2 is universal, and one scanner tool can support different manufacturers. You can also determine what type of OBD your car is by looking at the interface system. The OBD1 interfaces are different and completely different. The standard OBD2 interface is a 16-pin connector. OBD2 interfaces are the same, so if the interface has 16-pin connector, so your car is OBD2. I hope this helps you.
This response is to help you get started in solving your problem, not solve it for you.
Good Luck & Have Fun!


Thanks Gilshultz, I tested on a mid 2000s Jeep Wrangler and a 2017 Porsche Macan so both of them should be fully OBD2 compliant. I was requesting some common codes too (Vehicle Speed, RPM, Water Temperature etc). One query I had is on my approach of sending all requests in a burst followed by listening for any message responses. I'm not sure if this is the wrong approach but made more sense to me than sending one and waiting for a response then waiting again as this would slow down the overall code. 

The only other thing I can think of is that I was running at 500k baud. I've no idea if this is too fast or should be fine... It works without any issue on my test rig though.

Go Up