This is driving me nuts. I've got a 92. My laptop with serial on it has a dead battery and no brick so it's out of the running (would cost over $80 to get it charged), which leaves my laptop which only has USB. If someone can find me a relatively cheap way to connect this to my car, I would be way more than happy to test it out.

Originally Posted by http://www.obd2allinone.com/sc/toplevel.asp?cat=0

These serial adapters are sold with a disk that contains the software drivers needed to make them work. Buy one that can be returned in case it does not work properly on your computer, especially with the USB adapter. There are reports of compatibility problems with these USB to serial adapters, and they can be tricky to get working properly on certain computers. The USB adapter we have had the best reports about is the Belkin F5U103, and these can be found on ebay for $10 or less.

I don't understand what you mean about RS232 and TTL voltages being compatible.:

The TTL range is a subset of RS232.

Quote:

Originally Posted by b3lha

In the data sheet for the M377xx CPU, it specifies the "Absolute Maximum Ratings" for the inputs for the UART pins as -0.3 volts to Vcc+0.3 volts. Vcc being 5 volts.

Would it not exceed the maximum rating by a factor of over 100% if your PC serial port supplied a 12 volt signal to these pins?

If the serial port was supplying the maximum RS232 of 12 volts (or is it 15?), it would exceed the limit for TTL devices. However, computers are TTL devices, too. There is no reason to expect that a computers UART is boosting the voltages above TTL or native levels. This would require lots of extra stuff which would add cost and heat and the only reason to do it would be to opperate over long distances. (on the order over 1/4 mile)

If a device were to swing from +5 to -5 that would indeed be "legal" for RS-232. But as Phil said, the data output signal emitted by the ECU is standard TTL, 0 or +5 volts. Since it does not swing negative, that won't work for a "true" RS-232 device. Hence using the MAX232 chip (or similar) to convert to -12 and +12V RS-232 levels.

The standard does specify negative voltages, but it practice, zero is used. 'True' means nothing here.

This is driving me nuts. I've got a 92. My laptop with serial on it has a dead battery and no brick so it's out of the running (would cost over $80 to get it charged), which leaves my [other] laptop which only has USB. If someone can find me a relatively cheap way to connect this to my car, I would be way more than happy to test it out.

As Phil suggested, a USB to RS-232 adaptor will do the trick. Here's another one -- costs a little more but shipping is cheaper. Same place has another for $9 + shipping. You will find many more if you search the net.

