junkcltr

iTrader: (1)

So the crank fuel is injected with respect to the DRP. I should have remembered that because you said that the async stuff was removed.

I think I understand. The "restart crank fuel PW multiplier" is read during crank vs. DRP to determine the multiplier to decrease the crank PW by as more DRPs are received. It starts at mult of 1.5 of first DRP and decreases to .50 at DRP 23. This is what gives a decay PW as the engine cranks. Since it repeats then the PW would look like a sawtooth wave if the engine didn't start. Because it fires the injectors bank mode then each cell value is for only one bank. Overall, during crank each bank is fired per DRP and not every 4th DRP, correct?

Suppose the starting engine temp is 20*C and the mult table has a first value (DRP 1) of 1.5 and the crank PW table has a value of 30ms vs cool temperature. Then after the crank prime PW the next DRP injects bank A with a 1.5 * 30ms squirt. Then the mult table has a value of 1.0 for DRP 2 so bank B gets B 1.0 * 30ms squirt.
I originally was thinking the each DRP entry in that table represented 4 DRPs in order to do a bank squirt every crank rev (4 DRPs).

93V8S10

Quote:

Originally Posted by junkcltr

One other thing that I am not sure is caused by TP5. I get ALDL erronious values. All of the ALDL signals have strange 0 or 255 values every few seconds. I have seen this before when the ALDL buffer is not filled sync.

Junkcltr take a look at the Body Size in the reply command of the adx your using. I been working on some new adx files for stock code and have found that the Body Size needs to be 4 numbers higher than the Payload Size.

https://www.thirdgen.org/forums/diy-...ere-start.html
https://www.thirdgen.org/forums/diy-...pro-rt-da.html

dimented24x7

iTrader: (2)

I actually changed the table. Keep forgetting that. The stock code had a logic flaw in that the entries corresponded to DRPs, adn not injector firings, which would screw up the fueling for PFI systems. I changed them to be by injector firings, so each number is the number if injector firings that have taken place, which would be the number of consecutive bank firings.

dimented24x7

iTrader: (2)

Ill have to take a look at that. Some of the stuff in there is a bit dated, and TP has changed quite a bit.

junkcltr

iTrader: (1)

That makes sense to me because with the bank fire it would only hit every 4th table entry if it was still DRP. Each entry is the fuel in msec to fire a bank. That is, entry 1 is bank_A, entry 2 is bank_B, entry 3 is bank_A, etc. That would give 24 squirts total before cycling.

I wasn't sure if each entry corresponded to both banks. That is, entry 1 is bank_A, then entry 1 is for bank_B, then entry 2 is bank_A, then entry 2 is bank_B. That would give 24*2 squirts total before cycling.

I will change my XDF label to from "DRP" to "injector firing"

junkcltr

iTrader: (1)

Changing the ADX Body Size from 66 to (63+4=67) fixed the ALDL erroneous data problem. The data is all correct now. Thank You.

junkcltr

iTrader: (1)

I found another strange thing with TP5. If I change the "main SA bias" from 10 to 6* it should change the "main SA open throttle" and closed throttle tables because the table uses (X-Y). That is to remove the main SA bias. If I copy from another compare bin then it will not copy the values correctly.

I started doing a little tuning. The engine starts good now and idles. I have closed loop turned off by setting the min temp for CL to 150* C so it stays in open loop. When I stab the throttle in park it revs up a bit like it should but when it comes back down it falls to stall and then hits the stall saver. After that it gets into a rev to 1300 rpm and fall to stall mode until it finally stalls.
The AD2 bin is set for a manual trans so I am going to change it to my auto trans and start from there. I also noticed the AD2 bin has A LOT of spark advance at idle so it must have had a giant cam (240* @ .050 duration or bigger).

dimented24x7

iTrader: (2)

I told mark about the issues. Hes looking into it.

Your running off the MAF, now, correct? One thing that will cause the engine to surge up/down like that is the low airflow values in the MAF table being less then what the actual flow is. During decel, the airflow drops to a low value, and causes the engine to go lean. It wants to stall, but then the stall saver gets it, and once it hits the higher values in the MAF table, the AFR goes back to normal and the engine rapidly surges up, at which point the PCM closes the IAC, and the cycle repeats until it stalls.

