nAst1: Progress and Concepts Thread

[Superdave]

That might be it... i'll look tomorrow night and let you know.

[robertisaar]

and yes, dave, i have a VERY good idea of how nearly every byte in the 32KB BIN interacts with each other....

i should probably go through one last time and finally post it... it would apply to all 3rd gen A1 BINs.

[Superdave]

ok, using your RPMx50 test i was able to display up to 12750 RPM, after that the ECM freaked.. haha

Maybe later i'll get the rest of the sensor inputs hooked back up and see if i can get the data tracing to work.

[bszopi]

12750 RPM

Nice!

[robertisaar]

LOLOL, 12750? DAMN!

good to know it works as intended.

i calculated the maximum RPM the ECM could track using the 65536 Hz registers, but i thought it was a bit higher than that... like 18,xxx, but it's possible it's just not going through enough of the time loops and that's causing the issue...

but i guess 12,750 will have to be high enough.

now i guess i can work on some of the other stuff since this was a sucess.

[robertisaar]

just thought about it: 50 * 255 = 12,750.

so technically, it might be able to read higher if another RPM variable was setup, like RPM X 75 or RPM X 100...

but it's probably sufficient already, no?

[Superdave]

Yah, that's probably high enough.. lol

[robertisaar]

then it seems my project for tonight/tomorrow will be to patch all of the 3rd revision A1 BINs to have the new VE/spark tables, throw in the XDF/ADX and release them as nAst1 v1.00.

[robertisaar]

ok folks, here is nAst1 v1.00.

included in this ZIP are 4 BINs, notice they are all BFxx series A1 BINs, this is due to there being at least 3 versions of A1 BINs released by GM. i developed the patch for the latest series, though it could be applied to earlier BINs if the patch was modded a bit, however, that will just consume more of my time for little benefit. there ARE more BFxx series A1 BINs out there, but those are the only 4 i have that are confirmed correct, though with some byte swapping, you could more or less transfer a non-BFxx series BIN's contents to the newer algorithm easily.

now, i modeled the VE and spark tables off of the W-body BIN since it seemed the least aggressive of the group(and due to it being the heaviest of all 660 vehicles). mix/match/tweak as desired, the values are definitely safe to use without modification on a stock motor with 87 octane fuel, but you should get noticable gains with tweaking. i also have disabled single-fire base fueling(via constants, so it's not permanent yet), since that is based on the alpha-n tables, which have always been a PITA for me. i never noticed any issues at low BPW with double fire enabled, but if it becomes an issue for anyone, i can probably work up something to base single-fire on the VE tables as well.

now there are things i removed from the XDF that were present in the regular A1 XDF, this is due to them no longer being used, this is to reduce confusion as to why something appears to not be working.

there are also a few changes to the datastream, mostly you'll notice a calculated VE value in place of CCP duty cycle, this was just for testing, if you want to change it back, LMK, it takes all of 10 seconds. otherwise, i have a variable setup to monitor RPM above 6375RPM, this is in place of the idle timer, and there's also the MAP value: i have it changed to display normalized MAP instead of just raw A/D, since that is what the ECM uses for it's 3D lookups.

so, questions/comments, fire away.

EDIT: 1.00 removed due to bug, see 1.01 on next page.

[pocket-rocket]

Single fire and double fire, what is it?

[robertisaar]

GM's fueling strategy for MPFI:

single-fire: all injectors are fired once every revolution, at the same time. usually only used in low BPW situations, like deceleration, though interestingly enough, i was almost always in double-fire when at true idle... the idea being that at a low enough BPW, the injectors start acting crazy, so instead of firing the injectors twice per revolution, the calculated BPW is just doubled and fired once per rev.

double-fire: kind of explained it a bit in single fire, but injectors get fired twice per revolution.

i can't remember the exact timings of when it happens in a 3X(V6) system, probably when it recieves one 3X pulse, it fires them, waits for the next pulse, checks to see how much time it took between pulses, sets up a value that will cause the injectors to fire again in half the time it took for the first and second 3X pulse... but i'd have to look through the code again to be sure of that.



or is it single fire happens once every other revolution and double is every rev....

well, you get the idea, anyways, yeah?

[robertisaar]

http://www.thirdgen.org/techboard/v6/582188-batch-fire-single-fire.html

there we go....

check post 8, RBob knows what he is talking about... so in double fire, injectors get fired once every 2 engine revolutions (1 full 4 stroke cycle)

[Superdave]

Maybe i'll give this a try on the Camaro in a few weeks...

[robertisaar]

i ran the newest code last night when taking the wife to pick up allergy meds.... working great for me.

i think the next section of code will be for the spark advance vs IAT modifier... any opinions on this? i'm trying to decide between using calculated runner temp and raw IAT readings(though i may setup a switch to allow for end users to choose), and then i'm not sure if i want to make it a multiplier table or a table that shows the exact amount of advance removed/added due to temps...

[pocket-rocket]

So reading what was posted about double fire vs single fire, why even use double? I mean, as long as you aren't pretty much maxing your injectors out at WOT in single fire mode, why even consider double fire?