Chrome V3, need a place to organize my thoughts

[Monochrome]

[quote=""ChargerX3""]Agreed. That wasn’t lost on me, just his process.[/quote]

At the end of the day, all that matters is you get the Wideband numbers. There's dozens of tables which you can edit to get that. All I'm saying is the "correct" table to edit for tuning is the fuel and the smoothing table.

[aaronatstate]

[quote=""Monochrome""]Adding more to the adder value is going to richen the whole MAF range. Adding more to the smoothing table will only richen the mIxture at the HZ range you edited.

Also, there's the fuel side of all this. What injectors are you running and what injector size? Sometimes people running E85 will lower the injector size to get more fuel across the whole range. Same thing you're doing by adding more to the adder value. In fact that's probably smarter anyway!

When tuning E85 cars I completely disable closed loop and tune using only the MAF smoothing tables. Takes a few pulls but when you're done and reenable closed loop, the car runs stock smooth.

Don't let the 172 number in the smoothing table scare you either. I've gone higher than 200 in some tunes. Remember you don't have factory ICs or pipes AND you're running E85 which is 33% MORE fuel by itself.[/quote]

I’m running Evo 560s, with the base pressure set at 55psi. That makes them behave like 640s. So I have my injector size set at 493 (640/1.3).

[quote=""Monochrome""]At the end of the day, all that matters is you get the Wideband numbers. There's dozens of tables which you can edit to get that. All I'm saying is the "correct" table to edit for tuning is the fuel and the smoothing table.[/quote]

Agreed. There is more than one way to skin a cat as they say. Hopefully I can play around with the smoothing now so my WB02 matches my fuel table. It was 11.8 vs 11.0. I’ve adjusted the smoothing up by 7% (11.8/11.0). Haven’t had a chance to test yet. Hopefully if it’s close I can just mess with then fuel/timing tables.

One other thing, which EvoScan setting do I use to log my AEM UEGO? I know it’s pin 93 on the 99 ECU which is 55 on Adams 1g ECU, but I’m not sure which item to log in EvoScan.

[Monochrome]

Ya know what I just realized... If 33% more fuel is needed for ethanol then simply adding 33% more to the adder value should give you a good base line. Never thought of this before!

[Monochrome]

[quote=""aaronatstate""]I’m running Evo 560s, with the base pressure set at 55psi. That makes them behave like 640s. So I have my injector size set at 493 (640/1.3).



Agreed. There is more than one way to skin a cat as they say. Hopefully I can play around with the smoothing now so my WB02 matches my fuel table. It was 11.8 vs 11.0. I’ve adjusted the smoothing up by 7% (11.8/11.0). Haven’t had a chance to test yet. Hopefully if it’s close I can just mess with then fuel/timing tables.

One other thing, which EvoScan setting do I use to log my AEM UEGO? I know it’s pin 93 on the 99 ECU which is 55 on Adams 1g ECU, but I’m not sure which item to log in EvoScan.[/quote]

Wideband Scaled

BUT you have to flash the ROM with your Wideband voltage settings in the Wideband Scaled table for that log value to be correct.

[Monochrome]

[quote=""Monochrome""]Sensor Scaling

While these serve no performance function at this time, this was the best solution I could come up with for logging after market 5V sensors thru the stock ECU. If you guys like these, I'll add more 5V scaling inputs thru secondary O2s (say you wanted to log fuel pressure or oil pressure).

Right now, this is setup to log any MAP sensor thru pin 92 and any wideband thru pin 93. All you need to wire is the sensors 5V output signals into these pins, then scale them according to the manufacturer settings.



After you have this setup, then all you need to do to log them is select MAP and wideband Scaled in EVOScan. If you have your scaling setup correctly, the values will be accurate. You should be able to find the scalings for any/all sensors thru google.

For example, this is the scaling for the EVOX map sensor.



****I do not have a list of every sensor and their scalings however in the future I may compile a list for you guys. For now, you'll have to do a little searching.

Discussion here:
http://www.3sgto.org/f104/disassembly-m ... -8260.html[/quote]

[aaronatstate]

[quote=""Monochrome""]Wideband Scaled

BUT you have to flash the ROM with your Wideband voltage settings in the Wideband Scaled table for that log value to be correct.[/quote]

That’s what I figured. I set my scaling for my WB02. Just need to verify it’s hooked up. If it isn’t I have to find some extra ECU pins...I think I have one of Brett’s adapter harnesses though I can cannibalize.

[quote=""Monochrome""]Ya know what I just realized... If 33% more fuel is needed for ethanol then simply adding 33% more to the adder value should give you a good base line. Never thought of this before! [/quote]

