84Elky

What would cause SA to randomly drop during off-idle tip-in. Note, random, as it does not happen all the time. The SA table has no values close to the lower SA values shown in the log file? Car runs and idles great, but sometimes has a minor off-idle tip-in hesitation once at operating temp.

Below are settings and a log example where hesitation was noticed. Note the SA-TDC drop at 875 and 1125 RPM. The SA table shows the SA cells set to 21.09 at 875 and 22.85 at 1125 at the kPas shown. I understand there are cell transitions in tables, but no surrounding cells have values close to those reported, so what could be causing this? Is there something in the code (AUJP, 8D)? Thoughts?

Settings:
- In gear idle = set at 750 RPM, rock steady
- Closed Throttle SA = 21.09, 0 –1200 RPM
- SA Table = 21.09 for all kPa, 0-1000 RPM, SA 50-80 kPa at 1200 RPM approx 2* above 21.09

Coolant temp = 205*F for these samples:
RPM------TPS %------MPH------IAC Steps------IAC Comm------MAP (kPa)------SA-TDC------BPW
750--------0-----------0-----------28----------------0-------------54.7----------20.39--------2.15
750--------0-----------0-----------28----------------0-------------54.7----------20.39--------2.15
725--------0-----------0-----------28----------------0-------------54.7----------20.74--------2.11
775--------0-----------0-----------28----------------0-------------54.7----------20.39--------2.12
750--------0-----------0-----------28----------------0-------------55.1----------20.74--------2.12
750--------0-----------0-----------28----------------0-------------56.2----------21.45--------2.17
775--------1-----------0-----------32----------------5-------------58.4----------21.09--------2.32
800--------5-----------0-----------38---------------13-------------65.8----------21.09--------3.05
875--------8-----------0-----------48---------------21-------------74.6----------19.34--------3.66
1125------11----------0-----------57---------------30-------------76.5----------20.39--------4.26
1425------12----------0-----------58---------------31-------------74.3----------21.45--------4.24
1475------14----------2-----------64---------------36-------------75.7----------22.15--------4.15
1650------15----------2-----------67---------------39-------------75.0----------22.85--------4.35

Ronny

iTrader: (1)

Coolant temps could affect...SA coolant compensation...But one would expect that would be the same factor sec to sec.

Knock counts could affect if you are seeing KC?

84Elky

Thanks for prompt reply. Agree on sec to sec for SA Temp Correction .vs. Load .vs. Temp. Also, verified all cells there set to 20.04 from 90*F through 219*F (log was at 205*F and table breaks are 198*F and 219*F so should be OK), and SA Base Temp Correction Table Bias set to 20.04. As I understand how these 2 work together, there should be no spark added or subtracted based on temp or kpa since the values are equal. Is that correct?

Also, no knock counts or retard. It's because neither of these seem to be affecting SA that caused the question if the code could be doing something unexpected (sort of like Forced Knock rears its ugly head for some). I'm OK with C; but Assy -- not, so reviewing code is out.

If it's not code, looks like TPro data tracing is in my future to see what's getting accessed. Any other ideas?

EagleMark

That is an awfully small drop in spark advance at 800 to 875 RPM with a MAP drop from 58 to 74. Would have to see your spark advance table but it should be doing that. If not your really splitting hairs in data.

If it were'nt for that COOL analyzer you'd never have found it!

That small a change in spark is not the cause, maybe a little more AE?

HTH!

84Elky

Actually found this in the log while the Analyzer was taking a rest. Yea, you’re probably right about the small drop in SA and maybe overly **** about it. But after logging 15-20 easy accels from 0 to 5-10mph, everyone that had a hesitation had a SA drop. Good ones did not. On the good ones, SA went from idle deg. to approx +2 deg. per the SA Table. That’s what led me to wonder about what the code does under the covers.

At one point also increased all values in the following AE tables by 15% to try more AE: Enrich Accel Delta TPS Mult .vs. Delta TPS and MAP
That did not help. Are these the right tables for more AE? Hopefully they aren’t inverse. Was 15% enough, too much, or should they have been reduced for more AE?

SA Table attached. Thanks for the help.

EagleMark

I didn't want to say that! But with that ****yzer it's obvious your into good data!

Your right about spark table, most do drop in this situation. I was just trying to help since you donated your Analyzer project to everyone. But there's guys around here way more familiar with your mask and I'll let them help with AE. 15% if in right spot is not a lot depending on motor build.

Ronny

iTrader: (1)

You could disable the KC for a test run to see if it is that? But KC's would appear in datalog? So maybe redundant.

Is EGR disabled? Is EGR hardware removed?

84Elky

No knocks so that't not an issue. EGR and AIR deleted physically and in calib. Only thing left when the weather clears up is to sock a lot of AE to it (perhaps +50%) and see what happens. Then back it off a bit at a time if that works. If it doesn't, then back to square 1.

JP86SS

iTrader: (1)

You could have some retard without knock counts showing.
That happens to me sometimes and I've yet to figure it out.
Adding more AE when SA drops could cause the bog to become worse. Hard to do AE without a WB to see what is happening. Might look at the O2 sensor to see if the direction or magnitude changes at the same point the bog occurred. Kind of guessing but it might show something consistent each time it happens.
Jp

RBob

iTrader: (1)

This is from the knock counter being 16 bits (2 bytes) and the ALDL stream only showing the high order (most significant) byte. Get some counts and the low order byte moves but the ALDL stream won't show it.

