Turbonator T3

[ShelGame]

Turbonator T3 (SBEC-I and II) Codebases

Features:

1) Knock Indicator – This feature flashes the ‘Check Engine’ lamp whenever the timing is being retarded due to knock. It’s a useful feature to feedback to the driver when you should back off to save your engine.

2) Switchable boost – This allows a ‘LOW’ boost setting to be used when a switch is applied. Unfortunately, it must be one of the existing inputs to the SMEC (Cruise, A/C, P/N switch, etc.). But, these can be ‘doubled up’ – IE, you can have the cruise on/off switch work for both hi/lo boost as well as cruise. This is similar in operation to the S60 boost switch feature, though without the timing adjustment for low octane fuel.

3) Staging Limiter (2-Step) – This feature allows a lower than normal rev limit to be set. This lower limit can be enabled by a low speed cutoff (usually 2-10mph), and/or a switch (usually the brake switch for auto cars). The lower rev limit is useful for launching the car in a drag race.


5/17/12 - T-T3 v1.3 Now Posted:
Compatible with MP Tuner 2 (only - MAP scaling is not supported by MP Tuner 1)

- Updated the template to the new grouping
- Fixed a couple of table scale issues
- Added MP Scan data to RAM for simple setup
- Updated the pre-built 3-bar cal with corrected low-MAP range fuelling - AND - corrected lo-map scaling for +40's...



5/14/11 - T-T3 v1.2 for SBECII T3's (1992-93)now posted:
Compatible with MP Tuner 2 (only - MAP scaling is not supported by MP Tuner 1)

Update Posted 07/23/12 - Fixed an issue with the staging limiter code that would cause total fuel shutdown when the rev limit was reached.
Update Posted 12/14/12 - Updated some code definitions, and many updates to the 3-bar +40 per-built cal.




Same changes as above.

[Pat]

Awesome. How soon do you think?

Thanks for doing all of this. I've been lurking/reading and tinkering for a bit now to learn. I'm excited to see where this goes.

Pat

[risen]

Nice, I'm definitely interested in poking around in the code (so prepare for a barrage of "I don't get this" emails :) ) Will this be for all T3 ecus or just the SBEC-I based ones? I assume the templates will allow arbitrary map and injector scaling like your other cals do?

[wowzer]

Coming soon! This is just a teaser thread. :)

I have just about finished the dis-assembly of the T3 cal.


is this for a sbec1 or sbec2

[turbovanman²]

Once again Rob, :hail::hail::hail:

[zin]

The wheels of my mind are spinning.... :thumb:

Mike

[ShelGame]

Awesome. How soon do you think?

Thanks for doing all of this. I've been lurking/reading and tinkering for a bit now to learn. I'm excited to see where this goes.

Pat

Honestly, it's about a weeks worth of work. But it'll take me a month at least to it, and that's assuming I don't get a SDAC rush for cals...

[ShelGame]

Nice, I'm definitely interested in poking around in the code (so prepare for a barrage of "I don't get this" emails :) ) Will this be for all T3 ecus or just the SBEC-I based ones? I assume the templates will allow arbitrary map and injector scaling like your other cals do?

Yes and no. It will but that's where the tuning isue will come into play. With the 2D cals, you can cale for 3-bar and everything will run as normal up to the 'old' 2-bar settings. You, of course, have to tune over 2-bar for timing and boost.

With the 3D cals, scaling for 3-bar will scale the input tables to the 3D tables. But, it won't automatically re-scale the 3D tables. So, when scaling the T3 for 3-bar, it will require the 3D tables be re-worked in boost. Not a huge deal, but slightly more work than simply hitting a button in MP Tuner. I'm thinking if there's a way to make the process easier...

[ShelGame]

is this for a sbec1 or sbec2

SBEC-I, I haven't started into the SBEC-II T3 code much. From what I've seen, it should be pretty easy to do. Eventhoug the code is different, the tables are almost all the same. It should be pretty easy to figure out.

[Aries_Turbo]

I'm thinking if there's a way to make the process easier...

im thinking that doing all the scaling once and making individual templates for 2, 3 and 4 bar would be the easiest for the long term.

im thinking that doing all the scaling for both 2.2L and 2.5L beforehand and making an individual template would making things less painful as well.

and if you are getting fancy, doing injector scaling templates for stock, +40's, 72lb, 75lb, 83lb, 95lb and 120lb would make it easier. (screw +20's...go big or go home :))

i know its a fair amount of work now but i think it will make things simpler for you in the future.

you could farm out some of the tedious work to us if you are super overwhelmed.

Brian

[ShelGame]

I hadn't even thought about scaling for injectors. I think that should be pretty straight forward - much like the 2D cals, but I haven't really looked into it yet. Not sure how MP Tuner will deal with scaling the 3D tables for injectors...

[wowzer]

I hadn't even thought about scaling for injectors. I think that should be pretty straight forward - much like the 2D cals, but I haven't really looked into it yet. Not sure how MP Tuner will deal with scaling the 3D tables for injectors...

should be pretty straight forward since the injectors should be simply a math calculation, although i don't understand what the "units" are in the t3 3d fuel tables. is that a percentage or a fixed constant? if you can let me know i'll start making the programming updates.

i think the problem will be changing map resolutions, e.g. 2 bar to 3 bar. either we need to add "rows" to the 3d table on the fly to keep the same resolution or move the rows around to try to make it work.

suggestions?

[ShelGame]

should be pretty straight forward since the injectors should be simply a math calculation, although i don't understand what the "units" are in the t3 3d fuel tables. is that a percentage or a fixed constant? if you can let me know i'll start making the programming updates.

i think the problem will be changing map resolutions, e.g. 2 bar to 3 bar. either we need to add "rows" to the 3d table on the fly to keep the same resolution or move the rows around to try to make it work.

suggestions?

I went thru the 3D PW tables once before and I think I figured it out. But, I need to go thru it again to make sure.

I don't know about adding rows. Each row adds quite a bit of data. If we add rows to eacc 3D tables, we'd need a lot of additional data storage space. On the other hand, you don't necessarily need such high resolution in the 'middle' boost range - since you'll basically be 'just passing thru' those ranges as the turbo spools up. Anyway, it needs some thought.

[Aries_Turbo]

how bad would linearizing those tables be. i know all the points would need to be rescaled so that they act like stock, but do that once and the other scaling operations would be easier would it not?

Brian

[wowzer]

how bad would linearizing those tables be. i know all the points would need to be rescaled so that they act like stock, but do that once and the other scaling operations would be easier would it not?

Brian

linearizing?!?! nice word - what do u mean exactly;)

in the sbec2 code i've looked at there is ALOT of unused space in the table regions as well as being able to move the code up higher in the address space. the 3d code does allow the program to go directly to a cell for a value versus working its way up the "ladder" to find the right slope area like in a 2d table.

e.g. if a 1 bar 3d table uses 17 rows by 9 columns (153 bytes - need the extra row for interpolation), adding another "bar" should only take another 16 rows by 9 columns (144 bytes). problem is (potentially), the routine i think is limited to accessing only 255 bytes without a modification to the routine.

[risen]

Well, I guess I'll toss my .02 in on this 3d scaling thing. What about having the ASM having one *large* (64x9) table with values from 30in hg to +42 psi in every cell, with good resolution. Then you can have mptuner either copy the table in as the 1st 17 rows (two bar), every other row up to 17 total (three bar), or every 3rd row up to 17 total rows (four bar). That would also let you do the funny fractional bar map sensors. I know it seems like a lot of work, but it would seem to be the most flexible approach. And if someone wanted 5/6 bar (if such a beast even exists) you could just add the rows to the ASM and not have an effect on anything else, then mptuner would have to stride by (bar - 1) rows to build the cal.

[Aries_Turbo]

linearizing?!?!

meaning....

the redefine the low map and high map ranges so they are scaled linearly from -14.7psi to 29.4psi for a 3-bar and -14.7 to 44.1psi for 4 bar.

so the low map and high map range will be different from stock and ALL of the values will need to be rescaled so that the stock -14.7psi to 14.7psi range is fairly accurate to stock values.

low map and high map ranges will also be different for a 3-bar and a 4bar application.

the other thing that could be reasonable to do if the map range is made fully linear over lowmap and highmap, is that both maps could be then shown on the same table screen side by side for ease in tuning.

i could care less about increased resolution for emissions reasons. ease in tuning would be much nicer.

brian

[iTurbo]

Would love to have a SBEC-I 2.5L TIII cal soon. Considering the gasoline available around here, running the motor on a stock TIII cal is going to be asking for a lot of problems..

[CaptMoe]

any updates?

[ShelGame]

Morris made a test version of MP tuner for me to try and scale a T3 cal with. I've been working on a major revision to T-LM, so I haven't teted it yet. It's next on the list...

[zin]

I'm anxiously awaiting this version, as it seems to me to have potential to make the others kinda obsolete... Would the code run on a SMEC or is the computing power just not there? This assumes that the 3-d tables would be more intuitive/easier to manipulate... But then these are the words of someone who has yet to burn his 1st chip!:o Guess I'm just a technology whore! Gotta have the "best" stuff!:lol:

Mike

[1BADVAN]

... we'd need a lot of additional data storage space. On the other hand, you don't necessarily need such high resolution in the 'middle' boost range - since you'll basically be 'just passing thru' those ranges as the turbo spools up. Anyway, it needs some thought.

I am by NO means any good at understanding the computer process yet, but my thought on this theory of lowering the "middle boost" resolution is this. What about the guy who wants to set the max boost to 21 psi (a middle boost for a 3 bar) is he going to have issues with the low resolution?

My idea would be a low resolution for low boost like under 13psi cause that is where less problems would occur if using a lower resolution.

Like i said maybe i am way off but this is what made sense to me theoretically. :confused2:

[ShelGame]

Actually, I don't think it's going to be an issue. Should be able to have high resolution on all 3D data points. I may have to move the start point of the code section to accommodate the bigger tables, but that's not really a big deal...

[1BADVAN]

sweet this is motivation for me to get my R/T together again

[turbovanman²]

I'm anxiously awaiting this version, as it seems to me to have potential to make the others kinda obsolete... Would the code run on a SMEC or is the computing power just not there? This assumes that the 3-d tables would be more intuitive/easier to manipulate... But then these are the words of someone who has yet to burn his 1st chip!:o Guess I'm just a technology whore! Gotta have the "best" stuff!:lol:

Mike

What he said, :eyebrows:

[zin]

Here's an idea on the problem of resolution of the MAP, since the difficulty is due to the fact that as the max boost goes up, all we can do is more finely chop up the 0-5V signal, which starts to make "noise" more and more dangerous, what about soldering onto the board a pressure sensor that could use a 0-12V or some other larger voltage range?

I've seen this done on a stand-alone, they had a built in 5 bar sensor, but still had excellent resolution in a N/A application, I figure it is because it is using a larger voltage range...

Anywho, just my .02.

Mike

[ShelGame]

The problem there is that the A/D converter in our ecu is only 8-bit. Changing to a 12 volt system really would make no difference.

[zin]

The problem there is that the A/D converter in our ecu is only 8-bit. Changing to a 12 volt system really would make no difference.

