Appreciate the hard work also as i know your pretty busy . I do have a question on the VSS as the new locations are now at F2/F3 . I think i have this correct an please correct me if i'am wrong , F12 is the transmission output speed which is now for the Maf Sensor Signal an the TOS is now connected to F2 . The vehicle speed signal is at F13 now connected to F3 this is the one i'am confused on .

 

To make the VSS work in an e-trans application, you need to run a twisted pair directly to the VSS sensor as the MAF takes up the input that previously came from the buffer box. The input on pins F2/F3 is for reading in A/C waveforms, so you can hook the magnetic VSS directly up to it. A word of caution is that the input triggers with only 150 mV peak-peak so you should also try to keep the wiring away from sources of noise like the ignition, and use good quality twisted pair copper wiring to provide a good signal and some measure of shielding.

If your running a standard trans, the wiring is the same as stock.

 

Ok, here is the updated bin and cal. file. Im sure there will be questions, so ask away.

This is VERY generic for tuning. Has just some base parameters to make it work:

Error codes enabled
Basic PFI injector flowrate and AE tuning
Stock 0D timing/VE tables
Stock vortec MAF flowrate table
Set up for a standard 700-R4 with TCC (I have a specific XDF for the TCC params, Ill dig that up and post it, too)

I have not put in the alterate injector firing stratagy, yet. I want to see how it works before I start rolling in more changes. I dont use this PCM, anymore, so I cant run this myself. If you notice that, at low RPMs, the engine sometimes hesitates, or backfires out the intake, then that will be an indicator that I need to switch the firings from alternating batch to something quicker. Also, this cal is for a V8 ONLY! Dont try it on a 4.3L V6 or what have you, the injector firings will be off, and it will run like crap. If there are some V6 people that want to use it, let me know, and I can make a seperate cal.

 

It looks like the last bin posted is targeting 80 lb/hr injectors in PFI mode. Is this correct or should the injector flow vs vac. table be calculated differently?

If a MAF is not installed, then the code reverts to using the MAF sensor?

What is the overall new pinout for the MAF, VSS, WBO2, cooling FAN? I can trace through the code but was wondering if it is already in a text file. Overall, how has the pinout changed from the original $OD pinout?

I would like to try this out in my test rig, but I am not sure where to start. With my current $0D bin I started out with a CPI bin and adjusted for the ON/OFF EGR and changed spark and fuel tables accordingly.

With this PFI, what are the base tables used? TBI or CPI. My application is a stock 8.5:1 static CR 350ci TPI PFI with 24 lb/hr injectors.
I guess all I really need to change to try it is setting the injector flow vs. vac? Is it per PFI injector or num_inj*one_injector for the calc?

You mentioned "alternating batch". Do you mean alternating bank or single fire batch?

 

I probably forgot to change it. Change the injector constant to whatever you have. The flowrate should be for just one individual injector, in grams/sec.

Same goes with any other tables or constants. Use what you had before where applicable. The stuff in there is just generic.

There are no base tables anymore for CPI or TBI. All tables are applied to the current firing stratagy. The injectors are now fired by the software in alternating batch fire with each injector firing once per rev, so the memcal settings have no effect anymore. At low speeds, it would likely be better to fire them more often so there is less likelyhood of a cylinder going lean on tip-in, or the fueling being delivered lagging the engine, but this will be for a later release.

MAF is pin F12 (TOS input)

VSS is now pins F2/F3 (TIS input)

WBO2 is pin B16 (formerly EGR pintle position)

Cooling fan is pin E1 (EGR output)

As this is a non-emmissions calibration, there is no EGR or CCP related items. There are only the standard tables.

What is new is a prime pulse cranking table to allow the injectors to deliver a prime pulse to reduce the ammount of cranking. This is delivered with the first ref. pulse, and will not be delivered again until the PCM goes thru a full key-off cycle. The remainder of the cranking fueling is delivered as msecs pulsewith per injector firing. At some point, I may change this to grams/cyl. of fuel, so that its independant of injector flowrate.

 

Does the VSS have enough drive to for the ECM and DRAC as a sink? I would still need the DRAC to drive the speedo.

