OBD Serial Data

[amichie]

Sorry to say I've not worked on this for about 6 months. Maybe a Xmas project.

[wilbo666]

Amichie/Wilbo,
any chance you guys could give us a list of what you have discovered to date?
ie
data rate
first x bits known/unknown
next x bits
...
VAF (x bits)
ECT (x bits)
Throttle (x bits)
...

Just list out any bits you are uncertain about and when one of us gets time we can have a crack at it. I'd like to think maybe a Picaxe would be good to decode this with.

Thanks

Peter

I am also useless and haven't looked at this for quite some time!

I would like to get back onto it one day tho...

Cheers
Wilbo

[bk_]

I've had a crack at this over the last week or so, especially tonight.

Bit rate is 8.192 mS. Determined this without oscilloscope :-) Ahh, the beauty of using microcontroller timers and interrupts ;)

The data output is interesting... I only discovered this like an hour ago. one data set is ~160 bits. however, it is not the same one after another. I did notice the data set did repeat _exactly_ every 8 data sets (every ~10.5 seconds). This was on a non-running engine. I only noticed this when I dumped ~50 seconds worth of data onto my microcontroller. Before that, I only dumped 4 seconds worth (just over 3 data sets) and wondered why each data set was different and set aside the project until I had other ideas, like tonight ;)

~160 bits / 122 bits/sec is about 1.3 seconds... more or less inline of ~1.25 seconds with the toyota technical documentation PDF.

I think each data set is encoded with some sort of obscure proprietary dodgy checksum algorithm. What it is exactly, I'll have to work it out from trial and error ;) I'm guessing it might be a combination of using 2 extra bits per data value, and/or, XORing a mask on each value, changing for each data set, repeating every 8 data sets. The really crap thing is that each data set isn't aligned with each other using my 8 1's delimiter idea so I need to put some more work into figuring out something.

I can provide my data dump and text-formatted data if anyone wants ;). I can also show the every-8-interval behaviour. I did this by delimiting the data at every 8 1's pattern (only thing guaranteed to be the same for each data set) and giving each line a number. Two lines had 2 set of 8 1's so that made it 10 lines (00->09) but still 8 data sets.

Once that is solved, everything else will be easy. I'm guessing the sequence of sensor data is the same order as listed in: http://translate.google.com/translat...&hl=en&ie=UTF8

-BK.

P.S. can the thread title be changed to OBD from ODB? :)
P.P.S. for anyone that remembers from a few months back, I finally solved my weird ~1800 rpm cold-start idle issue.

[wilbo666]

Sounds like some progress is being made

Looks like good work bk_

Cheers
Wilbo

[bk_]

OK. i can post up some data

a raw dump of the bitstream, 768 bytes or 6144 bits or ~50 seconds worth :), in bits (represented by characters '0' and '1'):
- http://lasthop.ca/~bk./pics/toymods/..._obd1_dump.txt

bitstream split into separate lines when there's atleast 16 1's:
- http://lasthop.ca/~bk./pics/toymods/...and_sorted.txt

Now that's better!!! looks like each dataset is 163 bits long

Let the analysis begin :-)

-BK.

[bk_]

Realized a big mistake I made :-)

I was reading the bits and dumping them from MSB, and shifting to the right, every 8 times. So basically the data turned out to be: (numbered in terms of bit sequence)
[7 6 5 4 3 2 1 0] [15 14 13 12 11 10 9 8]

Looks a bit borked, eh? :)

Now if I had dumped the data to LSB, and shift left, it would turn out to be:
[0 1 2 3 4 5 6 7] [8 9 10 11 12 13 14 15]

Looks better? :-)

I only did the MSB and shift right because that's how normal serial ports do it.

.txt files updated; .png files removed since they make no sense.

-BK.

[82MKII]

Top Work Bk_
I guess now comes the tricky deciphering bit.
I'm guessing it may be easiest to look for single data value changes first. eg Water Temp. From my playing with the ECU temp sensor on my 1J (took it out and heated it up in a pan of water) I have the following approximate values:
Temp Resistance Vsensor
27 2000 2.12
47 1009 1.36
60 642 0.96
70 455 0.72
80 309 0.51
90 241 0.41
FYI, the ECU sensor appears to be fed from +5v supply via a 2k7 resistor.
I'd be hanging a pot off the water temp line & having a play whilst the engine is off to see if you can identify where in the data stream the values are changing.
I'd like to have a shot at this - but I'll have to knock up some data aquisition hardware/software first.

Regards

Peter

[bk_]

OK. tip top news, guys.

Problem was my PIC code. I was writing to FLASH right after timer interrupt flag went high then once it finished writing, read/store the bit stream in memory. Basically the time for FLASH to write could not be guaranteed. Easy fix: store/read bit after interrupt flag and before writing to FLASH.

