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.