You know what, my values make more sense now...

My fuel injectors are set at 30% less, my smoothing is set 72% less (102% less total). My MAF adder is set at just over double the stock value. (118% increase). Wonder if the MAF adder is a simple way to make flex fuel work

[Monochrome]

[quote=""aaronatstate""]That’s what I figured. I set my scaling for my WB02. Just need to verify it’s hooked up. If it isn’t I have to find some extra ECU pins...I think I have one of Brett’s adapter harnesses though I can cannibalize.



You know what, my values make more sense now...

My fuel injectors are set at 30% less, my smoothing is set 72% less (102% less total). My MAF adder is set at just over double the stock value. (118% increase). Wonder if the MAF adder is a simple way to make flex fuel work [/quote]

There is another correction factor in the code for ethanol. It's just set to 100 and I haven't made a post about it yet.

My original flex fuel code used the Octane value.

[aaronatstate]

[quote=""Monochrome""]There is another correction factor in the code for ethanol. It's just set to 100 and I haven't made a post about it yet.

My original flex fuel code used the Octane value.[/quote]

Interesting...

I would think you’d want to keep octane level alone, since doesn’t it control the timing as a result of knock?

[Monochrome]

[quote=""aaronatstate""]Interesting...

I would think you’d want to keep octane level alone, since doesn’t it control the timing as a result of knock?[/quote]

Knock will retard timing on its own. Octane will interpolate the high and low octane maps. Sort of like the codes way of remembering to keep the timing retarded. So you’d still get real time knock retard.

With Ethanol you would generally want more timing for more torque. The high octane map in a sense became the Ethanol map and the low octane became the pump gas map.

[aaronatstate]

So noticed today my rear turbo inlet pipe was off (happens a lot with the 13Ts). I think this was causing me to run leaner than tunes since more air was getting in that was not metered. I think it came off this morning though, so my experiments from yesterday are still accurate.

[Monochrome]

So you need 2x the air to show the ECU only one turbo is drawing it in.

Goes to show how well you can tune the car around issues caused by the setup. One time I tuned a car at NG15 to run on only 5 cylinders....

[Monochrome]

Finally able to focus my brain on this again.

https://www.bawcforums.org/vbb/showpost ... ostcount=3

A lot more on this to come but I need to go back and update some things I've learned about the MAF on the engine starting/cranking.

[ChargerX3]

Finally a reasonable explanation about Load. This helps to support the "your motor is nothing more than an air pump" idea. Nice work.

[Jeff V.]

Time for a history lesson.

https://www.bawcforums.org/vbb/showthread.php?t=31174

[Monochrome]

Sorry I couldn't reply to this earlier because I was pre-occupied and couldn't focus.

The issue with that thread is Load isn't exactly Air Mass per rev. Load is only calculated via MAF pulses.

Taking a step back, Air Volume is calculated just before Load. It uses value 80E (which I call AirVolumePerPulse) in the ROM which is a different multiplier value for every MAF pulse.

Code: Select all

seg002:20EE1             AirVolumeCalc: ! far                    ! CODE XREF: ScaleSensors+4BP
seg002:20EE1 1D 08 4A 80                 mov:g.w @BaseMAF_CF:16, r0 ! Move data
seg002:20EE5 1D 08 0E A8                 mulxu.w @AirVolumePerPulse:16, r0 ! Unsigned multiplication
seg002:20EE9 58 00 06                    mov:i.w #6:16, r0       ! Move data
seg002:20EEC
seg002:20EEC             loc_20EEC:                              ! CODE XREF: AirVolumeCalc+Dj
seg002:20EEC A9 1B                       shlr.w  r1              ! Logical shift right
seg002:20EEE 07 B8 FB                    scb/eq  r0, loc_20EEC:8 ! Control loop
seg002:20EF1 BF 91                       mov:g.w r1, @-sp        ! Move data
seg002:20EF3 03 01 44 2D                 pjsr    ClipTo1Byte:24  ! Branch to subroutine (specified page)
seg002:20EF7 AF 09                       add:q.w #2, sp          ! Addition
seg002:20EF9 A8 1A                       shll.w  r0              ! Logical shift left
seg002:20EFB A8 1A                       shll.w  r0              ! Logical shift left
seg002:20EFD A8 1A                       shll.w  r0              ! Logical shift left
seg002:20EFF 1D F2 E2 90                 mov:g.w r0, @AirVolume8Bit:16 ! Move data
seg002:20F03 1D F2 E2 80                 mov:g.w @AirVolume8Bit:16, r0 ! Move data
seg002:20F07 1D F2 DA 90                 mov:g.w r0, @AirVolume1:16 ! Move data
seg002:20F0B 1D F2 E2 80                 mov:g.w @AirVolume8Bit:16, r0 ! Move data
seg002:20F0F 1D F2 E0 90                 mov:g.w r0, @AirVolume2:16 ! Move data
seg002:20F13 11 19                       prts                    ! Return from subroutine (different page)
seg002:20F13             ! End of function AirVolumeCalc

