OBD-II (CAN) bus tool development

Continuing the discussion from Does Automotive have a OBDII scan / diagnostic tool? If not, can we get one?:

I’ve created this new thread for OBD-II home-brew development systems. Happy CAN bus hacking!

2 Likes

CAN analysis tools are easy to come by…Saleae Logic is a killer example. Is there a good source for the OBD protocol documentation though? I’ve never been able to find good solid docs on that without throwing down some bucks

1 Like

I have almost all the cables and software, also have a bluetooth wireless OBD-II scanner. Let me know if u need any help

1 Like

What limitations does it have? Or can you literally just plug it into any car?

(It’s my understanding that different manufacturers have different standards, especially along the European/American/Japanese split.)

1 Like

I have both a wired and Bluetooth scanner, can pull/read codes on just about anything along with resetting check engine light

2 Likes

For my learning, and when it comes to automotive, I have to work to make sure my ears/mouth utilization ratio is appropriately approaching unity. So let me ask some questions, help my understanding…

I think all the maxda stuff I did on Milly was OBDII. What is difference between OBDI, OBDII, CAN?

I think the ELM327 bluetooth scan tool I have is capable of doing any/all communication that any fancy pants big 1980s cell phone looking scanner can do, its a matter of having capable software it it that ‘knows’ the fancier operations (fancier registers). Am I correct? If no, what am I missing?

Pay close attention to “proprietary PIDs”. Most of what those 80’s-cellphone-looking mfg-specific diag tools do relates to what the auto makers won’t tell you.

1 Like

OK, sure. But the only thing that is possible through that port is digital communications. There are no analog measurements occuring through the port (A/D on scan tool side, measured quantity on car side). All analog measurements get made on the car side by a sensor on the car side, then they are reported to ECU, and the ECU data is read out over that digital port.

So, because of this, any device that can read/write appropriately across that port has complete access to all available information, should it know how to access and interpret it…

For this reason, the $8 ELM327 is all required to access everything, on all cars.

So this is all guesswork, where am I wrong?

To quote Star Trek 4:

“The sounds, but not the language. We would be responding in gibberish.”

1 Like

In Yodaspeak:

Understanding that answer, I am not…

Think of it another way; Ethernet is a widely-known protocol to connect computers. Even IP and TCP are well-defined standards. However, you can’t easily make the leap from “Well, it’s Ethernet” to “I should be able to write my own Skype client” if you don’t know the secret protocol that Skype uses between client and server.

OSI think: OBD-II is Link and Transport layers, with a little common set of commands at the Application layer so that Emissions testing machines can query the vehicle. There’s a lot more that Toyota, for instance, won’t tell you. Like how to flash new PCM / ECU code over the OBD-II connector, etc.

Spoken in plainspeak:

I am able to sniff packets on ethernet, and yes, it can range from difficult to impossible to interpret what is going on… I have unraveled difficult. I have never unraveled impossible. What separates the two?

Encryption. If the bits are encrypted and I don’t have the keys, I need NSA to crack the code. Otherwise, its usually not too tough to see what is going on. My guess is that Toyota encrypts certain transfer operations with keys only known to corporate folks. Other carmakers do the same for some important operations.

My suggestion, and mirrored on the other discussion, is to go ahead and grab one of the software suites for a genre of car that is helpful for us to have right now. Then let us LabVIEW inspired folk to play with it when not in use, sniff the port and see what we can/cannot figure out…

As far as I know, there’s no “encryption” on OBDI, nor II nor CANBUS.
You are welcome to sniff the stream.
The problem is there’s no protocol outside of the established calls/returns for OBDII compliance.
And there’s a shyte-ton of data flowing at any given time. Trying to sift through it can be cumbersome at best.
And all that only gets you to the point that you can READ the data.
If you want to write it, you’ll have to crack the no-standards-necessary methodology by which that is accomplished. Likely per manufacturer, possibly per application.

It is certainly doable. It’s done frequently by chip tuners. but I don’t know if it’s worth it to “you”.