It could also be a vacuum leak as well. Make sure your PCV inlet is plumbed in behind the MAF so the MAF can see the airflow for the PCV as well. If you have an open PCV system, that will cause lean-out at idle. All the air needs to be accounted for.

junkcltr

iTrader: (1)

I am using a 1 bar MAP sensor right now without any MAF connected. I disabled the MAF error flag. The ALDL reports MAF signal lost as it should, but reports a low MAF airflow also. Somewhere around 10-15 g/s. It looks like the code uses the MAP sensor to create g/s and still ALDL reports it. I used to report this with the $8D code also for estimated HP and to see where it was on the compressor maps. There are no vacuum leaks.

I am going to try recording more ALDL data over the weekend and see what is causing the surge. I think it has a lot to do with the AD2 bin having a lot of timing at idle. The fluctuating rpm could be due to an untuned set of VE tables and SA tables. I have to hand edit all the tables because of the TP5 "copy from cmpr" bug.

Once I get it to idle and respond decent then I am going to do a 2x on the incoming MAP signal and connect up the 2_bar MAP sensor. I am also going to set the trans for a 700R4 as the AD2 bin has it set for manual trans right now. Of course, that has the large throttle follower that is sort of ridiculous. Once I get it to run half decent I can swap out the 700R4 to the 4L60E that is sitting on the bench. That is where the real fun begins......first time tuning an E-trans with good hard parts and shift kit in it.

The_Punisher454

OK, you are running in SD mode on a mask modified to run MAF. What I dont understand is why you arent just running the other $0D code? Are you doing this to zero in the VE tables as a backup later in case of a MAF failure? Trying to follow all this $0D stuff is making my head spin a bit.

junkcltr

iTrader: (1)

I am running the modified PFI code because it does alternate bank fire and I wanted to see how the engine would/will run this way. I have no intention to run a MAF. The reason I want to run the bank fire is because the engine will get injectors that are too large (8 PFI 73 pph) to be fired double fire batch. It won't run well using single fire batch.

The_Punisher454

ok, that makes sense 2me now.

dimented24x7

iTrader: (2)

Why not maf? Planning on boost?

dimented24x7

iTrader: (2)

Also, another thing you can do if you plan on boost is to just steal the PFI logic from my code and transplant it with 2-bar MAP code into a base $0D cal.

bnio

The AD2 bin most likely has too much timing. I was messing with it this past week and I took out about 7 degrees of timing at idle between 600-800 rpm and it seemed to be a move in the right direction. I also cruise the engine in the 800 - 900 rpm range in 6th gear on flat grade roads around 35 -40 mph which is basically idling. it was much smoother with much less surging and bucking. I also think I may need some more fuel for my setup so keep that in mind if you use this post in your decisions for timing correction.

junkcltr

iTrader: (1)

No MAF because it is using boost. I played with the ODFPI quite a bit and it runs nice except for crank and AE. I spent a while trying different things with the crank fuel, but just can't get it to start like the stock $0D and $8D start the engine. The squirt every DRP really does make a difference. No matter how much TPS and MAP AE I added I couldn't get it to respond like the $0D and $8D.

Right now I went back to using my 3 bar $0D code that is a work in progress. It is basically the stock $0D with a patch for 3 bar and WBO2 and some other functions that aren't finished yet. I would like to add the bank fire, but plan on doing it differently. I plan on using the current double fire scheme but just fire one bank each time.

I did notice something strange with the ODPFI bin that I need to look into. It is the MAT sensor and how it is reported. The equation didn't look right for the ALDL reporting.

Also, You can use ECM Pin E7 at address 0x3FDA as a PWM output for the cool fan or something else. I use it for the cool fan right now. It is an unused pin that has the hardware installed.

junkcltr

iTrader: (1)

I pulled a bunch of timing when I used it. Do you see strange values for your Manifold Air Temperature sensor in the ALDL log?

bnio