So... The hardware won't see the larger "scale" that a higher voltage MAP would bring? Or is it that you can only chop the signal into so many pieces regardless of the voltage? If the latter, I would think it would still be an advantage, but only as a means of reducing "noise"....

How about using a digital signal? Any way of getting that into the "box", or is this a non-problem?

Mike

[ShelGame]

Right. It doesn't matter what the voltage is - it's going to be segmented into 256 steps. So, if it's 5v or 12v doesn't matter. A 2-bar map will have the same resolution with an 8-bit A/D. If we could somehow change to a CPU with a 10- or 12-bit A/D - that would help.

It's not really a big deal anyway. We have 2D cals runnign 3-bar MAPS with no driveability problems and passing emissions. The 3D cals will be more accurate, so I don't see an issue...

[zin]

It's not really a big deal anyway. We have 2D cals running 3-bar MAPS with no driveability problems and passing emissions. The 3D cals will be more accurate, so I don't see an issue...

That's what I was wondering, so it's really a non-problem... Now, when I start running a 5-bar cal.... ;)

Mike

[DoubleD]

Any update on this, Looking forward to putting this on my IROC?

[ShelGame]

OK, so I had an aha moment today. Been working on figuring out how the main PW is calculated in the T3 cals and I figured the math out today!

Actually, the .asm and the template for the '91 T3 are pretty much done. I need to do some tests to make sure it compiles back to stock code, then I can add the turbonator features. That should be no problem as it will be the same as T-SBEC for the SOHC 2.2 and 2.5.

Morris has been working hard on MP Tuner 2. Many of the features required to properly scale a 3D cal are already in MPT2, hopefully we can get it all worked out before he's ready to release it. The MAP scaling is nearly done. And, now that I have a full grasp of the fuelling, we can get that scaling ready to go.

The '92 T3 will be next behind the '91 as it's nearly identical to the '91 except for some hardware interface differences. '92+ T1 will be right after the T3...

[Aries_Turbo]

sahweet!!!!

Brian

[ShelGame]

Oh, I meant to post a request - I'm going to need a beta tester. I do still have my father-in-laws Spirit R/T. As long as it's still around I can use it for testing. But, it's up for sale. If it goes I won't have anything to test with.

So, I need someone who can test the code; But there are a few requirements:

1) Test bone stock cal made from the Turbonator ASM
2) Test with a 3-bar big injector cal (+20 or +40, etc. it doesn't matter really)
3) Can burn your own cals

Any takers?

[Aries_Turbo]

calling mark brooks, calling mark brooks..... well as long as i bring my burner and he gets a latch adapter. :)

Brian

[mark]

calling mark brooks, calling mark brooks..... well as long as i bring my burner and he gets a latch adapter. :)

Brian

I'm in. Tell me what I need to buy brian and you can play with my car :)

[Juggy]

your makin me want to rig up my car for the 92 SBEC now....lol...

[shackwrrr]

I have an ostrich, stock car at the moment and a 3 bar and +40s in the drawer. Just have to buy another latch adaper from you.

[ShelGame]

Hmm, sounds like I need to bust out the soldering iron and put together some more latch boards...

[shackwrrr]

Hmm, sounds like I need to bust out the soldering iron and put together some more latch boards...

If I had a good desoldering iron I could just nab the one from the sbec you built for me. the shadow isnt going anywhere.

[ShelGame]

OK, I have successfully built a stock binary from my source code - let the frankensteining begin...

My plan is to first add in the Turbonator features, copied over directly from T-SBEC. The first round of testing will be stock injector, 2-bar cals only since MP Tuner is not quite ready to scale the 3D tables. The Turbonator features should be OK (Anti-lag, Staging limiter, CE Flash, etc.) though...

[shackwrrr]

Kool, Ill get that latch adapter ordered when I have the money.

Any bad stuff that can happen trying to desolder that other latch adapter? If not then Ill just pick up a desolder iron and nab that one.

[Pat]

OK, I have successfully built a stock binary from my source code - let the frankensteining begin...

My plan is to first add in the Turbonator features, copied over directly from T-SBEC. The first round of testing will be stock injector, 2-bar cals only since MP Tuner is not quite ready to scale the 3D tables. The Turbonator features should be OK (Anti-lag, Staging limiter, CE Flash, etc.) though...

Excellent! Can't wait to see how this pans out.

[DoubleD]

Awesome, I would be willing to test the 92' T3 once its ready I have my IROC R/T just about back together but I dont have the stock cal parts, car came with 3 bar map, +40 injectors, 50 trim, FMIC and all the goodies. Now including a 255 walbro and Innovate Wideband O2 with data logging. Really want to get this car on corn in the near future too!

[ShelGame]

Kool, Ill get that latch adapter ordered when I have the money.

Any bad stuff that can happen trying to desolder that other latch adapter? If not then Ill just pick up a desolder iron and nab that one.

If you get the latch board too hot I suppose the solder could leach out of the header or socket joints...

[shackwrrr]

If you get the latch board too hot I suppose the solder could leach out of the header or socket joints...

alright, I think I can manage to get it as long as I have a proper desoldering iron. I desodered a chip on a LM once and that was a major pita with just a little sucker bulb and some braid.

[turbovanman²]

Awesome Rob, :hail:

Too bad the R/T I have here is a 92, I'd love to have an excuse to drive it around for a few weeks/months, :evil:

[ShelGame]

alright, I think I can manage to get it as long as I have a proper desoldering iron. I desodered a chip on a LM once and that was a major pita with just a little sucker bulb and some braid.

I always just cut the pins of the chip with my dremel, then pull the pins individually. The chips aren't worth the effort to save if you ask me. Unless it's a cal I don't already have; but I can get the cal off a SMEC and SBEC without opening up the computer.

[shackwrrr]

I always just cut the pins of the chip with my dremel, then pull the pins individually. The chips aren't worth the effort to save if you ask me. Unless it's a cal I don't already have; but I can get the cal off a SMEC and SBEC without opening up the computer.

It was a FWD stage 5 but then I learned that its a really old one and was known for killing engines.

[shackwrrr]

I picked at the hot glue for about 30 sec and gave up. Not worth the 30 bucks for a new one.

[ShelGame]

Awesome Rob, :hail:

Too bad the R/T I have here is a 92, I'd love to have an excuse to drive it around for a few weeks/months, :evil:

'92 T3 won't be too far behind...

[eski]

'92 T3 won't be too far behind...

Wheee.....!

[ShelGame]

OK, here she is - a relocatable source code for the T3. This has the basic Turbonator Features added (CE Flash, Switchable boost, Staging Limiter, Shift light and Anti-Lag). It compiles without any errors, and as far as I could tell there were no code overlaps or similar type of issues.

Notes:
1) I have NOT run this on my own T3 yet, but I hope to later this week. It has not been tested at all. Though, before the Turbonator mods were added, this did compile back to 100% stock code. So, I have confidence the code is bug-free.
2) The features are the exact same code as Turbonator SBEC (which is pretty much proven OK), so there should be no issues there.
3) This will compile with MP Tuner - HOWEVER!!!! MP Tuner will NOT correctly scale this template for MAP or Injectors. Don't even try it. It will have no effect on the 3D fueling surfaces and bad things will happen to your engine if you try to run your car on a scaled version of this template. You've been warned. We will have to wait for MP Tuner 2 to be ready for prime time to get proper scaling of the 3D tables. But, I wanted to get the testing started on this so that when MPT2 is ready, it should be relatively easy to update it.

So, feel free to try this as a modified stock cal (2-bar MAP, 33pph injectors) with the Turbonator features turned on. Let me know what works or doesn't and we'll get it all fixed up.

Oh, and the version # is currently 1.0 eventhough the template says .v07. When we get MPT2, I'll fix that also. Morris used .v01 as a debug template code for MPT1, so I couldn't use it.

Attachment removed, added update in later post. Go here (http://www.turbo-mopar.com/forums/showthread.php?48949-Turbonator-T3&p=803604&viewfull=1#post803604) for the latest files...

[turbovanman²]

Damn, wish I had a working 91 R/T.

[mark]

Thanks Rob!

[ShelGame]

FWIW, I have the '92 T3 code 99.9% disassembled right now. I need to figure out 4 tables that are actually different code from the '91. Transient fuelling, of course. I still don't understand why Chrysler changed the transient fuel code every single year... :banghead:

After those 4 tables, I need to convert the dis-assy to a template format, and test that it re-compiles. Then it will get posted too. Figure maybe 3-4 weeks...

I love slow weeks at the office, can really get a lot of work done :)

[eski]

I still don't understand why Chrysler changed the transient fuel code every single year...

That's one way to keep programmers busy or programmers try to keep their job with new features. New code, new features (to save fuel.. etc). :) well what do I know.. I don't program for living..

[ShelGame]

My gut feeling is they had some emissions issues in that area and had to change it to meet the law. I can't see any other reason to change that particular section of code so often...

[ShelGame]

OK, how about starting some discussion about how to scale the T3 (actually, all of the 3D cals) for 3-bar MAP. Actually, scaling the 3D cals for 3-bar is easy. I could make a couple of changes to the source code posted above and it would run on a 3-bar MAP. The problem is, the fuel and spark tables would still have the same range as the stock 2-bar cals. But, it should run just like stock on a 3-bar MAP.

So, I guess the real question is, how to setup the 3D tables for a 3-bar MAP. My original idea was to expand the 3D tables range so that the resolution in the 2-bar range was affected the least. However, this will add a TON of data to the template. Possibly forcing me to move code around to make space. The extra needed space would double for a 4-bar MAP wit that philosophy. On the other hand, if you are going to run a 3-bar MAP, you're not likely to run only 10psi of boost, right? So, now I'm thinking we can leave the 3D tables at their current size and concentrate on the low and high ends of the scale. Unfortunately, that means more tuning for the user. Unless I can figure out a way to automate the process and wowzer can code it into MP Tuner 2. I'm going to send him a note as well and see what he thinks about this stuff...

[Aries_Turbo]

since passing crazy EPA certification tests are the least of our worries, id want to linearize the range and, at the same time, recalculate the values, so they are still the equivalent of stock.

you know what i mean? make those scaling factors a straight line and recalc the values so that the injector pulsewidth still is pretty much the same as far as the engine is concerned.

as far as more points... we are still at a 0-5v range so we are going to lose some resolution. i see some need for added resolution with higher map ranges but i dont think it will be that critical to double or triple the table size.

im afraid that adding all kinds of data will slow down the computer. so when its pecking its way up the map values it will have to go twice as far till it can grab a fuel pulsewidth. i dont know exactly how it determines what bin to be in, but it will have to do some more calculating if the range is greater.

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

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

30461

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.

[ShelGame]

Oh, right. I forgot about that. It's kind of OK since that table is only used by the DRBII for one of the data display modes. Not an essential running function. Unless of course it totally screws up the binary when it's assembled.

What was the problem with that table anyway? There are 3 similarly structured tables in T-SBEC. Though, they are essential tables for engine running...

[wowzer]

the table bytes refer to locations via a label versus the actual byte. i need actual bytes in the template for mptune to work. the locations are not resolved until compilation.

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

Anyone test this out yet? Looking for some feedback...

---------- Post added at 01:24 PM ---------- Previous post was at 01:23 PM ----------


the table bytes refer to locations via a label versus the actual byte. i need actual bytes in the template for mptune to work. the locations are not resolved until compilation.