You mentioned that the injector rate is for a 8 cyl and is once per rev. I am guessing that you mean once per crank rev and all 8 fire. So it would be double fire batch. I use double fire batch right now, but it drops into single fire batch during decel. It is a typical small engine with turbo and supporting large injectors.
I don't think your current $0D will work with my setup because with that firing scheme I will not get the single fire squirt during decel. Instead, it will do a too small double fire PW and not get any fuel. I guess I could give it a try and see what happens. Stall maybe?

The $8D code does double fire batch and goes to single fire batch when the PW is too small to do a squirt. If you do change the $0D code later on it would be a good example of how to do it.

 

The firings are one bank firing each rev. Each injector only fires once per two revs, like an sfi system. Hence, the need to possibly speed them up at low rpms.

The vss must be hooked directly to the magnetic vss sensor in e trans apps. As its an AC input.

 

That makes sense now. It is alternate bank fire. 4 injectors fire every crank rev. This is what I wanted to do with the $0D at idle and low rpms for my setup. I would run out of injector at mid to high rpms and would switch to double fire batch at high rpms. That is, fire all 8 simultaneously every crank rev like the AUJP does. I think you will find that alternate bank firing is too slow for just about all the current bank fire setups out there. The injectors are too small for alternate bank fire at mid to high rpms.

I am not sure the VSS has enough drive for the ECM input and DRAC input. In my setup I need the DRAC to run the speedo.

 

As I said previously, I think at low speeds is when its likely to be an issue. The fuel loops still run async. with respect to the DRPs. The fuel loops run at 80 Hz, and below 2400 RPM, the fuel loops overtake the injector firings. In the future, Id like to switch firing modes below 2400 RPM to make the fueling at the injectors more frequent and more syncronous with the fueling updates. Above 2400 RPM, the injector firings are more frequent than the updates, so theres nothing to gain at that point from a fueling aspect. Probably I will have each injector firing once per rev, or twice per full cycle or maybe alternating like TBI at low RPMs, provided there will be sufficient engine load to ensure adequate pulsewidths.

Also, the current setup has each injector firing once per two revs (or once per full cycle). This gives the maximum possible time for injector firings as there is less time wasted on opening/closing events. The alternating firing is more of a time constraint as the control logic for the inejctors is run with each DRP, which really puts a lot of overhead on the PCM at high RPMs where there are 300-400 DRPs/sec. Firing both drivers at the same time means that the PCM has two interrups to service for the injectors instead of one, so theyre staggered to reduce the overhead.

Regarding your comment about the once per rev batch fire, how would doubling the firing rate help at higher RPMs? It seems that the extra needed open/close cycle would reduce the available DC. The firing rates are quite high at higher RPMs, so the fuel wont sit there for long in the runner. Its only at low speeds that Im concerned, as there will be a bit of lag in the fueling during transients as the bank firings are quite slow at lower RPMs/idle. Obviously this isnt an SFI system that calculates the fuel for each cylinder in real time, so there will be some discontinuities during transients.

As for the VSS input on pin F2/F3. This doesnt have to hook directly to the VSS. I said must earlier, but thats a bit misleading on my part. All that is needed is a zero crossing signal. The deadband is +/- 150 mV. As long as the signal goes outside the deadband, the input will trigger. Old red is using the method of just a twisted pair in parallel with the DRAC, and it seems to work. I think the input has a fairly high impedance, so it doesnt load the VSS very much. If you really wanted to, you could probably build a simple circuit that uses the DRAC for the signal, but introduces a constant voltage bias to ensure that the PCMs input sees a zero crossing signal. The PCM doesnt seem to be too picky the last time I was messing with that input. Just need to have a large enough amplitude to trigger it.

 

You are right about the injector firing strategy. I just read my post and none of it makes sense. I don't know what I was thinking when I wrote that in terms of needing double fire batch to speed things up. Your alternate fire bank is just as fast above 2400 RPM and has one less open & close time so this would extend an injectors usefulness.
Does the code do Async AE? That would help below 2400 RPM. I know in the $8D I would try and remove as much TPS async AE as possible and rely on MAP sync AE. It always seemed to work better for me this way, but it is double fire batch (all 8 inj fire once per crank rev).

