Open ECU?

[jedibow]

Originally Posted by arghx7

MAF calibration curves are never linear, they are logarthmic/exponential to have higher resolution in lower airflow ranges.

So it would be the same as attempting to find the AFR equation for a narrowband O2 sensor when you have the reading in volts.

Could I try to interpret using an exponetial equation, much like I have been working on to get the scaling correct reading O2 B1 (wideband)?

[arghx7]

I'm not an expert on the actual mechanics of reading the raw diagnostic data across the bus. I have only used software and hardware that has already been set up to read correctly. My understanding is that the ECU is already converting the raw MAF sensor signal voltages to a grams/sec value according to the exponential transfer function. Then the ECU sends that converted grams/sec value across the universal diagnostic protocol according to a linear scaling.

From my interpretation of the document, it looks like there's two bytes reported, and as the bits increment up each bit corresponds to .01 g/sec . I don't know what that actually means as far as what to set in Evoscan though. Again, this is not something I normally deal with--I use that document more for definitions and units, not for actually setting up data requests.

[Dimman]

Originally Posted by jedibow

Not completely no, however by changing the cylinder pressures and temperatures with adjusting timing, and fuel I think that we can atleast make it better.

However some will see this as a band aid, instead of a fix, as of right now I think your Cam phasing idea is the most likely candidate as the culprit.

Dimman, hurry up and design new Cams that will eleviate the torque dip, increase power across the board, and save gas!!!!

No pressure BTW!

Those would be some damn magical cams...

[serialk11r]

Originally Posted by Dimman

Those would be some damn magical cams...

Well, with correct cam phasing control and matching intake/exhaust header, 2 of the 3 should be attainable

[E92M3Guy]

Originally Posted by arghx7

What are you using, CANalyzer? Are you passively listening across the bus only or also requesting data using the info I posted earlier in the thread? For a simple car like this, most of these engine-specific diagnostic parameters are not normally reported across the bus in normal operation. Now for expensive German cars with a lot of control modules there will probably be more data being exchanged there.

I am using Vehicle Spy by IntrepidCS. It's very pricey, but the software side is very nice. Yes, it passively reads the data. To request data, you need a different device -- you need a programmable device.

You are correct, this car has a very simple bus structure, but believe it or not, so does the BMW. Just like the BMW, this ECU doesn't broadcast most of the interesting stuff on the engine CAN bus. To get that data, you need a tool like your evoscan tool that sends command bytes on the bus and waits for a response. To get the real interesting stuff on the BMW, you also need a tool that talks on the diagnostics protocol.

What you will find are engine speed, vehicle speed, torque reduction requests, steering angle and probably yaw rate, possibly wheel speed, tire pressure, and operation from the body control modules. Trust me on this from firsthand experience with actual manufacturer CAN message libraries...

Pretty much spot-on. So far, I've found a few dozen items. RPM, individual wheel speed sensors, brake sensor, steering angle, a few accelerometers. I haven't looked for tire pressure.

Originally Posted by arghx7

I'm not an expert on the actual mechanics of reading the raw diagnostic data across the bus. I have only used software and hardware that has already been set up to read correctly. My understanding is that the ECU is already converting the raw MAF sensor signal voltages to a grams/sec value according to the exponential transfer function. Then the ECU sends that converted grams/sec value across the universal diagnostic protocol according to a linear scaling.

I also have a few programmable CAN controllers which have the ability to download software that I write. I know exactly how the diagnostics protocol works, but I've never seen a spec for it, so I've never tried to implement it myself. I know there's a handshake with the ECU when the device connects; then after that, you send the program bytes and wait for a response. The more program bytes you send, the more data that comes in return and the slower it comes. If I had the spec for the initial handshake, then I could probably write something to probe the FRS/BRZ to send any PID you want and see what data comes back. I just need an excuse to work on something like this...so if you have the diagnostics CAN protocol spec, it would be a fun project.

From my interpretation of the document, it looks like there's two bytes reported, and as the bits increment up each bit corresponds to .01 g/sec . I don't know what that actually means as far as what to set in Evoscan though. Again, this is not something I normally deal with--I use that document more for definitions and units, not for actually setting up data requests.

