I may be a little premature here, but I think that I've figured out solved the problem of why the interface doesn't work on the 92 models.
My theory is that the ECU is sending the correct data, but the signal is being randomly corrupted due to electrical noise on the data lines. But I have neither the skills nor the tools to prove this. I reckon that it must have caused problems for Subaru too because it's fixed in the later models.
An electronics expert might be able to modify the interface circuit (or the ECU) to be less suseptible to this noise (if that's what the problem is). But I'm not an electronics expert, I'm a software guy - so let me explain how I came to this conclusion and how I've successfully managed to compensate for it in software. All the values below are fictional for the purpose of explanation and I have simplified things a little.
Let's suppose we want to read the data from memory location 1234 in the ECU memory. We send the command "78123400" to the ECU. The ECU should then respond with something like:
Code:
123456123456123456123456123456123456123456123456123456123456123456123456
The returned data contains the address "1234" followed by the data at that address "56" and this is repeated over and over until you tell it to shut up. This is what happens on my 94, and my 96 Legacy, and when accessing the TCU on the 92.
However, on my 92 ECU, the returned data looks more like this:
Code:
FB34C65F30561234561A005612348F123456C4545D12FC561234561CF4B310F456020F56
Some of the data is correct, some is corrupted in a random fashion.
So I first modified the software to discard data where the address was corrupted:
Code:
............123456......12348F123456............123456..................
But that still leaves us with the possibility of the data being corrupted as in the second result above where the data is "8F" instead of "56".
So I modified the software to collect several results and select whichever data value appeared the most popular. In the example above, the program would correctly choose "56" because that appears 3 times whereas the incorrect value "8F" appears only once.
To be honest, I didn't really expect it to work. But when I tested it, the results looked VERY good indeed. It's quite late now, so I'll experiment some more with it over the weekend.
I have two concerns with this technique. The first is that the program can't just read 3 bytes when querying an address. To get an accurate reading, it might need to read 30 or even 60 bytes. So it will take longer to read each address. This would have implications for anyone wanting to log data to sub-second accuracy - for example to calculate 0-60 acceleration. Surprisingly the program did not seem any slower than usual when I tested it, so maybe this isn't so much of a problem.
My second concern is how to handle a data value that really is constantly changing. The popularity test won't work in that case. I'll have to think on it some more, but it might be necessary for the IO routine to return both valid and invalid values. The top level program could then filter the data based on its expected value. For example, the IO routine only knows it's reading address 1234, but the top level program knows it's reading RPM, so it can filter out a reading of 6000 if the previous reading is only 2000 and the one after is 2100.
Anyway, it's 2:00am now and I need to get some sleep. But I am really happy that I have at last been able to get some sensible data out of the 92 ECU.
Phil.