With +/- 150mv deadband then I think the VSS would be able to drive two loads just fine.

EDIT: I like the alternate bank fire idea. It would be interesting to try on the intakes that are known to lean holes in the rear. The 4 rear injectors could use one driver and the code could have a bias to the PW. Poor mans approach at the lean hole problem.

 

Yeah, adding in multipliers to bias the injectors might not be a bad idea. The later PCMs have a multiplier for each cylinder in that case to allow tailoring of the fueling. It wouldnt give that level of control, but at lower RPMs, it would allow you to split the difference.

All the AE is sync. to avoid the loss of AE pulses when both the async and software logic goes for the injector drivers at the same time. From my experience, once things are set up right, only momentary TPS AE is needed when the engine is warm. This is to compensate for the inherent transient response of the MAF. The engine will go momentarily lean on tip in. When cold, MAP AE comes into play to compensate for the fuel that the manifold hangs onto when its cold. If you wanted, you could use the MAP as well and just set the filter coeff. and duty cycle to whatever is needed.

 

There are actually other unused A/D inputs that are not used by the factory wiring, but are wired from the ECM pin to the MCU pin. I have a list of them somewhere and I will post when I find it. I traced the ECM and then applied a voltage to the ECM pin and read the AN0-ANx registers to verify. I know I am using a few of them now for an extra IAT and MAP sensor.

I just read through this thread again. I forget, does the stock $0D code CPI mode fire the injector(s) every DRP when the MEMCAL is set for 8 cyl PFI (jumper wire installed), or does it fire the injector(s) every 4th DRP? I think bytes 4007-400D have something to do with it also. Did the V6 application fir the CPI injector every DRP or every 3rd DRP?

Does your MAF code revert to using the MAP sensor if the MAF goes bad / not istalled?

 

I am kind of confused. When I start with a stock bin I know engine parameters as published by GM so I can figure out what tables I need to tune for my application.

You say there are no base tables anymore for CPI or TBI. I don't understand that. This bin has tables but are they for 4.3,5.7,7.4 liters? Are you saying the no more base tables should not be tuned?

If I did the MEMCAL jumper wire for 8 cyl (evert 4th DRP injection) and set the CAL bytes 4007-400D for PFI more I would get all 8 simultaneous injectors firing every 4th DRP. Is the only difference in your PFI MAF code that alternating 4 injectors fire every 8th DRP?

 

To clear up the memcal thing, all the memcal does is run a timer in the mcu. The stock software that controls the injector drivers checks the status of that timer, and if its the right value, the software then enters an interrupt that will trigger the timer output compare 4/5 lines, which are hooked to the injector drivers. Lines go high, injector drivers trigger. Lines return to low, injector drivers go off.

What I did was to take control of the injector drivers directly, and bypass the memcal altogether. This allows me to control when each injector driver can be fired. The memcal and bit settings no longer have any effect on the injector firings. I did this to allow for future provisions of variable injector firing rates via the software logic based on fuel demand to help give the most optimal duty cycles.

There are tables such as timing tables and so fourth. If what you mean is by which engine size they are for, then they are for the stock 5.7L TBI engine as the calibration used as the base was a stock $0D TBI truck. Keep in mind that as this is MAF, the tables are now used differently. The SD tables are now only used in the event of a MAF failure. MAF fails, and the PCM reverts back to using SD for fueling. The failure parameters for the MAF are only a loss of signal or excessive noise detected as a frequency above 12 kHz. I had limiting checks in at one point, but took them out due to the wide range of airflow demands that engines can have.

The timing tables work much the same as before. The cranking fueling tables are based on PW, and are not really specific for any engine now that the code is PFI. These tables just dictate how long to hold the injectors open for during cranking. All I did to these was just scale them down for a standard 36 pph or so injector.

All the tables are generic, and should be calibrated to suite your specific application. No table is dependant on the actual engine size like some of the later PCMs that have the cylinder displacement imbedded in the table values. The only place the cylinder displacement enters into the equations is in the VE table lookups, and the value entered in as a constant is used.

 

