An ECU scan tool for turbo and NA owners

[mikec]

I think the AT/MT identifier is being read fine on my 92 turbo... It reads as Off, which to me seems right as its labelled Auto Trans.

[IronMonkeyL255]

I'm going to try adapting this to work on a Palm OS 5 device........

Man, I'm not too bright to take on something like this my first attempt at Palm programming.


I am hoping to come up with something that can display some of these values and hopefully record for a short period of time so it can be imported to an Excel spreadsheet.

The only reason I'm doing this is because I don't have a laptop, but I do have a Palm Zire 71......

[Legacy777]

Oh I wanted to mention that the mt/at ident thing read backwards on all the turbo legacy ECU's I tested. So I think this 92 n/a ECU I have is backwards. It's very weird.

[Warp3]

Just finished building the cable today and once I got my laptop's power settings happy (cpu, display and fan to "battery saving" mode and suspend "off"), then turned on the parallel port (which apparently is disabled in the BIOS by default on my laptop), it fired up, found the ECU, and works great.

FYI: I'm running a Toshiba Satellite A10-S127 using a bootable CD-R (made from the ISO image file on vrg3's site) on a 1991 Subaru Legacy Turbo with 4EAT.

Some things I noted:
- My O2 sensor appears to be dead. It's holding a steady 0.31V at idle and no amount of throttle/load seems to make it leave the 0.31V to 0.33V range. This might explain some of my crappy fuel mileage...
- The TPS works backwards compared to how I expected it to behave (it reads 4.741V at idle, then goes DOWN with more throttle).

[vrg3]

IronMonkeyL255 - Basing this on a PDA would be cool, especially if the PDA has a backlit screen. But in the meantime you might consider trying to pick up an old used laptop... you can find them fairly cheaply if you look around.

Josh - Wait, I'm confused. It read backwards for you on every turbo ECU? I wonder if maybe it's the wiring that is different on turbos and non-turbos or something. I was pretty sure I matched the functionality of the transmission ID thing up to the Select Monitor's.

Warp3 - I'm glad it worked.

Yeah, the ECU biases the oxygen sensor signal to about 0.3 volts, so with an open circuit that's what it sees, at least with Hitachi ECUs. But usually it's the heater that goes before the sensor itself, so if you were testing without the engine being driven warm, it's possible that the sensor is still okay.

And, yes, our TPSes read lower voltages as the throttle is opened. They only changed to the more common setup when they switched to OBD-II.

[Warp3]

Yeah, the ECU biases the oxygen sensor signal to about 0.3 volts, so with an open circuit that's what it sees, at least with Hitachi ECUs. But usually it's the heater that goes before the sensor itself, so if you were testing without the engine being driven warm, it's possible that the sensor is still okay.

I thought about that, though, and checked again after the engine had warmed up (enough for the radiator fan to kick in as the coolant temp passed 200F) and it was still as sluggish as before. I need to get a passenger in there to watch it while I'm actually driving, though, so I can see what it reads on some WOT (i.e. open loop) runs.

Josh - Wait, I'm confused. It read backwards for you on every turbo ECU? I wonder if maybe it's the wiring that is different on turbos and non-turbos or something. I was pretty sure I matched the functionality of the transmission ID thing up to the Select Monitor's.

FWIW: It reads fine on my car (1991 Subaru Legacy Turbo with 4EAT and auto mode reads as "ON").

[vrg3]

Oh, in that case you're probably right that you need a new oxygen sensor.

Thanks for the data point on the tranny thing... Not that it's that important, but it'd be kind of annoying if it were wrong sometimes.

[scuzzy]

I'm itching to see the source code or any development made with the scan tool.

do you have any ETA to the release of the source code? I know you're a busy person, but I figure if the community could get ahold of the code - our fellow assembler programmers (whomever they may be) can work on modifications and enhancements.

[Legacy777]

I think the 92 ECU is just weird. My 90 ECU, and all the turbo ECU's were read correctly. However the 92 was read correctly by the select monitor.

[vrg3]

scuzzy - No ETA as of yet; I'll post it here as soon as it's ready though.

Josh - Huh. So you think if I just reverse the reading on 92 ECUs, the functionality will be correct?

[mikec]

My 92 Turbo ECU still reads properly (Off)... Or are you referring to 92 non turbo ECU's?

