DIY OBD2 Dongle

>>1038233
So wait, why aren't you just using chink shit? It costs literally 8 dollars and works fine.

>>1038234
I think he likely wants to access a single feature of OBDII.

OBDII functions as an address specific information system. If you isolate the code category like you would an address on a network, you can use the output as a simple readout for one particular dataset. IE, if you only want to know the coolant temperature, you isolate the address output of that single piece of information and you can then feed that to a digital output to replace a gauge.

I'm assuming this is why he wants to break down the design.

>>1038239
OP here; this is what I am after. Pins 1, 3, 8, 9, 11, 12, and 13 are Make/Model specific and I would like to be able to perform custom processes.

>>1038233

You're out of your league if you have to ask this. But I'm obligated to help at all times, apparently.

Odds are you can simply buy one and have it do what you want via software. The all-in-one models made for every (or almost every) protocol (which is pretty much all of them) do nothing but provide a link from your phone/computer to the car. The host device tells the reader what information to look at, and the reader spits the data back at the host.

Additionally, if this is insufficient for some strange reason, it's almost certainly going to be easier to make one from scratch rather than reverse-engineer an existing one. It's just a low-end microcontroller with a USART attached to a bluetooth radio. Find the datasheet on the protocol you wish to interface with and have at it.

>>1038246
I don't know where you'll find it, but what you're looking for might be found as "Model, OBDII map"

I did a few for earlier Mercedes models, but I had the proprietary technical data for that from work, so I'm not sure where you'd find what you want on the internet.

>>1038248
I get what he wants, I've seen a number of vehicles with an OBDII passthrough, with certain pins branched off to allow for particular information to be piped to other devices.

For example, a common one is an OBDII passthrough on sprinters that merely tells a third party reversing camera when the vehicle is in reverse, etc so it can be active or off.

Thanks, folks.

>>1038248
>The all-in-one models made for every (or almost every) protocol (which is pretty much all of them) do nothing but provide a link from your phone/computer to the car. ...

>>1038249
>I did a few for earlier Mercedes models, but I had the proprietary technical data for that from work, so I'm not sure where you'd find what you want on the internet. ...

I dunno a whole lot about them, but I thought this was how they worked:
You can read all the codes with a bare arduino-style CANBUS shield--but the catch is that without the manufacturer/model/year-specific support docs for the car you are reading, you don't know what many (any?) of the codes mean.

>>1038346
>you don't know what many (any?) of the codes mean.

There are regulatory (EPA) requirements that a basic set of data be provided in a standard format. This is relatively easy to access and there are dozens of data items available, even on older OBD II compliant vehicles.

The OBD/CAN standards allow for vendor specific data channels (pins), protocols and data formats. It is this that you might have trouble getting info on.

Obd2 and nmea2000 are electrically compatible, but the data is obviously very different. I managed to read a lot from my cars port by using various nmea/rs485 gear borrowed from work. Look into Actisense, they might have something that'll do the trick.