I finally got _perfect_ data coming through. Here's a link to the good data: http://lasthop.ca/~bk./pics/toymods/..._good_data.txt

The above file has throttle being slowly moved to WOT and back again. Max value looks to be '10100101', ie: 165. hmm... no idea what that represents... doesn't look like it's in BCD format. throttle is field 7 (count from 0)

Some more juicy info about the format of the serial transmission and its frames:
1) it's 8N2 transmission, ie: start bit, 8 bits data, 2 stop bits. in other words: 0, 8 bits of data, 1, 1.

2) from the looks of it, the data is in reverse form, ie: LSB on left, MSB on right, eg: [1 1 1 0 0 0 0 0] represents 7, not 224. That's how I made the LSB/MSB mistake in the first place. It's done _after_ you've stripped the start/stop bits, not before it :)

3) if the line is held high for more than 10 bits, then the line is "idle". when it goes low, that's the start of clocking. I think the long high->low->high->low is to say "this is start of the clock, and the length of the clock pulse". As per: '111111111111111101000'

4) start of clocking happens when the stop bits transition to start bit. ie: on the falling edge.

5) bit should be read in the middle of the clock pulse just in case cable length is too long, ie: 4.096 mS after initial falling edge of clock, and repeating at every 8.192 mS until next clock falling edge. Or just reset the clock just after the idle state. Or trust the timer to be accurate :-)

Now the only issue is figuring out what is what, and what format is the values. I'll have to get my LCD screen cranking aswell :-) will be much easier to figure out.

82MKII, Thanks for the voltage values for the ECT. Will come handy.

Think that's enough today for me.

-BK.

[amichie]

BK

Marvellous effort that, simply super stuff.

You have inspired me to have another go.

I'm certain that the Japanese engineers that developed this system would have just used a PC to read it out when they were developing the system.

I suspect you can read the data out simply by using a properly configured serial port with a TTL to RS232 converter. 110 baud is pretty close to the clock rate you measured.

[wilbo666]

Data: Samples 1136:2318 (Note: Leading and Trailing Idle State 1's added)
11111111111111111110100011100010110110101011100000 00001101011111011000000000110010001101100011111011 00000000011000000000110000000011100000000011011000 000110000100011111111111111111111

Formated Data: (S=Stop, s=Start, 1------8 = data)
-Serial Data
-1 Start, 4 Data, 2 Stop Bits (No Parity) x1
-1 Start, 5 Data, 2 Stop Bits (No Parity) x1
-1 Start, 8 Data, 2 Stop Bits (No Parity) x11

11111111111111111 110 10001 110 0010 110 11010101 110 00000000 110 10111110 110 00000000 110 01000110 110 00111110 110 00000000 110 00000000 110 00000001 110 00000000 110 11000000 110 00010001 1111111111111111111
SSSSSSSSSSSSSSSSS SSs 1---5 SSs 1--4 SSs 1------8 SSs 1------8 SSs 1------8 SSs 1------8 SSs 1------8 SSs 1------8 SSs 1------8 SSs 1------8 SSs 1------8 SSs 1------8 SSs 1------8 SSs 1------8 SSSSSSSSSSSSSSSSSSS
word1 word2 word 3 word 4 word 5 word 6 word 7 word 8 word 8 word 9 word 10 word 11 word 12 word13

Word 1 =10001 (5 Bits)
word 2 =0010 (4 Bits)
Word 3 =11010101
word 4 =00000000
Word 5 =10111110
word 6 =00000000
Word 7 =01000110
word 8 =00111110
Word 9 =00000000
word 10=00000001
Word 11=00000000
Word 12=11000000
Word 13=00010001

I recall that the data wasn't set word lengths! I might have been wrong on that however!....

wavefrom pic

Has anyone else seen that?

Cheers
Wilbo

[bk_]

It's good that I've got you guys motivated to try again :-)

I'm surprised that no one has sucessfully made their own OBD-I reader. Probably struggling just as we have :-) Or think that OBD == ECU fault codes and that's it. hmm, the techtom costs 47,250 yen. that's 513$AU! I wonder if there will be interest if I could produce a device (more like a trip computer with OBD-I support) for _way much cheaper_ than that. Comments? Thoughts?

wilbo666,
not sure about that graph. what was the frequency of the data points? 1mS? that should not be a problem, other than getting 8 or 7 of the same state every 8.192 mS. My data was a bit dodgy aswell due to timing issues. If you can guarantee timing, data output should be perfect.

amichie,
yes, it's possible to use a PC and serial port. However the baudrate is non-standard, the lowest "official" being 300 baud. It's much easier using the parallel port since it uses TTL anyway.

Just had a thought on the format of the throttle value. I think it includes bit 2^-1. so a binary value of 10100101 (LSB or MSB on right, does not matter for this example) can be converted to a readable value by shifting 1 bit to the right. eg: 1010010. which is 82... sounds about right for WOT throttle angle?

