nAst1: Progress and Concepts Thread

[caffeine]

I've had it in open loop around stoich and it does pretty much the same thing. I was also considering reducing my fuel pressure from 55 to 45 engine off to see if that helps further.

[robertisaar]

interesting... you can test it to see if it's being caused by a "too small" pulsewidth issue by raising KAPLL and KAPHL to something like 10mS to force single-fire, just don't get into any really high load situations, since i haven't tested to verify if injector duty cycle is capped at 50% yet. if it's not capped, then you could stay in single-fire at all times(raise those values to something unattainable in normal situations, like 50mS) and instead of firing twice per 4 stroke cycle, you'll fire ince with double the pulse width.

ever try open loop near stoich? alternatively, i wonder if it's a closed-loop control calibration issue.

[caffeine]

Sounds like single fire mode would be great if it worked. Changing the table you mentioned helped a little bit but I still have misfiring at cruising loads; pretty much constantly every 3 seconds or so. Only happens once closed loop comes on and AFRs go from 13ish to stoich.

[robertisaar]

BPW as displayed is final pulsewidth. the values transmitted over the ALDL stream is the 3FD0 register, which is the hardware address for the injector driver. what you see is exactly the PCM is commanding.

[caffeine]

Oh and is the final pulsewidth shown in the data stream anywhere? BPW is shown but I can't tell if that's the final pause width being used or not.

[robertisaar]

async PW is injector pulses that don't happen synchronous to the 3X reference pulses. instead of happening when a reference pulse does, they are done on a 80Hz loop. if the calculated async pulse is less than the minimum value, then it doesn't get delivered. from the looks of it, not only does it not get delivered, it gets ignored completely as well. in some masks, the async PW will accumulate until it reaches the minimum injection threshold and then fire, A1 does not appear to do so. so, you may want to consider lowering that threshold as well, if you're running into situations that require it, but it's not being delivered.

minimum allowable sync PW(of a sort) is found at KAPLL and KAPLH. sounds like you need to skew those downwards, otherwise you'll bump into triggering single-fire mode. transitioning between single and double fire.... i still have never been able to get that working correctly. the code that controls it is quite confusing, but i do need to do some testing to see if permanant single-fire will allow above a 50% injector duty cycle(since it's been suggested both ways), that would allow you to roughly double your pulse width to keep it out of really small territory.

anyways, there is no real minimum PW value in the code, down to .015mSec could be calculated and the PCM will attempt to command it. most SFI code included a minimum PW value, but GM never implimented it into any MPFI code that i know of.

a "hack" way of making absolutely certain PW never goes between 0 and .71mSec would be to adjust the F94 table and change the .49 and .73 mSec values so that they will add up to .71mSec. since we're dealing with linear interpolation, a 0 in the .73mSec and .22 in in .49mSec will cause every injector pulse to be AT LEAST .71mSec.

[caffeine]

Hey one more question. Is there a setting for a minimum injector pulsewidth? I found out that the spec sheet for my injectors lists the minimum pulsewidth as 0.71, and I think short pulsewidths have been causing misfiring at idle and low load cruising.

I'm about to try some different settings in the BPW vs. batt voltage and BPW vs Short PW tables, but I was curious if you could also just set a minimum pulsewidth. I've found a minimum async PW setting but I'm not sure what async pw is for.

[robertisaar]

it's not a bug.... that's just the way GM programmed PE qualifications. there is a minimum MAP to enter PE (KMAPWOT) and a hysteresis (KMAPHYST), both those are only checked after other qualifications are met, not a "if any of these conditions present, PE" situation, they all need met.

i've considered changing this before, in fact, i'll probably add an option bit for it to go into PE whenever the MAP threshold is exceeded, regardless of other values, since applications where boost can come on at fairly low throttle can make use of it.

i've got a lot of free time in this upcoming week, so i can probably get this done and tested fairly quickly and move onto massaging the spark-cut code and adding in the T56 reverse lockout stuff too.

[caffeine]

Hey I was driving today and noticed that its possible to be in boost an not in PE mode when closed loop is enabled. Is this normal? For now I just lowered the TPS threshold for PE to get PE under boost with lowish throttle (like 40%).

[85maro]

I might have to try this, thanks.

[robertisaar]

yeah, it has to be done through dwell... basically quit sending EST pulses to the ICM while still holding the bypass line high, that way the ICM doesn't kick into it's backup mode.

[85maro]

I'm curious how you're handling the spark cut, details on how this will work code wise? If you're doing something dwell-related I'm very interested because I looked at this a few years ago but wasn't able to get any results with the '165 ecm.

[robertisaar]

2 step? what is this, soviet russia?

we have 3 step.

and it's been functional for a couple of months now. it's fuel-cut specific for now, but when i integrate the spark-cut code in, you'll be able to choose either for the 3-step limiter.

[Mars]

any 2 step progress ?

[robertisaar]

definitely a neat idea, should be easy to impliment too, since it's basically "is any timing being retarded due to knock, if so, light SES, if not, don't turn SES on".

of course, it's always going to be slightly more complex than that in assembly, but that's the idea. the light will come on when knock retard starts to be applied and turn off when the knock retard is filtered out, assuming the SES didn't get turned on for any other reason.



other stuff.... not really. my work ethic sucks, especially when other projects come up, like prototyping a MEMCAL adapter for the 93-95 northstar PCMs(they have 2 64KB PROMs and a knock filter in their MEMCAL, quite a bit different than a normal MEMCAL) and working on recalibrating the boost guages of TGP clusters and of course the 7730TCM project... and the neverending project of "find employment that pays me what i'm worth".... that one takes up a lot of time.