All of the data in the diagnostics protocol is 2-byte data and always big-endian -- whereas the raw data on the CAN bus can be any number of bits, and either little-endian or big-endian. On the FRS/BRZ for example, RPM is 14-bits wide. Bits[0-13] are RPM, and bit[14] is an on/off bit indicating when the throttle is pressed (=0) or not pressed (=1). But on the diagnostics bus, RPM would come as a 16-bit value and might include some scaling factor. To show how scaling works, on the BMW engine CAN bus, RPM is scaled =RPM*4, but on the diagnostics bus, it's scaled to =1xRPM. So yes, very likely by the time data arrives on the diagnostics bus, it has already been scaled.

I've read on another thread that Toyota plans to publish significant pieces of their engine CAN bus address map (the stuff I've been working to figure out). Once I read that, I kind of slowed down on my project -- figuring my time is being wasted. If anybody has seen that list (if it yet exists), then please point me in the right direction.

[arghx7]

see if any of this helps

[jedibow]

E92M3guy,

I've been working on getting the wideband O2 to log, however EvoScan doesn't like it, if you need a project, I have narrowed all the CAN PID's down to the one that is actually used for the ECU

Request ID 19 for volts, and 3E for Lambda, any help you could offer would be appreciated.

[E92M3Guy]

Originally Posted by arghx7

see if any of this helps

Thanks, got them. I think 1979 might be the one I'm looking for. I have a few projects queued up ahead of this, but this is something I have planned for a very nice track car project.

[Bg8780]

Disclaimer: I'm pretty new to the tuning community. So this may be a dumb question.

Does flashing or replacing the ECU void manufactures warranty? If so, is it possible to remove the new ECU or flash back to the stock ROM without leaving evidence apparent to the dealer techs?

Thanks!

[ahausheer]

As to your first question, yes it will void your warranty. Flashing or replacing the ECU is like transplanting a new brain into your car. Toyota spends a lot of money of their cars brains and wont insure any other brain.

[jedibow]

Originally Posted by Bg8780

Disclaimer: I'm pretty new to the tuning community. So this may be a dumb question.

Does flashing or replacing the ECU void manufactures warranty? If so, is it possible to remove the new ECU or flash back to the stock ROM without leaving evidence apparent to the dealer techs?

Thanks!

For your second question, as long as you save your stock ROM image you can flash it back whenever you choose.

[Bg8780]

Thanks a lot guys.

[bambbrose]

Originally Posted by arghx7

see if any of this helps

Helpful info! Can you get ahold of IS0 11898-2?

Originally Posted by jedibow

E92M3guy,

I've been working on getting the wideband O2 to log, however EvoScan doesn't like it, if you need a project, I have narrowed all the CAN PID's down to the one that is actually used for the ECU

Request ID 19 for volts, and 3E for Lambda, any help you could offer would be appreciated.

Is the bus sending the WBO2 as 11 bit or 29 bit frame? What is the bus rate? I know earlier (2010) Subaru used both 125 kb/s and 500 kb/s for different CAN groups. I'm assuming the diagnostic is still on the slower body CAN speed, and the 500 kb/s is for manufacturer specific information.

So far we know:

1 000 0011 1110 0 X blah blah blah

Find out if X is 0 or 1 and we can start to determine the Lambda packet.

Originally Posted by E92M3Guy

Thanks, got them. I think 1979 might be the one I'm looking for. I have a few projects queued up ahead of this, but this is something I have planned for a very nice track car project.

If you guys get down to the hex level please post any findings such as Node ids for requests, data packet bit size, etc.

This stuff is what I'm hoping Subaru/Toyota releases, but who knows what they'll actually give up.

Keep up the good work. This is the most important thread on the forum.




On a side note, I have the factory wiring diagram, and it shows that the injectors have their own MCU on the CAN network.

This means that the engine ECU sends signals to an injector MCU, and that injector MCU then does the fancy work on the injectors and DI system. This means traditional ROMs may just change the main ECU, and it will send out a standardized signal to the injector MCU, and the injector MCU will know how to handle it.

This may also mean that an entirely new ROM has to be developed to manipulate the injector MCU CAN Node values. This is going to be the key to tuning. The first tuners probably will get the standard ROM, but the tuning software that has the MCU for the injectors flashable will be the winner.

This is all just speculation of course since I haven't connected to the network.

[ImAwesome]

subscribed. Good read. hard to follow at parts for someone like me but some of the best info I've seen on a car forum outside rx7 club