This is the value we need to use to compare airflows between MAFs in order to adapt them to our ROM.

After this, then uses this calculated air volume to calculate load.

Code: Select all

seg002:21D5C             LoadCalculations: ! far                 ! CODE XREF: AirCalc+18P
seg002:21D5C 17 F8                       link    fp, #0xF8:8 ! '°' ! Create stack frame
seg002:21D5E 1D F2 DA 80                 mov:g.w @AirVolume1:16, r0 ! Move data
seg002:21D62 BF 90                       mov:g.w r0, @-sp        ! Move data
seg002:21D64 1D 08 0C 80                 mov:g.w @EngineVolume_80C:16, r0 ! Move data
seg002:21D68 BF 90                       mov:g.w r0, @-sp        ! Move data
seg002:21D6A 03 01 40 6F                 pjsr    Multi_16x16:24  ! Branch to subroutine (specified page)
seg002:21D6E 04 04 2F                    adds.b  #4:8, sp        ! Addition
seg002:21D71 BF 91                       mov:g.w r1, @-sp        ! Move data
seg002:21D73 BF 90                       mov:g.w r0, @-sp        ! Move data
seg002:21D75 98 FC                       mov:f.w r0, @(-4:8,fp)  ! Move data
seg002:21D77 99 FE                       mov:f.w r1, @(-2:8,fp)  ! Move data
seg002:21D79 03 01 44 EF                 pjsr    Incriment1:24   ! Branch to subroutine (specified page)
seg002:21D7D 04 04 2F                    adds.b  #4:8, sp        ! Addition
seg002:21D80 1D F2 B4 90                 mov:g.w r0, @Load_16Bit:16 ! Move data

Something I recently learned is our code uses Relative Load (both Barometric and Temperature Compensated) only if Short and Long Term Fuel Trims are enabled otherwise it'll use Absolute. In the code, right before it does the Fuel Map Look up, it populates that Load Axis value.

Code: Select all

seg002:23C4D             FuelMapLoadAxis: ! far                  ! CODE XREF: FuelMapLookUp+5P
seg002:23C4D BF 92                       mov:g.w r2, @-sp        ! Move data
seg002:23C4F 1D F2 B4 82                 mov:g.w @Load_16Bit:16, r2 ! NOT AIT or Baro compensated
seg002:23C53 1D F3 18 80                 mov:g.w @Periphery_00:16, r0 ! Short term + Long term Fuel Trims enabled = 1
seg002:23C57 0C 00 11 50                 and.w   #0x11:16, r0    ! Logical AND
seg002:23C5B 26 0E                       bne     loc_23C6B:8     ! Branch if Not Equal (Z = 0)
seg002:23C5D 1D F3 44 F1                 btst.w  #1:16, @OpenLoopCondFlag:16 ! Bit 1:  Open Loop Conditions NOT met = 1
seg002:23C61 27 08                       beq     loc_23C6B:8     ! Branch if Equal (Z = 1)
seg002:23C63 1D F2 BA 82                 mov:g.w @AirTempCompLoad_16Bit:16, r2 ! Move data
seg002:23C67 AA 80                       mov:g.w r2, r0          ! Move data
seg002:23C69 20 02                       bra     loc_23C6D:8     ! Branch Always
seg002:23C6B             ! ---------------------------------------------------------------------------
seg002:23C6B
seg002:23C6B             loc_23C6B:                              ! CODE XREF: FuelMapLoadAxis+Ej
seg002:23C6B                                                     ! FuelMapLoadAxis+14j
seg002:23C6B AA 80                       mov:g.w r2, r0          ! Move data
seg002:23C6D
seg002:23C6D             loc_23C6D:                              ! CODE XREF: FuelMapLoadAxis+1Cj
seg002:23C6D CF 82                       mov:g.w @sp+, r2        ! Move data
seg002:23C6F 11 19                       prts                    ! Return from subroutine (different page)
seg002:23C6F             ! End of function FuelMapLoadAxis

Code: Select all