I am using the incoming air temperature input not the MAT input, don't know if that makes a difference. My temps seemed to be appropriate. I have my temp sensor in my plenum and not in the best location for measuring air temperature coming in, I most likely have some heat saturation where it is mounted so I would say my seems to reporting correctly. What exactly is yours reporting? I am typically between 18-22 degrees c (64-73 F) with outside ambient somewhere between 54 and 64 F.

dimented24x7

iTrader: (2)

This is an indication of what I was saying earlier, that the firings at low speeds arent fast enough. The AE doesnt work because the firings arent quick enough to deliver the fuel. I suspected that it might be the case, and that gives the proof. The two ways to solve it are either deliver the AE async, or just speed up the injector firings at low speeds so the AE is delivered sooner. Same should be done during cranking, to deliver the fuel quicker.

Ill add in quicker injector firings in the next release.

dimented24x7

iTrader: (2)

Hopefully I might have some spare time to work on this at some point.

These are a list of things that I think the code still needs:

• Variable injector firing rates to speed up fuel delivery at low speeds
• Make cranking fuel mass based rather than pulsewidth based so tables are more easily edited

I can add more (within reason) if people think it needs more. I was thinking earlier of adding a boost version, but in a boost situation, you would get into the same issue that the older MAF systems get into, in that the MAF will max out. Even my 350 with a decent cam in it would pull 320 grams/sec or more near redline, so thats getting pretty close to the ~400 grams/sec limit.

The_Punisher454

About the 400g/s limit, is that the limit on the maf, or is it an internal software math limit?
I would really love to see a boost version.
Someone wrote quite a while back that the truck PCM's are the "swiss army knife" of gm computers. If you keep this up, that statement may have been a very good description.

dimented24x7

iTrader: (2)

Its a limit with many of the MAFs. Some flow a little more. You could probably run a little boost and still be ok, but with a 350, I was getting close to 75% the max flow. I could see that being maxed with only a few PSI of boost. As for the swiss army knife comment, that was me. They are quite flexible. I think the best bet for boost would be a two or three bar SD setup. Then you can feed a large engine with lots of boost.

The_Punisher454

'

OK, no problem. Looks like I'll have to whip up a digital MAF combiner. I'll use my trusty favorite uC (an AVR at 20mhz) and read the frequency of two MAF units at the same time. Then reference a lookup table to get an airflow value for each MAF seperatly. Then add the 2 airflow values together. Next lookup a third table for a new frequency output that matches the actual total airflow. Then match that final table in the PCM's MAF table. With this setup you could have progressive linkage on two separate throttlebody's with a maf on each one. I've built a maf translator before, this would be almost just as easy.

The current big block intake I'm building right now uses a single Q45 75mm TB, but for the next one I make I was wanting to use 2 LS1(or vortec)TB's.

dimented24x7

iTrader: (2)

Also, in my code, the MAF is limited to 512 grams per second. This is kinda hard to change as theres a lot of stuff thats dependant on the scaling of the MAF. To get around this, you can halve the injector constant to trick the PCM into basically doubling the airflow in the table, but this will cause a loss of resolution at low airflows, especially with dual MAFs

As for using dual MAFs, it could work if you have hardware ahead to average the two signals together to give a mean frequency. Idle with a setup like that will be real tricky. The airflow through the MAFs will be at a very slow creep, and wont give much resolution.

Another (and much better) possibility is to use a probe or blade type MAF in a large 4 inch tube. This will allow you to essentially keep the MAF signal below 12 kHz and still have lots of flow. I have some basic code that allows spark retard during boost based on the cylinder airmass. This gives some basic spark retard functionality, but even then, there may still be limits elsewhere. How much power or boost where you planning on? My personal preference would still be SD as it has a much larger dynamic range than a MAF. MAF is great in that you can read the airflow directly, but they have an achilles heel in that the dynamic range is limited by the sensor's design and size. With a V8, youll need to be able to resolve small airflows at idle, but still read potentially very LARGE airflows when under boost. This is very hard to do, which is one reason GM uses their dual SD/MAF dyna air logic.

The_Punisher454

ok, 512 grams as a practical limit. Thats still a lot of air, but defiantly wont do for a twin turbo setup