Need to look at the knock retard byte of the ALDL stream. Or compare the two SA values in the data stream. One is without knock retard while the other includes knock retard.

This may be what is occurring here. But with the limited amount of data and no BIN in this thread, we can only guess as to why the SA dips a bit.

RBob.

84Elky

No WB yet, so have to rely on the vagaries of the NB for now. Seems it’s 700 ish when hesitation occurs (indicating lean?) and 900 ish when all OK. Agree with what you say about making it worse with more AE, but gotta start somewhere. More analysis reveals that off idle tip-in is OK in OL and in early CL before operating temp (heated NBO2), but becomes random once at operating temp. That would seem to indicate it’s possibly short on fuel with the heat? Will post results when done.

On the retard without knocks, I also used to get it, but reducing SA slightly in kpa/RPM area where it was occurring solved it.

If I understand what you are saying about the 2 knock bytes, the LSB accumulates up to 255 and then once reached, registers a count in the MSB that is reported as knock. Is that right?
{EDIT: Just looked at the DDS list of $8d and byte 42 = LSB of SA TDC, byte 43 = Knock count and Byte 44 = SA Retard Degrees. Is the 2nd (LSB) byte of knock count in the code and just not reported? If so, would apprecite the address for possible later access.}

Don’t understand about the 2 SA bytes regarding one with and one without Knock retard. Are you referring to TDC .vs. Ref Pulse or the LSB and MSB within one or the other? More info appreciated. Thanks.

RBob

iTrader: (1)

With the MSB of the PA3 knock counter being L00C1, change it to L00C2 ($C2) to see the LSB of the counter in the data stream. Likely it is more useful that way.

The SA relative to the reference pulse is the final value. Use that and add in the Initial SA value for the actual at-crank timing. Can add the initial back in via the ADS/ADX file to make it easier.

The SA relative to TDC doesn't have knock retard subtracted out.

RBob.

84Elky

RBob – Regarding the knock counts, here are the 2 references to knock count address 0x00C1 in JP’s AUJP hack:

I take it you are saying to replace 0x00C1 with 0x00C2 ONLY where 0x00C1 is defined in the Mode 1 DDS, and NOT where it’s assigned to L00C1. Right? I can do ‘C’, Fortran and Cobol, but Assy = NOT!!! Not questioning you, but would like to understand why 0x00C2 is not referenced anywhere in the code if it’s used? Seems strange, but again, it’s Assy. Yuk!


JP – Increased Stock AUJP Enrich Accel Delta MAP and Temp tables + the Accel MAP and TPS factors/multipliers all by 40% and stalling gone at off-idle tip-in. Maybe 40% too much, but can now back down as time allows. No more SA drop. Now drives as it should be. The new cam is sucking much more air at idle and needed more fuel.

And then WTHeck – Just as I said that my knock retard without counts was gone, today logged and got them. And this was with a bin that had previously not shown any retard. Just changed fan on/off temps for a test. I was doing 3rd gear non-PE pulls from 2200 RPM to 3500+. Discovered that no retard resulted prevoiusly in pulls, but they were made at 184-189*F. But today, with fans set to come on/turn off later, the same pulls were made at 205-208*F and got the retard. There has to be something in the code that causes this because coolant temp is the only variable here! Guess I’m going to have to learn Assy. Yuk again!

RBob

iTrader: (1)

Just change it in the ALDL stream list, nowhere else. If you can do C you can do assembly. The reason you don't see L00C2 referenced is that it is being saved at L00C1 such as an unsigned short int, not as an unsigned char.

Hotter engine == more prone to knock.

RBob.

84Elky

Thanks. Changed 0x00C1 to 0x00C2 at 0x8992 & all is good. Gotta play with it some more to see how/why it actually reports the counts.

Understand, and now see that byte address 0x00C2 is not assigned. And OK, against my better judgement, I'm going to try & learn Assy. Looks like I have to first understand the directives and addressing modes and then try to injest all the nuances of the OP codes. Yuk. C is intuitively so much easier.
BTW, it looks like all the 63 DDS values are defined as ".word", yet only reported in the DDS as 63 bytes of data. Any idea why? Just seems strange for so many of the items to be this way when LSB and MSB are not used/reported in the DDS.

Understand!

JP86SS

iTrader: (1)

I'm interesting to hear if that shows better sensitivity to the retard happening. (toy is stored for the cold season already )

Use the LST files from the hac as it will indicate ALL addresses as they are arranged in the file. (If you are using the stock AUJP)
Most of the addressing shows only the beginning of the line where the address starts. You'll have to count from there to get the latter ones such as the second byte of a value.
I can provide exact S_AUJP addresses also if needed for the std or NVSRAM versions.
Jp

84Elky

Will let you know. Tried today, but a little cooler so no knocks. Will have to re-up the fan temps in hope of getting the knocks w/out counts for a valid comparison. But that may be getting harder as the ambient temps here are dropping.

Your comment about the .lst file finally turned on the light bulb as to what that file contains. Would have been nice to have used it when searching for 0x00C1 from the start of the DDS in the Calib. Thanks. Am using stock AUJP for now, but once everything ironed out, I'll likely change to S_AUJP and would like to have the .lst for that as well.
Tom

RBob

iTrader: (1)

Think of it as an array of pointers to unsigned chars. The pointer being a 2-byte address.

RBob.

84Elky

RBob - Got it. Thanks!