Is my OBD-reader correct ?

Thread Starter

abtpad

Joined Apr 9, 2021
8
Hello everyone,
I'm trying to build an OBD interface to be able to read data from cars. The idea is to use an arduino and some cheap hardware to handle "low-level" protocols, and to get the arduino connected to a laptop, which will take care about the OBD2 protocol.
Based on some opensource projects, I designed this scheme (See the attached).
I'm planning to use https://github.com/iwanders/OBD9141 for ISO 9141-2 and ISO 14230-2, https://github.com/matafonoff/J1850-VPW-Arduino-Transceiver-Library for J1850-VPW and https://github.com/coryjfowler/MCP_CAN_lib for CAN, and so, I should be able to work with four protocols on five.
My questions are the following: Is that gonna work or not ? Do I have an error in my scheme ? Adding a circuit to power all the transceivers in 12v will it be enough ?
Thank you for reading :) !
 

Attachments

MisterBill2

Joined Jan 23, 2018
9,307
Do you have a specification for the amplitude and polarity for the OBD connection port? And if the laptop computer is going to handle the decoding and protocols why waste any effort on an arduino??
The very first thing to know when creating an interface is what you are interfacing to.
 

Thread Starter

abtpad

Joined Apr 9, 2021
8
Thank you for your answer !
Well, I'm not an electronics expert, but I guess amplitude and polarity depend on the given protocol. J1850-VPW won't have same as CAN for example. Here there are simple explanations about the five protocols : https://learn.sparkfun.com/tutorials/getting-started-with-obd-ii/all (Middle of the page). Why an arduino ? Because I have no idea how to do it directly with a laptop. The trick is that OBD is divided in two part : A physical protocol, (One of the five I talked about to be exact), and one "logical", built on top : OBD2. A bit like TCP is built on top of ethernet. I know how to handle OBD2 directly with the laptop since it's just about packets crafting, but I do not know how to work with physical protocols, which are encoding data within electrical signals. It seemed easier to do with an arduino than directly with a laptop, since you will have to use interrupts and stuff like that to encode data as electrical wave
But maybe (probably) I'm wrong...
 

debe

Joined Sep 21, 2010
1,251
Be interesting to see how you go. Some brand vehicles require specific readers. I use a cheap ebay reader thats ok on some vehicles after 2005.
 

Thread Starter

abtpad

Joined Apr 9, 2021
8
Your ebay reader is probably based on the elm327 chip. This chip is able to handle the five protocols, but is also a bit expensive when you buy it one by one. And you have to use the elm327-specifc protocol, so it's still not the perfect solution, even if probably the easiest one.
 

bwilliams60

Joined Nov 18, 2012
1,419
Maybe I am not understanding but why reinvent the wheel? There are literally dozens of cheap OBDII readers out there. Why go to all thr trouble of trying to figure out all the proprietary data etc needed to interface with these vehicles when it is already there? An EMLM327 is very cheap and easy to use. What is the end game on this endeavor?
 

strantor

Joined Oct 3, 2010
5,646
Maybe I am not understanding but why reinvent the wheel? There are literally dozens of cheap OBDII readers out there. Why go to all thr trouble of trying to figure out all the proprietary data etc needed to interface with these vehicles when it is already there? An EMLM327 is very cheap and easy to use. What is the end game on this endeavor?
I don't speak for TS but I've looked into doing the same thing, and my answer is, that an ELM327 only gets you so far. It can only access that information which auto manufacturers are required to make available at the OBD plug. Most of the information flying around your vehicle's miscellaneous busses is not able to be read by an ELM327. It's good for displaying engine load and RPM with the Torque app, troubleshooting O2 sensors, and checking DTCs (trouble codes). Some DTCs anyway, the ones that are required to be available for reading by a generic scanner. But every OEM has many more DTCs than those generic ones, and those proprietary DTCs are meant to be read only by a $xx,xxx scanner that only dealers are allowed to buy. And there is so much more to a car's digital ecosystem than DTCs, which again, is intended only to be viewed by a dealer. Want to change your transmission shift points? I'd like to see you do that with an ELM327. Want to tune your ECU for a new cam? Again,...

There are tools out there, other than the dealer's scanner, more powerful than an ELM327, and easier than starting from scratch with an arduino. I won't drop any names because I haven't used any of them but just Google stuff like "canbus hacking" and "_________(insert make of vehicle) programming software"
 

Thread Starter

abtpad

Joined Apr 9, 2021
8
Being able to read and write other things than standard information, like updating ECU software, would be just amazing, but right now I'm just trying to get something working. I thing this kind of modification will require the UDS (https://en.wikipedia.org/wiki/Unified_Diagnostic_Services) protocol, which is basically an OBD2 upgrade, and so, only supported on most recent cars. I found this implementation : https://github.com/openxc/uds-c, but I do not really understand what it does exactly because quickly looking over the code didn't show any SID or stuff like that
Anyway, can someone tell me about my design and the validity of the software chosen ?
 

bwilliams60