[vrg3]

Sorry, yeah, just non-turbo 92 ECUs.

[mikec]

Ok... I was starting to wonder if I had something weird going on with my car

[ultrasonic]

Just built a cable and tried vrg's scan tool for the first time. It works as described and I expect it will be a big help in maintaining and tuning my Sport Sedan. I did notice that the program was unable to read the ECE once, but I shut down the laptop, then restarted and rebooted. The only other issue is that sometimes I have to hit the enter key several times to acquire data.

I would have done this months ago but I'm normally a Macintosh guy. Only recently did my job provide me with a PC laptop, too.

Thanks again Vikash!

[vrg3]

Cool, glad to help.

It sounds like you may have an intermittent loose connection, or maybe that the computer is slow enough that the data transfer fails sometimes. Do you sometimes see the reading stop updating?

[ultrasonic]

I'll have to look into it more closely. So far I've only hooked it up on my way home from work. I'll have a chance to work on the car this weekend, I hope.

[Legacy777]

Yeah if you swapped things around for the 92 that would work.

I'd like to have someone with a 92 n/a try it, just to make sure things aren't messed up due to my swap, and the fact something is just different from the factory. I'd be curious to see if the 93 & 94's are the same way as well.

Anyone with 92, 93, & 94 n/a cars want to do some testing??

[vrg3]

Yes, please?

[IronMonkeyL255]

Crap.....

If only I had a laptop to hook it up to, then I'd help with my bro's '94 n/a wagon.

[scuzzy]

vrg3, if you could give me some technical information as to the read timing of pin 13 and the write timing of pin 1 on the port to th ECU?

IIRC, you write to pin 1; and pin 13 is an input-only pin on the parallel port.

I write in C, and I've got some libraries at my disposal that allow me to cycle the HIGH/LOW status of pin 1, and to read the status of pin 13

I just need to know the sequences and the timing.


if all you could give me was the sequences to read the ROM ID, I'd be tickled to death

[mikec]

You need to figure out where the ECU stores the bit that tells it whether or not to drive the factory boost solenoid, and add something to your scantool to turn it back on... Bloody car isn't cooperating with my attempts to get it running properly again (note to self: don't wash engine bay).

[scuzzy]

allright, I have some findings to report.

Since I'm such an impatient lad, waiting on vrg3 to update the scan tool; I decided to take a peek and see what this ECU talk was all about.

From todays adventures (I just cut my car off, 1991 Legacy Wagon 5MT NA), I can tell you a few things:

The ecu is NOT quiet:

By this I mean, the ECU does not sit there quietly on its diagnostic connector and wait for anything to be said - it's constantly talking. - vrg3, I know you already know this; I'm just sharing with the community all the gritty details.

By constantly talking, I mean - in absense of scan tool (or select monitor) or not, it's constantly sending data (I'll explain this in a second) down the line aimlessly all the time.

Here's how the communication works:

In computer land, Eight BITS (IE: a 1 or 0, ON or OFF, is a BIT) equal s one BYTE ( A, B, C , D are all individual BYTES, compromised of eight BITS)

The ECU has one transmit and one recieve line. there's absolutely nothing digital about it, it works on voltages (aka logic) by turning the voltage high (5 volts) for an ON bit; or turning the voltage low (less than 0.7 volts) for an OFF bit.

It takes eight bits to equal a byte; like I said. So this one transmit (to the scantool) line has to flip its voltages eight times to give us a letter (like the ROM ID)


It's not quite as simple as that, however. Recall vrg3 saying "TIMING IS ESSENTIAL" on his website? It truely is, this is why a scantool for our ECU will never work in a multitasking environment.

There is no BIT seperator (or BYTE seperator) to tell us when one sequence has ended and one has begun; well, other than TIME.

So the only way we can tell the difference between the letter A and the letter B when sent by the ECU is the bit (on/off) sequence, and the time frame that it occurred.

So take this string of bits for example:

1010101010101010

16 bits, 2 bytes total.

if we wanted to read the first 8 bits to get a character, yet we started one bit to the right of the left most number, we'd get a totally different character.

IE: we wanted: '10101010'
but our time frame error gave us '01010101'

two completely different characters.

It doesn't end there.

There's a timing sequence between bits. take this string of bits, for example:

11100000