seg002:23B7B             FuelMapLookUp: ! far                    ! CODE XREF: JumpToFuelMapP
seg002:23B7B 12 2C                       stm     (r2,r3,r5), @-sp ! Push data from one or more registers onto the stack
seg002:23B7D 5D 00 80                    mov:i.w #0x80:16, r5 ! 'Ç' ! 10000000  Bit 7
seg002:23B80 03 02 3C 4D                 pjsr    FuelMapLoadAxis:24 ! Branch to subroutine (specified page)
seg002:23B84 1D F1 DE 90                 mov:g.w r0, @F1DE_AxisValue:16 ! Move data
seg002:23B88 BF 07 E0 EC                 mov:g.w #0xE0EC, @-sp   ! Move data
seg002:23B8C BF 06 02                    mov:g.w #2, @-sp        ! 2E0EC - RPM Axis
seg002:23B8F 03 01 47 35                 pjsr    AxisLookUp:24   ! Branch to subroutine (specified page)
seg002:23B93 04 04 2F                    adds.b  #4:8, sp        ! Addition
seg002:23B96 BF 07 E1 10                 mov:g.w #0xE110, @-sp   ! Move data
seg002:23B9A BF 06 02                    mov:g.w #2, @-sp        ! 2E110 - Load Axis
seg002:23B9D 03 01 47 35                 pjsr    AxisLookUp:24   ! Branch to subroutine (specified page)
seg002:23BA1 04 04 2F                    adds.b  #4:8, sp        ! Addition
seg002:23BA4 1D F2 1C F5                 btst.w  #5:16, @TableSetSelect:16 ! Test bit
seg002:23BA8 27 09                       beq     loc_23BB3:8     ! Branch if Equal (Z = 1)
seg002:23BAA BF 07 E7 EA                 mov:g.w #0xE7EA, @-sp   ! Move data
seg002:23BAE BF 06 02                    mov:g.w #2, @-sp        ! 2E7EA 11984 LoOctFuel
seg002:23BB1 20 07                       bra     loc_23BBA:8     ! Branch Always

So it's not that you're wrong with that thread Jeff, it's just that you can't use Load as your value for directly calculating air mass per stroke. If we could then we wouldn’t need to use a 3D fuel map with RPM as the one axis already would contain that info.

To sum this all up in other words, Air Volume is volume of air per MAF Pulse and Load is volume of air Vs the volume of the engine. Does this make sense?


Another way to think of 100 engine load is the motor is consuming 100% of it's internal volume which is why NA motors can't make power beyond 100 Load. Since turbos are pushing more than the engine volume of air thru it, it can go beyond 100.

I've been stressing for YEARS that the biggest advantage with a MAF is you don't need to go to a dyno. You have a real time one built in the car! More LOAD = more POWER! If whatever you're doing isn't increasing LOAD than you're just making heat.

[Monochrome]

BTW there's STILL more to add to this. It has to do with the rest of the intake tables and things like idle gain and dynamic vs kinematic viscosity....

[Monochrome]

I need a history lesson on the 1G photo sensor causing timing issues. Where did this idea come from and how was it proven?

Long story short.... It’s BS too....

[mjannusch]

It came from some of our early work on the AEM EMS. The two different sensor types used different latency values in the AEM to keep correct timing at high RPM in relation to being accurate at low RPM. I don't remember the actual values off the top of my head, but it started there. Saw it across several local cars, and other AEM users reported the same.

[Jeff V.]

So it's not that you're wrong with that thread Jeff, it's just that you can't use Load as your value for directly calculating air mass per stroke. If we could then we wouldn’t need to use a 3D fuel map with RPM as the one axis already would contain that info.

To sum this all up in other words, Air Mass is volume of air per MAF Pulse and Load is volume of air Vs the volume of the engine. Does this make sense?


Another way to think of 100 engine load is the motor is consuming 100% of it's internal volume which is why NA motors can't make power beyond 100 Load. Since turbos are pushing more than the engine volume of air thru it, it can go beyond 100.

You're over complicating this. Making matters worse, you keep flipping between mass and volume like they're interchangeable. They're not.

The sensor measures the volume of air drawn through it over a given period, applies the temperature and baro corrections to determine the mass of air in that volumetric measurement, and then uses the 3D lookup table to determine how much fuel to inject to achieve the desired AFR for the engine's current speed.

"Load" is air mass drawn through the sensor per unit of time.

[Monochrome]

[quote=""mjannusch""]It came from some of our early work on the AEM EMS. The two different sensor types used different latency values in the AEM to keep correct timing at high RPM in relation to being accurate at low RPM. I don't remember the actual values off the top of my head, but it started there. Saw it across several local cars, and other AEM users reported the same.[/quote]

I just had someone run a test for me using a timing light and having the code fix the timing to 5 degrees. Would like at least one or two more people to verify this.

You just have your 2G spyder correct?