Hopefully this post will stimulate some discussion. Frankly, I hope what’s being written here is wrong. Maybe someone with a test bench could refute or verify it.

Here's the issue. For some time now, I’ve noticed that Spark values in log files were, on average, anywhere from 1 to 3 degrees lower than those in my MAIN Spark Table at a given RPM and kPa. But values in the logs from the EXTENDED Spark Table were as expected.

This just did not make sense. So set out to simulate the code to see exactly what was happening. To my surprise, the simulation supported my observations!

Note: This applies to a regular AUJP bin, not S_AUJP; but it’s likely the same. The 3 Dimensional look-up Subroutine at LE3B5 (the SR) is used to extract Spark values from the Tables.

Bottom Line: Code simulation shows no Spark value is returned from the MAIN Spark Table from any cell above 3200 RPM. And there is no value accessed in the MAIN Table above 3600 RPM in the process of returning a MAIN Table Spark value. What this means is that Spark is “all-in” at 3200 RPM regardless of what is entered in the MAIN Table at 3600 RPM and above.

Here are some examples:
Is this by design, or is the simulation in error?

At first I thought surely the simulation must be in error. So, as was done for the Spark Tables, unique values were entered into all cells of the other Tables accessed by the SR. In every case, the values returned from these other Tables were as expected. Other Tables: Coolant Compensation Spark (L8138), Closed Throttle Main Spark (L81FD), VE Lower Table (L86EB), VE Upper Table (L8797), Barometric kPa Adder to MAP (L86C7) and EGR Duty Cycle (L82B2).

Have uploaded an Excel spreadsheet that shows the exact Spark Table cells accessed, plus other test-related documents.

Anyone have ideas? Does this also occur with other Broadcast Codes?
Would really appreciate someone with a test bench confirming this or shooting a hole in it.

 

As a quick thought, can the calculations be further verified using the History table in TP and exporting?
That may be how you did it, I'm just slow this morning.
Am going to load up some logs and see if the results follow.

I'm looking into your other source question also.
Jp

 