Looks like the last word also contains a bit on whether the throttle is closed or not.

Once I get enough information, I'll produce a PDF on the data format. Although it will only be 100% correct for the 1jz engine. But 99% useful for the other engines listed at the techtom site.

-BK.

[wilbo666]

That data was ripped from what i already had...but indeed I'm motivated as well...to some extent! lol

I'd like to get around to making some more progress on it soon...

From memory the sample rate was 1kHz (1mSec / sample).

The 4-5 data words will throw out your software uart unless you account for it....

btw rough work I did a long time ago on resolution / value meanings...

Page1 47.pdf
-fuel System Loop Status
-calc Load
-coolant Temperature
-long Fuel Trim
-engine Rpm
-vechicle Speed
-ignition Advance
-airflow
-throttle Position
-oxygen Sensor
-injection Duration
-iac Duty Ratio

Page3 47.pdf
-injector(x.xmsec)
-ignition(xxdeg Ca)
-iac Step#(xx)
-engine Spd(xxxxrpm) Res 50rpm(guess 256 * 50 - > 12800)
-vaf(x.xxv)
-ect(xxxdeg F)
-throttle(xdeg) Res - > 0.5deg(guessPrint )
-vechicle Spd(xxmph) Res - > 1mph(guess)
-target A / F L(x.xxv)
-target A / F R(x.xxv)
-a / F Fb Left(on / Off)
-knock Retard(on / Off)
-a / F Fb Right(on / Off)
-sta Signal(on / Off)
-ctp Signal(on / Off)
-a / C Signal(on / Off)

Page9 47.pdf
-injector(x.xmsec)
-igniton(xxdeg Ca)
-isc Step#(xx)
-engine Spd(xxxxrpm)
-airflow(x.xxv)
-coolant(xxdeg F)
-throttle(xdeg)
-vehicle Spd(xxmph)
-target A / F L(x.xxv)
-target A / F R(x.xxv)
-a / F Fb Left(off)
-knock Retard(off)

Cheers
Wilbo

[82MKII]

Great stuff guys!
BK_ - think the most useful bit of gear would be a '1JZ OBD protocol converter'. ie it reads the OBD data stream and spits it out as RS-232. That way you can feed it into almost anything (PC, another micro, handheld terminal, etc). I would hope this could be done with one of the small 8 pin pics & a max232.
I know I'd be keen on that as I would like to use the water temp, A/c state & vehicle speed as inputs to a thermofan controller. I'd prefer to read the data from a serial stream instead of directly measuring it.

Regards

Peter

[bk_]

wilbo666,
;) Throw out my software uart? It seems to be good now, after fixing the weird issues I had. just a matter of resynchronising it after each idle period. :-) When I calculated the timing, my 16 bit timer displayed ~10uS drift every second or so, so re-synchronisation is important.

82MKII,
the thermo fan controller idea is _exactly_ one feature I would like to (re-)implement. I currently have an analog controller for my fan. It works... but I'd like to control the minimum on/off and maximum on time. Another idea is to detect the PWM from the fuel pump wire from ECU and control the fuel pump relay with the PIC. Not a problem to code... just a matter of how to compromise any implementation so it's K.I.S.S. I'll see in the next month or so what can be done. A side project for extra money :-)

OK... did a little bit more work today... logged data before and during running of the engine.
Here's a link to the processed (and finally formatted to something readable) data:
http://lasthop.ca/~bk./pics/toymods/...b_on_right.txt

Here's another link to a preliminary guide on what all the words may represent and what format they are in. '>>' means shift right by X bits, or alternatively, removed bits are on right side of decimal point. Map sensor reading (VAF) I have no idea other than trial-and-error of calculations.
http://lasthop.ca/~bk./pics/toymods/obd1/obd1.txt - it also contains other notes so can be ignored.

Would be nice if anyone (wilbo666 :) can progress further on the analysis, and verify the results. Yes... it's in plain text... PDF can be done later :-)

-BK.

[wilbo666]

bk_,

You haven't seen any 4bit and 5bit words? You mention that all the data looks like 8 data bits...? (I think the first word is 5bits, then 4 bits and then followed by 8bit words..., format is 1 start bit, 2 stop bits)...I can send you my huge data dump which shows the same format repeating when I get home if that would help? (it would certainly help me if someone could either call me crazy or confirm that there are mixed word lengths...)

....I would have thought if you were only reading 8 bit words all the time it wouldn't sync very well...but you seem to be having no problem reading the data....

I'll try and get my crap up and running again... (need to reinstall laptop, might as well chuck the spare PC in the shed while I'm there...oh and I need to make room to get the car into the shed ).

Cheers
Wilbo