I took a look and I see you made a new DRP counter and fire TOC4 (inj bank A) at DRP 3 and TOC5 (inj bank B) at DRP 7. Looks good to me. 8 cyl alternate bank fire. In my case that is close as good as it can get. With the small engine and big injectors the bank fire helps by doing a 2x on the low rpm / idle PWs. So my double fire batch 1.4ms PW becomes roughly 2.8ms. In theory I could pull the 42 #/hr injectors and put the 83 #/hr in there and still idle decent and have a 2x HP potential or play with E85 and other fuels.

The only future fuel upgrade I can see is "async" at low rpm. That is, for a given injector with a min. allowable PW, calculate the running PW required and once the min. PW + margin is met then fire the injector.

I will change the injector constant and give it a try without a MAF connected. I am going to do a 2x multiply to the incoming MAP A/D value to compensate for a 2_BAR MAP. I might even throw in a negative PE spark value & a decent PE fuel increase in case I get into boost by accident.

 

I tried opening the BIN using the supplied XDF. All of the tables show the XDF defining them with 1 column and 1 row using TP 4.14. Is this setup for a different version of TP? It seems strange.
The SA base is set to 0 and the other MAT base is set to 28*.

All of the tables have the base address for the table as address 0000. Strange.

For some reason the format of the XDF you have is way different than the XDF format I have that was created with TP 4.14. The XDF I have displays the tables correctly, but the XDF you have does not.

 

Try using TP version 5.0 it should display the right format , i had TP 4.14 an the format display was partially their .

 

I tried the ODPFI.BIN that is latest MAF bin posted. The engine is a stock 305ci TPI with 30 pph injectors. The only changes I made was setting the MAIN SA to 6*, changed the cyl volume to .63, and changed the gm/sec to 3.8.

The engine would not start. I tried cracking the throttle a little and still no start. Pulled a few plugs and they all had spark during crank. All of the plugs were dry.

I currently do not have a MAF connected, just a 1 BAR MAP sensor. Would this cause the problem? I did a ALDL diag mode and it only blinked 1-2. No error codes.

Any tips on where to start modifying the CAL? It looked like the ODFPI.BIN would be close enough to get the engine to start.

EDIT: After looking at bnio's bin, I think I need to add a lot more to the crank PW and prime PW tables to get the cranking injector PW higher.

 

Pins B6 and B11 are A/D inputs.

B6: TO Uproc A/D
B11 : TO A/D MUX pin 2 (has reverse bias diode)

 

So the prime PW vs. coolant is injected only once at the first DRP. Then the crank PW vs. coolant is injected.

This makes sense why my 30 pph won't start the engine. The crank PW starts at 4.33msec and QUICKLY decays to 2msec. The engine only had a little over 2msec PWs during idle when warm so this cranking PW is way too small.
I will increase the crank prime PW and the crank PW tomorrow and try it out. Which table / constant ramps out the crank PW?

 

DRP threshold to transition from crank to run , you might want to try an double the msec to give it a chance to run .

 

I see two number of DRP constants and one RPM constant to transition from crank to run in the asm code. What address is the DRP threshold for the msec at? I don't see it.

 

address (hex) 0x4136

 

That is used along with 0x4134 to determine if the engine is running. The 400 RPM is used as a trip point to switch to using the running PW tables. I know the engine has not exceeded 400 RPM when I am cranking it to start. The 0x4136 and 0x4134 are fine for my setup as is. That is what I had them set to before in the $0D and $8D bins before.

I think the main problem is the prime PW, crank PW, and decay rate tables. Also, it looks like the entire crank PW stuff is over complicated by GM. It has many tables, multipliers, AFR, coolant, etc).

 

Yea I just figured this out the other night too, but have not had time to play with it yet. I put my ported edelbrock 3817 base and SLP runners on the van Sunday. I went to fire it up and it only freewheeled. I doused it with a little shot of ether and it fired right up and stayed running. Actually ran very well for being nearly completely untuned.

 

What if you crank stop wait for it to go back into prime pulse and cranking mode then crank again to get the enrichment of fuel does that do anything for you ? With the DRP crank to run transition time , maybe the pulse is not long enough to get the enrichment of fuel . This is new for me also an trying to understand the function . bnio's bin shows the cranking tables doubled in some area's

 

