nAst1: Progress and Concepts Thread

[robertisaar]

teaser post:

turns out i never disabled single-fire fueling, however, it seems it VERY rarely is enabled anyway(only when the BPW is around 1mSec or less in stock cals)... what i actually ended up doing was disabling the ability for the factory alpha-n stuff to be used at all. that alone has helped immensely. interesting fact: it actually takes a lot longer to calculate the factory alpha-n code compared to the speed-density code...

it seems GM normally refers to single-fire in it's documents as "quasi-synchronus" fueling. however, in the A1 call listing, the "injector constant for single-fire" is actually the injector constant for just alpha-n, that threw me off for a while... but now i've done a few changes to the code and removed the MPH requirement for single-fire and upped the maximum BPW to allow single-fire, now around 8mS, i'm going to see how well the engine reacts, and if necessary, i'll have single-fire disabled whenever a large enough change in TPS is registered, so a temporary double-fire event will happen in that situation...

this change should roughly double the size of injectors you can use without sacrificing idle quality or low-throttle/high RPM issues.... interestingly enough, a side effect of this is that by using larger injectors, less injector on-time is required to flow the same amount of fuel, which will increase the range where single-fire will be in effect... neat.

stay tuned.

[dskopek]

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...

I would use the same as Superdave but my use would be to rev up to a point of where the turbo starts to make boost. Would like to use a microswitch on the shifter to activate the first step.

[robertisaar]

so.... automatic, and want to be able to spin the engine up to the boost threshold while sitting still with the brake on, then go back to full RPM limit when moving and brake off... and use the switch as an override/arming device, in case you need to spin the meats?

seems like you two would need the exact same thing, just potentially different cut/restore points.

how exactly are you compensating for the boost in $A1 though? i haven't added boost support yet.

[pocket-rocket]

stay tuned.

Pun intended?

how exactly are you compensating for the boost in $A1 though? i haven't added boost support yet.

Is boost support going to happen in the future? I do hope so. Also, on a side note: how many (if any) unused inputs are there on the 727/730?

[robertisaar]

Pun intended?

of course!

Is boost support going to happen in the future? I do hope so. Also, on a side note: how many (if any) unused inputs are there on the 727/730?

i'm STRONGLY considering it... when the MAF stuff gets patched in(which will require ~500 bytes if i more or less paste in the algorithm and tables from $2E(94-95 LQ1)), there will be a check to see if MAF is the default fuel calculation mode or not. if not, then a check for another option will be run: checking for a 2(MAYBE 3, if anyone thinks they'll be going over 14 PSI) BAR MAP sensor. if it's there, then the 1 BAR MAP sensor will be used for any kind of fuel and spark calc at or under 100kPa, it should increase resolution and allow me to not have to try and rescale every table, constant, etc for a 2/3 BAR sensor.

when you go above 100kPa, there will be a BPW multiplier(similar to the TGP code) applied, somewhat like a rising rate fuel pressure regulator, except you aren't constrained to a single linear adjustment. i do this only to save on processor time and code space, since it would require a lot more room to go about it the way code59 did (MASSIVE 3D VE tables).

for spark above 100kPa, there will likely be a similar multiplier, much like a boost retard box(emulating hardware via software sure can save a lot of money, huh? ), since again, MOAR gigantic tables is ridiculous even for me.

unused stuff on a 7727/7730 meant to run $A1? i thought about this a while ago and came up with a little chart.... not sure if this one is up to date or not, but:



at least 2 free outputs, 1 is PWM(3 more if EGR was removed/not required(LZ9), 2 of which are PWM)
10 free digital inputs
and it looks like at least 6 analog inputs free as well...

[dskopek]

so.... automatic, and want to be able to spin the engine up to the boost threshold while sitting still with the brake on, then go back to full RPM limit when moving and brake off... and use the switch as an override/arming device, in case you need to spin the meats?

seems like you two would need the exact same thing, just potentially different cut/restore points.

how exactly are you compensating for the boost in $A1 though? i haven't added boost support yet.

I am running a Megasquirt setup right now but it would be nice to go back to a factory CPU setup.

[bszopi]

Robert, if you keep this up, I might consider going OBD1 for the Mustang. I'll need 3-bar support though...

Droid via Tapatalk