If the ECU flips the transmit line to ON (the 1), and then after the 1 is another 1; it won't turn the transmit line to OFF (a 0 bit), rather, it'll WAIT on the line (keeping the bit ON)

we have to know the mean time the ECU waits to change states (aka bits) in order to determine what exactly was sent

For example, if we knew the ECU waits 250 microseconds between bit changes; well call this wait period a CYCLE; then this will happen:


At exactly 1000 microseconds, the ECU changes the transmit line from HIGH (bit 1) to LOW (bit 0) for 2 cycles (500 microseconds will pass)

at 1500 microseconds, from LOW to HIGH for 1 cycle
at 1750 microseconds, from HIGH to LOW for 3 cycles
at 2500 microseconds, from LOW to HIGH for 1 cycle
at 2750 microseconds, from HIGH to LOW for 1 cycle

we can read this as the ECU sending the bits:
0010001

if we're off by one cycle in reading this string of bits - we'll get the wrong character.

This is easy to assume; remember how I said the ECU is always talking?

We can send it a question, and it will respond, but it will immediately go back to talking on the line with unrelated data to the question; so it's VERY easy to get bits that don't belong to our question if the timing is just slightly off.


It's obvious how complex it was for vrg3 to build this program the first time around.


I wrote a small software application in C which allowed me to watch the state of pins 1 and 13 (send and recieve) on the parallel port as the bcbf scan tool TRIED (and mostly failed at some points) for communication;

It's output went like this (just a small summary):

PIN 13 CHANGED: AT 1117315719.273121 STATE: LOW
PIN 13 CHANGED: AT 1117315719.325465 STATE: HIGH
PIN 1 CHANGED: AT 1117315719.442751 STATE: LOW
PIN 13 CHANGED: AT 1117315719.505404 STATE: LOW
PIN 13 CHANGED: AT 1117315719.507988 STATE: HIGH
PIN 1 CHANGED: AT 1117315719.689370 STATE: HIGH
PIN 13 CHANGED: AT 1117315719.751082 STATE: LOW
PIN 13 CHANGED: AT 1117315719.753611 STATE: HIGH
PIN 13 CHANGED: AT 1117315719.755153 STATE: LOW
PIN 13 CHANGED: AT 1117315719.755646 STATE: HIGH

the 'AT' denotes the time, '1117315719' is the time in seconds since epoch (a date in 1970); and '273121' is the time in that second of microseconds.

As you can see, the ecu communicates across the line very fast, sometimes less than a few hundreds of microseconds from the last state change.

microsecond: One millionth of a second (0.000001). Used primarily by lab equipment, GPS receivers, or other hardware.

These are some massive hurdles involved in writing a tool that can read this ammount of data; clearly we have the Subaru Select Monitor, and vrg3's scan tool; both are fairly limited (with the Select Monitor having more versatility, I assume).

Regardless, the limiting factor here won't be just the tool that we use to communicate, moreso the communication protocol, and the ECU itself.

The only thing I can reliablly say about that is that if you truely want data logging capabilities which will be error free (logging the data provided by the stock ECU can be prone to errors when the timing gets off); or if you want a stronger tool in general, research and invent in an alternative standalone or piggyback ECU.

Our stock ECUs simply were not designed to be pushed very far.


Recall that back in 1991-1994, Computers were little more than 100-133Mhz MSDOS or Windows 3.1 machines with barely any processing capabilities compared to today; any ECU you buy aftermarket for your subaru is going to be far superior in many ways compared to stock.


for the record, I've got an old Compaq laptop, 486-DX2 at 25Mhz, 12MB system ram, and a 238 meg hard drive which can successfully monitor the ECU using vrg3's scan tool.

Hope this information is helpful to anyone.

[mikec]

Wow! Awesome work

[nzKAOSnz]

crap.
so it has no relation to rs232 at all then? That would explain y the max232a chip wouldnt read anything.

hmmm. i think i need to dust off an old microcontroller, then use that to convert the ecu codes to a standard serial communications so it can be read inside windows, either usb or the rs232 port.

i would luv to get my hands on a portable oscilliscope.

[nzKAOSnz]

whats the fastest time between two state changes that you have come across?

so from what i read from scuzzy - there is just a continuous stream of data, with no seperation? then is there anything to use as a reference point?