As far as a maf combiner device. I wouldnt average the airflow values, I'd add them together for an exact number. It would certianly be easy to concentrate the lookup table's to give a lot of resolution at very airflow rates, but how stable and accurate are the maf sensors when flowing half or even less air than a stock 5.3 at low idle?
I can see the impracticality of using 2 LS1 maf's. OTOH, for certain manifold,TB and intake plumbing combos 2 smaller MAF's that flow in the 255g range could work out?

But anyhow, a boost $0D (B0D) MPFI would be awesome once you have the MAF version all worked out. Then I wouldnt have to consider running code59 on one ecu and $0D on another for trans control. Plus I suspect $0D may have better idle routines ?

dimented24x7

iTrader: (2)

You can get the PCM to see more airflow by manipulating the injector constant. Halving the constant doubles the airflow values in the table, but reduces resolution to 1/64th of a gram instead of 1/128th of a gram. It will reduce resolution, but it will work. The only limit is that the frequency must not exceed 12 kHz, as it wont read in anything higher.

dimented24x7

iTrader: (2)

I should probably finish this while I have some time now.

Heres how Im going to roll in the variable firing stratagy. There will need to be two parts. The first will obviously be the injector firing rate. That will be based on the RPMs, and MAP readings.

But, there is a second component needed as well, and thats filtering of the mass airflow readings. This is due to the fact that the fueling is calculated async. of the injector firings, so the fueling should be more indicative of of the average needed as opposed to instantanious values like it is now if the firing rates change. The filtering will be based on both the throttle position, as well as the RPMs, and rate the throttle is opening, which should give complete control over the conditioning of the MAFs output.

This will probably be the last thing Ill do with this code, as Id like to concentrate more on the later '411 and get that done, as Id like to try it out once the weather gets nicer. If you want something else added in, nows the time to say so.

95 4x4

iTrader: (1)

In your XDF you added in the Injector Offset PW vs Battery Voltage can you include this in your new version also .

dimented24x7

iTrader: (2)

That will automatically be included in the future releases as its now in the XDF. The actual table is part of the original $0D code logic, and will remain in future releases of the code.

dimented24x7

iTrader: (2)

The coding is done, I just have to test it on the bench.

Basically, the firing rate works like this. There is 1x mode, which each bank is fired once per two engine revs, 2x mode, which each bank is fired twice per two engine revs, and 4x mode which fires the banks in alternating fire. 1x is for high RPM or low load fueling to ensure that the PW stays within limits so teh injector DC doesnt get driven too high or low. 2x allows the injectors to fire faster at higher loads provided the RPMs arent too high, and this will increase the firing rate to allow for the fueling to track more closely to whats desired.

Lastly, there is 4x mode, which is essentially used during acceleration enrichment, to allow the fueling to be delivered as quickly as possible so the AE doesnt lag at low RPMs. The PCM will default to 2x mode if the RPMs are above a certain limit. The RPM and MAP thresholds are defined in the XDF so they can be set to whatever is desired.

The actual injector firing modes basically remain in effect for 8 cylinder firings to ensure that the fueling remains consistant over a full work cycle. There is a potential drawback in that there will be some overlap between cycles as there will be a few cylinders that where fueled in another mode before the firing rate was switched. This will cause them to be a bit rich until the engine fully transitions to the next firing mode since up to 3 could have been fueled twice in two different modes.

There are ways around this by using logic that keeps track of the fuel quantity delivered, and splits the difference during transitions to ensure more seamless fueling, but this will add more overhead to an already overtaxed processor. Id like to avoid it unless its absolutely necessary. If its needed, it can be incrementally rolled in.

I also added in dynamic filtering for the MAF flow to help ensure that it provides more even fueling. This is necessary as the PW is essentially divided down at faster firing rates and the overall fuel delivered is basically the average over the firing period.

dimented24x7

iTrader: (2)

For those few following this: I came up with a way to provide an acceptable way to allow the injectors to transition. Basically the way to do it is to provide variable filtering for the pulsewidth for each inejctor bank so it stretches the transition out to blend the fueling from one mode to the next. It adds complexity to the code, but it does provide a way to fix the problem without driving the overhead way up. Basically, the PW for each bank will be transitioned over two or three firings rather than immediately over one when a transition occurs. This should help prevent the fueling from going suddenly rich when teh computer has to change modes.