Doesn't do a thing. Just cranks. No matter how many times you cycle the key. I checked the fuel pressure and have 50 PSI at the rail. I tried Bnio's bin and it also will not start. I need to dig out my noid light and pull the doghouse off again. I am begining to doubt I am even getting anything fuel wise.

 

You did the same thing I did. I tried doing the key thing early and it didn't help. Still no start. If I put my original stockish $0D in it then it starts.
I agree with the fuel thing. It is almost like the injectors are not turning on, but I smell a hint of gas.
I didn't try hitting it with starting fluid. I also tried bnio's bin and it would not start. Maybe it is time to dust off the testbench and check it out. I haven't used it in over a year. I am going to go through some old ALDL logs and see what I had for crank PWs and compare to what I the $0D PFI bin is giving.

It looks like the crank prime fires both banks, but the crank PW only fires one bank. Maybe I need to double the crank PWs. I will dig around a little bit.

EDIT: With my stock $0D tuned for PFI the crank PWs are as high as 27ms using the stock $0D V8 double fire batch. So for one engine rev I had all 8 injectors squirting for 27ms. With the 0D_PFI it is bank fire so to get all 8 injectors to squirt the same for one engine rev I need 2*27ms = 54ms for the 0D_PFI bin. This is only for the crank PW table. It looks like he code both injectors to fire for the Prime PW. So that would only need the 27ms.

 

I tossed the stock BJYN memcal in it after just for the hell of it and it fired right up. I pulled it back out, put the PFI bin back in it and it would not start again. So its certainly a calibration problem for me.

 

Same here. It is a CAL problem not setup right for my engine with the latest 0D_PFI. I am reading through the code to try and understand the crank PWs better. I did an edit to my previous post.

EDIT: Did you also notice the data drop out on the ALDL line? I get blips of all data being zero with key on and engine off. I have seen this before with my BAUJP on the testbench when the code was resetting when I had bugs. I have also seen this with some of the other BINs/Masks due to how the code fills the ALDL buffer. I am not sure why this $0D is doing it.

 

Interesting. The $8D I ran this engine on had ALDL report crank PWs starting at 3.2ms and decaying. It started nice with this setup.
The original $0D code with a PFI CAL setup reported crank PWs of 27ms and decaying. It started rich with this setup.
With the 0D_PFI I can't get it to start with the bnio bin or the latest ODPFI bin. So something is definitely wrong with my CAL setup.

 

I just found something interesting with TP5. I did a copy from compare for the prime PW and crank PW and then clicked the save button on the tables. It doesn't save the values even though they are changed to red text. So the bin I modified to use bnio's crank stuff was still using the original 0DPFI values.

Anyone else notice this with TP5. Is it a bug or am I supposed to do something special to get the copy from compare function to work? The log file says it changed it, but the bin isn't changed. Must be a bug in TP5.

 

Whats the OD_PFI bin showing for crank PW? I didn't see any info for what it was doing at crank compared to the other two you noted. Also whats you injector size?

When I first started it was doing a similar thing. Not enough fuel to start. I haven't used the new bin yet but the old one had a scaling issue with the crank pw tables where you had to increase your value you typed in because it would down scale by like 1.6 times or so. Maybe even more, I honestly can't remember. This is what bit me in the *** many times, the value I saved was different when I reopened to adjust for my cranking values. If this is the problem though I would imagine you would have noticed this by now and said something and I think dimented fixed this. I was just throwing the history out there to make sure everything has been covered.

Just read your new post, go in and manually update the values, save and reopen to confirm. Like I said above there was a scaling issue on the orig bin maybe its still there and I am using V5 also.

 

The ODPFI showed ALDL crank PWs starting at 4.3ms and decaying. That is in line with the $8D starting around 3.7ms and decaying. The thing is that the $8D is double fire batch. The ODPFI looks like it is cranking using alternating bank. In the code it looks like it does the 2x to the crank PW because it is alternating bank. I am not sure if the crank PW should also be 2x because of alternating bank fire.