[robertisaar]

LOL, what else would you be using if that wasn't there? maybe i can "borrow" some ideas from it.

[bszopi]

What else would I be using? Motec, Electromotive, F.A.S.T. are a few that come to mind, as well as either a F.A.S.T. or PCS tranny controller. May still have to use the tranny controller, though.

Droid via Tapatalk

[robertisaar]

so, nothing really groundbreaking about them...

and i'm not going to attempt coding a PCS with these ECMs, it would just require WAY too much code rework even though the hardware CAN support it. i still need to confirm if the stock code will control 4T60E shift solenoids the way i expect it to....

also, as a little side project due to me having knowledge of a few applications where tuners are having issues with the stock stuff, i'm adding in the big VE tables to the $8F mask, since it's almost a direct port and the $8F PROMs actually have more free space to begin with. just about done with that though, may be able to test the newest nAst1 code tomorrow too.

[Penglii]

also, as a little side project due to me having knowledge of a few applications where tuners are having issues with the stock stuff, i'm adding in the big VE tables to the $8F mask, since it's almost a direct port and the $8F PROMs actually have more free space to begin with. just about done with that though

This makes me happy.

[robertisaar]

patch is finished, however, i'll release it with a warning: do NOT go over 5200 RPM until you can confirm the RPM X 50 value shows up correctly. if it occasionally blanks out or is displaying a value that is clearly incorrect, STAY UNDER 5200 RPM!

it should be correct, since there were a few continuous bytes of RAM free in 8F, but i'd like to see a good datalog indicating that the RPM X 50 variable is working correctly.

i also added a normalized MAP variable to the datastream, since that's what the ECM uses for it's VE calcs, and it's what you should use to tune fueling.



assuming it all works well, i'll likely just toss this out to the TGPForums and see if it catches like wildfire

also, the VE table is based on the stock AZRC table, and there's a WHOLE lot of 100% values... it's a shame 8F doesn't use a double-byte VE value.

this patch disables the normal VE tables(main, idle and base), it also removes ALL alpha-n related tables, scalars, etc. i will likely take those items out of the XDF when the patch is confirmed good.

[Penglii]

this patch disables the normal VE tables(main, idle and base), it also removes ALL alpha-n related tables, scalars, etc. i will likely take those items out of the XDF when the patch is confirmed good.

Awesome.
Can you please apply that patch to the attached bin?
Then I should be good to get some datalogs soon.

[robertisaar]

done. for anyone that's watching, unless you happen to have a disco potato and ~26.5 lb/hr injectors attached to a 3.1, i wouldn't try running this...

[robertisaar]

WONDERFUL NEWS!?!!!111!1!?!1!

i was looking around since i started thing about it, and found exactly what i wanted: 7727 and 7730 style ECM connector pins! i was worried we would have to srounge junkyards for them... it should also allow me to start adding in the stuff that required external connections to the ECMs, like the brake/2 step switches, WB O2, etc...

7727-style
20-22 guage

http://www.eficonnection.com/eficonnection/TerminalDetails.aspx?ItemId=890

16-18 guage

http://www.eficonnection.com/eficonnection/TerminalDetails.aspx?ItemId=490

7730-style
20-22 guage

http://www.eficonnection.com/eficonnection/TerminalDetails.aspx?ItemId=298

16-18 guage

http://www.eficonnection.com/eficonnection/TerminalDetails.aspx?ItemId=297

they also have cable seals listed on the appropriate pages, and for the 7727-style, cavity plugs(7730 style doesn't use them)



they also list replacement connectors(which you will see on the pages that the connectors are intended for), but they don't have the secondary locks(not that big of a deal though, i've never broken one and they don't actually hold anything in IIRC, and they're conveniently pocket sized(not that i would condone such an activity :O)).

http://www.eficonnection.com/eficonnection/ConnectorDetails.aspx?ItemId=313

^i DO need to ask and see if they have ALL of the cavities avaliable in the 7727 style, otherwise we might need to PRECISELY drill through the "cast as plugged" ones... the 7730 guys also don't have this issue though, since they can freely connect their wires since all cavities are already opened.



a group buy may be a good idea, to get the price-breaks, since individually, we may not be able to get to those thresholds.

i guess i should go test the single-fire code, huh?