Joined Nov 18, 2012
1,419
@stantor, thank you for your reply and I do understand what you guys are doing. I am well versed in this area and like many others, I too have gone down this road and I can tell you that it is exhausting. OEMs have their code etc very well wrapped up and yes it can be hacked etc but it will take countless hrs and more than a cheap program or peripheral to crack that nut. I wish you all good luck and would love to see an end result but most people give up before they get there. You are correct, there are many aftermarket tools out there that do the work and they are worth every penny
 

strantor

Joined Oct 3, 2010
5,646
Anyway, can someone tell me about my design and the validity of the software chosen ?
Sorry I don't think my evaluation of your design would be worth your time to read, however if I were you, I would look at the schematics for this and for this, and compare to the design. They should point out anything you missed or got wrong.

I too have gone down this road and I can tell you that it is exhausting.
Heck yeah it is. I only ever got one foot into the rabbit hole. There were mental lights flashing and alarms sounding "danger Will Robinson," and "time suck ahead."
 

MrSoftware

Joined Oct 29, 2013
2,015
I skimmed so forgive me if I missed a detail; but generally speaking, if you want a relatively easy way to expand the OBD capabilities, get a basic CAN bus interface device to get you on the physical wire at the low level, then handle all of the OBD stuff in firmware on your arduino or even better on your PC. Google found this, maybe it would allow you to talk on the CAN bus from your pc. You could port some existing arduino libs for the OBD functionality, or there are probably existing open source libs out there:

https://www.seeedstudio.com/Serial-CAN-BUS-Module-based-on-MCP2551-and-MCP2515.html
 

Thread Starter

abtpad

Joined Apr 9, 2021
8
This is all very heartening...
@strantor, Sparkfun interface use an ELM327, so the schematic is completely different
@MrSoftware, the issue is not in OBD2 itself, but in the underlying protocols. I don't know how to handle them. And you are right, using directly a PC would be better, but it seems to be easier to use arduino as a "physical" bridge. If you know how to do let me know
 

MrSoftware

Joined Oct 29, 2013
2,015
If you get a CAN bus adapter with a serial interface, then you can use a serial to USB bridge to connect it directly to the PC, such as an FTDI. SparkFun has some on breakout boards for I think around $20 or less. I haven't looked at the protocol stack, but if you can get a CAN bus adapter that will give you raw frames to serial then the rest of the stack can be handled on the PC.
 

bwilliams60

Joined Nov 18, 2012
1,419
I hate to say it but this all looks far too familiar. I am sure you have gone down the road of Open Source Garage and CAN sniffing so I feel it a waste of time to mention it here. I believe anyone I know of that has gone down this road, eventually caved in so I do wish you well. Successful people are the ones that took the road less travelled and somehow found gold at the other end. Good luck with your project.
 

strantor

Joined Oct 3, 2010
5,646
This is all very heartening...
@strantor, Sparkfun interface use an ELM327, so the schematic is completely different
I don't know what sparkfun product you're referring to but it isn't either of the products that I linked to. Not sure why both of my links are now blocked? Did someone report my links as spam?? WTF? Let's try this again...



"SparkFun OBD-II UART - WIG-09555 - SparkFun Electronics" https://www.sparkfun.com/products/9555"
It provides you a serial interface using the ELM327 command set and supports all major OBD-II standards such as CAN and JBUS [...] STN1110 is an OBD to UART interpreter that can be used to convert messages between any of the OBD-II protocols currently in use, and UART. It is fully compatible with the de facto industry standard ELM327 command set. Based on a 16-bit processor core, the STN1110 offers more features and better performance than any other ELM327 compatible IC.
It has 2 different comms ICs on it, and neither of them are an ELM327.
  • Support for all legislated OBD II protocols:
    • ISO 15765-4 (CAN)
    • ISO 14230-4 (Keyword Protocol 2000)
    • ISO 9141-2 (Asian, European, Chrysler vehicles)
    • SAE J1850 VPW (GM vehicles)
    • SAE J1850 PWM (Ford vehicles)
  • Support for non-legislated OBD protocols:
    • ISO 15765
    • ISO 11898 (raw CAN)
  • Support for SAE J1939 OBD protocol
The OBD-II UART board has both the STN1110 and the MCP2551 chips populated on it, allowing the user to access both CAN and OBD-II protocols. The schematic can be viewed/downloaded here.
CAN-BUS Shield - DEV-13262 - SparkFun Electronics" https://www.sparkfun.com/products/13262
It uses the Microchip MCP2515 CAN controller with the MCP2551 CAN transceiver.


That first one (OBD to UART) is essentially what you're tying to build if I understand correctly. This is worth paying $50 for. I have one. It works. The rabbit hole of automotive comms busses is so deep, expansive, and shrouded in intentional secrecy, there are plenty of rocks to dash your head against. Don't spill your brains on the very first step. Do your self a favor, buy the thing, do the thing, and if you get bored later (you won't), come back and build the thing the way you want.
 
Last edited:

Thread Starter

abtpad

Joined Apr 9, 2021
8
Maybe reversing the STN1110 code is an easier way to go than re-writting everything from scratch ?
I quickly tried to decompile it, but the header start by "STNFWv05". Pretty sure there is an obfuscation layer cleaned by the uploader program when needed
 

Attachments

Top