nAst1: Progress and Concepts Thread

[robertisaar]

quick update:

new XDF(consider it 1.06.1), release notes as such:



correct labeling for shift light min RPM and TPS, was actually hysteresis

KTPSNLT3 address was off by 1

Fan 1 Request (X=Normally Open) address was incorrect

maximum fan MPH is for A/C, not coolant temp, if coolant temps are high, it doesn't matter what speed you're at, they'll start and stay on until the temps drop

Maximum Commanded Idle Speed Change in 50mSec was given a label (KISMAXCH)

KAC3HYS and KAC4HYS were added in, give a default value for BHAK(2 should work), since it's the only factory 4T60E BIN

some non-F31 TCC scalars are more accurately described now and slightly reorganized

couple of IAC scalars moved around for less segmentation

KAIRFLOW has a better description now

added in KISINTP, KISQUGN and KISINQU. take caution and make sure you understand what they do, should you decide to change these

EGR scalars reorganized, some given better explanations, mostly better digital/EVRV seperation





as you can see, small changes, but more accuracy nonetheless. what prompted this update? well, i used the nAst1 XDF as a basis for creating a full bodied $88 XDF and found these little issues along the way.

[robertisaar]

the new XDF does have some corrections compared to older versions, in addition to the new stuff, so yes, updating would be a good idea, even if not using the newest BINs.

if you get to the point of nudging up against 100% VE, then BPC will have to be adjusted again. the stock code, even with the adder tables, only ever used an 8-bit value to represent VE from 0-100%. it would be POSSIBLE for me to add in an option to allow the VE table to go from 0-200%, but that would reduce resolution.

[LZeppelin513]

Thanks for the info. I dropped my BPC down 40 pts and compensated for fuel with the VE table. This brought my idle VE to about 40% which is more normal than 20%. So far it the actual AFR seem to be following the target AFR much more closely. Hopefully this fixed the issue I was having. Now with my BPC lower I am wondering if I may run into greater than 100% values in the VE table, will this cause any problems?

Right now, I don't plan to use the features you have been talking about with your new release nAst1 file. Do you still recommend I update the .xdf?

[robertisaar]

if the target AFR and actual AFR aren't changing at the same rate, there are a couple of possible things going on:

WB sensor error (they are not the perfect sensor people make them out to be)
air/fuel mixture still combusting at/past the WB sensor (cold engine or very retarded timing)
BPC/VE table issues

trust me when i say this, with a wideband, tune(VE) in open loop, at full operating temp, with all possible variations removed. anything other than that and you'll have stupid little issues pop up that you'll have to undo and redo a lot of work.

that being said, i'll expand on the BPC/VE note: one crutch of the BPC vs EGR system is that it's kind of a fudge.... there's no real injector flowrate and no real cylinder size defined in the BIN, it's all done via the BPC vs EGR% table. so if your actual VE and the VE that is entered into the VE tables differ and need to use BPC to make up for it, it will skew the rate at which BPW changes with AFR.

so, if you can confirm it's not the wideband being a wideband, you'll need to skew the BPC around and then move the VE table to bring your actual AFRs back in line.



it's an issue i've considered correcting with real cylinder size/injector flow constants...... but i'm not sure how important it is to change.

[LZeppelin513]

When tuning in open loop, the target AFR seems to have too little affect on the pulse width. For example, I can tune at a specific temp closed throttle, open loop, but as the engine temp changes and target AFR changes, the actual AFR from wideband shows not enough change. Is there a way to increase the affect the target AFR has on pulse width?

[robertisaar]

gah, 44PSI? that's 4BAR.

that would HAVE to be handled via a MAF, a monsterous one at that.

[pocket-rocket]

Got a calibration that would work for this turbo? Lol

"This turbo on a Dodge will build boost really well from 2000 rpm on up and pulls really strong above 2500 rpm. I have 200hp injectors and a Quad Adrenaline 4K and this turbo would make around 44psi."

http://www.ebay.com/itm/HOLSET-Hx50-Cummins-turbo-with-custom-T3-housing-/261076038932?pt=Motors_Car_Truck_Parts_Accessories&hash=item3cc9583514&vxp=mtr

Sent from my HTC One X using Tapatalk 2

[Superdave]

IIRC it's pin D16 on the 7730 for the P/N switch, grounding that does 2 things;

1. it switches to the P/N idle table that's normally not used in the 5 speed tunes
2. It enables the P/N rev limiter, From the factory in both auto and manual tunes it's maxed out (disabled)

The P/N limiter is only active:

1. When the input is grounded
2. Car is not moving


I set mine for ~3K RPM in the tune. Do a regular burnout at the strip, roll up to the beams, flip the switch and hold the brakes hard, stick the gas to the floor, let off the brake on the last yellow and hold on.

The only problem i've had is before i replaced my brakes, once the wheels spin a little the limiter is disabled and it goes back to the standard which in my case is 7K. I red-lighted a few times that day.


