Turbonator T3

[Pat]

RPM.... when looking at the RPM range values in the test t3 cal, only see values that go up to 6136. i know our motors arent the revviest things in the world, but shouldnt we at least allow a 7k rev range for those pushing the envelope with porting, cams, intakes etc.

brian

I don't have much I can contribute, but on the rpm piece, the T-III is much more rev happy than you think. Last time dyno I did, with stock longblock, 50 trim, large IC, exhaust and an FWD cal, it's powerband sweet spot was something like 5600-6800 rpm, hp peak was just over 6500 rpm, and didn't drop more than a few ponies until almost 6900. This was with a simple build. RPM resolution would be a key piece to being able to do a finely tuned cal.

On the stock cal tables showing rpm values to 61xx rpm, I recall on datalogs I've done that after about 6200 rpm, my duty cycle readings went all over the place, which I took to believe that the cal was asking for more duty cycle than time permitted. My assumption was that at that point, the injectors were "
full on."

Pat

[ShelGame]

It all comes down to how to adjust the 3D table for those type of changes - RPM or MAP. You can adjust the RPM range by simply changing the 2D input table, but you would then need to re-scale the entire 3D table accordingly. I'm not sure how to do that automatically, yet.

As for the resolution issue, the 3D tables now calculate a 255x255 grid of points. Here's how it works (as simple as I can explain):

Take any 4 points in the 3D table...

3D table.JPG

The ECU basically interpolates the X-axis first, then the y-axis. So, for example, say you have a MAP value of 5psi and engine speed at 4000rpm. The ECU would find the value to be between 3855 and 4112rpm. It would calculate the fraction for the X-Axis [(4000-3855)/(4112-3855)] and then the fraction on the Y-Axis [(5.0-3.7)/(5.6-3.7)]. And then multiply those fractions by the difference in the Z-values.

So, if you're RPM was 3855 exactly, and the MAP was 3.7psi exactly, you would have an output of 129d.

But, there are ~10-16 steps in between any 2 points (actual number of steps depends on the slope of the input table).

If we keep the 3D table at the same dimensions as it is currently, then all we really do is reduce the number of steps in between the 3D table points from 16 down to 12. But, it's still linearly interpolated in between the points. What Chrysler did by changing the input slopes is to put more interpolation points in between the 3D table points. But, again, it's still limited by the actual input value. LoMAP, for example, the resolution is cut by more than 1/4.

Anyway, that's kind of rambling. I'm not really sure what to do about scaling the 3D tables. My philosophy with the 2D cals has been to leave it as close to stock as possible. If we start re-scaling the 3D cals (to make the input linear, etc.), we get farther and farther away from stock...

[ShelGame]

I don't have much I can contribute, but on the rpm piece, the T-III is much more rev happy than you think. Last time dyno I did, with stock longblock, 50 trim, large IC, exhaust and an FWD cal, it's powerband sweet spot was something like 5600-6800 rpm, hp peak was just over 6500 rpm, and didn't drop more than a few ponies until almost 6900. This was with a simple build. RPM resolution would be a key piece to being able to do a finely tuned cal.

On the stock cal tables showing rpm values to 61xx rpm, I recall on datalogs I've done that after about 6200 rpm, my duty cycle readings went all over the place, which I took to believe that the cal was asking for more duty cycle than time permitted. My assumption was that at that point, the injectors were "
full on."

Pat

The 3D tables only read up to 61xx rpm. So, anything above that, you don't get more fuel. You get the same fuel you had at 61xx rpm...

The conclusion I seem to be coming to is that no matter what/how we do it, the 3D tables are never going to be both close to stock and user-friendly...

[Pat]

The 3D tables only read up to 61xx rpm. So, anything above that, you don't get more fuel. You get the same fuel you had at 61xx rpm...

The conclusion I seem to be coming to is that no matter what/how we do it, the 3D tables are never going to be both close to stock and user-friendly...

That explains quite a bit of what I've seen from A/F's with both stock and the old FWD cal I have now. Gets very rich, then ramps up sharply with rpm at the very top.

[ShelGame]

On the plus side, scaling for injectors is pretty straightforward and relatively simple...

[Aries_Turbo]

My philosophy with the 2D cals has been to leave it as close to stock as possible. If we start re-scaling the 3D cals (to make the input linear, etc.), we get farther and farther away from stock...

right, if we scale it to be linear, its all interpolation and slope changes to get the values to act like stock but have a different range.

im sure we could make a spreadsheet that mimics the table itself and the scaling factor math so that if we change the scaling factor, it will automatically interpolate and rescale all the table values accordingly.

its just math. it should be possible. ill take a look at it and see if i can wrap my mind around it.

Brian

[mark]

I can actually hear the gears in Bucars head turning from miles away...

[ShelGame]