You may also be able to find a +12V adaptor for your other laptop for less than $80. CompUSA just closed a bunch of stores across the US and probably had some (but it's a bit late in the game for them). This kind of thing frequently turns up in the clearance bins at the office stores. Also try eBay and your local Craigslist -- people kill their laptops and sell (or even give away) the still-perfectly-good power adapters and other accessories they no longer need.

I've been looking for a free laptop to use for this kind of thing. Doesn't matter if it has an old, slow processor or a battery that no longer holds a charge. It just needs enough horsepower to run a comm program. I actually want this to hack TiVos, but it would work to talk to ECUs too.

What this simple circuit adds are always on request to send and clear to send signals. These signal lines were incorporated to overcome a devices processing limitations. This became a non-issue around 1970 and are rarely, if ever, used today. Anyway, what this stuff does is defeat their purpose. Something akin to fingernail polish. It might look good and doesn't hurt anything, but serves no useful purpose.

Please have another look at their circuit diagram. I don't think the circuitry they have added is "fingernail polish".

There is no wire connected to pin 2 (receive data) or pin 8 (clear to send) of the PC serial port. It looks to me like they are not using the UART in the normal manner. They seem to be sending and receiving the data one bit at a time by directly accessing the handshaking lines.

You mean like this thing I found in the basement with my dad's old cables?

Great, what's step two?

EDIT: The laptop I have I actually got from Vikash for testing his Scan Tool software. But he gave it to me without the brick and with a dead battery (thus why I got it), and I haven't found an adapter for an OmniBook 4000CT anywhere.

I wanted to put the "92 problem" into context and explain how it affects the VWRX select monitor software. I may have given people the incorrect impression that this method of extracting data from the ECU doesn't work on 92's at all.

There is a problem on the three 92 cars that have so far been tried, but as Charl rightly pointed out, we don't have a big enough sample group to conclude that all 92's have this problem. Nor are we likely to get one. Ever. Even if the problem does affect all 92's, it is not insurmountable and, depending on your application, you may hardly notice it.

Kevin's VWRX software is the best software currently available and I assume that most people who build one of these interfaces will be running it. (At least until I learn windows programming and produce a better one, specially for the SVX ) This software does not validate the data coming back from the ECU as far as I can tell. It doesn't care if the address bytes in the reply is corrupted and it displays whatever data comes back for the user regardless of whether is it sensible.

The upshot of this is that you can run Kevin's software even if your car has the same problem as mine. If the data from the ECU is getting corrupted then you will see the gauges on the screen fluctuating a lot. It's returning several values a second and unless you are doing some detailed diagnostics, it probably doesn't matter too much to you if some of them are incorrect. You can usually pick out the correct information from the values that are obviously incorrect.

For my application, I need valid data to examine, to see how the ECU software works and to find the parameter addresses. That is why the corrupt data returned by my 92 ECU has been a problem for me. But now I have what looks like a workable solution.

I hope that sets a few minds at rest.

As I see it, the main stumbling block in this project now is the lack of good data logging software available. I would like to write some, but I don't know how to write windows software and it will take me some time to learn it to a good enough standard.

Please have another look at their circuit diagram. I don't think the circuitry they have added is "fingernail polish".

There is no wire connected to pin 2 (receive data) or pin 8 (clear to send) of the PC serial port. It looks to me like they are not using the UART in the normal manner. They seem to be sending and receiving the data one bit at a time by directly accessing the handshaking lines.

... They seem to be sending and receiving the data one bit at a time by directly accessing the handshaking lines.

That's exactly what they're doing. They're using the RTS input to read the ECU's transmit data output, and using the DTR output to pulse bits into the ECU's receive data input.

Why? Well, if you don't know whether the device you want to communicate with uses standard RS-232 bit rates or word formats, this method gives an assembly language program complete control over the format and timing.

The monitor code was first written to work with the PC's parallel port in a similar way (flipping bits "the hard way"). This circuit may have just been a cheap and easy way to use a serial port while re-using most of the previous code.

The original code and parallel port circuit may have simply been a cheap and easy way to talk to the ECU without having to build an RS-232–to–TTL converter.

I may be a little premature here, but I think that I've figured out and 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

OK. I haven't solved the problem and it's driving me nuts.

Sometimes the data quality is not too bad. Like on Friday night I could pick out one good response every dozen or so bad ones. I could work with that, and so could the VWRX software.

On Saturday it was the same. Using the Friday night technique, I managed to copy the first 32K of the ECU address space to disk. It took nine hours though and flattened my battery. Unfortunately the most interesting part is the last 16K which I didn't get.

But on Sunday Morning, after recharging the battery, it was futile. There was no good data at all coming back from the ECU. Just pages and pages of random crap. No software could possibly do anything with that. Sunday evening it was a little better. I managed to get about 4K of good data from over the space of 3 hours but then it went back to random crap again.

Just a thought.
What about running the engine for a while and then shutting it off and then dumping the memory?

Your problem with the ECU lends a liitle more belief to the 92's having that extra 50 horsepower

It appears Subaru didn't want anyone getting inside the ECU.

That's a pretty good idea. I'll give it a try.

I had a crazy idea the other day that it was to do with the battery voltage. It was working (to an extent) until the battery went flat. After I recharged the battery it no longer worked. So I left the headlights on for a while to drop the voltage a little. Didn't seem to make any difference.

I downloaded the firmware from my 92 TCU the other day. There are quite a few differences from the 94 TCU - although they are based on the same program. I can't help wondering if they made some changes on the later cars to try and stop the gearbox from self destructing.

I haven't got far enough with understanding the code to say what functionality has changed. It does raise the question of whether a 92 box would last longer if it was controlled by a 94 TCU.

I'm also thinking that it must be possible to reprogram the TCU the way that LAN does for the ECU. There is a space provided on the board for an eprom socket. It's got the same number of pins as the socket on the ECU. Maybe LAN's memory adapter board would plug right in there. If so, it might be possible in future to reprogram the TCU for different shift points which could be useful for those who have raised the rev limiter on their ECU.

The 94 and up have a speed limiter in one of the computers. Which is it? If it's the transmission computer, that might be where the difference is.

The speed limiter is in the ECU on JDM models. I assume it's the same on US models. I can't see how they could implement a speed limiter in the TCU. The ECU can cut off the fuel, when you reach the limit, but what can the TCU do? Maybe shift into neutral? Actually thinking about it, there is the torque control signal that the TCU sends to the ECU to cut the power when changing gear. I'd still put my money on the limiter being in the ECU though.

Hopefully one day I'll understand enough about the TCU to say what the differences are.