[Gmecm] Re: Tweaking Asynchronous BPW

Beau Blankenship ne14roxcj
Mon Sep 11 04:38:31 UTC 2006


I would definitely not continue to reduce the VE tables. Especially in the
areas where you don't have problems. AE is pump-shot. Not power enrich. PE
is towards WOT (like you said, >60% TPS.) Accell enrich is just that. Fuel
enrichment upon acceleration. The amount of fuel added depends on the AE
tables (delta TPS and delta MAP (delta being the amount of change). These
enrichment pulses are Asynchronous. They are not synchronized with the
ignition reference pulse. They are just pulses of a duration determined by
how much the TPS and MAP values changed. If you are using TunerPro, look for
tables with a description like Delta TPS Acelpump and Delta MAP Acelpump.
The MAX and MIN Async BPW, I think, is to limit the amount of fuel the
Acelpump tables can add or subtract. I wouldn't mess with the Max and min, I
think they are just safety things. Also, they didn't look like real BPW
numbers using the def file I have. IMO, you should scale your tables back to
"normal" and use the injector constant. Usually labeled BPW constant. If you
decrease the BPW Constant by a certain percentage, the rest of the tables
would remain the same (on the same engines with different injector size/flow
rate.) If you are happy with where your VE tables are now, use them, but if
you start finding that everything is too rich or lean, change the BPW
constant.

Beau


-----Original Message-----
From: gmecm-bounces at diy-efi.org [mailto:gmecm-bounces at diy-efi.org] On Behalf
Of matthew10_5 at netzero.net
Sent: Sunday, September 10, 2006 6:41 PM
To: gmecm at diy-efi.org
Subject: [Gmecm] Re: Tweaking Asynchronous BPW


Boy I missed that, it was Base Pulse Width that I meant.
 I guess the next step is to continue to reduce the VE tables some
more. I am still at a loss about the word asynchronous. To me it means
"to be unrealated to time" and Syncronous is realated "directly to
time". Why is it that we need asynchronous anyway. A few have suggested
that it dosen't matter and to just disable it. Any more thoughts? 
As for power enrichment the setting for that particular rpm is not
enabled until the TPS is past 60.15. The stumble is happening at an TPS
of 3.6 so the PE shouldn't even be a factor. These are some of the
actual readings during the stumble in closed loop:
1. RPM 900
2. MAP 84
3. BLM 108
4. TPS 3.6

One curiosity though is the Lean Rich column. In a 20 second period it
steadily will climb starting at 78 and rising to 186 in that 20 second
time frame.
 
Does anyone really know what Asynchronous Base Pulse Width is for?
Thanks for the help it's really appreciated...Fred




    Where have you found that term? BTW? Sounds like a type-O. Asynch
BPW makes more sense (Base Pulse Width). Asynch pulses are used during
AE among other conditions. Setting asynch BPW to zero would at a
minimum reduce the AE shot, and likely decrease it to 0 ms of fuel
added. I without a better understanding of this table, I would play it
safe and "leave it alone."
 
 27 Eproms? Consider that a good start. You might be into it for far
more by the time you get done.
 
 Most of the fuel delivery calcs in the ecm are tied in with the
injector constant. If the constant is adjusted, the fuel delivery
calculations will also be adjusted. One function which is ignorant of
injector size is the Acceleration Enrichment. AE is delivered as timed
shots of fuel to help during transient conditions. AE is set up to
prevent stumbles, bogs, and excess emissions by trial and error. If you
alter engine airflow and response, as well as injector size, you'll
need to re-adjust the AE to fit your engine and injectors.
 
 If you have a "low end" cam it will tend accelerate the engine faster
at lower engine rpm. There will be less change in airflow at higher
rpm. AE should follow, with greater fuel delivery at lower engine rpm.
If you have a "top end" cam you'll get more effective cylinder filling
at higher rpm. AE should tend to be higher at higher rpm.
 
 Larger injectors really affect AE the most. And larger injectors with
increased fuel pressure are even worse. In the old days of Holley
Carburetor madness it was tough to get too much AE. Not so today. Too
much AE is very common now and the results are a squishy, saggy,
hesitating engine which can run great under steady load, but will show
rich O2 readings and can spew black smoke at the same load if it's
after a rapid increase in MAP or TPS.
 
 If we're voting, I'm with Beau. Less AE may save the day.
 
 Zaphod
  
 -----Original Message-----
 From: matthew10_5 at netzero.net
 To: gmecm at diy-efi.org
 Sent: Sat, 9 Sep 2006 2:02 PM
 Subject: [Gmecm] RE Tweaking Asynchronous BTW
 
  Thanks Darryl.. 

 Maybe a bit more info would be in order. I built this engine 2500

miles ago. I put every thing new inside and out. It has been overbored

has a cam a little taller than stock. I thought that maybe one of the

new sensors might be bad , so one by one they have all been replaced

again. The wiring harness was replaced and the speed sensor. The TBI

unit is from a 350 cid and therfore has larger injectors . This larger

injector size facilitated an 8% lowering of the VE tables almost across

the board (so far). The timing tables have been tweaked only slightly

mostly to stop preignition. I had taken my van to a Chip maker to start

with because at the timeI was unfamiliar with reprogaming the ECM. When

the engine was first fired it would hardly run blowing clouds of

unburned fuel from the tail pipe. When I picked up the van it was

better and it would idle now but was still blowing black smoke under

what I now know as WOT. After taking the van back 3 times for the same

problem, and after an $800 bill, I deceided to try it myself even

though it didn't have the Dyno. Everything the shop did has been undone

except for the increased fuel pressure regulator. For some reason they

thought this was part of the problem. Anyway I bought all of the

equipment, (except the Dyno and Sniffer) and have burned 27 EPROMS so far.

 This is why I am now at the place it must be something else. All the

sensors and the IAC are working properly. The BLM is still low at this

point in Real time using a data logging program. I have extensive

records of in car actual driving conditions, even through the Rocky

Mountains.

Back to my ORIGINAL QUESTION , what is "ASYNCHRONOUS BTW" and how does

it affect the VE tables. Is it nessessary or should it just be disabled.?

If your reading this Steve, do you have any comments?







From: "dgilbert78 at juno.com" <dgilbert78 at juno.com>

Subject: Re: [Gmecm] Tweaking Asynchronous   BTW

To: gmecm at diy-efi.org
Message-ID: <20060908.105104.3679.893120 at webmail16.lax.untd.com>

Content-Type: text/plain



Hello: make absolutely sure that the MAP sensor is seeing proper

vacuum. No 

kinked hose, no mushy hose, no partially carboned map port in the TBI

body. 

Restricted (delayed) vacuum to the MAP will act like bad acclerator

pump in a 

carb. Make sure that is absolutely perfect befort re programming. May

have to 

remove TBI and rod out the MAP vacuum port, these become carboned and

gummed. 

Good luck. Spent many hours finding that one.

Darryl..



    Tweaking Asynchronous BTW

        

Date    :   Fri, Sep 08, 2006 10:04 AM

        

        

            





I have been unable to remedy the stumble problem with my 305 using

the 7747. I have readjusted the timing tables, the VE tables. 

Although the motor runs great it still stumbles on takeoff in open or

closed loop. The system goes rich under partial throttle between 800

and 1100 RPM without going into WOT inrichment. My question is about

the asynchronous BTW handles in three tables. One table is for Maximum

and one is for Minimum and still one is for RPM.

One blog that I ran across tells off fixing the stumble problem that I

have by setting one of these table values to "0". Can someone shed 

some

light on the asynchronous BTW modes? What is it, and does it overide

the VE table, or work with them, or none of the above? Which setting

would potentially remedy my problem. Any Thoughts?   Matt

Darryl..



_______________________________________________

Gmecm mailing list

Gmecm at diy-efi.org
Subscribe: http://lists.diy-efi.org/mailman/listinfo/gmecm
Main WWW page: http://www.diy-efi.org/gmecm
   
________________________________________________________________________
Check Out the new free AIM(R) Mail -- 2 GB of storage and
industry-leading spam and email virus protection.


------------------------------

Message: 2
Date: Sun, 10 Sep 2006 08:06:37 -0400
From: davesnothereman at netscape.net
Subject: Re: [Gmecm] Tweaking Asynchronous   BTW
To: gmecm at diy-efi.org
Message-ID: <8C8A2E8B36391C0-880-291F at FWM-M15.sysops.aol.com>
Content-Type: text/plain; charset="us-ascii"

     
 -----Original Message-----
 From: matthew10_5 at netzero.net
 To: gmecm at diy-efi.org
 Sent: Fri, 8 Sep 2006 1:04 PM
 Subject: [Gmecm] Tweaking Asynchronous BTW
 
  


 My question is about
the asynchronous BTW handles in three tables. One table is for Maximum
and one is for Minimum and still one is for RPM.



I didn't catch this part of the question originally.  "handles" =
constants?  Singular values 

as opposed to a table of values?



There's two possibilities which I can think of.  One is that these
values work with an 

"asynchronous pulse accumulator" which can be read about in the turbo
P4 document.  The 

second is that these constants determine when synchronous fueling is
abandoned for 

Asynch fueling due to physical limitations imposed by the injectors.  



Have you seen a change by adjusting these values?  If they affect the
asynch accumulator, you may not.  If 

they change fueling mode then you'll hear the injector pulsing change
as you set min and max value as 

well as rpm to fairly large numbers.



Zaphod





   
______________________________________________________________________

_______________________________________________
Gmecm mailing list
Gmecm at diy-efi.org
Subscribe: http://lists.diy-efi.org/mailman/listinfo/gmecm
Main WWW page: http://www.diy-efi.org/gmecm





More information about the Gmecm mailing list