I went out trying to tune my 96530006 ROM (upgraded from 94170008).

I noticed the timing was not following the 1-byte load that I was logging.
From what I understand the timing follows the barrow+temp compensated load, which is what the 1-byte is. But there is a condition where timing will not follow that load, what is that?

Edit: My 1-byte multiplier is 1.2. I'm not sure that makes a difference here.

 

Here are some notes that I have from a thread where mrfred posted on the disassembly:

spark advance lookup: For air temp below 77F, baro+airtemp compensated load is used for spark advance. For temps above 77F, then baro compensated load is used.

afr lookup: for closed loop conditions when load is < ~20, uncompensated load is used, otherwise, baro+airtemp compensated load is used. This means that baro+airtemp compensated load is used essentially all the time for AFR lookup.

 

Thanks, l2r99gst

I think the ambient air was around 71 that day. But maybe the intake air was about 77.
I didn't log IAT though unfortunately.

 

Okay. I logged a 1byte (air+temp load), barometric load, and raw load, all three.

I'm looking at some logs and I have an example...

At 3500 rpm
1byte - 205
barometric load - 219 (should be following this)
raw load - 228

my timing is 5. In my timing map the nearest 5 I have is at load of 260.
Timing at 220 and 240 load is set at 6 in my map.

How am I getting a 5? My logged octane number is 100.

Is the eval formula wrong for timing? x - 20 ?

 

One thing I thought of is it could be that I changed the load scaling on the timing and fuel tables.

If I read the map according the the stock scaling then the timing makes sense.

Do the tephra roms not allow rescaling of load on the timing + fuel maps?

 

This is interesting...

I kept quiet about this because maft pro has always fudged my load #'s. But when I recently moved to the new rom V7.6 w/ 1 byte load... they went stupid. I mean total bull****. I was seeing nearly 50lbs/min in GM /sec and 260 load...

I was contemplating dumping the Maft-Pro and going to SD on the ecu - in hopes it would FIX this. But I think it would actually make it a lot worse. Maft Pro locks the IAT down to 80* and does it's own temp compensation for SD. So I should see less variation in load than even you would.

 

Did you have any knock at all? If you expect 6 and get 5, that may be close enough that simple interpolation to other cells or logging speed may be contributing to that.

Let's see the log and your timing map.


Eric

 

Thats what I was thinking. If this was load ramp up on spool the difference in time between logging rpm, then load, then timing could possibly account for the difference.

Silly question since I don't use the live map - are you sure that your load axes are scaled in the map storage location AND the live map location?

 

I haven't looked at the timing/fuel maps in the live app map. I always just read my CSV log and refer to the map in ecuflash.

I was thinking this too, but there are some timing values where interpolation would make no sense. You can see timing of 4 at 3715 rpm. Nearest 4 is at 280 load, 3500 rpm. Also timing doesn't get pulled until octane number starts dropping right? My octane is 100 all the way.

I have been logging at the default 15625 baud.

 

Should I be using 2-byte RPM? Or speed up my logging rate?
I was under the impression 2-byte RPM is just to get better resolution data, not on-time data.

edit: I logged 2-byte RPM today. No revelations from that. I tried logging at 31250 baud but I kept getting an error. I'll try 62500 tomorrow.

 

I believe I found the answer to my problem.
I didn't know there were two different timing values that can be logged.
MUT06 and 33.
I've been logging 06 which doesn't follow the timing map.

I will confirm this on the weekend, hopefully.

 

i log both with live timing(dma) you can log both, i believe the 33 is the real value from the maps and the 6 is the compensated one that is running on the engine