OBD Serial Data

[82MKII]

BK_,
awesome work again!
I've been looking at your dump of running engine data and your decoding of it. Is my summary below correct:
1. first few rows, the engine was warm (ie had been running for a while) ECT = 167F = 75C
2. It is started in row 5 (STA flag)
3. It idled at about 900rpm up until the ECU terminated cold start (in f11 row 12)
4. It proceeded the warm up (to 179F = 81.6C) and the idle speed came down to 700RPM

If this seems correct then I have a few questions:
a) why do you want to shift ECT right by 1? If you just take the value & convert it to deg C it looks correct
b) I think the RPM scaling is more like f04 x 14 = RPM. This gives about 900 RPM during warm up and 700 RPM once it is warm.
c) I wonder why injector time (f02) is not 0 when the engine is not running?

Regards

Peter

[wilbo666]

I think RPM resolution is 50rpm / bit...

Cheers
Wilbo

[amichie]

Hey guys.

I'm following three threads on Toymods at the moment and they are all making great progress. This one on OBD another on injector sizes and the last is on Homebrew.

keep up the good work guys. The longer I wait the less work I will have to do next time I try this OBD stuff. More time for drinking homebrew.

[stevevp]

I have some qbasic code I was using with a max232 on the MX83 7MGE ecu back in 2002 to convert and display on a laptop running Dos - the only thing I didn't have is the mapping of what each field meant.

I'll fish it out if anyone wants it

[bk_]

wilbo666,
Hmm... I highly doubt serial communications would use variable length words. Otherwise 8N2 would have no relevance at all :) All my dump parser is doing basically is checking for 0xxxxxxxx11 and increments by 11 and checks again. I think the first word (or field) is a start character marker. Total guess since it does not change.

82MKII,
I made the mistake of not mentioning the state of the engine (eg: temp, rpm). Also made a few mistakes (more like total guessing!) in how to interpret a few of the fields. Engine was cold (~33C), rpm went to ~1750, then ramped down to 1250 rpm until my data logger stopped. (heh, looks like I'm still suffering from the weird idle issue, but a little bit less so, bleh).

this is what I can confirm:
1) word[03] (start from 0) is IAC step, initial step is 125 which matches toyota documentation.
2) word[04] is RPM, and needs to be multiplied by 25.

I'm totally lost when it comes to ECT... it cannot be in F or C since it makes no sense. Which means a conversion table is needed since it's not linear either! I'm guessing it is an inverted value from the ADC. that is: 5V minus reading_from_OBD. My initial value is 1.72V which looks close to 35C or so. interesting to see it warm up straight away ;-)

The injector value is unusual aswell... why it is non-zero before starting is confusing. Maybe it has to be non-zero for engine to actually start and then run? :-)

I've updated the (two) txt files... the dump is a little bit better formatted, and the known word values are converted.

Anyone know what the official and/or measured injector duty time and ignition timing at idle (~800 rpm) for a 1jz-gte? that would greatly help to understand what format is the value.

Next "major" step for me is to program the PIC to interface with an LCD and view the numbers in real time. I'll see if I can do that in the next few weeks if I have time.

-BK.

[wilbo666]

wilbo666,
Hmm... I highly doubt serial communications would use variable length words. Otherwise 8N2 would have no relevance at all All my dump parser is doing basically is checking for 0xxxxxxxx11 and increments by 11 and checks again. I think the first word (or field) is a start character marker. Total guess since it does not change.

I agree, but the data I collected seemed to show that to me...at anyrate it isn't that important

Most uarts will check to see that the stop bits are both 1's and if they aren't will bin the data, so that is why it might not be an issue. Still as long as you did find the same as well! I suspect you are right in it being a sync / preamble type packet.

The injector value is unusual aswell... why it is non-zero before starting is confusing. Maybe it has to be non-zero for engine to actually start and then run? :-)

Anyone know what the official and/or measured injector duty time and ignition timing at idle (~800 rpm) for a 1jz-gte? that would greatly help to understand what format is the value.

-BK.

The injector value is what the ECU is going to use...it isn't a measured value!

I think at a guess the inj value will be around ~2msec ...

Cheers
Wilbo

[82MKII]

BK_,
ah - a shame about my data interpretation - just completely wrong!
I think I'll have to knock up some hardware to look at the data stream to figure out the ECT field.
Can you just confirm all I need to do is:
a. bridge the necessary connections on the check connector
b. Sample every 8.192msec
c. Look for a series of at least 16 1's
d. record the data stream (163 bits)
e. Do b,c & d again

I though timing for a warm 1J was 10 deg btdc

Regrds

Peter

[wilbo666]

BK_,
ah - a shame about my data interpretation - just completely wrong!
I think I'll have to knock up some hardware to look at the data stream to figure out the ECT field.
Can you just confirm all I need to do is:
a. bridge the necessary connections on the check connector
b. Sample every 8.192msec
c. Look for a series of at least 16 1's
d. record the data stream (163 bits)
e. Do b,c & d again

