nAst1: Progress and Concepts Thread

[robertisaar]

well, as you read, the max duty cycle for injectors in single fire is actually 50%, and i've been chatting a bit with Dimented24x7, and when he made the MAF patch for the $0D mask, apparently single fire couldn't really keep up with fast throttle transitions. he made a rather interesting section of code to deal with that, but he still has double fire enabled, i assume for a good reason...

i was actually planning on making single fire the default fueling mode up until a much higher BPW limit than what is currently used in most calibrations(around 1mSec), i was thinking around 10mS, since that will go pretty far into most fueling needs without getting close to the 50% duty cycle limit. but before that happens, i need to get single-fire working on the VE tables instead of basing it off of the damn alpha-N tables...

[robertisaar]

ok, new release, nAst1 1.01

only 1 change here, dave ran some tests using his testbench to verify a bug i saw that only happened at 5200RPM, the 2000RPM value for VE and spark would get used until you reached 4975 or 5225 RPM, then everything acted normally. this is now fixed, so please discard of any 1.00 based BINs to avoid any potential issues.

1.02 will be coming in just a few days, i'll be adding the IAT spark modifier, just as a heads-up.

EDIT: 1.02 released, check next page.

[Driver_10]

well, as you read, the max duty cycle for injectors in single fire is actually 50%, and i've been chatting a bit with Dimented24x7, and when he made the MAF patch for the $0D mask, apparently single fire couldn't really keep up with fast throttle transitions. he made a rather interesting section of code to deal with that, but he still has double fire enabled, i assume for a good reason...

i was actually planning on making single fire the default fueling mode up until a much higher BPW limit than what is currently used in most calibrations(around 1mSec), i was thinking around 10mS, since that will go pretty far into most fueling needs without getting close to the 50% duty cycle limit. but before that happens, i need to get single-fire working on the VE tables instead of basing it off of the damn alpha-N tables...

This a bit of a tangent, but you sent me a zip file with a complete collection of GM base tune operating perameter info. Ive updated my zip-file reader and cant open the file anymore. Can you send me a fresh file again. I think that mine is corrupted.

[pocket-rocket]

I'm itching to get working on my car this spring (especially with the nice weather we have been having lately) and will be most likely using this for my tuning. I can't wait to start tuning my car, but I want to get an Ostrich first.

Side note: Driver, you have a 95" (inch) Camaro?

[robertisaar]

hmm.... what exactly are you looking for, Driver_10?

i've put out quite a few archives before, are you talking BINs or BIN definitions?

also, i just realized, for the REALLY extreme motors that have more or less no vacuum at idle?

i can change one byte and allow the ridiculous VE/spark tables to be alpha-n instead of speed-density...

[pocket-rocket]

Here is a thought. How hard would it be to set up a second rev limiter tripped by the clutch switch? Sort of like a wannabe launch control... This could also double as a setup for WOT shifting, possibly.

[robertisaar]

hmm.... kinda sounds like a 2-stage rev limiter if i'm reading that correctly... would it be desirable to have different cut/restore RPMs when sitting still(or close to it) compared to during a WOT shift?

it sounds pretty easy to impliment, i may put that directly after the IAT spark modifier in the roadmap of "stuff to do".

[pocket-rocket]

Aye, kinda like a 2 step. You know, my dad always used to say "There's two kinds of people in this world. Smart fellers and fart smellers, which one are you?" I'm glad you are one of the smart fellers and are on our side

[robertisaar]

who else's side is there?

the non-DIY/Open Source GM OBD1 hacking/modding community?

it barely existed in the past, i certainly won't be the one to bring it back either.

GM did some amazing things back in the late 80s/early 90s in reference to the ECM/PCMs, while i could potentially do the same/similar work on OBD2 PCMs, i have a fairly good grasp on this hardware, i'd rather not have to relearn everything again until it's necessary.

[robertisaar]

http://robertisaar.co.cc/index.php?p=1_21

even though no one reading and subscribed to this thread would need to, i decided to start a mailing list for anyone not on this specific forum since this can be used on quite a few engines other than 660s. i guess the only reason i'm posting it is due to me not wanting to start a bunch of more or less identical threads on 5 or 6 different forums and having to potentially update them all when one striking post comes up in one to allow for discussion in the others... so now i only have to manage/track two sources of ideas.