Yeah, I was thinking about doing a little VBA in excel to do the table lookups and calculate the output value. Scaling them is different, though. With the 2D tables, we have a value given for both the X and Y axis. We can just scale that value (and the slope) by the appropriate fraction and get the correct new value. With the 3D tables, the X and Y axis values are implied (thru the 2D transfer tables). So, scaling the x and y -axiis is not so straightforward.

As an example, lets consider a simplified table that has just 3 rows that cover a 2-bar MAP. Basically, to scale for 3-bar, you want to 'move' the data in row '3' to row '2'. Now, row '3' becomes the new 3-bar data and has to be tuned (no problem, similar to the current 2D setup). But, what do you do with the data that previously was in rows 1 and 2? In the scaled table, there would only be 1 row for those 2 data sets to fit into. You can't simply interpolate between them to get the new row '2' data, as then you would be changing the actual shape of the 3D surface. Now, this is a simplified example of course. We actually have 16 rows of data, but we either have to compress it down to 12 rows (and somehow not significantly alter the original 3D profile), or we add 50% more data points to the table to cover the extra MAP range. Either way, the 2+ bar range calibration data will have to be created by the user.

Another way to look at it, is to consider you have a 16x16 2 color bitmap. Now scale that bitmap down to 12x12. Does it look exactly the same as it did at 16x16? No, it doesn't. There's some resolution loss just from scaling it.

This is why I originally thought leaving the 3D tables alone and adding a complete MAP range to them would be the best thing. There should be enough room to do this for a 3-bar MAP.
However, it doesn't help at all when you consider increasing the max RPM from 6100 to 8000. How do you scale the 3D tables for that? Add 2 columns to the table? Space-wise, if we add a couple of rows to expand the RPM range or if you start talking 4-bar MAP (or bigger, gulp), we may start to run out of room.

I don't think processor time is an issue. The 3D lookup seems pretty efficient.

FWIW, the value from the 3D fuel tables is not a PW. It's a scaling factor. I'll run thru the math for the 3D fuel calculations later...

---------- Post added at 01:36 PM ---------- Previous post was at 01:27 PM ----------

Well, I was just looking at some bitmap scaling algorithms. And, averaging the 2 adjacent pixels is exactly what they do. So, I guess maybe it's not such a bad thing afterall.

After thinking about it some more, I think what we need to do is very similar to bitmap scaling, actually.

[ShelGame]

OK, doing a little math here. Someone check me if I'm wrong...

The 3D hiMAP tables are 17x17 currently (=289 bytes per table); if we add 2 rows to get up to 8k rpm, then it becomes a 19x17 table (323 bytes), and if we then make it a 3-bar it becomes a 19x25 (475 bytes) or 4-bar becomes 19x33 (627 bytes).

At the worst (4-bar), that’s 338 bytes bigger than the original table. But, we only have 4 tables that reference hiMAP (loMAP tables would not be affected at all and would not need to be expanded; except for RPM maybe), so we’re only talking about another 1352 bytes total, and that’s for a 4-bar MAP. There’s almost (but not quite) enough room to get that by only moving the start point of the code section.

If we include the extra bytes for the RPM range added to the loMAP tables, we still only talking about another 2x17x5 = 170 bytes...

Of course, with the bitamp scaling parallel, we could both increase the size of the 3D tables and keep the 3D profile mostly intact.

[Aries_Turbo]

sounds like things are possible for keeping resolution and stuff. i bet some smoothing will need to happen anyway for the stock stuff as there was some emissions specific tuning that happened that we dont need to keep when we are shooting for performance. even a state sniffer test isnt going to be as bad as EPA certification testing i would imagine.

so you thinking about just going for the gusto and doing it all in one shot for adding the 3 and 4 bar support and additional RPM?

i should be going over to marks house next friday to do some 2 bar testing but he does have a 3-bar and +40's for the car.

Brian

[ShelGame]

sounds like things are possible for keeping resolution and stuff. i bet some smoothing will need to happen anyway for the stock stuff as there was some emissions specific tuning that happened that we dont need to keep when we are shooting for performance. even a state sniffer test isnt going to be as bad as EPA certification testing i would imagine.

so you thinking about just going for the gusto and doing it all in one shot for adding the 3 and 4 bar support and additional RPM?

i should be going over to marks house next friday to do some 2 bar testing but he does have a 3-bar and +40's for the car.

Brian

I'm still not sure.

Part of me prefers the keep it simple method of keeping the tables the same size as stock and adding the ability to scale either axis for whatever reason. Maybe even expand the size (if the user chooses). I could see some advantages to a 19x19 fuel table, for example, that supports RPM up to 8000 with proper fuelling adjustments.

On the other hand, part of me prefers the idea of keeping the lower ranges closer to stock. The problem there is, there is more chance for code problems due to the possible size of the template.

Personally, I'm leaning toward the first idea right now. But, I'm still very much on the fence. I'm going to try and figure out a scaling method for the 3D tables based on the smooth bitmap scaling concept (in excel for now). I might send you guys a 3-bar cal to try if I can figure out a good way to do it...

[zin]