I though timing for a warm 1J was 10 deg btdc

Regrds

Peter

BK_ prbly has a better idea but this is what I think...

a. bridge the necessary connections on the check connector
b. Sample every 8.192msec (SAMPLE_TIME...assume BK_is right with this value! )
c. Look for a series of at least 16 1's (Assume BK_ is right )
d. wait for the start bit (line goes low), then sample the next 8 bits (wait SAMPLE_TIME / 2 to get to the middle of the bit and then sample SAMPLE_TIME for the rest, then check to see if the stop bits are correct (if the data wasn't in the format "0--------11 [start, bit, bit, bit, bit, bit, bit, bit, bit, stop, stop] then data wasn't right!)
e. If at any time over 16 1's (Assume BK_ is right ) are detected go back to d. (this is to re sync if required...)
e. Do b,c & d again

Sound OK?

Pretty well what I did (except I checked for the 5 bit and 4 bit words....)

Cheers
Wilbo

[bk_]

wilbo666,
you're nearly right... but I'll clarify the preamble bit:

If you've counted atleast 11 1's and until it is pulled low, you can consider the line as idle. The way I would do it, when I will get onto the next stage using LCD as output, is to use a 2 byte (16 bit) buffer and shift each bit onto it until bit10==0 and bit01==1 and bit00==1 (if shifting to left from LSB), and there is your serial frame. Once you've detected it, flush/clear the buffer and repeat. If you hit 16 bits, consider the whole dataset as invalid/corrupted. heh. Or alternatively, maybe use a serial driver with ability to set baudrate to 110-122 with ability to check if line is idle - little bit easier than doing it emulated... ;)

also, the 163 bits includes the preamble and start/stop bits.

timing is 8.192 mS, I verified it with a 16 bit timer with minimum resolution of 1uS :-)

I've updated the text files yet again, and added a new one:
http://lasthop.ca/~bk./pics/toymods/...engine_hot.txt

I think I had IGN and INJ mixed up. Now it all looks more or less correct, identification wise. I hope the INJ value is right. unless it's too high? :) Only things left are the flags...

82MKII,
Can I ask how did you measure the ECT? ie: setup. Your numbers look pretty much spot on compared to the toyota values I used for interpolation, with only one decimal point for voltage! surprised it's less accurate on the low end of the temperature scale.

voltage, 82MKII(measured), BK(interpolation)
0.41V, 90C, 89C
0.51V, 80C, 79.5C
0.72V, 70C, 69C
0.96V, 60C, 58C
1.36V, 47C, 44.7C
2.12V, 27C, 26.2C

Only thing now to determine is the MAP values... 1.88V (96 in decimal) looks to be 1 atm or ~101 kPa. Toyota documentation describes non-turbo MAP so I could not use the table with sample values. Anyone know if the maximum voltage on MAP sensors is 4V or 5V? And if it's linear for both positive and negative relative atm pressure? A sample MAP graph (pressure vs voltage) would be nice!

Also, stupid question: how to calculate injector duty cycle?

-BK.

[82MKII]

Thanks Wilbo/BK_.
Now all I have to do is find the time and get stuck into my pic development board again.

BK_,
I got the ECT by taking out both the gauge & ECU sensors, strapping them to a thermocouple, boiling the whole lot up in a saucepan & measuring the resistance of both sensors and the temperature.
I then calculated the voltage across the ECU sensor based on the fact it is fed with a regulated 5 volts through a 2k7 resistor. I'm glad it is looking like it is accurate!

Regards

Peter

[wilbo666]

mV Bar
2705 0.00
2851 0.08
2933 0.12
3458 0.40
4012 0.69
4104 0.74
4460 0.92
4492 0.94
4608 1.00
4655 1.03
4655 1.03

5000 1.0789
y = 0.0005x - 1.4211

Not sure how accuarte. Kudos goes to Manny.

duty cycle... (http://www.stealth316.com/2-calc-idc.htm)

injector time window (mSec) = 120000 / RPM
duty cycle = injector open time (mSec) / injector time window (msec)

Cheers
Wilbo

[bk_]

hmm... ignore my specific implementation idea - it's slightly wrong. How you implement it, is up to you ;)

thanks for the info wilbo666 and 82MKII. ;) I'll have to measure injector pulse width and MAP voltage since I have no idea what format is used by toyota OBD-I.

I've written a draft document (PDF format) describing the toyota OBD-I protocol. ( link ). It's more or less the same as the obd1.txt text file, but with graphical presentation of the bitstream and its layout. I'm not really happy with it so if you have any suggestions, corrections, flames, send them my way. :-) also, if something can be worded better, just tell me.

-BK.

[wilbo666]