decided to go with a spark multiplier based on IAT or estimated runner temp(letting the end user choose, though i'm leaning towards IAT being the default), look for it in a few days, once i have my laptop fully functional again.

[robertisaar]

i have the code finished for the next release, going to be testing it in a few hours on the way to and from the wife's appointment with her doctor. at the moment, i have some generic values for the modifer table, with a multiplier of 1 (meaning no change) at 68*F, since that is what the SAE does a lot of their tests at or corrects them to, especially when it comes to dyno stuff. otherwise, more spark is added at lower temps, more removed at higher temps. at the absolute highest and lowest values of the table are values of 1.00 since if there is a sensor failure, it should either go full resistance or no resistance and go to either of the extremes for a few seconds before the ECM sets the code for a IAT failure and assumes what the temp is, so normal spark will be applied in those situations. but at -18.4*F, the multiplier is 1.1, and at 284*F, is 0.82, i made it essentially a straight line, should work relatively well, especially with the interpolation that goes on.

i'm thinking on the way there, i'll test with IAT, on the way back, runner temp, see which i like better... as a default, IAT will be selected in the BINs i release though, just keep it in mind.

i also added some stuff to the XDF to allow for alpha-N using the big tables, technically, you can run the VE table on alpha-n and the spark based on speed-density in the same tune now, if you needed that kind of craziness, or both speed-density, or both alpha-N, whatever you might need to run.

also, the two-step rev limiter idea? are there any automatic cars out there that might want this? otherwise, i'll only be integrating the feature if the manual transmission option is selected and then have the option of using just the traditional rev limiter, or a combo of traditional and the 2 step based on a clutch switch input. if i do make autos able to use it as well, some kind of physical switch would be necessary to turn it on and off, maybe the brake switch? i could do it based on vehicle speed, but that may not be as reliable, especially if you are able to generate enough torque to overpower the brakes/tires below your set rev limit.

next order of business, after the 2-step patch, what would everyone watching like to see implimented next? i'm trying as long as possible to keep this on a 32KB chip and within the RAM capabilites of a 7727/7730/7749, and i have around 1500 bytes left of free, continous ROM, and at least a few bytes of RAM, so that SHOULD last for a few more patches, depending on what they are... i know of at least one person looking forward to the ability to use a MAF for fueling.



expect an update after ~4PM, that's when i should be back home and have the couple of minutes necessary to patch all of the BINs.

[Superdave]

I'll be using the auto flag and a 2-step would be pretty cool to have so i could rev it up to my converter's stall speed. Brake switch would work or just a generic input that i could run to a microswitch off my shifter...

[robertisaar]

hmm.... i'm thinking a little more about it and how to impliment it better with an automatic(since it should be easy to do with a manual)

i'm worried about the rev limiter kicking in when trying to heat up the tires....

maybe a seperate switch to bypass the two-step limiter for the purpose of burnouts? then if that condition is met, then it will look at the brake switch to see if the lower RPM limiter should be in effect....

ideas?

and for the manual trans cars, there should be a MPH limit to apply the limiter so that the ECM doesn't cut fuel when the clutch is disengaged at high RPM.... wouldn't want that.



also, IAT spark modifier code has been tested, seems to be working pretty well. i suggest using it with the IAT option, only due to you would need to modify the ALDL stream a little bit to watch the estimated runner temp to get some idea of where it's operating at in the table... i noticed a 2.5* difference at nearly identical conditions with the options selected differently, so it's certainly capable of significant differences.

EDIT: nAst1 1.02 is attached, enjoy.

EDIT 2: SEARCH FURTHER!

[pocket-rocket]

I wish ECM was connected to the ABS system so we could do some sort of traction control. Something like set it for a 10% or so tire slip, but not pull so much power it dogs it off the line.

[robertisaar]

that's actually very similar to the way the early NorthStar cars implimented traction control, that and the EBCM sending a PWM signal to the PCM to tell it to reduce spark advance when necessary.

and the ABS VI equipped cars DO share a data line with the ECM, though i'm not certain of all of the commands available. if the EBCM allows it, it MIGHT be possible to have the ECM basically send a command to the EBCM that commands the ABS solenoid apply duty cycles to whatever is necessary... but that seems like it would be an incredibly in-depth project. that and the PM3 cars wouldn't be able to use it since IIRC, they aren't on the same data line, let alone the commands to control apply duty cycles would likely be different, if present at all.

i did have a relatively simple method of traction control thought up, basically tracks how quickly the vehicle speed sensor ramps up, if it goes too quickly, indicating tire slip, it reduces spark, waits and watches again, when it gets back under the threshold to remove advance, it adds it back in, and continues watching and adjusting as necessary.... it's also somewhat of a torque limiter.

^ that concept would definitely require per-car adjustements, since the rate of acceleration that is acceptable is heavily determined by the longitudal grip of the tires.