Its a MAF limitation. Scott's solution is an interesting way to prevent clip. The value was actually discussed awhile ago when Smoggrunner was running into clip issues on his GT35/Stock MAF setup. I believe the stock MAF is good for something like 2700 or 2800hz before it gets erratic though it will max at 3000hz as I recall. MalibuJack posted this along time ago when he first was looking for an alternate and rescaled the MAF table to work with a GM blow through.

I am curious what the Hz was when the load value pegged on that 35/37.

 

Unfortunately, Airflow wasn't scaled but it maxed at 1603 in the 330 loads. I was actually reading old threads just now about MJ and smogrunner. How expensive are these higher flowing MAF's? I knew a SAAB kid who had the MAF issue and ended up running 2 stock MAF's (he owned like 6 SAABs so he had an extra one already) and just used a formula in the ECU to convert one MAF signal and basically double the airflow numbers. God knows no one wants to cram to MAFs under their hood though,lol.

I hate limits with the stock ECU, I just feel there is a lot more potential with it but we just haven't figured out all of the tricks just yet.

 

http://www.dsmparts.com/customer/pro...cat=114&page=1

I am not sure what was involved in scaling the MAF table to make it work. The other option is a MAFT or MAFT Pro and let it do the work. Then the ECU has plenty of resolution.

 

I know of the MAFT thing but what exactly is it doing? Scaling the signal so it mimics the stock MAF's, with higher resolution? It'd be great to just set the ECU to read the GM MAF, that'd be my goal if I had to use one. Needing to use one would be great anyways...since I have enough HP to warrant such a need,lol.

 

Your confusing what the maximum value the variable could theoretically hold with what the maximum value the ECU's calculations allow it to be.

Thing of the maximum value as a lake and the ECU's calculations only being as big as a glass of water. The glass of water can be filled until its full. After that any other water just goes into the dirt. You can dump the full glass of water into the lake...doesn't mean the lake is full though .

 

That analogy confused the hell out of me,lol. The ECU can in fact go that high, its the OTHER variables limits which will cause the Boost Limit Load to reach its limit. If you extended the adjustable (and usable) range of the other variables involved, the ECU can definitely extend its LOAD for the boost limit.

 

How on earth are you hitting these loads at such rpms with stock turbo???


i dunno if this helps, but there's the values from the fq360 map:


boost delay timer: 2500
boost control load offset: 159.4 (maxed out)

desired engine loads:

140
140
158.75
158.75
158.75
158.75
158.75
158.75
158.75
158.75 4000
158.75 4500
158.75 5000
158.75 5500
154.375 6000
149.375 6500
145 7000

 

No, the table is only writen so FF is the max, but a quick look at the code sugests we can write a new table with a Max of FFFF and change the pointer for the code.

MB

 

It was late last night what can I say? If you re-read my post I just said that

Point is that what is it important is not what the maximum value it could potentially hold, but what is the maximum value that it currently is allowed to hold.

If you have enough time and you go meddling with stuff in the ECU you can probably make it play monopoly too .

 

I'm looking for the code where I get to collect the $300! And a get out of jail card wouldn't hurt either

 

How do I find what the Tables maximum set HEX value is? Is that a diasm mod to change its limit? I'm just tinkering with my desktop roms to get a better feel of "how it works" and how it can be manipulated if necessary.

 

For me there is a little more educated guess work than for tephra and the like. A good place to start is to look at the scaling for the value you're interested in. For example something scaled with Hex 16 can go to FFFF and something with Hex 8 can go to FF Bearing mind that if you set the max value to FF, say as in WGDC that might not make the car use this theoretical max. Disassembly can make things clearer as you can see what the code is capable of doing and the raw values of the maps and scales.

MB

 

Well, i thought if you changed the scaling you'd be changing the theoratical max value. Like you said, from hex8's FF to hex16's FFFF. I just didn't know if the range simply expanded to span the entire hex range. So where FF was the max limit, FFFF would now be the limit. I'll need a walk through from one of the big boys on how the scaling changes are possible...and when they are not.

 

Paypal me $300 and its on j/k

 

The way scaling seems to work is that it basically tells the program to interpret the set of bytes in the rom in a certain way. I stand to be corrected on that though....

Computers really can't differentiate between bytes it is reading in. Anything that differentiates between them is something that we (humans) have written on top to help us work with them.

For example, using the hex stuff above (if you have the windows calculator just put it in scientific mode and set it to Dec, then switch to hex to follow along).

Hex 8 really means you can represent any value from 0 - ((2^8) - 1) so basically from 0 - 255. 255 is FF in hex notation.

Hex 16 means represent any value from 0 - ((2^16)-1) so basically from 0- 65535. 65535 is FFFF in hex notation.

So roughly if the data at the address that we are interested in is FFFF and we tell the computer that it the scaling is Hex 8 it interprets it as two hex 8 values: FF followed by FF.

If we tell it is Hex 16 it will see it as one hex 16 bit value: FFFF.

Stand to be corrected on all of this but this is how it works elsewhere....