OK, I changed the table to use the actual address (in HEX) rather than the reference. This should be OK, I think.

I'll post that update as soon as I get some feedback. I'd like to roll any other changes up with the next release...

[Aries_Turbo]

not yet, i hope to get to marks sometime soon to try it.

[Aries_Turbo]

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.

ok, im just getting things ready to test over at mark's.

i compiled the file and then opened it in MPTuner. i got some errors. I dont know if they will pose a problem.


C:\MPTuner\cals\T-T3v1\T-T3_22_T3_MTX_A393.bin - line number: 0
X max value for table LB600 (LB600) was set to 255 vs 65535

C:\MPTuner\cals\T-T3v1\T-T3_22_T3_MTX_A393.bin - line number: 0
X max value for table LB610 (LB610) was set to 255 vs 65535

C:\MPTuner\cals\T-T3v1\T-T3_22_T3_MTX_A393.bin - line number: 0
X max value for table LB612 (LB612) was set to 255 vs 65535

C:\MPTuner\cals\T-T3v1\T-T3_22_T3_MTX_A393.bin - line number: 0
X max value for table LB613 (LB613) was set to 255 vs 65535

C:\MPTuner\cals\T-T3v1\T-T3_22_T3_MTX_A393.bin - line number: 0
X max value for table LB615 (LB615) was set to 255 vs 65535

C:\MPTuner\cals\T-T3v1\T-T3_22_T3_MTX_A393.bin - line number: 0
X max value for table LB616 (LB616) was set to 255 vs 65535

C:\MPTuner\cals\T-T3v1\T-T3_22_T3_MTX_A393.bin - line number: 0
X max value for table LB617 (LB617) was set to 255 vs 65535

C:\MPTuner\cals\T-T3v1\T-T3_22_T3_MTX_A393.bin - line number: 0
X max value for table LB620 (LB620) was set to 255 vs 65535

C:\MPTuner\cals\T-T3v1\T-T3_22_T3_MTX_A393.bin - line number: 0
X max value for table LB7E0 (LB7E0) was set to 255 vs 65535

C:\MPTuner\cals\T-T3v1\T-T3_22_T3_MTX_A393.bin - line number: 0
X max value for table LB7E1 (LB7E1) was set to 255 vs 65535

another thing that posed a question is this:


What's really important, is that the 3D tables value can simply be scaled for injectors like the older 2D tables

I didnt see the 3d tables included in the scaling for injectors list.... unless i missed something.

Mark has +40's in the car and it would be really awesome to not have to swap stockers in there cause i have a few sets but i really dont know the exact condition of them. i wouldnt want the injectors to be all gummed up and to act up, making us think that the cal is messed up when it was mechanical bits.

I know his +40's are in good shape.

Thanks

brian

[ShelGame]

ok, im just getting things ready to test over at mark's.

i compiled the file and then opened it in MPTuner. i got some errors. I dont know if they will pose a problem.

None of those will be a problem, but I'll fix it for the next release so that they don't popup...




I didnt see the 3d tables included in the scaling for injectors list.... unless i missed something.

Mark has +40's in the car and it would be really awesome to not have to swap stockers in there cause i have a few sets but i really dont know the exact condition of them. i wouldnt want the injectors to be all gummed up and to act up, making us think that the cal is messed up when it was mechanical bits.

I know his +40's are in good shape.

Thanks

brian

MP Tuner won't scale the 3D tables correctly for injectors(yet). So, I moved the injector scaling to the density factor for this release. It's not technically the correct place to put it, but it should work the same as scaling the entire 3D table. Read my T3 fueling notes a page or two back if you missed it...

I guess my preference would be to run it completely stock first, just to make sure there are no problems with the code anywhere. Then switch to the +40's and scaling for injectors. If you just start out with the +40's, and there's an issue, it's harder for me to figure out where to start looking for the problem.

But, I understand your point, too. No sense using hardware in unknown condition; it could cause the same problem. So, go ahead and try it with the +40's if you think that's best.

I can actually try a stock build on my father-in-laws R/T. Just have to dig up the flashable T3 SBEC I built and plug it in...

[Aries_Turbo]

ill dig up some injectors and try them but ill also try it with the +40's first.

i figured you might have did the density scale when i didnt see the tables included. yeah i read all that stuff :) i just wanted to be on the same page before i started trying to scale stuff and whatnot.

Brian

[ShelGame]

ill dig up some injectors and try them but ill also try it with the +40's first.

i figured you might have did the density scale when i didnt see the tables included. yeah i read all that stuff :) i just wanted to be on the same page before i started trying to scale stuff and whatnot.

Brian

I guess Morris just posted a new MP Tuner (1.2.2) that can scale the 3D tables. So, for the next test release, I'll move the fuel scaling to the 3D tables.

[wowzer]

I guess Morris just posted a new MP Tuner (1.2.2) that can scale the 3D tables. So, for the next test release, I'll move the fuel scaling to the 3D tables.

This update hasn't been tested alot so be careful. was kinda a "stealth" update!! i'll do more testing on it this weekend when i get a chance.

[mark]

Just an update. Yesterday brian (aries turbo) came over. We put in a burned chip, latched sbec and put a 2 bar in and left the 40's in. Result was a tac needle erratic, no fuel prime, otc2000 showed no connection. Brian didnt have burner so we could not do much after that. Hes gonna double check code. His socket job is nice i got a pic i can upload if any one wants to see it.

[Aries_Turbo]

rob, ill email you those files hopefully tonight. didnt get to it last night.

Brian

[ShelGame]

just an update for everyone watching at home...

Playing around with T-T3 and MP Tuner 2 this morning yields good results. Scaling for 3-bar seems to be working (though not tested on a car); even 4-bar scaling worked without a space issue.

Injector scaling seems to work also with the 3D tables selected for scaling.

This is all with MP Tuner 2, mind you. The MAP scaling still won't work right in MP Tuner 1.x.

If Brian and I can get the bugs worked out of T-T3, it should be ready to release when MPT2 is ready...

[ShelGame]

OK, I loaded up T-T3 on my flashable SBEC and tried it in my father-in-laws R/T this morning. It started and ran (and this was with my latest .asm, with some of the code relocated). It did hunt a little at idle and it hesitated blipping the throttle. So, I think I have an error in the template data somewhere. But, it DID run. Which means we're (hopefully) just a few steps away from releasing this code...

Brian - I sent you a PM about what I think is going on with Marks car...

[Aries_Turbo]

oh, so this isnt a totally relocatable source just yet?

yeah i really cant test again till i get a burner that can do UV erase eproms well if the 27SF chips arent cooperating with the latch chip.

brian

[ShelGame]

oh, so this isnt a totally relocatable source just yet?

yeah i really cant test again till i get a burner that can do UV erase eproms well if the 27SF chips arent cooperating with the latch chip.

brian

None of the 32k sources are totally relocatable due to the EEPROM window from B600-B7FF. You'l always have to manually check that the code doesn't overlap that window when you move stuff around...

[Aries_Turbo]

ahhh, makes sense.

[DoubleD]

Looking forward to this being released. Ready to start tuning my car and not rely on anyone else to do it for me. I like my current cal but its limited to 20 psi and Im not happy.

[ShelGame]

Anyone else get to do any testing with this yet? I'm going to try it again tonight with my R/T. But, I'm going to be doing a little confirmation test for T-SBEC with it also...

[mark]

I ordered a new burner last week after talking to brian. once that comes in and we both have time we are ready for another round.

[ShelGame]

So, I got some good testing in today. There were a couple things I changed (just because T-SBEC had an issue). And, I had a little setback. The staging limiter doesn't work. I was using a RAM location that is located on the peripheral/bus controller chip. I'm not even sure the memory exsists where I'm assigning addresses for the staging limiter. And, of course, it doesn't work. So, I need to do a little more research first.

But, I did get T-T3 running and even drove it around the block. The stock build runs like stock. Next step is to build a 3-bar version and see if it runs like stock...

I'll post an update tomorrow.

[mark]

Thanks so much rob for your work!

[ShelGame]

The Staging limiter code should be fixed and working. but, I have not had the chance to test it yet as-is.

The MPT2 version is ready to go - as soon as Morris releases it, I'll post T-T3 for general consumption.

Also, we'll need a little primer on converting the T3 code to 3-bar. Just like the 2D cals, the code and tables will be scaled to work with the 3-bar (or 4-bar) MAP sensor automatically. However, the table data will not be automatically scaled in the 2+ bar range - ie, the added range will need to be tuned. This is the same as the 2D code. Tuning the 2D code can be as simple as moving 1 data point - but usually involves adding a point or 2 also. In the 3D case, the code will automatically add a complete section to the 3D table(s). But, the added data will be the same as the data in the last row/column of the original 3D table. What this means is the user will have to tune ~8x16 3D data points for each affected table (1 fuel table and 3 spark tables). That's going to be the tricky part...

[ShelGame]

V1 is released. MAP scaling has been tested and appears to be working. Though I have not had the chance to try it on my R/T yet.

[CNH320]

Awesome Rob! :clap: I wish i still had a t3 just to test this out... :nod:

[Aries_Turbo]

you gonna put v1 in the first post?

[ShelGame]

you gonna put v1 in the first post?

Maybe refresh your browser? It was posted this morning... http://www.turbo-mopar.com/forums/showthread.php?48949-Turbonator-T3&p=655723&viewfull=1#post655723

[Aries_Turbo]

strange. all i see in that first post is a stock 91 t3 bin file. on two browsers.

brian

[CNH320]

Same thing here Brian, when i save it to my desktop it saves it as 91_t3.bin not a zip file??

[ShelGame]

Doh! Looks like I posted the wrong .zip... my bad... I'll have the right one up later this morning.

[ShelGame]

OK, try it now. The correct files are posted...

[ShelGame]

Just to tease you IROC R/T guys - I just finished up my '92 T3 disassembly today. I still need to convert it over to the template format and test the re-assembly. But, I think I can have that done next week...

[zin]

Just to tease you IROC R/T guys - I just finished up my '92 T3 disassembly today. I still need to convert it over to the template format and test the re-assembly. But, I think I can have that done next week...

Just out of curiosity, are these cars using the SBECII? I'm curious if this will open up a new source of computers and if there would be any significant benefit to using these newer ECUs....

Mike

[ShelGame]

Just out of curiosity, are these cars using the SBECII? I'm curious if this will open up a new source of computers and if there would be any significant benefit to using these newer ECUs....

Mike