hmm... ignore my specific implementation idea - it's slightly wrong. How you implement it, is up to you

thanks for the info wilbo666 and 82MKII. I'll have to measure injector pulse width and MAP voltage since I have no idea what format is used by toyota OBD-I.

I've written a draft document (PDF format) describing the toyota OBD-I protocol. ( link ). It's more or less the same as the obd1.txt text file, but with graphical presentation of the bitstream and its layout. I'm not really happy with it so if you have any suggestions, corrections, flames, send them my way. :-) also, if something can be worded better, just tell me.

-BK.

Tis excellent!

Might want to add that data is outputted on VF1 pin of DLC1 or DLC2 after bridging TE2 to E1 (in DLC1 or DLC2) into the PDF.

Hmm with revs being 25 * bit that means the highest RPM that can be shown is 6400rpm...pretty sure the 1jz can rev higher than that ...I think this might be an engine specific thing. I would have thought the 1JZ would have been 50rpm..?

What does yours read atm if you rev over 6400?

I also think that what you have marked as 'clock test' might be the information identifying what ECU / engine it is (so the tool knows how to interpret the data coming...)...

Also I realise that the notes are just that, but the number of words per dataset can change depending on engine, so perhaps add a note section that pertains to 1JZ-GTE...?

Cheers
Wilbo

[bk_]

Had a break from the OBD stuff... back into it again ;)

I'll clear up the information regarding Vf1 and ENG and DLC1/DLC2... I'll probably also include an image of both the plugs. And will note down that the information is specific to the 1jz-gte, aswell as incomplete, although 90% (or more) of the information would still be relevent for other engines.

with respect to RPM, I was surprised about the RPM being in multiples of 25 aswell. I guess it will just clip the revs beyond 6375 (25*255).... Or maybe there's a 9th bit stored elsewhere. You wouldn't want to be revving it that high when you're trying to diagnose a problem ;) Maybe they (the designers) did not envision revs exceeding 6000 rpm back when OBD-I was designed?

hmm... I think word[00] might be an identification tag. As for 'clock test'... the 4 bits after idle and before the first start bit... I'm guessing it's toyota's proprietary way of syncing the serial clock. Or it could be what you described. Would be very unusual to represent data not in 8 bits form.

I finally got my LCD working... after so much fun... here's an image:


I'll take back my comment that software UART isn't that more difficult - it was painful!

Noticed something "interesting" when disconnecting MAP sensor. word[01] changes a little bit. eg:
w/.. map sensor: w[01] = 1000 1001, w[05] = 0110 0000
w/o map sensor: w[01] = 1000 1010, w[05] = 0100 0000

Also finally convinced myself that w[05] (MAP) is not in volts... but rather in kPa, with an (offset) error, in my case being -5 (towards lean). Oh... on the topic of turbo MAP graph... one exists in h35.pdf, page 5. ;)

Next stage will be to convert values from binary to decimal... That's the _hard_ part ;)

Also noticed my microcontroller was getting out of sync after 30 seconds or so... not sure why... oh well. atleast my code detects the desync and does a resync. I might have to resync when the line goes idle every ~1.3 seconds.

Here's my todo list wrt figuring out the unidentified OBD data:
- determine ignition angle through empirical means.
- measure injector pulse width with microcontroller.
- feed oxygen sensor wire with voltage (0/1V) to falsify lean/rich condition. (engine=off)
- measure ECT with digital thermometer, to get a close-to-accurate ECT table generated from microcontroller. (FUTURE)

If anyone has more information, feel free to comment.

I'll finally conquer this mofo... eventually :-) unless someone wants to join in on the fun :)

-BK.

[wilbo666]

I'll take back my comment that software UART isn't that more difficult - it was painful!

Also noticed my microcontroller was getting out of sync after 30 seconds or so... not sure why... oh well. atleast my code detects the desync and does a resync. I might have to resync when the line goes idle every ~1.3 seconds.

I'm not sure what micro you are using, but have you looked into setting the UART settings for the correct BAUD?

The ability to get the correct BAUD will be dependant on the crystal you are using (heck it wouldn't be hard to change that to be able to use the hardware UART!)...

This page has a little BAUD calc that I've used b4... it is for atmels, tho I'm unsure if Pics etc use the same UART registers (or similar) BASCOM AP NOTE

The idea with the hardware UART would be that you would have the UART off, and poll until the first word arrived (the 4 bit one...), the Atmel UART can detect 5 bit words, so I'd turn the UART on after the first 4 bit word was detected, read the 5 bit word and then config the hardware UART to read the rest of the 8 bit words... (then turn the UART off again...).

Setting up an interrupt driven off a timer to detect the line idle state would also be nice; to reset / resync. I'd set it so that it was oversampling...

I'll finally conquer this mofo... eventually :-) unless someone wants to join in on the fun

-BK.

I'm trying to get organised to do some work on it

Cheers
Wilbo