I played around with the crank PW in TP5. I tried entering raw hex values because when I used the regular calculated values it will not save them. When I enter using raw hex it will save them only for certain values. For some values, you enter them and they change with red text. Then when you save the table and save the bin and re-open, the values will be 0. It seems odd. It seems like it has a round off problem and instead of resolving it zeros out the cell. Maybe it is something to do with the eqn being X*Y*15.26msec. The X*Y is a new thing so maybe there is a bug or it is supposed to be used differently?

 

In $8D, during cranking, the fuel is injected via an async PW. The actual PW used is not saved in ECM RAM, so it can not be had via the ALDL link (unless the code is modified).

The cranking fuel routine is run for every DRP that arrives. Whether to start injecting fuel for that DRP or not is based on the "crank fuel delivery delay vs MAT" table (L839C). Typically, the higher the MAT, the more DRPs required before the ECM injects fuel.

The cranking fuel PW is based on a scalar value. Then barometric pressure, TPS%, CTS, and a multiplier that is based on which DRP it is from beginning of cranking is factored in.

Cranking PWs as high as 40 msec is not uncommon on a cold engine. Although note that this is for an ECM that cranking fuel is supplied via standard synchronous double fire mode.

RBob.

 

Thanks RBob. This is my first time looking at the crank algorithm. I looked through the code and saw what you said about the crank fuel being injected in terms of a DRP pulse count and the PW value calculated from multiple tables. So during crank the PW is calculated per DRP and the injector is fired every X DRP pulses which is a constant in the CAL. Once the RPM exceeds a CAL value then the run fuel algorithm is used. You mentioned $8D does the crank PW async, but doesn't it do everything using the DRP so it would be sync?

Suppose the v8 engine cranks at 300 RPM so the DRP is 200ms/4 = 50ms and the DRP pulse count to inject value is 0. Then the injector will fire every DRP pulse or every 50ms. Is this the scenario where the injector would fire for 40ms out of the 50ms? Seems like a lot of fuel.

 

The sync injection counter (ECM hardware) is programmed for a 0 PW. Then as an injection is required the async counter is programmed and then fired.

This provides a single pulse of fuel. It isn't really sync'd to the DRP, as they arrive asynchronously to the 160 Hz firmware loop.

My last paragraph along with your last paragraph: The 40 Msec of fuel is in sync double fire mode. So once per revolution for the injection pulse. Which would be 10 msec if fired at each DRP. Looking at the log file that was at 66* F CTS.

RBob.

 

That makes sense. A crank PW loop runs every 6.25ms and counts DRP pulses. When enough have occurred it writes the async FMD with a value to turn on all 8 injectors.

Since 40msec is desired for one crank rev the 40ms/4_DRPs = 10msec per DRP.
Thanks.

 

It starts using the AD_2.bin from bnio. I figured I try it as is because we are running about the same size injectors. It started rich, but it started and idled somewhat. It was idling on the rich side but I was happy to see it start.

I did a file compare of the latest odpfi.bin and the ad_2.bin. The code section is different and the cal is different. I think there was crank fuel code changes made and that is why the bins differ.

I still need to figure out what is going on with TP5 and the crank fuel tables.

 

I am heading home this weekend for break so I will try the new code out on my setup also and see what happens. It will be interesting to see if I have similar issues/results.

 

Wow, lot of replies since I last checked in. See a lot of things that I want to reply to once I digest all the new posts.

 

As fast355 mentioned, you need to raise the cranking injector PW. This is one of the future changes that I want to make to the stock code for the cranking. The 98/99 blackbox PCMs use the same stratagy, but instead of a pulsewidth, its given in terms of fuel mass. This means that the table wont need to be changed each time you change the injectors, as the cranking fuel mass will be independant of the injector size.

 

Heres the lowdown on how the crank fuel is calculated. The crank fuel is injected syncronously like the fueling for when the engine is running. The async fueling regs. are bypassed completely for the PFI code and only the software injector controller has control over the injector firings. When the engine starts cranking, the PCM first gives the prime pulsewidth to get the engine some fuel while the injector logic syncs up with the DRPs. Once the injector logic syncs up, it begins firing each bank of injectors at the pulsewidth specified in the cranking fueling tables. The pulsewidth cycles according to the DRPs listed in the tables, and this cycling is controlled by the restart crank PW multiplier tables, which cycle the fuel from rich to lean to avoid flooding the engine. Once 24 DRPs have been reached, the table goes back to 10 DRPs and this continues round-robin until the engine starts. At that point, the engine transitions to running off of the MAF.

 