Yep, SBECII. No advantage for a 4 cylinder - it uses the same processor at the same speed. But the 6-cylinders engines (V8's, too) all got full-sequential injection with the SBECII. The T3 code between the SBECI and SBECII is nearly identical except for some hardware interface differences.

[Aries_Turbo]

i went to scale this cal and it didnt seem to scale at all. the range was still 2 bar.

i mentioned it in the mptuner thread.

here are some screen shots of what happens after i reopen the new file.

3155231553

[ShelGame]

i went to scale this cal and it didnt seem to scale at all. the range was still 2 bar.

i mentioned it in the mptuner thread.

here are some screen shots of what happens after i reopen the new file.

3155231553

Did yo usave it before closing? In MP Tuner 2, you need to save the table data before closing the table window; and you need to save the template file. You'll notice there are 2 'save' buttons...

EDIT: Nevermind, I get the same thing. I think the issue is with the Z-axis scaling. MP Tuner seems to be getting confused about the axis to be scaled for the 3D tables (hence the errors). It's adding the extra rows to the 3D tables, but not re-scaling the MAP axis values...

[wowzer]

see the mptuner forum for an update.

[Aries_Turbo]

ok, it added the points.

now i need to add the point to the map 2d thing and then do some editing,

brian

[Aries_Turbo]

why does it only go to 26psi and 61xx rpm?

i see the rpm transfer function but i dont dare change it as i wouldnt want to have to retune all those points.

[ShelGame]

why does it only go to 26psi and 61xx rpm?

i see the rpm transfer function but i dont dare change it as i wouldnt want to have to retune all those points.

'Cause that's what Chrysler tuned it for. Not sure why they stopped the RPM range so low, though. It doesn't make any sense to me.

I had it on the wish-list for Morris to be able to insert a row or column to a 3D table so that the range could be increased without having to re-tune the stock 3D sections. But, he hasn't had the chance to add it yet.

If it only goes to 26psi, it must be beacuse the point you added to the HIMAP transfer table only goes to 26psi. Post a screenshot of HIMAP...

[eski]

Just to tease you IROC R/T guys - I just finished up my '92 T3 disassembly today.

Don't forget few of us who have '92 spirit ;)

[5DIGITS]

'Cause that's what Chrysler tuned it for. Not sure why they stopped the RPM range so low, though. It doesn't make any sense to me.

I had it on the wish-list for Morris to be able to insert a row or column to a 3D table so that the range could be increased without having to re-tune the stock 3D sections. But, he hasn't had the chance to add it yet.

Rob, this was due to interrupt servicing at high RPM.
The system is heavily taxed in stock form and adding additional workload further reduces the ability to completely service routines at high RPM.
The controller used the existing upper breakpoints up to fuel cut-off to limit over-head and the additional map/rpm checks.

[Aries_Turbo]

'Cause that's what Chrysler tuned it for. Not sure why they stopped the RPM range so low, though. It doesn't make any sense to me.

I had it on the wish-list for Morris to be able to insert a row or column to a 3D table so that the range could be increased without having to re-tune the stock 3D sections. But, he hasn't had the chance to add it yet.

If it only goes to 26psi, it must be beacuse the point you added to the HIMAP transfer table only goes to 26psi. Post a screenshot of HIMAP...

31611

heres the transfer function.

Brian

[Aries_Turbo]

rob,

i tried what you told me to do in the PM. it still doesnt show the fullthrottle from himap reaching 29psi. the last number range stops at 26. there appears to be a one row of values after the ones labeled 26 though.

is the image in the last post showing correctly?

i dont exactly know what the transfer function does. why is the Y axis 14.7psi max?

brian

[wowzer]

rob,

i dont exactly know what the transfer function does. why is the Y axis 14.7psi max?

brian

the y axis is really just an output value, it really isn't psi but just a value used as input to the 3d table. that axis needs to be scaled (as well as the x axis). in mpt1, "psi" was how the program knew if an axis needed to be scaled so it probably is just a carryover from that. in mpt2, the scale "code" is its own command and is controlled by the scale/map tables menu option. you could/should go into that table and change the y axis stuff to something like, (min) = 0 , (max) = 255, (desc) = 3d input, (units) = units. that probably makes more sense.

the last row is used to calculate the table value for all maps > 26+ using interpolation.

the image is correct. a point was added to the table by clicking on a data grid row, pressing insert, adding pt 4, then setting the x and y to 255.

[Aries_Turbo]

ahhh ic. so the last row is the highest map bin then?

so i think im about ready to try and make a t3 cal then i guess. here comes some mad guesswork yo lol.

Brian

[ShelGame]

OK, just finished up getting the '92 T3 code in order. It compiles back to stock code now. Still need to add the turbonator mods. T-T3_ii should be posted up this week for those that want to try that version out...

[eski]

Great.. Can't wait for "good" version.

[ShelGame]

Great.. Can't wait for "good" version.

"good" version?

[wowzer]

"good" version?

ouch...

[ShelGame]

Anyone who trying this - go and get the latest T-T3 before you try anything with 3-bar. I forgot to comment out the '.org' statements in the template to make it relocatable. When you try to scale for 3-bar, the bigger 3D tables will overwrite each other (in the previous upload).

[Aries_Turbo]

thanks for the heads up rob.

Brian

---------- Post added at 11:15 AM ---------- Previous post was at 11:13 AM ----------

i dont think the "good" version was meant as a rip but a "i cant wait till this is thoroughly tested and all the bugs are worked out".

then again, with only a small handful of folks testing and working on the code, it takes time. you know if you have the capabilities, you can test stuff too. :)

Brian

[ShelGame]

i dont think the "good" version was meant as a rip but a "i cant wait till this is thoroughly tested and all the bugs are worked out".

then again, with only a small handful of folks testing and working on the code, it takes time. you know if you have the capabilities, you can test stuff too. :)

Brian

Yeah, it doesn't get better on it's own...

[eski]

"good" version?

Well.. maybe not correctly said.. that's why it's in quotation marks. How about "finished" and tested 3bar calibration.:) Then I will be ordering one.

---------- Post added at 03:32 AM ---------- Previous post was at 03:28 AM ----------


Yeah, it doesn't get better on it's own...

That's true. But R/T is my only car and I need it running. I know excuses excuses..

You guys are doing great job!!

[shackwrrr]

I just ordered the stuff I need to start testing this. Well except for the chip burner... I have the ostrich but I dont trust it with the issues for a daily driver.

[shackwrrr]

i went to scale this cal and it didnt seem to scale at all. the range was still 2 bar.

i mentioned it in the mptuner thread.

here are some screen shots of what happens after i reopen the new file.

3155231553

what was the fix for this? I was messing around and I got the same thing. I can't find it in the mptuner thread.

[ShelGame]

Well.. maybe not correctly said.. that's why it's in quotation marks. How about "finished" and tested 3bar calibration.:) Then I will be ordering one.

---------- Post added at 03:32 AM ---------- Previous post was at 03:28 AM ----------



That's true. But R/T is my only car and I need it running. I know excuses excuses..

You guys are doing great job!!

Yeah, I understand that. I had a hard time sometimes convincing myself to test stuff on my van cause I had it running really well and it was my daily...

[wowzer]

weird - i just downloaded the t-3 zip file and scaled it to 3 bar and didn't get any messages! also, even the values that are in the 3d table are different?! could u be looking at an older version?

[shackwrrr]

weird - i just downloaded the t-3 zip file and scaled it to 3 bar and didn't get any messages! also, even the values that are in the 3d table are different?! could u be looking at an older version?

I downloaded a fresh copy of mptune2 and a fresh zip of the files in the first post of this thread. I dont get any messages but the table goes to 12.80 for 7 rows after the 11.07/12.80 row.

[wowzer]

see the last line of post 124. u need to add a point.

[ShelGame]

I really need to make a quick tutorial on how to finish scaling the 3D tables for 3-bar...

[shackwrrr]

I really need to make a quick tutorial on how to finish scaling the 3D tables for 3-bar...

I guess Ill wait for that because I don't understand what morris said, I dont even have an insert to press other than the one on my keyboard, which does nothing.

[wowzer]

scale to 3 bar. sort by table type. open the himap3dinputmodifierfrommap table under the table_unsigned_8bit group. click on any row in the grid under the data tab. press insert key. enter 4 and click ok. go to the raw x and raw y columns for the last row and enter 255,255 for each value. save the table. now open the 3d table called fuelfullthrottlefrommap and you will see that the values now go up to 26+ for map.

[shackwrrr]

scale to 3 bar. sort by table type. open the himap3dinputmodifierfrommap table under the table_unsigned_8bit group. click on any row in the grid under the data tab. press insert key. enter 4 and click ok. go to the raw x and raw y columns for the last row and enter 255,255 for each value. save the table. now open the 3d table called fuelfullthrottlefrommap and you will see that the values now go up to 26+ for map.

Thanks, I thought I was supposed to do that on the fuel full throttle map.

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

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.

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.

Since there are a couple of guys trying to tune a 3-bar T3 cal now, I thought I should revisit the fuel again.

The most important thing to remember when tuning the 3D fuel surfaces in the T3 cal(s) is that the surface does NOT represent PW. It represents (primarily) A/F and PumpEff - along with the engine size, injector flow rate, and some conversion factors. If your PumpEff was always 100% and you wanted a constant 14.7 A/F, then the surface would be FLAT!

I know my tendency is to look at the surface as a series of 2D lines similar to the 2D Chrysler cals, and the surface is definitely not at all like the 2D tables. In the 2D tables, the PW is a 16-bit value that is looked up (well, interpolated) from the table. Then a correction is applied for RPM (PumpEff). The 2D table value represents the A/F, injector flow, etc - but also the MAP portion of the calculation.

The 3D table does not include the MAP portion of the calculation. That is done after the lookup (see the equation above). It's confusing because the 3D tables have a MAP axis. But, all that is for is to allow a different A/F at different MAP and RPM levels. The value from the table is multiplied by MAP, which is how the PW increases with MAP. So, even though the stock tables appear to increase with MAP, that is only because Chrysler designed it to get richer with increasing MAP.

Any questions, please feel free to post up. I'm working on a 'generic' 3-bar +40 T3 cal to post up as a baseline; so I'm going thru it all, too.

[shackwrrr]

Since there are a couple of guys trying to tune a 3-bar T3 cal now, I thought I should revisit the fuel again.

The most important thing to remember when tuning the 3D fuel surfaces in the T3 cal(s) is that the surface does NOT represent PW. It represents (primarily) A/F and PumpEff - along with the engine size, injector flow rate, and some conversion factors. If your PumpEff was always 100% and you wanted a constant 14.7 A/F, then the surface would be FLAT!

I know my tendency is to look at the surface as a series of 2D lines similar to the 2D Chrysler cals, and the surface is definitely not at all like the 2D tables. In the 2D tables, the PW is a 16-bit value that is looked up (well, interpolated) from the table. Then a correction is applied for RPM (PumpEff). The 2D table value represents the A/F, injector flow, etc - but also the MAP portion of the calculation.

The 3D table does not include the MAP portion of the calculation. That is done after the lookup (see the equation above). It's confusing because the 3D tables have a MAP axis. But, all that is for is to allow a different A/F at different MAP and RPM levels. The value from the table is multiplied by MAP, which is how the PW increases with MAP. So, even though the stock tables appear to increase with MAP, that is only because Chrysler designed it to get richer with increasing MAP.

Any questions, please feel free to post up. I'm working on a 'generic' 3-bar +40 T3 cal to post up as a baseline; so I'm going thru it all, too.

so you are saying that if we want something that goes to 11.8:1 after a certain PSI then the table will level off? Sounds like that might make it a bit easier to tune.

I was going to raise the pressure one psi at a time and try to tune each row individually.

[ShelGame]

so you are saying that if we want something that goes to 11.8:1 after a certain PSI then the table will level off? Sounds like that might make it a bit easier to tune.

I was going to raise the pressure one psi at a time and try to tune each row individually.

It could. It depends on the PumpEff, then. If the PumpEff is constant, and you want a constant 11.8:1 A/F, then yes, the 3D table would be flat in that area.