1 Like

The ELM327 chip documentation and app notes are a good place to start to learn the OBD II CAN bus interface.

https://www.scangauge.com/support/x-gauge-commands/ has information about the addresses and scaling of manufacturer-proprietary information on the bus.

2 Likes

Indeed. And it appears that the full set of functionality for the Mazda that I worked on extensively with ELM327 was available through ELM327 and Torque app. I checked out the actron at DMS at it had same PIDs available. Exact sme functions available.

Furthermore, it appears that for that Mazda, the same set available via ELM327 and Actron is identical to set of data accessible via all of the SnapOn tools in their catalog. It seems Snap on advertises additional PIDs are available as add on package, but Torque has same add on capability, but jsut much, much cheaper, and only $5 for the original torque software. So from what I can tell from Mazda, we will get exactly nothing over and above what torque provides for the snap on money. Sad, but unfortunately true… (I think, prove me wrong…)

Here is a bunch of CAN stuff, mostly for electric vehicle conversions, but they have a few things for hacking CAN.

http://store.evtv.me/products.php?cat=28

Including one specifically for the Tesla Model S. http://store.evtv.me/proddetail.php?prod=TeslaCANKit&cat=28

I see the pushback, and I’ll agree with it, aside from these notes:

I worked on early 2000s cars, and for these I would venture that it would be foolish to venture much further than ELM. The hackaday article has only 1 point that makes sense on these cars: pin 1234 can be hacked as long as the car is on. And even that does not make sense unless you are driving around with jerk in your cab who wants to hack your car. Bluetooth serial is mighty quick for the sorts of data even available on early 2000s cars, and I would watch some 100 dials fluctuate in apparent real-time using ELM327-android Torque as though there was a hard connection. And considering my androind has GB of storage and connects to the cloud through wireless antenna, the storage issue is a moot point as well.

Now I recognize that most certainly newer cars are doing a lot more with OBDII and CAN, and I don’t have the experience to argue those points. But if a DMSer wanted to see what ELM did before spending $ on something expensive, give me a jingle and plug in one of the 5 or so ELM327s I have laying around prior to spending money over $10. The ELM327 is just a pass through, immediate bus to bluetooth data conversion, and faster than the car’s computer for all early 2000 models I worked on (Lexus, Mazda, Cadillac, Toyota, Nissan, Chrysler).

Also, my feedback is related to auto diagnostics/repair. But for these early 2000s cars, even if you want to put up cool looking displays, the data bottleneck was ECU, not ELM. And again, the password 1234 was only usable with key in ignition, switched to power on (therefore ELM327 on diag port now powered on).

But again, keyless entry cars, newer cars I dunno.

And one final comment: “you can’t change the software:” I call BS! With LabVIEW we absolutely can. And I know the C programmers can as well. The trick will be to understand all the manufacturer PIDs (which is carspeak for ECU registers). Installing a port monitor and watching while torque runs would tell you a lot, in addition to the resource @Jerry mentions above…

First, let me apologize ahead of time if I’m misunderstanding the general thrust of the contention here.

But if the posit is that because of all the EOBD stuff, use of the CAN bus, etc. that an ELM327-based device can’t pick up a complete set of information (including manufacturer-specific) that most modern cars put out, I can physically demonstrate next time I’m at the space that that opinion is for the most part incorrect. There are some (ok, more than a few) special cases where one or another pin has to be wired in a non-standard fashion; those special cases are typically well-documented in numerous forums and can be found fairly easily. The only real difficulty is finding genuine ELM327-based devices, as opposed to the ubiquitous knockoffs (or, at this point, finding a really high-quality knockoff – which is a reasonable possibility at this point, and in fact actually has some advantages over “real” ELM327 devices – some are based on some Atmel chips that folks have reprogrammed to provide even more functionality than the ELM327 emulators).

For a “purer” representation of what the car puts out, one may want to look at J2534 pass-through devices. Not really that much more than the “legit” OBD decoder chips out there.