Open ECU?

[arghx7]

Thanks for your continued efforts. The more useful data we can get, the better we can understand the engine. I'm still waiting on the emissions and fuel economy certification filing so we can try to figure out why the automatic is rated at so much more fuel economy. That's another thing I'd like to look into.

Now I'm taking a look looking at the CSV files. I don't see fuel trims or fuel pressure, so I'm not sure what's going on with that. I moved the decimal places around for the cat temp. Assuming it's the right data, it seems to have a slower refresh rate than other parameters. The trend line kind of makes sense but I am not sure I 100% trust the cat temp estimate data.

So here are some new charts (I have trouble reading Jediblow's screenshots):



Keep in mind that Jedibow's car is at high altitude. Things I notice from this:

1. The timing "dip" corresponds to a local maximum in the absolute load/pumping efficiency.

2. The estimated cat temp, assuming we can trust the data, peaks around 900C at redline. This is roughly what I predicted the max temp to be. This cat temp occurs at peak enrichment/richest AFR.

3. Generally speaking, timing advances as pumping efficiency is decreasing and retards as pumping efficiency is increasing

4. Up to about 4000rpm, the engine is running at max WOT spark advance and a commanded AFR which should help torque output. This seems to correspond to the torque "bump" (ie, before the "dip"). I'd like to see cam phasing data to learn more, but that will probably have to wait until ECU datalogging becomes available.

Now what is absolute load as reported over the CAN bus? Absolute load is a pumping efficiency calculation.



Absolute load is not exactly the same as the grams/sec load term used in internal Subaru ECU calculations. They are directly related, yes, but they aren't the same. When absolute load goes up, grams/sec should go up.

According to the ECUtek guy's post, these are the stock basic ignition timing map and basic commanded AFR maps:





notice the load axis is in grams/sec.

Just looking at this data we have so far, the stock maps definitely seem to be tuned to maximize torque under 4000rpm.

[E92M3Guy]

Originally Posted by arghx7

Now I'm taking a look looking at the CSV files. I don't see fuel trims or fuel pressure, so I'm not sure what's going on with that. I moved the decimal places around for the cat temp. Assuming it's the right data, it seems to have a slower refresh rate than other parameters. The trend line kind of makes sense but I am not sure I 100% trust the cat temp estimate data.

There's two things I can think of that might explain this. 1) Refresh rate of D-CAN; 2) Refresh rate of the sensor itself.

1. D-CAN shares a single CAN address to receive data. If you request more than two parameters (RPM, Lambda, timing, etc.), then it most likely extends the request to a multi-frame CAN message. This means refresh gets slower when you request more parameters because all of the values must clear the CAN bus before the next request is made.
2. The sensor itself might have a slow refresh rate. In this case, the ECU is reading the sensor data at a slower rate, and that's why it only updates in your logs at such a slow rate as well. For example, RPM data on my BMW CAN bus is updated every 1ms, but temperature data is updated every 1s. D-CAN pulls the data down every 70ms (on the BMW), but you can clearly see temperature sensor refresh rate matches the engine CAN bus at 1s update intervals.

[johnbradley]

Originally Posted by jedibow

Okay so this is the last log again 3rd gear pull on the freeway from 2500 RPM to Redline. I have included Maf Flow, same log as previous with appropriate scaling, a close up of Timing and RPM, AF Map (not AFR, but what the ECU is telling the car to run), and the map tracer now works so...

Here we go

George

Your log of MAF voltage parallels the powerband perfectly. The dip in torque is related to Airflow and I would wager its AVCS dropping cylinder pressure to prevent knock at peak load.

After reading the rest of the thread and seeing the ignition screenshot from ECUtek, the timing is low there but I havent ever seen ignition timing affect airflow. It wont be helping of course but I am not sure thats the whole cause. The other thing I wonder is if its like the GTR and not a real number anyway but a calculated burn rate vs ignition timing number.

[jedibow]

Originally Posted by johnbradley

Your log of MAF voltage parallels the powerband perfectly. The dip in torque is related to Airflow and I would wager its AVCS dropping cylinder pressure to prevent knock at peak load.

Don't tell me you jumped the Evo also? John were the scalings in EvoScan made specifically for the Evo X? for some reason certain values do not log correctly for this vehicle, I.E. Maf reading 10,000 ???? throttle percentage 80, at WOT, O2 feedback 65****,

Thanks John

P.S. I don't mean to put you to work HaHA

[Dimman]

Originally Posted by jedibow

That is one hypothysis, atleast my log shows that the VE of the engine drops in that area. So I believe that yes it is linked, now we just have to figure out why the VE drops in that area, and causes the torque dip. What is interesting is that the factory tune increases timing in that area, which in most cases increases VE, but for some reason it doesn't in this car

From a bike tuning book:

Where the pipe produces a flat spot, cylinder filling sags and so does flame speed, thus requiring more advance.

[johnbradley]

Originally Posted by jedibow

Don't tell me you jumped the Evo also? John were the scalings in EvoScan made specifically for the Evo X? for some reason certain values do not log correctly for this vehicle, I.E. Maf reading 10,000 ???? throttle percentage 80, at WOT, O2 feedback 65****,

Thanks John

P.S. I don't mean to put you to work HaHA

Not jumped, but I tune Nameless' cars and they use our dyno. John and Jason involve me in the projects though and I had this the other day for the header testing. They narrowed the gap in the flat spot from stock and the reason I feel is that the scavenging has been improved (i.e. airflow is up) and fills the cylinders better. If I can log MAF voltage we can overlay the stock one you have vs their car on monday when it comes back. Can you PM or email what I need to log the BRZ?

sales@englishracing.net

Thanks

JohnBradley

[jedibow]

Originally Posted by johnbradley

Not jumped, but I tune Nameless' cars and they use our dyno. John and Jason involve me in the projects though and I had this the other day for the header testing. They narrowed the gap in the flat spot from stock and the reason I feel is that the scavenging has been improved (i.e. airflow is up) and fills the cylinders better. If I can log MAF voltage we can overlay the stock one you have vs their car on monday when it comes back. Can you PM or email what I need to log the BRZ?

sales@englishracing.net

Thanks

JohnBradley

You have evoscan correct?

I have also already posted two difference .csv files for Arghx7, they are earlier in the post

[johnbradley]

Yeah I have EvoScan 2.6 I think is the newest..I can look and see I might have 2.9 right now.

[jedibow]

Originally Posted by johnbradley

Yeah I have EvoScan 2.6 I think is the newest..I can look and see I might have 2.9 right now.

If you don't you do now HaHa, check your email,

George

[serialk11r]

Is absolute load a reading that comes (essentially, calculated) from the MAF then?

[jedibow]

Originally Posted by serialk11r

Is absolute load a reading that comes (essentially, calculated) from the MAF then?

Partially yes, there is also compensation from the barometric sensor (MAP), intake air temp sensor (IAT), and the crack position sensor to determine stroke (CPS), arghx7 posted the formula for the calculation above, post #67.

George

[serialk11r]

Originally Posted by jedibow

Partially yes, there is also compensation from the barometric sensor (MAP), intake air temp sensor (IAT), and the crack position sensor to determine stroke (CPS), arghx7 posted the formula for the calculation above, post #67.

George

Ah, so it's the ECU calculated volumetric efficiency, right? Thanks!

[johnbradley]

Originally Posted by serialk11r

Is absolute load a reading that comes (essentially, calculated) from the MAF then?

In the Evolutions for reference (and other Subarus as far as that goes) its a derivation of MAF reading / Rpm * X

where X is a predetermined constant

The Evo uses a Karman so its Hz/rpm*852, this uses other variables but you get the basic idea. Load itself is also a form of gram/s (g/rev) which in the GD/GR Subaru is a Grams Per sec * 95 = load (as found in the Mitsu as the listed percentage of 0-400%).

[arghx7]

Originally Posted by E92M3Guy

If it will help, I've been taking complete data logs of the engine CAN bus and reverse-engineering the data locations. I suspect your tool communicates with the ECU via D-CAN (diagnostics CAN) and that's why you're sending PIDs to the ECU and getting response data. I'm looking at the raw data on the bus itself. Let me know if there's any of the raw data might be helpful.

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.

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...

Originally Posted by E92M3Guy

The sensor itself might have a slow refresh rate. In this case, the ECU is reading the sensor data at a slower rate, and that's why it only updates in your logs at such a slow rate as well. For example, RPM data on my BMW CAN bus is updated every 1ms, but temperature data is updated every 1s. D-CAN pulls the data down every 70ms (on the BMW), but you can clearly see temperature sensor refresh rate matches the engine CAN bus at 1s update intervals.

The cat temperature is an estimate based on a model. There is no exhaust temperature sensor. Even if there were a sensor (like some of the older turbo Subarus, 2005 Legacy GT for example) there would still be a model. The model could actually be a simple look up table, or more likely it is pretty involved.

I suspect it is just the bus reporting it at a slow rate as you mentioned.

Originally Posted by johnbradley

Your log of MAF voltage parallels the powerband perfectly. The dip in torque is related to Airflow and I would wager its AVCS dropping cylinder pressure to prevent knock at peak load.

Just FYI, MAF airflow is reported in grams/sec when you request it as a universal diagnostic parameter. There is no raw MAF voltage available when you request data in this manner. From page 14 of the parameter list I posted:



If you want raw voltage, you will need equipment to measure it at high speed or you will need to read it directly from the ECU.

After reading the rest of the thread and seeing the ignition screenshot from ECUtek, the timing is low there but I havent ever seen ignition timing affect airflow. It wont be helping of course but I am not sure thats the whole cause.

Generally speaking, ignition timing affects combustion phasing more than anything else. That means it affects the crank angle degree at which max cylinder pressure occurs and it affects the mass fraction/heat release curves.

The other thing I wonder is if its like the GTR and not a real number anyway but a calculated burn rate vs ignition timing number.

The GTR's ignition timing control system is greatly misunderstood... those offering tuning solutions for it figured out just enough to make some adjustments, but they do not really understand the calculations that go on inside the ECU. Unless something drastic has changed with the BRZ software (compared to prior Subarus that we understand), the BRZ is not even close to the way the GTR calculates timing.

[Dimman]

Originally Posted by serialk11r

Ah, so it's the ECU calculated volumetric efficiency, right? Thanks!

Which means that fueling and ignition will not be flattening the dip out.

[jedibow]

shouldn't the maf voltage be linear? What I'm getting at is if we know the lowest voltage, and the highest voltage couldn't we calculate the voltage corresponding to the g/sec reading by creating an excell sheet with ploted points?

Example

xmin=0 (0 compared to g/s), xmax=5 (655.35 compared to g/s), plot the sensor readings and choose the best fit equation in excell to give us or conversion formula?

Just a thought, this has been the direction I've been attempting to take to get the scalings corrected in Evoscan as long as I know the readings are on a linear sensor.

[jedibow]

Originally Posted by Dimman

Which means that fueling and ignition will not be flattening the dip out.

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!

[arghx7]

It doesn't report voltage. It reports mass flow. Plug a universal scantool (like the orange Actron ones used at Autozone) into any vehicle equipped with a MAF sensor, and you will read MAF sensor airflow in grams/sec. You can't read voltage using this type of request.

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

[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