[ShelGame]

07/08/11 - v1 for SBECII T3's (1992-93) now posted:
Initial release, compatible with MP Tuner 2 (only - MAP scaling is not supported by MP Tuner 1)


Also added are pre-built 3-bar, +40 binaries. This is my first stab at tuning the T3. However, I think it's pretty close. These have no other options enabled, just scaled for 3-bar and +40's and tuned in the 12+psi range for both timing and fuel.

All files are on the 1st post in this thread...

[turbovanman²]

Rob and others, wow, you guys are truly a class act, :hail:

[shackwrrr]

07/08/11 - v1 for SBECII T3's (1992-93) now posted:
Initial release, compatible with MP Tuner 2 (only - MAP scaling is not supported by MP Tuner 1)


Also added are pre-built 3-bar, +40 binaries. This is my first stab at tuning the T3. However, I think it's pretty close. These have no other options enabled, just scaled for 3-bar and +40's and tuned in the 12+psi range for both timing and fuel.

All files are on the 1st post in this thread...

awesome, can't wait. The +40s and 3 bar are ready.

[ShelGame]

awesome, can't wait. The +40s and 3 bar are ready.

If you do get to try it, please let me know the results. I'd like to say I'll test the 3-bar on my father-in-laws Spirit R/T this weekend, but I know I probably won't get to it...

[shackwrrr]

Im just waiting until you get more sst chips in. Im going to try and desolder the stock chip and keep it since Im so worried that something won't work like if the chip gets xrayed or my ostrich has messed up.

[shackwrrr]

32360

Lookin Good

[ShelGame]

Anyone have the chance to try out either of the posted .bins?

[Aries_Turbo]

not yet for mark and i

[shackwrrr]

should be trying this out this week. as long as the soldering iron and ostrich cooperate.

[shackwrrr]

T-T3 normal v1 wont compile for me now. I did it a few times before just to mess with it and then deleted everything because I was playing with stuff. I downloaded it again today and I get an error that says there was a major error in assembly please review .lst file.

[shackwrrr]

Ok, Im all set up to do testing. I couldnt get the base code to compile so I loaded the stock file and it started up just like stock and drove perfect. I then swapped in the +40s and the 3 bar and loaded your basic cal. This cal started up perfect, just like stock but as soon as I tried to drive it all it did was go lean.

Also I noticed that the PT fuel wasn't adjusted.

[ShelGame]

T-T3 normal v1 wont compile for me now. I did it a few times before just to mess with it and then deleted everything because I was playing with stuff. I downloaded it again today and I get an error that says there was a major error in assembly please review .lst file.

Hmm, OK. I"ll check it out tomorrow...

[ShelGame]

Ok, Im all set up to do testing. I couldnt get the base code to compile so I loaded the stock file and it started up just like stock and drove perfect. I then swapped in the +40s and the 3 bar and loaded your basic cal. This cal started up perfect, just like stock but as soon as I tried to drive it all it did was go lean.

Also I noticed that the PT fuel wasn't adjusted.

There's nothing that should need to be adjusted with the part throttle fuel. But, maybe it's not getting setup right for the 3-bar I'll check.

Also, I didn't have a problem compiling the stock unscaled code?

[shackwrrr]

There's nothing that should need to be adjusted with the part throttle fuel. But, maybe it's not getting setup right for the 3-bar I'll check.

Also, I didn't have a problem compiling the stock unscaled code?

I tried uninstalling mptune, downloading it multiple times and it still wouldn't compile the T-T3_22_T3_MTX_A393.tpl file that I also downloaded a few times. I can upload the .lst file it spit out when I get back home.

I just noticed that the part throttle Himap table 3 bar section was just filled with the same number as the last row in the 2bar section. I know with computer controlled boost you would never get there but I run an MBC that allows me to and if someone drives my car and gets scared the first thing they will do is lift and put it into part throttle. Guess its not as bad as I thought it would be last night.

Ill try some more stuff tonight and try compiling on a different computer. I looked and it looks like MPtune was updated since the last time I messed with it so that might have messed something up.

[ShelGame]

Ok, Im all set up to do testing. I couldnt get the base code to compile so I loaded the stock file and it started up just like stock and drove perfect. I then swapped in the +40s and the 3 bar and loaded your basic cal. This cal started up perfect, just like stock but as soon as I tried to drive it all it did was go lean.

Also I noticed that the PT fuel wasn't adjusted.

Did it go lean in vacuum? Or in Boost?

Just to clarify - I didn't adjust the P/T table because I didn't think there was much chance of running high boost at P/T. So, it still gets the same (maximum fuel) mixture at P/T at boost above ~12psi. If it is needed, I can adjust the P/T fuel table for high boost. If anything, not adjusting that table will make it rich from probably 10spi on up - not lean.

I'm looking at the vacuum table now, but I don't see anything that would cause it to go lean. So far.

---------- Post added at 10:27 AM ---------- Previous post was at 10:25 AM ----------


I tried uninstalling mptune, downloading it multiple times and it still wouldn't compile the T-T3_22_T3_MTX_A393.tpl file that I also downloaded a few times. I can upload the .lst file it spit out when I get back home.

I just noticed that the part throttle Himap table 3 bar section was just filled with the same number as the last row in the 2bar section. I know with computer controlled boost you would never get there but I run an MBC that allows me to and if someone drives my car and gets scared the first thing they will do is lift and put it into part throttle. Guess its not as bad as I thought it would be last night.

Ill try some more stuff tonight and try compiling on a different computer. I looked and it looks like MPtune was updated since the last time I messed with it so that might have messed something up.

MP Tune 2 should be on version 2.0.0.7

[shackwrrr]

It would idle great, Any throttle even free rev would make my wideband drop past full lean. If I drove it and I went past probably 1/8th throttle it would drop lean. It wouldnt bog but it was definitely lean.

[ShelGame]

It would idle great, Any throttle even free rev would make my wideband drop past full lean. If I drove it and I went past probably 1/8th throttle it would drop lean. It wouldnt bog but it was definitely lean.

Is it just lean under transient? If you hold the throttle (free rev) will it 'catch up'?

I'm trying to figure out if it's a base fuel or a transient fuel issue...

[wowzer]

I tried uninstalling mptune, downloading it multiple times and it still wouldn't compile the T-T3_22_T3_MTX_A393.tpl file that I also downloaded a few times. I can upload the .lst file it spit out when I get back home.



i got the following errors also. has to do with these lines in the template and asm referring to non existent tables (t3 v1):

681 ;.org 0x8539
8502 682 KNENRC_KnockRetardEnrichment: ;EMRETB_EmergencyRetardInBoostFromRPM:

CB4E DD FE [ 4] 7680 LCB24: stD *Temp7 ; store D to RAM
u CB50 96 00 [ 3] 7681 ldaa EMBSLM_EmergencyRetardBoostEnableSetpoint ; load a with memory contents (data is 7a)

CB78 4D [ 2] 7703 LCB4F: tsta ; test a
CB79 27 18 [ 3] 7704 beq LCB6A ; branch if equal (zero)
u CB7B CE 00 00 [ 3] 7705 ldx #EMRETB_EmergencyRetardInBoostFromRPM ; load index with value

[ShelGame]

Yeah, I changed the name. Not sure how the 'old' version got uploaded. I'll add the corrected version in a sec...

[shackwrrr]

Ill do some testing tonight and see if its just transient. Ill also build a 3bar scaled cal without adding points and see what that does.

Thanks for the help. Now That I have the ostrich figured out I can test this stuff a little easier.

[ShelGame]

Ill do some testing tonight and see if its just transient. Ill also build a 3bar scaled cal without adding points and see what that does.

Thanks for the help. Now That I have the ostrich figured out I can test this stuff a little easier.

