RomRaider

Yeah that would work and has been done by many. It's a hack but proven.

That's true. But for me looks like that the format/conversion (uint16 x*0.021) for load axis we use isn't the one used inside DME for calculations. In that format the max value is 0xFFFF = 65535 =1389,34 mg/stroke. If you look my log, the highest load reported by DME is 1248,47 mg/stroke. But after the load reaches 1000 mg/stroke, there happens some kind of overflow inside the DME. After that the injector PW drops and the engine leans out seriously. I can't see the exact figure but I would have to guess, the max load is 1024 But it's strange that the MAF value also drops. I didn't have log with MAF volts, but that doesn't drop. Maybe DME does backwards calculation for MAF value from load and RPM for logging. (the MAF values in log seem to be one report behind of everything else, which also makes sense if it does backwards calculation).

But I haven't disassembled the code, so these are just guesses. And I just brought this up, so that people know this and could try to avoid the problem. Leaning out the boosted engine in WOT pull can cause serious damage. Especially with pump gas and stock internals, it will quickly lead to broken piston ring lands or even something worse. And maybe we can do something for the problem in future, now that we know it exists.

Here is my new scaled partial, if someone want's to take a look. The load axis over 1000 is useless so I will later take those columns in better use somewhere else.

Well, good information in here, thank you all!

For my situation with the automatic trans still controlled by the factory TCU, I can't simply halve the MAF table as that would provide insufficient load indication to the trans.

At any rate, it seems clear what I need to do for now while I have this transmission setup in the car, keep my current scaling up to around 500kg/h, and then curve it down real hard above that. It will involve some re-tuning in boost, but that's no problem.

ba114, if you are able to push ~15psi before hitting the "boost cut," does that mean that you are running a bit larger of a turbo that spools a bit later? I'm currently running a China 61/62 journal bearing turbo, sold as a "GT35."

My 3bar MAP is showing weird behaviour in my logs so i cant rely on that right now. I have a defi clone in the car that monitors boost, fuel pressure, oil pressure/temp etc etc but it doesnt log. Using the peak playback function showed it recorded a peak of ~15psi.

Turbo is a PTE6262 journal bearing so i wouldnt expect it to spool slower (rather the opposite) than a lesser quality product.

This aside, i need to replace my fuel pump. whilst the stock pump is sufficient for low boost, fuel pressure is dropping as boost increases so i need to do that before i do much more testing.

Is your map sensor fluctuating output?

Yes, but it's also registering too high voltage at vaccum. I think it's dodgy.
The rear o2 sensor inputs are susceptible to noise. I'm going to try a 0.1uF 50v cap across the signal and ground to try remove some of the noise

Easily could be true. Even my billet wheel Precision 6265 spooled surprisingly well on a 2.0L 4-banger.

I did have to scale up your MAF table quite a bit to give my slushbox the loads it needed to see for proper shifting, so maybe that is the entire reason I'm hitting the boost cut at less boost pressure than you are.

Other than that, everything about the engine operates fantastically though!!

Yes, the Load variable can definitely overflow and go back to 0 if exceeding 1389 Load mg/stroke. The reason you may think it's overflowing before that is because of the datalogger response times.

In fact, I had already mentioned this a few months ago...


So, I suggest delaying the boost spool up a bit for a quick spooling turbo for now. I have a plan to address this issue but it will take me some time to implement since a lot more table definitions may need to be added for a comprehensive fix.

Superchargers need not worry since they don't hit significant boost till much later in the RPM range.

Looking back at more of my logs over the past week or so has led me to this conclusion too. The rate at which the load jumps between data points definitely supports the idea that it could be surpassing 1389, and then rebounding down to the reported level for the following data point.

If you're working on a correct fix for this issue, I'll resist the urge to rescale my MAF table for now. My slushbox trans really doesn't want any more boost anyway! Lol

Added this to the 1st post.

Caution - If you run this with a Turbocharger that spools up quickly, you will overflow the Load variable in the 2500 to 3500RPM range since Load/Torque builds too quickly for the stock ECU code to handle and will result in extremely lean AFRs and engine damage. Datalog and make sure you are not getting close to the 1389 Load (mg/stroke) limit. If you are, delay the onset of boost a little bit.

Superchargers and NA tunes are OK to use with this.

For the time being i've multiplied the MAF scaling by 0.5 and gone through all the defined tables and any table that reference load also had those values multiplied by 0.5.

are there potentially any undefined tables that this would have negative effects on?

Probaply yes. And multiplying MAF table by 0,5 is not very good way. You will distort the shape of the curve compared to the voltage. And even when you multiply load values by 0,5 you will get everything wrong and it will be big job to tune everything. Better way is to use that MAF resistor scaling in your excel to fix the broblem. I have 2,2k resistor and used 1k resistor scaling. So the MAF voltage is off by 10%. In that way you keep the MAF curve shape right and it has very minimal affect on low loads. (15kg/h becomes something like 14 kg/h. Compared to 7,5 kg/h if you just multiplied values by 0,5) Basically no extra tuning required. Just small adjustments to fuel and ignition tables. But the scaling affects quite much on the big airflow values lowering those drastically. Which gets rid of the high load spikes.

This all makes me think we need to put our efforts into the process/method of converting the code to running on MAP for turbos. As I've thought in the past with my other turbo builds, "Glad I'm running MAP, MAF seems like it could be problematic." Turns out now I know it is!

Of course, the down side of turning "our" efforts toward the MAP project is that "we" seem to really consist solely of mrf582, and that's pretty much it... There certainly is nothing I could offer to the project other than willingness to test stuff out and feed back result data. Ain't no way I can help with the coding.

As an aside, my bumping into the load limit seems to happen at around 4100-ish RPMs, as opposed to within the window of 2500-3500. It is possible that the indicated ~4100 is inaccurate also because of the reporting frequency. But overall it seems like we will be severely limited on how much boost we can run unless we are able to scale down the MAF table as ba114 mentioned. In my case I can't currently do that so I can deliver a "high enough" load signal to the slushbox controller.

Are you sure? Halving all the values in the MAF table will keep the shape exactly the same and still follow the 3rd order polynomial curve.

No. I just gave this second thought and yes it should work by halving the values. If there isn't anything critical that is using load calculation and is not defined yet. I have at least heard from guys tuning -413 bosch for example that will cause serious tuning issues. But the XDF files those are using aren't really well defined so...

But still my point is that if you just slightly rescale the MAF voltages, you will get rid of the high MAF values without causing too much change in the low loads.