Please Note:

I think I found out why nobody can get their engines to start. Tunerpro seems to have an error in it when I go to edit the cranking PW tables. These are based on a table that uses a scalar to scale down the values to an 8-bit value for storing, like the old $6E MAF tables. For some reason, tunerpro will not store or display these correctly when factoring in the table scalar, resulting in erronious values in the cranking tables, which screws up the crank fueling. Im going to send mark an email to see what it is. I can post up the correct tables, but these will need to be entered as raw data in the mean time until the issue is sorted out.

 

I mentioned that in post #84. There is a problem with TP5. If you switch to "raw hex" view in the tables then you can change and save the values, but "calculated values" won't work right. Also, even in "raw hex" mode it will sometimes zero out the value in the table instead of storing them.

Your XDF uses X,Y for the spark table using a subtracted (X*K-Y)and it works fine. It must be a X*Y problem. I was going to change my TP5 def file so it was only crank_table_val*15.26msec and do the constant mult outside of TP5.

 

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.
In the stock $0D with TP4 the ALDL reads fine, but with the ODPFI and TP5 it gets these 0 or 255 in all the recorded signals every few seconds. The ALDL can't be post processed because of the strange values.

The packet error count is zero when this happens.

I need to look at my MAP ALDL value also. For some reason the ALDL MAP pressure reports as 20 kpa key on and engine off. Then it is 83 kpa with the engine running. Either the MAP sensor went bad which would be the first I have seen go bad or something else happened. It almost seems like the ALDL reports vaccum and not pressure, but at the same time the ALDL MAP high error is being set. I have two ALDL errors. One is no MAF present and the other is the MAP is too high. I am going to test the MAP using a voltmeter at the ECM MAP pin.

 

Just checking to make sure I understand this.
1) crank routine runs at 6.25ms.
2) crank routine receives first DRP pulse and injects after that DRP using Crank Prime table using the 6.25ms loop
3) crank routine syncs with DRP pulses and counts them
4) crank routine fires ONE bank of injectors every 4th DRP pulse using the Crank PW table (so the Crank PW should have a msec value for 4 DRPs or roughly 40msec or 4 times what the $8D code would have for a crank PW)
5) DRPs are counted to cycle between two tables (I need to look at the addresses of the tables used and the addresses of the DRP count constants used)

 

First, make sure your using the latest ADS file. This can be found here: https://www.thirdgen.org/forums/diy-...af-tuning.html

As for the error count. I think this is because TP is requesting the ALDL stream too quickly. The PCM has to service other interrupts, and sometimes will dump the ALDL stream. With the older versions of TP, slowing it down would eliminate the PCM from occasionally dumping the stream. It could also be because of noise as well. Also, is the mask ID set to $0D? I think I set it, but just want to make sure its doing the checksum. If you forget to set the mask ID and the cal is corrupt, that could do it as well.

As for the MAP display. try the new ADS first to see if that helps. The ADS posted there should match what is entered into the ALDL address table.

 

Pretty much, except for 2 and 5. Prime pulse is delivered with the first DRP as the injectors are only fired within the DRP interrupt routine.

Teh cycling DRPs (actually, each number represents an injector bank firing) are for the crank fuel multiplier table. Once the PCM reaches the end of the table, it cycles back to cell 10 (I think), and starts again. This allows the fuel to lean out and go rich again to avoid flooding on an extended crank.

 

I am using the XDF from post #53 in this thread. Is it the same as the other thread XDF?
I will look at the TP5 options for the ALDL datastream requests. This is my first time using TP5 and I have never had these drop outs with my TP4 defaults using my modified $0D code. With that, I don't think it is a noise problem. I will check the mask ID setup and checksum. I do burned proms so I use the checksum but maybe TP5 defaults not too and I didn't check this.

The MAP problem was my mistake. I put in a 1 bar map to try this code. By accident I installed a BPS instead of a MAP. So the voltage from the sensor was incorrect. A real 1 bar MAP fixed that.