This might be a bit of a distraction, but given the desire to have higher resolution, and the possible lack thereof due to the bit rate of the ECU, would it be advantageous to run this on a newer/faster SBEC?, assuming the two would be compatible...

Just a thought, now back to your regularly scheduled program...

Mike

[ShelGame]

This might be a bit of a distraction, but given the desire to have higher resolution, and the possible lack thereof due to the bit rate of the ECU, would it be advantageous to run this on a newer/faster SBEC?, assuming the two would be compatible...

Just a thought, now back to your regularly scheduled program...

Mike

There is no newer faster SBEC. The SBECII uses the same processor. And, again, it's not the processor that determines the resolutions. It's the A/D converter with is 8-bit on out ECU's. There are 10- and 12- bit A/D's out there, but at that point, might as well go aftermarket ECU.

[zin]

There is no newer faster SBEC. The SBECII uses the same processor. And, again, it's not the processor that determines the resolutions. It's the A/D converter with is 8-bit on out ECU's. There are 10- and 12- bit A/D's out there, but at that point, might as well go aftermarket ECU.

Just showing my ignorance... I really kind of expected that the newer units would be more capable.

Mike

[wowzer]

rob - i sent u an email. the table called FastDataOutputAddressTable will cause a problem if anybody SAVES the cal and then compiles. a straight compilation will work tho i believe.

[bakes]

is it posible to make a second table for rpm when it gets to the end of the table it flip over to the second table to continue the rpm range?

[ShelGame]

is it posible to make a second table for rpm when it gets to the end of the table it flip over to the second table to continue the rpm range?

It's possible, but it's kind of a hack...

[ShelGame]

OK, 3D fuelling...

Here's basically how the 3D fuel tables work. For now, I'm going to describe just how the 3D tables work and what the values mean. I can get into the 2D input function tables later.

There are basically 3 values used to calculate the 'base' PW in the T3 - MAP Value, Density Factor, and the AirFuel Factor.

Essentially, Base PW = MAPValue x DensityFactor x AirFuelFactor

The Density Factor is a 16-bit constant that is multiplied by MAP and stored for use after the 3D lookup. I labelled this value as AFPART and AFFULL in the template above. I originally thought this value set the target A/F ratio for WOT and P/T operation. But, that's not what it is. So, if you're looking at the pre-release above, keep in mind that the value that looks like it sets the A/F, doesn't. It has a different purpose.

The Density Factor is a constant for converting the MAP Value into a MAP density. The Density Factor assumes a certain air temperature (why they just didn't use the charge temp sensor, I don't know - maybe a failsafe thing). It appears that they assumed a different charge temp for P/T vs. WOT - which makes sense. WOT actually has a lower temperature assumption. Which, again, kind of makes sense. In a way, though, Chrysler kind of screwed up - they used a 16-bit value and scale it by MAP to get a 16-bit value. The scaling routine is kind of long. You get the exact same value if you simply multiply the MAP Value by the upper byte of the Density Factor (in fact, this is how the '92 T1 3D code works).

The AirFuel Factor is a combination of many factors - F/A (Fuel/Air Ratio, inverse of the A/F Ratio); Pumping Efficiency, Engine displacement, fuel injector flow rate, fuel density, and some constants. The AirFuel Factor is what is stored in the 3D tables as an 8-bit value. It's not a PW, it's a factor from 0-100% that is all of the factors above multiplied together.

What's really important, is that the 3D tables value can simply be scaled for injectors like the older 2D tables (or for fuel density, or engine displacement, etc.). The problem is, there is no way to separate the pumping efficiency from the target F/A since they combined the factors. We could make the assumption that the F/A is a constant over the entire table, but I think that's not likely to be the case.

Since the DensityFactor and the AirFuel Factors are simply multiplied together, it is possible also to move the scaling for injectors to the 16-bit DensityFactor to simplify the scaling. Though, it's not technically correct...

Outside of this 'base' PW calculation, the PW is modified almost identically to the 2D cals - the cold start enrichment (the A, B, C tables), transient enrichment, spark scatter fuel, and the adaptives all work exactly the same to modify the 'base' PW. The only difference being that the PumpEff table is set to 100% in the 3D cals (it IS still in there, though) since that factor has been moved to the 3D tables.

[ShelGame]

Here's an updated .asm and template with the DensityFactor values correctly named. I also set them up to be scaled for injectors. So, theoretically, this cal can now be scaled for injectors. I'd like to have someone test it out to see if it works correctly for injector scaling.

The template/MP Tuner are still not setup yet for MAP scaling. This cannot be properly scaled for a 3-bar MAP at this time...

[wowzer]

...theoretically, this cal can now be scaled for injectors. I'd like to have someone test it out to see if it works correctly for injector scaling.

.....

see post 75. saving the cal with mptuner using the template will not work. if you need to make any changes you can only use the bin/tbl file. loading the template file will corrupt the noted table. again, compile the template FIRST then modify the bin file.