Anyway you could test a 2-bar cal with injector scaling or a 3-bar cal without? That would help to determine (assuming it's scaling related) which scaling operation causes the lean condition...

[shackwrrr]

I can test a 2 bar easily, the gm 3bar has the same connector as the 90 down map sensor. I can check the injectors fairly easy too.

I should be able to complile now? just an upload goof?

[ShelGame]

I can test a 2 bar easily, the gm 3bar has the same connector as the 90 down map sensor. I can check the injectors fairly easy too.

I should be able to complile now? just an upload goof?

Yeah, I guess. It looks like the .asm was updated but not the .tpl file. It should be all OK now, though, if you get the latest download.

[shackwrrr]

Ok I did some testing and Im going to do my best to explain whats happening. It seems that the map scaling is what is messing it up. I took the base T-T3 cal and scaled it for +40s with a 2 bar this cal ran perfect, just like stock, rich and happy under boost. Next I scaled for the 3 bar and installed that(I didnt fix the table) this ran decent at idle but would lean out to about 13-14:1 in boost and light load. Next is where it got funny, while it was running I added the point in the Map3d section so the HIMAP table would look right, as soon as I flashed it the car began to surge at idle and sounded like it was dying then coming back over and over at idle. Looking at the HIMAP tables and they looked alright. I saved, closed it and reopened mptune and this is what I found.

32929

I tried the whole thing over from combile to scale to MAP3d adjust and it did the same thing. Other than the reset surge at idle it ran lean (around 13-14:1 under load)


I tried your readymade cal again and it seemed to do the same thing but for some reason it runs alot leaner than the ones that I scaled myself?????

Im short on money right now or I would order up a FTDI cable to datalog with.

[shackwrrr]

Ok, did some more testing and ignore some stuff in my previous post. The Fooked up graph is a bug I just discovered. The bug is when scaling for map while editing the cal as a .bin, that happens. Editing injector scale doesn't hurt anything.

If you scale for map on the TPL file and then compile it does not mess up the table but I do get these errors(I can scale just injectors with no issues.)

Warning->Cal binary byte value (7) does not agree with current map choice value (9) for table:ScaleMAPVoltsToPresMultiplyConst


Warning->Cal binary byte value (865) does not agree with current map choice value (1792) for table:ScaleMAPVoltsToPresAddConst

[wowzer]

shackwrr - i was able to confirm that there is a bug in the program. i'll look at it tomorrow.

it looks like it only affects a bin file that is loaded and then scaled to a new map value. scaling a bin file for injectors seemed to work ok.

i was able to take the original template file, scale it for injectors and map, and then save it and compile. THAT bin file looks okay so you could use that as a short term fix. i.e. do all your changes/scaling FIRST to the template, save it, compile it, then open that new bin file for flashing.

sorry.

[wowzer]

Ok, did some more testing and ignore some stuff in my previous post. The Fooked up graph is a bug I just discovered. The bug is when scaling for map while editing the cal as a .bin, that happens. Editing injector scale doesn't hurt anything.

If you scale for map on the TPL file and then compile it does not mess up the table but I do get these errors(I can scale just injectors with no issues.)

Warning->Cal binary byte value (7) does not agree with current map choice value (9) for table:ScaleMAPVoltsToPresMultiplyConst


Warning->Cal binary byte value (865) does not agree with current map choice value (1792) for table:ScaleMAPVoltsToPresAddConst



crap - another bug when saving the bin file. apparently the fixed scaling tables are not getting updated correctly. it's on the list!

[ShelGame]

Yeah, the way MP Tuner is setup to scale for MAP, I odn't see how it could ever work to scale a .bin. There's no way to guarantee that there is enough room to add the needed data points to expand the 3D tables. I think MAP Scaling MUST be done in the template.

Thanks for testing Ian. I'll try to look into the MAP scaling tomorrow. Maybe I mised scaling something, or maybe the 3D scaling isn't quite right. I'm not sure. Good to know that the injector scaling is working OK, though.

[shackwrrr]

crap - another bug when saving the bin file. apparently the fixed scaling tables are not getting updated correctly. it's on the list!

I meant to post in your thread but I was getting hungry. What about the Errors? Or wont they cause any issues?

---------- Post added at 11:10 PM ---------- Previous post was at 11:07 PM ----------


Yeah, the way MP Tuner is setup to scale for MAP, I odn't see how it could ever work to scale a .bin. There's no way to guarantee that there is enough room to add the needed data points to expand the 3D tables. I think MAP Scaling MUST be done in the template.

Thanks for testing Ian. I'll try to look into the MAP scaling tomorrow. Maybe I mised scaling something, or maybe the 3D scaling isn't quite right. I'm not sure. Good to know that the injector scaling is working OK, though.

Yeah, Im glad I dont have to swap the injectors out over and over. The maps being the same plug helps a lot.

[wowzer]

shackwrr - for now do everything in the template, save it, compile and then flash until i get a chance to look at the code. also, rob is right - map scaling a 3d table (or adding points manually to other tables) using the bin file could cause problems since the extra points could result in tables overrunning each other. i suppose we could set up a dummy table type to provide "filler" space for that purpose in the template but it seems best to just use the template! i'll probably disable adding points if a bin file is selected just to make it safe for everyone.

[shackwrrr]

Sorry I meant if I do scale using the template file save, then compile I get these errors when I open the .bin

Warning->Cal binary byte value (7) does not agree with current map choice value (9) for table:ScaleMAPVoltsToPresMultiplyConst


Warning->Cal binary byte value (865) does not agree with current map choice value (1792) for table:ScaleMAPVoltsToPresAddConst

[ShelGame]

Sorry I meant if I do scale using the template file save, then compile I get these errors when I open the .bin

Warning->Cal binary byte value (7) does not agree with current map choice value (9) for table:ScaleMAPVoltsToPresMultiplyConst


Warning->Cal binary byte value (865) does not agree with current map choice value (1792) for table:ScaleMAPVoltsToPresAddConst

Hmm, if the values are really that far off, that could cause the lean issue. Those are the transfer function constants for the MAP sensor. the (9) isn't too much concern, but the (1792) instead of the (865) is a huge change in the MAP reading. I'll look into that myself, too.

[ShelGame]

I don't get that error with the .bin file I created (3-bar, +40 version)...

[turbovanman²]

Does this have the proper spark advance curves?

[ShelGame]

Do you get any codes with the 3-bar version of the cal?

[ShelGame]

Never mind about the codes. I found the problem. I'll post a fix and an explanation in a few minutes...

[shackwrrr]

Never mind about the codes. I found the problem. I'll post a fix and an explanation in a few minutes...

I didnt get any codes, I didnt get any errors with your version but it was leaner.

Ill try it out tonight.

[ShelGame]

8/4/11 - v1.1 Uploaded
- Added 'TBLBK3_3DTableBreakPointHiLo' to the template. This was previously a declared value in the code that specifies the break point between the hi- and lo-MAP 3D input tables.
- Fixed the definitions of 'AVMMAP_MinimumMAPToResetAverageMAP' and 'AVMRPM_MinimumRPMToResetAverageMAP'. They were swapped and 'AVMMAP' was not being scaled correctly for MAP.
- Added 'OFSMID_OffsetForMAPOverIdle' to MAP scaling list.

The first one is the big one. This affected the range of the 3D tables and caused the fueling to be very lean off-idle.


v1.1 for the SBECII should be coming later tonight as well with the same changes.

[shackwrrr]

8/4/11 - v1.1 Uploaded
- Added 'TBLBK3_3DTableBreakPointHiLo' to the template. This was previously a declared value in the code that specifies the break point between the hi- and lo-MAP 3D input tables.
- Fixed the definitions of 'AVMMAP_MinimumMAPToResetAverageMAP' and 'AVMRPM_MinimumRPMToResetAverageMAP'. They were swapped and 'AVMMAP' was not being scaled correctly for MAP.
- Added 'OFSMID_OffsetForMAPOverIdle' to MAP scaling list.

The first one is the big one. This affected the range of the 3D tables and caused the fueling to be very lean off-idle.


v1.1 for the SBECII should be coming later tonight as well with the same changes.

Awesome, is the 3bar +40 cal updated too?

[ShelGame]

All files are now updated with the MAP switch fix (.asm, .tpl's and .bin's)...

[turbovanman²]

Bueller, anyone? :p

[shackwrrr]

Does this have the proper spark advance curves?

Compared to the stock A393 bin they are the same. Is that what you wanted to know?

[ShelGame]

Does this have the proper spark advance curves?

Proper how? Not sure what you mean...

[turbovanman²]

Proper how? Not sure what you mean...

As in are they the proper TIII curves or just generic ones you used?

[ShelGame]

As in are they the proper TIII curves or just generic ones you used?

Well, they're not curves per se, they're the full 3D tables. Up to about 13psi, they're the stock timing tables. For the 3-bar +40 basic builds I posted, I 'tuned' it above that based on my best guess. Since nobody has run it that far yet, it's difficult to say if it's good or not.

[turbovanman²]

Well, they're not curves per se, they're the full 3D tables. Up to about 13psi, they're the stock timing tables. For the 3-bar +40 basic builds I posted, I 'tuned' it above that based on my best guess. Since nobody has run it that far yet, it's difficult to say if it's good or not.

Thanks, :thumb:

[ShelGame]

Thanks, :thumb:

Oh, and I'll have to send WOP'R a new chip. The one one the way (if he doesn't already have it) has a problem that will cause it to go lean. See previous 2 pages for details...

[shackwrrr]

Ok, just tried the 3bar stuff. I made one without tuning and tried yours and they both ran the same so Im pretty sure im doing everything right. It still runs lean, the closer to 0 vac I get the leaner it gets so like taking off at a light or stop sign it will pop and sputter. Then if I dare go into boost the farther I go the richer it gets but its still in the 14-16:1 range. at "0" it drops the gauge to past 18:1.

Afterwards I switched back over to the 2bar and I was messing with some settings like the fan temps and turned off decel fuel cut, I also played with turning o2 feedback on an off and all that worked. Im going to try out some turbonator features right now.

[ShelGame]

Ok, just tried the 3bar stuff. I made one without tuning and tried yours and they both ran the same so Im pretty sure im doing everything right. It still runs lean, the closer to 0 vac I get the leaner it gets so like taking off at a light or stop sign it will pop and sputter. Then if I dare go into boost the farther I go the richer it gets but its still in the 14-16:1 range. at "0" it drops the gauge to past 18:1.

Afterwards I switched back over to the 2bar and I was messing with some settings like the fan temps and turned off decel fuel cut, I also played with turning o2 feedback on an off and all that worked. Im going to try out some turbonator features right now.

So, would you say it is about the same as before? Or better/worse? As far as lean-ness goes...

I'll look it over again tomorrow. Maybe there's another MAP thing I missed.

Oh, and thanks a ton for the testing/feedback. It's very helpfull :thumb:

[shackwrrr]

So, would you say it is about the same as before? Or better/worse? As far as lean-ness goes...

I'll look it over again tomorrow. Maybe there's another MAP thing I missed.

Oh, and thanks a ton for the testing/feedback. It's very helpfull :thumb:

I would say it feels better than last time but its about the same lean-ness. More like its lean in a different location.

[turbovanman²]

Oh, and I'll have to send WOP'R a new chip. The one one the way (if he doesn't already have it) has a problem that will cause it to go lean. See previous 2 pages for details...

Gotcha. What chip are you burning it on? Will my Moates burner burn it?

[ShelGame]

Gotcha. What chip are you burning it on? Will my Moates burner burn it?

I used the stock style chip - 87C257. I think the moates burner will work, but not sure. Usually you can set it up to burn as a 27C256 and it will work.

[ShelGame]

I figured out another reason why it might be lean. I updated just the bin files this time to test it. If this works, I need to do some math to figure out why this is the right way to do this particular type of scaling.

This is just the .bin/.mpt setup for 3-bar, +40's.

Once it's confirmed that this is the fix, I'll update the templates and re-post...

EDIT: Attachments deleted... new ones coming soon...

[Aries_Turbo]

i dont think the moates burner will burn the uv erase eproms like the 87c257 or the 27c256 simon. its only for flash chips iirc.

[shackwrrr]

I figured out another reason why it might be lean. I updated just the bin files this time to test it. If this works, I need to do some math to figure out why this is the right way to do this particular type of scaling.

This is just the .bin/.mpt setup for 3-bar, +40's.

Once it's confirmed that this is the fix, I'll update the templates and re-post...

Ok the "X" code works great as far as scaling, it never went lean, and when I got into boost it got rich at the same rate as stock. The only thing that was messed up its pretty rich, I turned off o2 controll to see exactly what it was doing and at idle it runs at 10.5:1 afr but as soon at you use a little throttle to accel it runs at 13:1 at cruise it goes back to 10.5-11:1. Under boost where it normally drops to around 12 then gets richer the more boost your run this .bin drops to 10.5 and gets richer from there.

[ShelGame]

Ok the "X" code works great as far as scaling, it never went lean, and when I got into boost it got rich at the same rate as stock. The only thing that was messed up its pretty rich, I turned off o2 controll to see exactly what it was doing and at idle it runs at 10.5:1 afr but as soon at you use a little throttle to accel it runs at 13:1 at cruise it goes back to 10.5-11:1. Under boost where it normally drops to around 12 then gets richer the more boost your run this .bin drops to 10.5 and gets richer from there.

Well, that's good news, I guess.

It would be expected to be a little rich, actually. The 3-bar scaling will tend to introduce some error in the PW calculation that almost always seems to get rounded up (purely coincidentally) resulting in a bigger than necessary PW.

You should be able to tweak the 'DensityFactors' to try and bring it back down to a reasonable level. I would only move it a couple of percent at a time. For example, if you're at 13:1 and you want to be at 14:1, you can scale it by 14/13 = 7%; which would be 93% using MP Tuner 2's table scale utility. So, for the DensityFactorFull, try changing it to 2F6Eh (12142d) and for P/T try 30D4h (12500d).

For some reason, I put the DensityFactors under the 'ScatterControl' group. I'll fix that for the next release. These are running fuel values.

Also - just a reminder - anything over ~13psi boost has only been tuned by me on the bench using a calculator (ok, well Excel). So, expect that to be pretty rich also.

[shackwrrr]

ok, thanks Ill try that. Any thoughts on why the idle and cruise are richer than PT accel?

[ShelGame]

ok, thanks Ill try that. Any thoughts on why the idle and cruise are richer than PT accel?

I'll have to ponder that one. That's not the case with the stock cal, I take it?

[shackwrrr]

also Im trying to figure out that density factor thing and I cant enter those numbers you gave me, Hex only allows 4 digits and dec only allows numbers

---------- Post added at 11:18 AM ---------- Previous post was at 11:17 AM ----------


I'll have to ponder that one. That's not the case with the stock cal, I take it?

Stock runs ~14.5:1 at idle, cruise and PT in vacuum. Even with O2 off.

[ShelGame]

also Im trying to figure out that density factor thing and I cant enter those numbers you gave me, Hex only allows 4 digits and dec only allows numbers

Just drop the 'h' or 'd' at the end of the numbers, I was just trying to show that those are hex or decimal values. They shouldn't be entered into MP Tuner.


Stock runs ~14.5:1 at idle, cruise and PT in vacuum. Even with O2 off.

OK, so something is still not right somewhere.

When you ran the 2-bar +40 version, did you have any of the rich/lean transitioning issues like you do with the 3-bar +40 version? Need to figure out if it's a MAP scaling issue or an injector scaling issue we still have.

[shackwrrr]

Just drop the 'h' or 'd' at the end of the numbers, I was just trying to show that those are hex or decimal values. They shouldn't be entered into MP Tuner.



OK, so something is still not right somewhere.

When you ran the 2-bar +40 version, did you have any of the rich/lean transitioning issues like you do with the 3-bar +40 version? Need to figure out if it's a MAP scaling issue or an injector scaling issue we still have.

The 2 bar version didnt have the issue. Could it be something with warmup enrichment that references map and is getting exaggerated? I have an 180 degree thermostat.

[ShelGame]

The 2 bar version didnt have the issue. Could it be something with warmup enrichment that references map and is getting exaggerated? I have an 180 degree thermostat.

I'll have to poke around some more. There are a lot more MAP references in the T3...

[wowzer]

Sorry I meant if I do scale using the template file save, then compile I get these errors when I open the .bin

Warning->Cal binary byte value (7) does not agree with current map choice value (9) for table:ScaleMAPVoltsToPresMultiplyConst


Warning->Cal binary byte value (865) does not agree with current map choice value (1792) for table:ScaleMAPVoltsToPresAddConst

this is a bug that result when you open a template, scale for map and then compile without FIRST saving the template. i had an autosave feature that would always save a loaded template before compiling that needed to be switched on. for the next version i am just going to force an autosave before you compile. that will give me some time to figure out how to easily compile the template on the hard drive vs the one loaded in memory in mptuner.

[shackwrrr]

this is a bug that result when you open a template, scale for map and then compile without FIRST saving the template. i had an autosave feature that would always save a loaded template before compiling that needed to be switched on. for the next version i am just going to force an autosave before you compile. that will give me some time to figure out how to easily compile the template on the hard drive vs the one loaded in memory in mptuner.

I thought I might have saved but I guess I didnt.


Rob, I messed witht eh density factors and that made it better, I have to dial it back a bit because it made it a little lean. But doing that It showed me the rich at idle isnt a problem with the density factors. It had the same 10.5:1 AFR idle as before. After messing with it I think the 10.5:1 afr I was getting at cruise was because I was crusing at such a low speed it was basically idle. I got on the highway and its somewhat normal(other than density tuning.)

I have yet to turn up the boost though

[turbovanman²]

i dont think the moates burner will burn the uv erase eproms like the 87c257 or the 27c256 simon. its only for flash chips iirc.

I'll have to check. If I can burn it, saves Rob sending a chip out.

[ShelGame]

I thought I might have saved but I guess I didnt.


Rob, I messed witht eh density factors and that made it better, I have to dial it back a bit because it made it a little lean. But doing that It showed me the rich at idle isnt a problem with the density factors. It had the same 10.5:1 AFR idle as before. After messing with it I think the 10.5:1 afr I was getting at cruise was because I was crusing at such a low speed it was basically idle. I got on the highway and its somewhat normal(other than density tuning.)

I have yet to turn up the boost though

When I looked at the rounding error earlier today, it looks to me that the PW is usually calculated ~1-2% to the rich side when in boost. The error is much smaller in vacuum - less than 0.5%. So, that 7% before may have been too aggressive...

[ShelGame]

OK, found an issue with the cal itself. I forgot to copy over the HiMAP transfer table when I made the latest 3-bar cal. Oops. So, don't use the binaries I posted previously.

I'll fix that, and whatever else I can find and re-post in a little bit...

[shackwrrr]

OK, found an issue with the cal itself. I forgot to copy over the HiMAP transfer table when I made the latest 3-bar cal. Oops. So, don't use the binaries I posted previously.

I'll fix that, and whatever else I can find and re-post in a little bit...

See my latest post, it works fine though??

---------- Post added at 03:44 PM ---------- Previous post was at 03:41 PM ----------

Well I accidentally deleted the post, anyway that latest binary runs great except the rich idle and a lean dip when you get on the throttle after decel. I Just tried 20 psi and once it hits about 5 psi it goes to 11:1 afr and holds it all the way to 20psi fine.

[wowzer]

I'll have to check. If I can burn it, saves Rob sending a chip out.

i think it works with:

AT29c256
SST27sf512
AM29f040

[shackwrrr]

i think it works with:

AT29c256
SST27sf512
AM29f040

http://www.moates.net/manuals/FlashAndBurn.pdf

p (http://www.moates.net/manuals/FlashAndBurn.pdf)age 4 shows that the 27c256 is a read only on their burner.

[ShelGame]

See my latest post, it works fine though??

---------- Post added at 03:44 PM ---------- Previous post was at 03:41 PM ----------

Well I accidentally deleted the post, anyway that latest binary runs great except the rich idle and a lean dip when you get on the throttle after decel. I Just tried 20 psi and once it hits about 5 psi it goes to 11:1 afr and holds it all the way to 20psi fine.

Well, I can see how that would work. You would just get roughly the same A/F at 20spi that you get at 12psi assuming the Pumping Efficiency is the same.

[ShelGame]

OK, the rich idle - is that cold or warmed up? Or both?

[shackwrrr]

OK, the rich idle - is that cold or warmed up? Or both?

Both, stays about the same but with the flat black hood and the sun "cold start" is about 120 degrees

---------- Post added at 04:46 PM ---------- Previous post was at 04:43 PM ----------

if I add the point in the transfer function in the .bin will it work?

[wowzer]

...
if I add the point in the transfer function in the .bin will it work?

the new version won't let u add a point in the bin. need to add the point FIRST in the template after you scale.

[ShelGame]

Both, stays about the same but with the flat black hood and the sun "cold start" is about 120 degrees

---------- Post added at 04:46 PM ---------- Previous post was at 04:43 PM ----------

if I add the point in the transfer function in the .bin will it work?

Probably not. MP Tuner doesn't 'pad' the tables with extra space. So, if you add a point, it will overrun the table next to it...

[shackwrrr]

Probably not. MP Tuner doesn't 'pad' the tables with extra space. So, if you add a point, it will overrun the table next to it...

ahh, Ic. I didnt know if was that or the scaling itself that did it.

[shackwrrr]

I did some messing around with the turbonator features and the staging limiter doesn't seem to work for me. I tried it with no switch enabled (im guessing that means its speed based) and nothing and I tried it with the cruise control switch and nothing. I enabled the CEL flash and antilag but I don't know if they are working.

I also found something out when I was cruising down the highway, I get 45+mpg according to the stock traveler lol. Im not sure if it can be scaled for the bigger injectors or not? Im not worried about it though.


Thanks for all the help with this It nice to be able to do this stuff with my car.

On a side note, 20 psi slips the "TII/TIII" clutch in third gear.

[ShelGame]

OK, I'll look into the Turbonator features. Could be the RAM I'm trying to use for the temp storage for the staging limiter.

In the meantime, here's another 3-bar binary to try. I adjusted some transient fuel tables that I had not previously adjusted for MAP (in the SMEC and SBEC versions of Turbonator). But, I think maybe these need to be adjusted. Plus, in the T3 code, there are 4 tables where there are only 2 in the older cals. I don't know if this will fix the rich idle/lean transition or not. But, maybe.

EDIT: attachment pulled...

[shackwrrr]

thanks Ill give it a try

[shackwrrr]

Ok tried it out. I had to scale density again but that was fine. Idle was still rich but not as rich. 13:1 this time.

I had the lean dip thing but it was only cold startup, I couldn't get it to do it after it warmed up. I did get a little lean dip right off idle during cruise but I think it just needs tweaked a little bit in the tables because I could hold it there and it would stay 16:1 untill I get into it more or let out of it.


here is where I have it right now and it runs great and If I turn the O2 back on it takes care of the rich idle after a few trips along with the lean dip off idle. I turned OB and Decel fuel cut off on this cal. I turned on antilag and CEflash. I also set boost goal to 20psi everywhere for the antilag.

[ShelGame]

Ok tried it out. I had to scale density again but that was fine. Idle was still rich but not as rich. 13:1 this time.

I had the lean dip thing but it was only cold startup, I couldn't get it to do it after it warmed up. I did get a little lean dip right off idle during cruise but I think it just needs tweaked a little bit in the tables because I could hold it there and it would stay 16:1 untill I get into it more or let out of it.


here is where I have it right now and it runs great and If I turn the O2 back on it takes care of the rich idle after a few trips along with the lean dip off idle. I turned OB and Decel fuel cut off on this cal. I turned on antilag and CEflash.

OK, good. That means I have some adjustments to make to the other cals, too. I'll keep looking for some MAP-realted fuel items. There may be more in the transient fuelling that I'm missing.


I also set boost goal to 20psi everywhere for the antilag.

I didn't look at it yet, but can you be more descriptive? The Anti-lag should go to zero at ~2-3psi boost target delta at least. The anti-lag looks at the difference between the boost target and the current boost. The value on the X-Axis of the anti-lag table is this difference-from-target boost. As the difference goes to zero, so should the anti-lag value. So, if you have it set to a high value all the time, you will always get some ignition retard.

Then again, if the RAM I'm using is invalid, it won't actually do anything anyway...

[shackwrrr]

OK, good. That means I have some adjustments to make to the other cals, too. I'll keep looking for some MAP-realted fuel items. There may be more in the transient fuelling that I'm missing.



I didn't look at it yet, but can you be more descriptive? The Anti-lag should go to zero at ~2-3psi boost target delta at least. The anti-lag looks at the difference between the boost target and the current boost. The value on the X-Axis of the anti-lag table is this difference-from-target boost. As the difference goes to zero, so should the anti-lag value. So, if you have it set to a high value all the time, you will always get some ignition retard.

Then again, if the RAM I'm using is invalid, it won't actually do anything anyway...

I went under the target lookup section and made all the tables (time, temp, RPM, and charge temp) 20 psi. I didnt mess with the antilag table.

Eventually I want to hook up computer controlled boost but I hate having 30 miles of vacuum line for it. I would want to relocate the solenoid to the drivers strut tower for it.

[shackwrrr]

Id love to test the fuel/timing up higher but my clutch is really hating life now. I grabbed second pretty good and roasted the tires for a bit then I felt them quit spinning but the RPM's never dropped. Im going to take it easy now.

[ShelGame]

OK, the last file I posted had a value scaled for MAP that shouldn't have been - it's TPS table. So, I updated the 3-bar build again for you to try. I fixed the DensityFactor scaling in this one, too. I'm working with Morris to update MP Tuner to automatically handle the scaling of these factors and tables that need to be inversely scaled with MAP.

As for the Staging limiter - I have a test for you to try. Try setting the main rev limiter to a low value and see if it activates. Basically, the 2-step uses the same code as the main rev limiter. I just substitute the lower value when the staging limiter is supposed to be on. But, I want to see if the main rev limiter is even working. It will help me figure out where the problem is.

I'm looking at the fuel mileage reporting now. It's obviously different from the earlier cars since it's using the CCD bus.

EDIT: Attachment removed...

[shackwrrr]

OK, the last file I posted had a value scaled for MAP that shouldn't have been - it's TPS table. So, I updated the 3-bar build again for you to try. I fixed the DensityFactor scaling in this one, too. I'm working with Morris to update MP Tuner to automatically handle the scaling of these factors that need to be inversely scaled with MAP.

As for the Staging limiter - I have a test for you to try. Try setting the main rev limiter to a low value and see if it activates. Basically, the 2-step uses the same code as the main rev limiter. I just substitute the lower value when the staging limiter is supposed to be on. But, I want to see if the main rev limiter is even working. It will help me figure out where the problem is.

I'm looking at the fuel mileage reporting now. It's obviously different from the earlier cars since it's using the CCD bus.

I was just going to say something about TPS, I noticed today that a certain spot in the throttle would push it lean. Other than that Ive been driving with the adaptives off and it runs right around 14.7 on the highway.

Currently the main limiter is working with the last file ive hit it a few times in first gear. But Ill still try it on the new file when I get home. (we need a PDA/smart phone app for the ostrich or a mobile mptune)

[ShelGame]

The last file will hopefully fix the TPS issue you mentioned. Without affecting the other changes.

If the main limiter is working, that's good news. It means that the RAM locations I chose is valid. But, it also means there's a problem in the code elsewhere...

[ShelGame]

OK, here's the 3-bar dealy-o with the .asm updated for the staging limiter. I think I found it. Which means it probably doesn't work in T-SBEC either... Doh!

This also has the Density factors scaled, as well as the transient fuel tables scaled inversely for MAP. So, it should be nearly ready-to-run...

EDIT: Attachment removed...

[shackwrrr]

OK, here's the 3-bar dealy-o with the .asm updated for the staging limiter. I think I found it. Which means it probably doesn't work in T-SBEC either... Doh!

This also has the Density factors scaled, as well as the transient fuel tables scaled inversely for MAP. So, it should be nearly ready-to-run...

Awesome, Ill try it out.

[shackwrrr]

Does remind me, staging limiter didn't work in t-sbec. I quit messing with it when I thought the ostrich was fugged.

Going to try the latest right now.

[shackwrrr]

New one did pretty good but the idle still starts out at 10:1 and adaptives take care of it after a while.

No more crazy lean spots but throttle transition still blips it down to 16:1 then it recovers. And staging limiter still doesn't work.

I do have one problem that might be related to the rich idle though. every once and a while at a stop light the check engine light comes on, I finally caught it and checked it and got back code 13.

[ShelGame]

New one did pretty good but the idle still starts out at 10:1 and adaptives take care of it after a while.

No more crazy lean spots but throttle transition still blips it down to 16:1 then it recovers. And staging limiter still doesn't work.

I do have one problem that might be related to the rich idle though. every once and a while at a stop light the check engine light comes on, I finally caught it and checked it and got back code 13.

Hmm, code 13 is an odd one. I'll check it out, but I think that one really cannot be the cal or MAP scaling. It only looks for a change in the MAP signal over time. If there isn't one, you get a code. But, there are 2 ways to set that code (2 different tests). So, I'll double check.

I'll look at the staging limiter again, too.

Does the stock cal start out at 10:1 with feedback turned off?

[ShelGame]

Afterwards I switched back over to the 2bar and I was messing with some settings like the fan temps and turned off decel fuel cut...

Just out of curiosity - how are you turning off the decel fuel cut in the T3 cal?

[ShelGame]

No more crazy lean spots but throttle transition still blips it down to 16:1 then it recovers.

Is this during off-throttle transitions? Or, do you mean if you blip the throttle after/during a decel?

[shackwrrr]

Is this during off-throttle transitions? Or, do you mean if you blip the throttle after/during a decel?

Basically all throttle transitions Bliping the throttle taking off at a light dips to 16:1. Adding throttle while cruising (as long as I stay in PT map). If I let up on the throttle to slow down a bit(not completely released)[stock does this]. and If I get into it after a decel it goes real low to 18:1 and stays like that for a while.

When its cold these are ALOT worse, to the point it feels like it cutting out.

I turn off Decel fuel cut by setting the "20mphdecelfuelshutoff" tables to max. I didnt think this would mess with anything, I just like the pops:love:

[ShelGame]

Basically all throttle transitions Bliping the throttle taking off at a light dips to 16:1. Adding throttle while cruising (as long as I stay in PT map). If I let up on the throttle to slow down a bit(not completely released)[stock does this]. and If I get into it after a decel it goes real low to 18:1 and stays like that for a while.

When its cold these are ALOT worse, to the point it feels like it cutting out.

OK, so the turbonator is just like stock? Or worse?


I turn off Decel fuel cut by setting the "20mphdecelfuelshutoff" tables to max. I didnt think this would mess with anything, I just like the pops:love:

OK, well, I identified the actual factory Decel Fuel Cut code and values. Here's a new test version with those values ID'd. I'm not 100% clear on how each of the values works. But, there are 2 that really control the RPM (above idle) to cut and re-instate the fuel. I think the one to really tweak would be "DFRPMH_DecelFuelShutoffDeltaRPMOff" and maybe "DFRPML_DecelFuelShutoffDeltaRPMOn".

I also think there's a chance that the decel fuel cut code was interfering with the staging limiter. So, I set it up to bypass decel fuel cut when the staging limiter is active. So, hopefully, this fixes the staging limiter, too. Except for the decel fuel cut, the staging limiter is the same between T-T3, T-SBEC, and T-SMEC. T-SMEC does not have the decel fuel cut (yet) and the staging limiter works there.

EDIT: Attachment removed...

[shackwrrr]

OK, so the turbonator is just like stock? Or worse?



OK, well, I identified the actual factory Decel Fuel Cut code and values. Here's a new test version with those values ID'd. I'm not 100% clear on how each of the values works. But, there are 2 that really control the RPM (above idle) to cut and re-instate the fuel. I think the one to really tweak would be "DFRPMH_DecelFuelShutoffDeltaRPMOff" and maybe "DFRPML_DecelFuelShutoffDeltaRPMOn".

I also think there's a chance that the decel fuel cut code was interfering with the staging limiter. So, I set it up to bypass decel fuel cut when the staging limiter is active. So, hopefully, this fixes the staging limiter, too. Except for the decel fuel cut, the staging limiter is the same between T-T3, T-SBEC, and T-SMEC. T-SMEC does not have the decel fuel cut (yet) and the staging limiter works there.


The only thing it does stock is when letting up slightly on the throttle it leans out then comes back, I am guessing the computer thinks Im going to let off the throttle and it cuts fuel for a sec and then comes back.

Ill try out the new code tomorrow morning. I haven't got a chance to check my map sensor. Today it started idling rough for sec then the idle jumped up and it set code 13 again.

[ShelGame]

The only thing it does stock is when letting up slightly on the throttle it leans out then comes back, I am guessing the computer thinks Im going to let off the throttle and it cuts fuel for a sec and then comes back.

Ill try out the new code tomorrow morning. I haven't got a chance to check my map sensor. Today it started idling rough for sec then the idle jumped up and it set code 13 again.

The lean thing could be the decel fuel cut working. You can turn that off if you want to. Just set the min temp ("DCLMCT_MinCoolantTempForDecelFuelShutoff") to FF.

Are you using any kind of data logging?

[shackwrrr]

The lean thing could be the decel fuel cut working. You can turn that off if you want to. Just set the min temp ("DCLMCT_MinCoolantTempForDecelFuelShutoff") to FF.

Are you using any kind of data logging?

I have a TE wideband that can datalog but I haven't hooked up the datalog inputs. They used a Chinese serial chip and it flakes out after a few minutes of datalogging. I need to buy a MAX202 chip for it but never get around to it. It had a RPM noise problem but I have the sheilded wire to use now.

It will datalog MAP, TPS, RPM, and AFR.

[ShelGame]

I have a TE wideband that can datalog but I haven't hooked up the datalog inputs. They used a Chinese serial chip and it flakes out after a few minutes of datalogging. I need to buy a MAX202 chip for it but never get around to it. It had a RPM noise problem but I have the sheilded wire to use now.

It will datalog MAP, TPS, RPM, and AFR.

I'd be curious what the MAP trace looks like when it sets the code...

[shackwrrr]

I'd be curious what the MAP trace looks like when it sets the code...

If I can at lunch Ill hook the OTC genisys up and get a pic of it.


I drove that new code to work today. Staging limiter still isnt working, well if Im doing it right. If I don't specify a switch it's just based on speed right? or does it need a switch?

The only thing I did to this cal was turn off overboost I didnt mess with anything else.

[ShelGame]

If I can at lunch Ill hook the OTC genisys up and get a pic of it.


I drove that new code to work today. Staging limiter still isnt working, well if Im doing it right. If I don't specify a switch it's just based on speed right? or does it need a switch?

The only thing I did to this cal was turn off overboost I didnt mess with anything else.

No, it doesn't have to have a switch. If no switch is specified, it should just go off of speed. I'll keep looking at it. Not sure why it's not working.

[shackwrrr]

Just hooked it up to the genisys and when the code sets Nothing changes. At idle, map volts are right at .55 pretty solid (19InHg). I can get the code to set by just barely touching the throttle, so little the scan tool doesn't see a change in TPS. And bam the code sets. Maybe the computer is seeing a slight change in TPS and the Map doesn't react quick enough for it?


Idle map volts are .55 KOEO is 1.5v. Decel is .35-.4


Idle is sill really rich, it has adaptives maxed at -25% but as vacuum tapers off so does the adaptive long term. bring the throttle up to 15inHg and adaptives are -15% 10inHg is 9% and at 0 in of vacuum adaptives read 0%. Sounds like something is messed up with that one table you were messing with.

Also noticed that my knock sensor reads .04 all the time. I gotta check that out,

[ShelGame]

OK, here's what I think you should do for the MAP code:

Since we scaled for MAP, the threshold for checking the MAP is reduced in resolution. The MAP check code also looks for a minimum change in RPM to set the code. We can't change the MAP resolution, but we can change the delta RPM threshold. So, I would try setting "MPRMPD_CheckMapAtZeroSpeedAndThisDeltaRpm" value (in the 'Setup - On-Board Diagnostics' group) from 0x0200 to maybe 0x0250 and see if that helps. It's just a guess.

[shackwrrr]

OK, here's what I think you should do for the MAP code:

Since we scaled for MAP, the threshold for checking the MAP is reduced in resolution. The MAP check code also looks for a minimum change in RPM to set the code. We can't change the MAP resolution, but we can change the delta RPM threshold. So, I would try setting "MPRMPD_CheckMapAtZeroSpeedAndThisDeltaRpm" value (in the 'Setup - On-Board Diagnostics' group) from 0x0200 to maybe 0x0250 and see if that helps. It's just a guess.

Alright, that sounds like it should work though.