Stay tuned...

dimented24x7

iTrader: (2)

I spent some more time thinking about this. I dont think this current firing stratagy will be workable due to the difficulties with trying to get the right fueling during mode transitions. There will be cylinders that will be dead lean, and others pig rich due to overlap in the fueling modes. Its too difficult to come up with a stratagy to find what the proper mean pulsewidth should be during a transition. So, Im scrapping this idea.

The interesting thing about these PCMs is that there are 3 seperate lines that control the injector drivers. Software, immediate async, and TBI alt. fire. The nice thing about the immediate async is that you can just fire the injectors all at once whenever you want for a fixed period of time. Obviously with MPFI, slow injector firing rates are desirable as it maximizes the time available for delivering fuel. The downside is that the updates are slow, so AE is virtually impossible. What Im thinking of going with is a break-in type system. The injectors will fire the way they would on a TPI ECM. All at once, once per rev. When AE is required, then it gets interesting.

Additional fuel is needed right away to cover the transition, but normally wouldnt be available until the injectors fire. But, since I also have the async. line as well, I can fire the injectors at any time I want. So, the best way to do it is to simply deliver the AE sync'd up with each cylinder firing. This way the AE can be delivered on the next cylinder firing, rather than having to wait and do the typical 1x or 2x firings. I also know when the injectors last fired since the software keeps track of when the injectors opened in the time domain. This avoids the problem with shadowing that typically plauges async AE. If the injectors are already open, simply calculate when they would have closed, and just add that time on so they stay open long enough to deliver the AE fueling as well. This gets around the need to change the firing rate as the AE and steady state fueling are now de-coupled. It will also be better than the typical 80 Hz async TBI AE as its delivered on each DRP instead, so its sync. async. AE, if that makes any sense.

The interesting thing is how the hardware will respond to having both injector firing lines operated at teh same time at a high rate of speed. GM never intended these PCMs to do what Im trying to make it do, so it should be interesting to see how it works. If it does work, it would provide a neat and clean way to deliver timely and accurate fueling under all conditions with a batch fire system.

The_Punisher454

Awesome! So with so much flexibility on injector driving does that mean that someday(obviously not right now on this project) a modified $0D could perhaps control 2 stages of injectors (16 on a v8)? I know thats OT but when I read about blending injector firing schemes that thought always pops into my head (and leaves me with a faint smile, and far away look).

dimented24x7

iTrader: (2)

For the firing scheme, what Ive settled on is an adaptive type of logic. The injectors will still fire in 1x mode. Basically, they all batch fire every other full engine rev. This allows you to use larger injectors and not have the PW bottom out at idle. Additionally, it maximizes the available firing time at high RPMs. But, it introduces the problem of slow injector updates. This is even a problem with my SFI system, as the fueling can change so fast that the fuel delivered to the current cylinder coming up isnt adiquate to meet whats actually needed in real time during transients. This is doubly compounded in batch fire type situations as you at least have to fire half of the injectors. So, lag is an inherent issue.

As I said above, chaning the mode is hard due to the fact that there would be overlapping inejctor firings. You can fire them faster, but then you get into the small PW problem at idle if you want to use large injectors. The factory band-aids it by going into 1x mode when the pulsewidth is too low, and back to 2x mode during normal operation, but this would still have some issues during hard transitions as you have to wait until all the cylinders fueled in the last mode have had a chance to fire so you dont "double dip" some of them, sort of speak.

To compromise, there will be afterpulses delivered after the main pulse when the engine is running at low RPMs. At low RPMs, the fueling logic actually runs a bit faster than the injectors do, so there can be multiple updates to the fueling after the injectors have already fired. Basically, if the fuel demand suddenly increases, the code will be able to deliver aferpulses in 4x mode if there is enough PW demanded. Basically, the code will look at how much fuel has been delivered, and how much more is actually desired by the main fueling logic. Additionally, the code will also factor in how many of the cylinders have already fired since the last main injector firing. This will allow the code to dynamically split the difference in required fueling for the remaining cylinders vs. those that have already fired and do not need the extra fuel. This will deliver additonal fuel at low firing rates to help improve load transitions between main firings. Its inevitable that there will be one or two that will be a lean or rich during a throttle stomp, but at least they will hopefully be within the range of AFRs where the fuel can properly combust, and not bang out the intake or go into detonation.