I do use a pretty high stall converter (4K), this helps to get it close to the flash point.


In a 5 speed car this would be easier, just flip the switch and trust the limiter. Let off the clutch and go. I really wish i had known about this back when i had my Z24.

[ga2001532]

the P/N limiter as a 2 step does work quite well, kinda fun on the street too.

how does that work?

[robertisaar]

well, here is 1.06.

lot of notes in the release notes document, but as always, if something is unclear, ask.

couple of things to note, since i sometimes fail to remember to add them into the release note document:

if you're running a boosted engine, try and set the max RPM to allow baro update under your boost threshold, otherwise when you go into boost, your baro reading will update to 104.45kPa and throw off your fueling. BPW while in boost is determined by the 100kPa row in the VE table at the proper RPM + the BPW multiplier table. spark advance while in boost is similar, except there is a spark advance subtraction table that works off of the 100kPa column.

i haven't tested the skip-shift F31 shifting on-bench or in-car, but i have no reason to believe that it doesn't work. should be able to drop directly from 4th to 2nd or 3rd to 1st if the situation arises, instead of 2 downshifts.



i need my damn MEMCAL back to test the ability to use 64KB BINs(i'm not sure how well my G3 adapter is reacting to it) after some internal modifications to the PCM. GM, for whatever reason, connected 5V to the highest address pin on the MEMCAL connector(essentially only allowing 8000-FFFF to be usable on the PROM, instead of the potential 0000-FFFF range not counting the adresses taken up by the RAM and registers), so i did a quick mod to remove the 5V applied and have it switch as necessary, but i haven't been able to test it yet. this is pretty much a requirement to move much further forward, since PROM space has quickly run out.

if that test goes well, i'll post the information necessary for anyone to DIY, it's...... interesting, to say the least. luckily, the soldering skill required isn't very high either, it's essentially removing a pin from the MEMCAL connector in the PCM, then connecting it to one of the edgecard pins via a short length of wire out the side of the connector. it sounds odd, but seeing it makes it much simpler. i'd like to find a way to make it easier, but outside of installing a permanent adapter, i'm not really sure how to do so at this point in time.


i have a small example of a patch in this XDF, it will allow you to switch between using a coolant level sensor and a transmission temp sensor with the push of a couple buttons to apply/remove the "patch", it's certainly a welcome addition to tunerpro to be able to do this, since all future updates to nAst1 could be done via these patches, allowing you to use the same BIN at all times, press a button to patch and be up to date.



i think that's everything. enjoy, and feel free to suggest what direction to go next.

[robertisaar]

it took some digging......

but for some reason, which i have yet to actually find, the PCM thought that it was continuously in mode 4 and that the fan was being commanded off no matter what. so i simply disabled the mode 4 fan 1 control in the algorithm until i can find out what's causing that bit to get set... but now at least fan 1 comes on when it should due to a/c pressure and coolant temps.

anyways, i'll need to do some cleanup, since i had to modify the crap out of the datastream to get information into it to help me troubleshoot why the fan wasn't coming on. but my next post should be accompanied by a ZIP archive.

[robertisaar]

got the 4 circuit PRNDL decoding debugged, along with the TCC PWM stuff completely functional as well. now the only issue that i know of is for some reason fan #1 won't come on due to A/C pressure or coolant temp.... fan 2 kicks on as expected, but not #1. i don't remember messing with anything that effects fan #1 either(lot of stuff that effects fan #2 though), so this may take a little while. the code ACTS like the fan is being turned on(extra IAC steps get added and a few status bits get triggered), but i'm not seeing it on the LEDs in my testbench.

otherwise, it's ready for release.

[robertisaar]

well, assuming you want to redo the wiring, you can now use 7727 pin D22 (7730 pin D14) for a 2/3 step rev limiter instead of tricking the PCM thinking you're in P/N instead of D. i don't THINK A1 has trans abuse prevention code in it(been a while since i've looked), but if you were to do it that way with DF, it can cut fuel temporarily as the trans "shifts". of course, it could always be tuned out, but if that code were present in A1 and it weren't defined in the XDF, it could cause lots of hair removal in the process of figuring out why it happened.

also: 4 circuit PRNDL decoding has proven to be more problematic than i thought, but i believe i'm on my final fix of it...... most of the issues have been due to GM leaving in legacy support for older stuff, like a/c pressure switches instead of the pressure sensor, stuff like that. i could have done a full PRNDL decode with only 3 circuits, but i'm using all 4 as used with the 4T60E for now.

[Superdave]

the P/N limiter as a 2 step does work quite well, kinda fun on the street too.

[robertisaar]

oddly, GM did do a few things right with a couple of tunes....



also, figured out my BPW disparity... changed my comparison tunes so that the only thing different between them was that one used a 3BAR and one used a 1BAR and now the BPW issue is resolved. now to disable barometric updates when using a 3BAR..... since that's exactly what GM did with all of it's factory boosted stuff. or at least only allow it under a certain RPM(below the boost threshold).