I'm glad to see you are still questioning everything
After review of some of my logs logs, there are not many data points above 3200 that are not in PE. (that's just my driving style)
There does "seem' to be a slight loss of the total set in the table but the SA does creep above the values set at the 3200 mark (I think anyway, values are not that much different to 100% confirm).
The losses could be attributed to the LSB knock counts you pointed out earlier. I don't have any logs with that memory location to check it.

Still need to look some more because of the lack of good data points.
Car is hibernating with all my good hardware in it.
Does make me want to fire up the bench and play

 

JP - Thanks for responding. Really wish you, or someone else, could fire up a bench test to see if my assertion is right or wrong. But if that is done:

• there should be no entries in the MAIN Table above 3600 RPM.

If my assertion is correct, the spark reported by the bench test, say at constant RPM of 4000, should be normal if nothing is being accessed by the code above 3600 RPM.
Short of a bench test, the only thing I know to do is to raise my TPS percentages at which PE is invoked so it won't be, and delete all entries in my MAIN Spark Table above 3600 RPM. Then do a gradual acceletration to < 4800 RPM to see what happens. If my assertion is correct, the thing should NOT nose-over once at 3600+ RPM because spark will be being pulled from RPM < 3600, and the logs should support that. But don't really want to do that except as a last resort, in case I'm wrong.

Bench test please.


They can't because spark is being pulled from the spark table at every 25 RPM below 4800, but NOT from the actual RPM row. So the History table, as does a log, shows a spark value for every RPM and kPa encountered during the logging session -- but the spark reported is not from the RPM expected, again if my assertion is correct.


Thanks!

 

OK, you made me think about this too much and I got most of my bench back running today.
I didn't have my burning stuff so I just used old bins to run with.
I am getting SA changes above 3200 (at 4000 and above) via MAP changes and via steady MAP with RPM changes.
I only have open loop operation and could not make a bin with step changes to verify actual cells that were being returned.
I will grab my autoprom, etc and make up some fake tables to verify.
Hopefully by this weekend. Car in storage with all my stuff in it

Almost forgot how much fun it is to play with the bench

 

Fantastic. Yea, you'll get spark above 3200 but it's not yet certain where it's coming from. Remember in the "fake tables" to leave blank or zero all MAIN spark table entries for 4000, 4400 and 4800 RPM, all kPas. Just think, playing with that bench will give you something to do on those cold winter days you won't be driving or tuning! Thanks JP!

 

JP. Did you ever get traction control in v4 working

 

No I never got a chance to see why that code block was being bypassed.
Still on the short list though.
Need it with my 406

I'm in Salt Lake City so I haven't been able to get my stuff to make bins and test the SA routines. (Work emergency trip)
Hoping to have equipment by saturday some time to begin playing.

 

If you ever find yourself in vegas, hit me up

 

Got back last night.
As it happens I had to fly into Vegas on my flight to Nashville, then Cleveland. Never got off the plane though.
Was warm there, should have stayed a while
Got my autoprom and NVSRAM ECM so i can setup to play for a bit today.

 

Did it and it is averaging between the cells (as it should)
As soon as I cross 4000 RPM, the adjacent cell begins averaging between them.
Once I cross the zero'd boundary cell, the value stays low.
Working as expected.
Sorry Elky, but you'll need to look back over that code again.

This is Open loop BTW, can't simulate CL yet.
going to try "pre-warmup and other situations to see if your findings work there.

 

Note that when you enter the 4800 RPM cells in the lower table you are averaging from the 4800 in the upper table (or from the 5200 from the upper??)

From your investigation, can you tell if the lower 4800 avg with the upper 4800 or with the 5200 cell?
or
When the transition to 4800 is made, what cells are being used going forward and then as RPM drops and re-enters the lower table?

 

OK, did some more sweeps to see how this works.
400-->4400 RPM interpolates the value between the cells.
4800 is avg with the 4800 from the upper table until it crosses into the 5200 rpm cell.
Then coming down it reverses to using the 4800 from the lower table.

Strange thing is, TPS is changes the SA value!
I saw this before but it seemed to go away after a speed up/slowdown cycle or temp warmup. here are some details of what i'm seeing.

MAP constant, RPM constant, TPS increasing causes around 3* retard. not sure why.
2000 RPM, 80.55 MAP, both perfectly steady, SA = 33.1
I come off idle SA table with TPS rising slowly...to 2% TPS, SA still @ 33.1*
TPS = 3.1%, SA = 33.4
TPS = 20%, SA = 33.1
TPS = 24.3%, SA = 32.7
TPS = 32.9%, SA = 32.3
TPS = 40%, SA = 31.6
TPS = 44.3%, SA = 30.9

At 45% I go into PE so can't go farther at 80 KPA.
Any ideas?

 

Trying to figure out what is going on at times is difficult. IIRC, there is a closed throttle SA table, that would explain the jump in SA: from 2% TPS going to 3% TPS.

As far as the reduction in SA while opening the throttle. It may have been that at 0% TPS to say 10% TPS, at 2K RPM, and 80.6 KPa, the ECM was starting to believe that the MAP sensor was bad (on a real engine the MAP can't be that high).

If so the ECM would go into N-Alpha mode and create a MAP value via the TPS & RPM. This won't set the SES right away, and this default value isn't in the ALDL stream (unless I missed it). Only the raw MAP ADC is there.

RBob.

 

Who asked for a Bench Test? DARN!!! OK, I'll start the code reveiw, but a couple of things:

• What are you doing that tells exactly what Spark cells are being accessed? Do you have unique values in each cell so that can be determined? If not, seems any value could be reported and it's source would not be known. Not questioning your tests, just searching for answers.
• Would appreciate one more test. What results do you get at a constant RPM of say 4400 or 4600 with the empty table (4000-4800 RPM)?

Also, IIRC don't believe CL or OL makes a difference. Also, my results were the same regardless whether Warm Kickdown was enabled or not (ie - +/- 113*F didn't matter).

Edit: Not sure it matters, but forgot to add that the Closed Throttle table is not used until Warm Kickdown is invoked at > 113*F.
Edit: Also the 100 kPa Column is used for Spark until 113*F.

 

Totally clueless. The only thing TPS% appears to be used for in setting Spark Advance is to determine whether to use the Main/Extended tables or the Closed Throttle table. Since you were never at closed throttle, the results don't compute -- that is unless your Idle-Max TPS% is set very high. Your results are somewhat like what I'm seeing in a different way.

 

JP -- When you have the time, still interested in a test at steady RPM of 4400 or 4600 with 4000-4800 Main Spark table = 0 or blank.

Regardless of that result, have given a lot of thought to this and have taken a fresh view of everything. The only problem I'm seeing is the extraction of values from the MAIN Spark Table. This is done using the 3D Subroutine (SR) at LE35B. In every simulation of the hundreds that have been run, all other Table values extracted by this SR are correct except those of Main Spark. The same SR code was used in the simulation of every table (file diffs have been run to verify no copy-and-paste differences), so that eliminates different SR logic from being used for the erred Main Spark Table.

So this leads to the logical question: Why is MAIN Spark showing to be different? It shouldn't be! Heck, at a high level, the SR is basically dumb. It merely receives input values, processes them and provides a single 1-byte output value. So with identical SR code, the only variable is the input to the SR. Could all my Spark input values be invalid, providing unexpected results; while all other Tables' input values are valid, providing correct results? Hard to believe.

But despite that, I followed your suggestion and took a very hard look at the SR code -- even to the point of tracing through it with several manual Main Spark calculations a line at a time using various input values. Then I used the same input values in ThrSim11 simulations. The results were identical! On the surface, this says that the simulation is NOT in error, and the values returned from the Main Spark Table are at times not what is expected.

So now I'm really stumped because I can't think of any other variables to eliminate to disprove my assertion. Any other ideas?

In the interim, how about a test to eliminate all Spark except that from the Main Table. Below is what I hope can be Bench Tested to do that. Some of the items listed may not have an effect, but rather be safe than sorry.


In addition to zeroing the 4000-4800 RPM cells in the Main Spark Table, eliminate the following:

• Distributor SA Setting - Set L8025=Initial Distributor SA = $00
• Forced Knock Spark Retard - Set L829C=Min Cool for Err 43B Test = $FE (151*C)
• PE Spark Adder - Set L81B3=Enrich Power Spark Advance .vs. RPM Table = $00 (all cells)
• Hwy Mode Spark Adjustment - Set L81A8=Hwy Mode SA Max MAP = $01 (1 kPa)
• Coolant Adjusted SA
  - Set L8137=SA Base Temp Correction Table Bias = $00
  - Set L813B=SA Base Temp Correction .vs. Load .vs. Temp = $00
  (all cells)
• Hot Restart Spark Advance - Set L8672=Disable Hot Restart SA if Greater = $00
• Extended Spark Table - Set all cells = $00
• Spark Latency Correction -Set L8129 = $00 (all cells)
• Startup Temp SA Adj - Set L81B9=SA Startup .vs. Temp = $00 (all cells)
• Closed Throttle SA - Set L81FD=SA Closed Throttle .vs RPM = $00 (all cells)
• Low Octane Retard - Set L8229=Low Octane Knock Retard MAP Enable = $120 (110 kPa)

Thanks for your time in performing these tests!

 

OK, just got back into the web.
I tried doing a steady state with zeros and it did return zeros all around.
Using values of 1 produced some wierd values but will need to go back over that. (gave me some infinite values, possibly went negative???)

I'll make up a bin with the items you cite taken out and do some sweeps.
If you have certain SA values in mind you would like to see, create a bin and send it over. I will copy the values and and run sweeps for you at different MAP or RPM combinations. You may see something in those logs to nail this down.
Won't be able to do much today with Santa coming tonight

Merry Christmas!

 

Set all that and got all zero's everywhere. can't make any SA.
One thing you may want to look at is the Stall saver routines.
could be something in there that is adding back in.

I did get full SA when the TPS went below my minimum setting of 1.2% but that I believe is my voltage on the input going negative just a bit.

 

JP -- Attached are some Bench Test files (bin, adx, xdf) with the above-listed changes. If done correctly, there should be no spark except from the Main Table. Note that these files are NOT S_AUJP versions but before S_AUJP as that is all I have adresses for from the .LST file to do address hunting (re - my PM about S_AUJP .ASM/.LST files).

TPro Data Tracing has been enabled for the Main Spark table. That should allow viewing of accessed Spark Table cells while viewing RPM and MAP in the TPro Dash. Just enable Data Tracing and view the Main Spark table and Dash while logging.


Really interested in what this shows in a Log. Maybe you could post that after some tests:

• Steady 3200 RPM
• Steady 4000 RPM
• Steady 4400 RPM
• Acceleration from idle to 4400
• Anything else you can think of

Coolant temp does not matter.Thanks in advance!

EDIT: Looked at Stall Saver and it appears there is a Spark Blend Multiplier (L013B) that operates on Spark-REF (L00BB) in Subroutine at LE347 to determine a final Saprk-REF. The only way to cause that not to happen would be force L013B=1. Is that possible?

 

Well, nothing earth shattering. Seemed to do what is expected.
Ran with two different ADX files, yours and mine to be sure there were no conversion issues.

 

Wow! Thanks for your time and effort running this. No question the test files isolated spark to only the Main table, and spark tracked RPM as it should. So it's back to the drawing board to understand why hand calculation and simulation of the 3D subroutine at LE35B produces different results, but only for main spark and not the other 3D tables it accesses.

Really don't understand it because the input values to the SubR for main spark are not complicated:
Accum A = RPM / 25 (0x00 - 0xFF)
Accum B - MAP (0x00 - 0xFF)
X = Address of the main spark table at L8033

The only thing I can think of is that the addresses of the spark table elements created by the simulations's compilation of the code snippet are incorrect. But they are visually sequential and appear correct. And why woudl they be incorrect when all other 3D tables work Ok. I know there are problems simulating snippets if any of code contains embedded addresses, but there aren't any in the tested tables.

Any ideas? Gonna be some wine consumed this evening!

 

Welllll -- The mystery is finally solved, and stupid is as stupid does! But the good thing about doing something wrong is that something is generally learned -- and it certainly was in this case. I've been consumed with why my Main Spark Table code simulation did not agree with JP's bench test results. Clearly it had to be a problem with the simulation, but what?

The problem was/is a little thing called "Scaled RPM". WTH? I was feeding RPM/25 to the subroutine that extracts Spark values from the Spark tables with the understanding that RPM/25 was RPM/25 was RPM/25. NOT SO!!! If interested, here's why. Once the engine is declared running, AUJP $8D (and perhaps other masks) computes several RPM values every 12.5ms in the Spark Minor Loop based on the # of ECM clock ticks equal to the current # of Distributor Reference Pulses. All these RPM values except one are identical, despite being saved differently as either RPM/25 or RPM/12.5. The exception RPM is called "Scaled RPM/25". In AUJP, that RPM variable is L0057. Have always wondered why it was called "scaled" and now I know. Rather than having a maximum value of 6375 like other RPM/25 values (0xFF = 255d * 25 = 6375), its values differ from those of the other RPMs and appears to have a maximum value of 4800. Don't have a clue why! But it is clear that this variable, computed as it is, was specifically designed to extract Spark values.

In summary, from 1200 RPM up, the Scaled RPM/25 values begin to get progressively higher than actual RPM, and up to 1600 RPM higher at 2400+ RPM. That's why the simulation results were skewed and did not agree with the bench test.

A spreadsheet is attached containing values computed for L0057 (Scaled RPM/25) and L0058 (Normal RPM/25) from ECM clock ticks at various DRPs. Also included, because the initial document was incorrect, is a revised file showing the spark values extracted from the spark tables at various RPMs and kPas.

Just when I think I'm starting to understand some of this stuff, it spanks me.