dimented24x7

iTrader: (2)

Ok, I worked on this some more and got most of it done. Needed to make a lot of changes to make it all work. The PCM is pretty much max'd out now processing wise, so I dont think I can get much more in there.

I changed the crank fueling and AE to be based on cylinder fuel mass, so that changing the fuel pressure or to going to different injectors will have no effect on those like before.

I also moved the fuel prime pulse to be when the key is first turned on. Basically the code will wait for teh pump to prime (~1 sec, but adjustable if desired) and deliver a starting injector pulse at key on to help the engine get fired up quickly.

Theres also the dynamic 1x/4x mode switching I mentioned before, and the code will now work on V6 and well as V8 motors by simply selecting the cylinder count to be 6 or 8 cyls. These changes should help make it as flexible as possible. When I get the code tested and XDF done, Ill go thru the changes and how they work, and that should pretty much wrap this up...

dimented24x7

iTrader: (2)

Ok, heres the finished code. There wont be any key-on prime fueling as I couldnt get the injector drivers to work properly when there are no reference pulses from the dist. Aside from that, everything I mentioned before is there.

The acceleration enrichment is now given in terms of cylinder fuel mass. This means that you no longer need to worry about changing it to match the injectors. The code automatically computes the pulsewidth needed based on injector sizing. The same is also true about the crank fueling. This eliminates the need to change these as you change the injector flowrate.

The fueling logic in this code is essentially a mirror of whats in my vortec PCM, which seems to work very well for NA PFI setups.

The biggest addition is including the adaptive fueling. This works by providing additional fuel as needed after the main injector pulse. There can be up to 3 additional injector firings at low RPMs if the fuel demand suddenly increases. The computer keeps track of the fuel delivered after the initial firing, and adds more in as necessary. The basis for constructing how much fuel to deliver is as follows: The computer keeps track of the current commanded pulsewidth, and basically generates an error term which reflects how much additonal fuel is needed to meet the current fuel demand. If theres enough fuel, and the initial 1x injector firing is complete, the computer will then switch to dynamic 4x injector firings, delivering extra fuel as needed. To control this, there is a 3 line table of gain terms that determines what percentage of fuel will be delivered to the engine. As all the injectors have to be fired together, you cant just deliver all of the fuel. The reason is that as time goes on, more and more cylinders have already fired, and dont need extra fuel. The remainder do, however, and a percentage balancing their need for fuel vs. how many cylinders have already fired determines the gain. I set it to something reasonable which should work, but you can tinker with it to see if it will give faster throttle response. There is also an upper limit on the engine speed. As the code is called with each dist. reference pulse, it can use up a lot of time as the RPMs climb, so its disabled after 3200 RPM or so to conserve processing power. Its also disabled below 400 RPM as the counters in the computer roll over every .5 secs., and the firings would get erratic below that point.

The current bin is set for a V8 with a standard 700-R4 with TCC only control. This is adjustable as needed, tho, by changing the flags, as wel as the cylinder count. The allowed cylinder counts are 6 and 8. Anything else entered in will result in the computer disabling the fueling. The calibration included is generic, but is based on stuff Ive used before, so it should for the most part work right away.

Anyway, let me know how it works. I think I got most of the bugs out on the bench, but its impossible to know until its actually used.

The_Punisher454

Just downloaded and looked at it in tp5. looks good and easy to understand (so far).

Questions,

1. Are the electronic controlled transmission portions of the code effected? In other words, can I open up the bin in another 0D XDF and adjust the trans parameters?
All of the cars I would like to use this on have either 4L80E,4L60E or 4T80E.

2. Did I read this right, that the memcal will not be checked to see if its 4,6,or 8 cylinder, its all in the program now? (no more jumper wires!!)

Thanks for your hard work on this, its very much appreciated.

95 4x4

iTrader: (1)

Many Thanks for the hard work dimented , noticed in the updated $OD their is an od maf ads file which does not like TP5 can we use your previous od maf xdf file ?

dimented24x7

iTrader: (2)

Sorry about that! I attached the wrong file. theres teh right one.

I also updated the above to have the correct ADX file instead of the ADS.

dimented24x7

iTrader: (2)

1. The Etrans stuff is unaffected. If you have an XDF with those parameters specified, I can make a few tweaks to it to allow it to work properly with the PFI code. There are a few things that have moved when the code was first created for the TBI MAF. I can make the changes so all the etrans stuff appears correctly.

2. Yes. The memcal no longer has any effect over the firing stratagy (although youll still want to use the correct V6 or V8 memcal for the KS). Its all done internally. The only thing you will want to do is bypass the sense resistors on the inj. driver for using saturated firings.

dimented24x7

iTrader: (2)

I made a minor change to the code and reposted it. There was an error in the original $0D code that I never fixed.

Also, to illustrate what the adaptive fueling logic does, the two scans below should help. Basically, Im rapidly varying the MAF frequency to vary the commanded pulsewidth. The first image is standard batch firings without the adaptive logic at low engine speeds. You can see how jagged and delayed the fuel delivery to the injectors is without it enabled. The second shot has the logic enabled, showing how it interpolates the fueling between main firings to help smooth rapid transitions. This explains why people where having trouble with the AE when the code had only standard batch fire logic.

PS excuse the spikes, my function generator sucks and isnt real stable.

95 4x4

iTrader: (1)

Well i have a little good weather break not for long snow on the way again , an i have been itching to try this new code out . I plugged in my injector constant into the new code a she fired right up SWEET !! Idle was alittle choppy but i just happy to see it run , i have yet to do the the E-Trans set up that is next along with the WB hook-up .

95 4x4

iTrader: (1)

Okay got a problem with the trans goes into reverse an goes into drive an it feels like it is slipping big time with no shifting . I have the wires twisted an protected going to F2 an F3 possilbe these should be reversed ? WB still working on that reads manually but not with the ADX . I switched the wires around an still the same result . Anybody have any idea's how i can figure out what the problem is .

dimented24x7

iTrader: (2)

I sent you a bin w/ the proper corrections. See if that works.

As a note to other users: by default, the code is set for a 700-R4. To enable the option for the 4L60-E, uncheck the TCC only option flag, and make sure the manual trans option flag is left unchecked. Otherwise, there will be no line pressure when you shift into drive.

95 4x4

iTrader: (1)

Yep that was the ticket trans working like it should thanks . Now that i went on a test an got the Maf table dialed in alittle more noticed i have no speedo ? I looked at the number of VSS pulses set at 40.23 an the time to wait for TOS pulses set at 20 msec . With saying that does it have some thing to do with the VSS . I switched the wires back an still no luck from F3 to F2 an back to where i started from F2 an F3 . I will look at the connector maybe a pin got pushed or pulled askew at the connector from the twisting of the wires ?

dimented24x7

iTrader: (2)

How did you wire up the VSS? Does tunerpro still show the PCM registering the vehicle speed? The buffer box and PCM should both be hooked in paralell to the VSS sensor at the trans. Both will need that signal. If you just wired the VSS directly to the PCM, the buffer box will no longer have a signal, which will also effect the ABS, and cruise control.

95 4x4

iTrader: (1)

I wired the VSS directly to the PCM , i read post # 52 thier is no mention of a buffer . I don't even no what a buffer does or what it looks like , can you point me in the right direction an i will do a search also .

95 4x4

iTrader: (1)

Okay i see where i went wrong i have only the VSS hooked up an the buffer box is not . Can i splice into the connector just before the buffer box an then run the wires from thier to the PCM to F2 an F3 . I think it will have the same effect .

95 4x4

iTrader: (1)

Update as to the splicing before the connector is all good saved some wire an shielding as the factory wires were already done an twisted . Finally we are good to go with the tune . One thing that i noticed is the intial start up she fires right up BUT if i just tap the pedal she dies with no recovery an once she warms up a bit all is okay .

Saar

AE: tune it!