Page 7 of 9
Re: Chrome V3, need a place to organize my thoughts
Posted: Mon Aug 26, 2019 10:32 pm
by Monochrome
[quote=""Jeff V.""]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.[/quote]
Ah yep. I need to be saying volume not mass. Ill go back and edit that.
But....
Do we have two different ROMs disassembled? The fuel table look up is just another correction factor to the equation which comes later. Ill get into that when I get into the rest of the intake tables.
All Im focusing on is Load. I just posted the code for how Load is calculated....
What am I missing?
Re: Chrome V3, need a place to organize my thoughts
Posted: Mon Aug 26, 2019 10:59 pm
by mjannusch
[quote=""Monochrome""]You just have your 2G spyder correct?[/quote]
That's correct. Now it has a 1G CAS with a 24-tooth trigger disc.
Re: Chrome V3, need a place to organize my thoughts
Posted: Mon Aug 26, 2019 11:08 pm
by Monochrome
[quote=""mjannusch""]That's correct. Now it has a 1G CAS with a 24-tooth trigger disc.[/quote]
Damn. I need a couple people with 91/92 cars and a flash ECU to replicate this test.
Re: Chrome V3, need a place to organize my thoughts
Posted: Mon Aug 26, 2019 11:14 pm
by aaronatstate
[quote=""Monochrome""]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?[/quote]
At idle RPMs the timing is off by less than a degree, so I doubt you’d see it with a timing light. At 700 RPM it’s 0.35 degrees off. At 7000 RPM it’s off by 3.5 degrees, based on the sensor latency. The math works out to be 0.0005xRPM=Timing difference. With a 1g sensor it advances the timing more.
The latencies are 0.05 milliseconds for 1g, and 0.130 milliseconds for 2g. It may not be in the code but built into the hardware of the ECU. The signals are definitely coming in at different rates between the sensors.
So it may not be entirely BS
I have a 92 with a flash ECU from Adam.
Re: Chrome V3, need a place to organize my thoughts
Posted: Mon Aug 26, 2019 11:18 pm
by Monochrome
[quote=""aaronatstate""]At idle RPMs the timing is off by less than a degree, so I doubt youd see it with a timing light. At 700 RPM its 0.35 degrees off. At 7000 RPM its off by 3.5 degrees, based on the sensor latency. The math works out to be 0.0005xRPM=Timing difference. With a 1g sensor it advances the timing more.
The latencies are 0.05 milliseconds for 1g, and 0.130 milliseconds for 2g. It may not be in the code but built into the hardware of the ECU. The signals are definitely coming in at different rates between the sensors.
So it may not be entirely BS
I have a 92 with a flash ECU from Adam.[/quote]
Yeah but who has actually tested this? How did they test it?
Hint: I think I know why the timing variates but if Im right its not because of sensor lag. Again
I need a couple more people with timing lights and 91/92 cars with a flash ECU to do a test
Re: Chrome V3, need a place to organize my thoughts
Posted: Mon Aug 26, 2019 11:30 pm
by aaronatstate
[quote=""Monochrome""]Yeah but who has actually tested this? How did they test it?
Hint: I think I know why the timing variates but if I’m right it’s not because of sensor lag. Again
I need a couple more people with timing lights and 91/92 cars with a flash ECU to do a test[/quote]
Why don’t you explain it first? :d ontknow:
My point is you aren’t going to be able to discern a .35 degree difference on the scale on the lower timing cover. Especially when the scale is 5 degree increments. Sorry, there is no one that will see that difference.
AEMs software has a setting for sensor latency. They must think it’s important enough
Like I said it could be in the hardware of the ECU.
Re: Chrome V3, need a place to organize my thoughts
Posted: Mon Aug 26, 2019 11:32 pm
by ChargerX3
What else could the lag be then?
Re: Chrome V3, need a place to organize my thoughts
Posted: Mon Aug 26, 2019 11:51 pm
by Monochrome
[quote=""aaronatstate""]Why don’t you explain it first? :d ontknow:
My point is you aren’t going to be able to discern a .35 degree difference on the scale on th elbowed timing cover. Especially when the scale is 5 degree increments. Sorry, there is no one that will see that difference.
AEMs software has a setting for sensor latency. They must think it’s important enough
Like I said it could be in the hardware of the ECU.[/quote]
Actually... You can.
So about a month ago I finally finished disassembling the MUT commands in the code. I had to go across 6 different ROMs to figure out what each command did (our ROM doesn't have all of them populated) but one of the commands is D9.
Code: Select all
RAM:0000F644 ?? ?? MUT_Actuator_Flag0:.space 2 ! DATA XREF: FP_CrankRotate_Test+6r
RAM:0000F644 ! PurgeSystem+24r ...
RAM:0000F644 ! Bit 00 = MUT D9 - Fix Timing to 5 Deg
RAM:0000F644 ! Bit 01 = MUT D8 - Fuel Pump
RAM:0000F644 ! Bit 02 = MUT D7 - Purge Solenoid
RAM:0000F644 ! Bit 03 = MUT D6 - FPR Solenoid
RAM:0000F644 ! Bit 04 = MUT D5 - EGR
RAM:0000F644 ! Bit 05 = MUT F2 - VICS
RAM:0000F644 ! Bit 06 = MUT D3 - BCS Solenoid
RAM:0000F644 ! Bit 07 = MUT D3 - Fuel Pump resistor
RAM:0000F644 ! Bit 08 = MUT D2 - Active Exhaust
RAM:0000F644 ! Bit 09 = MUT D1 - Open
RAM:0000F644 ! Bit 10 = MUT CF - Open
RAM:0000F644 ! Bit 11 = MUT CE - High (Both) Radiator Fans
RAM:0000F644 ! Bit 12 = MUT CD - Low Rad fan
RAM:0000F644 ! Bit 13 = MUT CC - O2 heaters
RAM:0000F644 ! Bit 14 = MUT CB - Open
RAM:0000F644 ! Bit 15 = MUT CA - MIVEC
RAM:0000F646 ?? ?? MUT_Actuator_Flag1:.space 2 ! DATA XREF: PurgeSystem+2Ar
RAM:0000F646 ! PurgeMUTCmd+17r ...
RAM:0000F646 ! Bit 0 = MUT C9 - Alternator
RAM:0000F646 ! Bit 1 = MUT C8
RAM:0000F646 ! Bit 2 = MUT C7
RAM:0000F646 ! Bit 3 = MUT C6 - Purge Solenoid
RAM:0000F646 ! Bit 4 = MUT C5 - Vent Solenoid
RAM:0000F646 ! Bit 5 = MUT C4
RAM:0000F646 ! Bit 6 = MUT C3 - SAS Mode
MUT command D9 forces the ECU to skip all it's timing modifiers and fixes the timing to 5 degrees without going into SAS mode which also disables closed loop and the ISC.
Using this command and a timing light, I had a local guy shine it at the crank and rev the motor. He claimed it never moved... Obviously the timing belt cover could be distorted or the crank pulley itself could be nicked or improperly made aftermarket.... but if there was a latency, you'd see this lag with the light with the ignition timing fixed.
There are several timing modifiers beyond the timing table in the code for idle, sudden TPS movement, acceleration, deceleration, etc... I really really wonder if anyone has actually tested this properly or just shined a light and assumed there was a sensor latency when actually it could just be one of these timing modifiers in the code.
This is why I need a few more people to test this.
Re: Chrome V3, need a place to organize my thoughts
Posted: Mon Aug 26, 2019 11:54 pm
by Monochrome
On the topic of MUT Commands, I also need someone with a 98/99 SL to verify that VICS command because I don't trust the source who told me it was F2 based on the pattern you see in the bits...
Re: Chrome V3, need a place to organize my thoughts
Posted: Tue Aug 27, 2019 1:13 am
by mjannusch
[quote=""Monochrome""]but if there was a latency, you'd see this lag with the light with the ignition timing fixed.[/quote]
That seems like a pretty big assumption. Have you disassembled the routine that sets it to 5 degrees? Id think all that would do is feed 5 degrees of advance into the ignition timing routines instead of pulling from the map, If thats the case, then you would not see the timing drift at high RPM.
Re: Chrome V3, need a place to organize my thoughts
Posted: Tue Aug 27, 2019 1:22 am
by Monochrome
[quote=""mjannusch""]That seems like a pretty big assumption. Have you disassembled the routine that sets it to 5 degrees? Id think all that would do is feed 5 degrees of advance into the ignition timing routines instead of pulling from the map, If thats the case, then you would not see the timing drift at high RPM.[/quote]
Yes I have. I can post the code if youd like.
And
Thats exactly what it does. Skips the timing table completely and feeds 5 degrees to the coil output pin.
Why would sensor latency show if it was using the map but not show when being fed a constant from the code? Isnt this latency supposed to be a lag from crank trigger signals itself? Which would mean we would see this latency get worse and worse with the timing light as the motor was reved?
Re: Chrome V3, need a place to organize my thoughts
Posted: Tue Aug 27, 2019 1:53 am
by aaronatstate
How do you trigger the MUT commands?
If I can get a timing light this weekend I’ll try it out.
Re: Chrome V3, need a place to organize my thoughts
Posted: Tue Aug 27, 2019 1:58 am
by Monochrome
[quote=""aaronatstate""]How do you trigger the MUT commands?
If I can get a timing light this weekend Ill try it out.[/quote]
Use the Custom Request box in the lower right corner of the window in EVOScan.
Re: Chrome V3, need a place to organize my thoughts
Posted: Tue Aug 27, 2019 4:11 am
by mjannusch
[quote=""Monochrome""]Yes I have. I can post the code if youd like.
And
Thats exactly what it does. Skips the timing table completely and feeds 5 degrees to the coil output pin.
Why would sensor latency show if it was using the map but not show when being fed a constant from the code? Isnt this latency supposed to be a lag from crank trigger signals itself? Which would mean we would see this latency get worse and worse with the timing light as the motor was reved?[/quote]
Can you post the code, please? Not sure what's going on, but it could be possible that any sensor latency is compensated for in hardware with some type of predictive latching IC. Or we got it wrong and the latency values in the AEM are actually compensating for how the AEM reads the hall-effect or optical sensor waveform since it might be using a more generic detection strategy than the stock ECU, which likely uses a dedicated IC to read the transition states and trigger an interrupt.
Re: Chrome V3, need a place to organize my thoughts
Posted: Tue Aug 27, 2019 3:39 pm
by Hans_GZP
I'd say the best way to test that theory is to get a stock 91-92 vr4 and plug in a 93 vr4 ecu into it and run the base ignition timing test. If it's hardware, you would see the difference then.
Re: Chrome V3, need a place to organize my thoughts
Posted: Tue Aug 27, 2019 4:59 pm
by DCIV
I have a 92 with a cas.
Coop
Re: Chrome V3, need a place to organize my thoughts
Posted: Tue Aug 27, 2019 11:26 pm
by Monochrome
[quote=""mjannusch""]Can you post the code, please? [/quote]
Hold onto your hats.
It starts here when you enter in custom request MUT D9
Code: Select all
seg001:1F9DB loc_1F9DB: ! CODE XREF: MUT_CMD_Process+B8j
seg001:1F9DB EE 06 05 00+ cmp:g.w #0xD9:16, @(6:8,fp) ! '+' ! Fix Timing to 5 Deg BTDC
seg001:1F9E0 26 14 bne loc_1F9F6:8 ! Branch if Not Equal (Z = 0)
seg001:1F9E2 1D F0 A4 16 tst.w @T40_MUT_CMD:16 ! Compare with 0
seg001:1F9E6 36 01 0F bne loc_1FAF8:16 ! Branch if Not Equal (Z = 0)
seg001:1F9E9 1D F6 44 C0 bset.w #0:16, @MUT_Actuator_Flag0:16 ! Test bit and set
Bit 0 of this flag is switched on. It then gets referenced again here:
Code: Select all
seg002:21164 1D F6 44 F0 btst.w #0:16, @MUT_Actuator_Flag0:16 ! Fix Timing to 5 Deg
seg002:21168 27 04 beq loc_2116E:8 ! Branch if Equal (Z = 1)
seg002:2116A AA CC bset.w #12, r2 ! Test bit and set
It then sets bit 12 of this flag (F21C)
Code: Select all
1D F2 1C 92 mov:g.w r2, @TableSetSelect:16 ! Move data
I named this flag TableSetSelect has this flag is used a lot to reference different sets of tables in the code (like Park/Neutral switch). Anyway that's a side track.
Following this bit. Here it then activates another flag...
Code: Select all
seg002:2598E DiagnosticModeTest: ! far ! CODE XREF: FixedTimingDiagModeP
seg002:2598E 1D F2 1C FC btst.w #12:16, @TableSetSelect:16 ! Fix timing to 5 deg
seg002:25992 27 0B beq loc_2599F:8 ! Branch if Equal (Z = 1)
seg002:25994 1D F2 1C FB btst.w #11:16, @TableSetSelect:16 ! SAS mode
seg002:25998 26 05 bne loc_2599F:8 ! Branch if Not Equal (Z = 0)
seg002:2599A 58 00 01 mov:i.w #1:16, r0 ! Move data
seg002:2599D 20 02 bra loc_259A1:8 ! Branch Always
seg002:2599F ! ---------------------------------------------------------------------------
seg002:2599F
seg002:2599F loc_2599F: ! CODE XREF: DiagnosticModeTest+4j
seg002:2599F ! DiagnosticModeTest+Aj
seg002:2599F A8 13 clr.w r0 ! Make zero
seg002:259A1
seg002:259A1 loc_259A1: ! CODE XREF: DiagnosticModeTest+Fj
seg002:259A1 11 19 prts ! Return from subroutine (different page)
Which then switches another flag bit....
Code: Select all
seg002:2597A FixedTimingDiagMode: ! far ! CODE XREF: Timing+8P
seg002:2597A 03 02 59 8E pjsr DiagnosticModeTest:24 ! Branch to subroutine (specified page)
seg002:2597E A8 16 tst.w r0 ! Compare with 0
seg002:25980 27 06 beq loc_25988:8 ! Branch if Equal (Z = 1)
seg002:25982 1D F4 6A C7 bset.w #7:16, @IgnTimingFlags:16 ! Test bit and set
seg002:25986 20 04 bra loc_2598C:8 ! Branch Always
seg002:25988 ! ---------------------------------------------------------------------------
seg002:25988
seg002:25988 loc_25988: ! CODE XREF: FixedTimingDiagMode+6j
seg002:25988 1D F4 6A D7 bclr.w #7:16, @IgnTimingFlags:16 ! Test bit and clear
seg002:2598C
seg002:2598C loc_2598C: ! CODE XREF: FixedTimingDiagMode+Cj
seg002:2598C 11 19 prts
Which is finally reference here:
Code: Select all
seg002:25FE8 1D F4 6A F7 btst.w #7:16, @IgnTimingFlags:16 ! Test bit
seg002:25FEC 26 0A bne loc_25FF8:8 ! Branch if Not Equal (Z = 0)
seg002:25FEE 1D F3 36 80 mov:g.w @EngineRotationConditions:16, r0 ! Move data
seg002:25FF2 0C 00 11 50 and.w #0x11:16, r0 ! 10001 Bits 0 and 4
seg002:25FF2 !
seg002:25FF2 ! Bit 0 = Engine Running RPMs > 438
seg002:25FF2 ! Bit 4 = Engine Running (starter and isc tests complete)
seg002:25FF6 27 07 beq loc_25FFF:8 ! Branch if Equal (Z = 1)
seg002:25FF8
seg002:25FF8 loc_25FF8: ! CODE XREF: IgnTimingCalc+ACj
seg002:25FF8 1D 09 FE 83 mov:g.w @InitialSparkAdv:16, r3 ! Move data
seg002:25FFC 04 14 2B adds.b #0x14:8, r3 ! Addition
seg002:25FFF
seg002:25FFF loc_25FFF: ! CODE XREF: IgnTimingCalc+B6j
seg002:25FFF BF 06 46 mov:g.w #0x46, @-sp ! 'F' ! Move data
seg002:26002 BF 06 0A mov:g.w #0xA, @-sp ! Move data
seg002:26005 BF 93 mov:g.w r3, @-sp ! Move data
seg002:26007 03 01 44 4C pjsr Chk_value_Hi_Lo:24 ! Branch to subroutine (specified page)
seg002:2600B 04 06 2F adds.b #6:8, sp ! Addition
seg002:2600E 1D F4 70 90 mov:g.w r0, @IgnTimingFinal:16 ! Move data
seg002:26012 02 2C ldm @sp+, (r2,r3,r5) ! Pop data from the stack to one or more registers
seg002:26014 0F unlk fp ! Deallocate stack frame
seg002:26015 11 19 prts
9FE (what I call InitialSparkAdv) is 0x0005 aka 5 degrees which is just fed to F470 which is the ignition coil drive output address for that pin.
[quote=""mjannusch""]Not sure what's going on, but it could be possible that any sensor latency is compensated for in hardware with some type of predictive latching IC. Or we got it wrong and the latency values in the AEM are actually compensating for how the AEM reads the hall-effect or optical sensor waveform since it might be using a more generic detection strategy than the stock ECU, which likely uses a dedicated IC to read the transition states and trigger an interrupt.[/quote]
To throw a monkey in the mix (don't shoot me), there is actually a value at A10 which i call Timing Circuit Activation Delay time. Maybe Jeff could double check for me but this value is 0x000F which translates to only 60 uSec (.00006 Seconds or .06 mSec). 0x000F = 15 * 4 = 60
https://www.stealth316.com/2-cas_conversion.htm
As determined from the AEM standalone engine management calibrations, the latency for the 1991-1992 sensors is 50 microseconds (us), or 0.050 millisecond (ms). The 1993 sensors have a 130 us latency (0.130 ms). What this means is that if you install the 1991-1992 optical pickup sensor and use a 1993+ ECU there will be more ignition timing advance than the ECU wants
IF this value in the ROM was for this sensor latency then it's only about half what the AEM calibration calls for unless I got my scaling wrong for this value.
Edit: Found this in the 1G DSM Code
Code: Select all
8878 ECDF ;--------------------------------------------------------------------
8879 ECDF ; At this point, we will check the CAS signal to make sure it stays
8880 ECDF ; set until 56us after the start of the interrupt. I guess this might
8881 ECDF ; be to filter eventual glitches in the CAS signal
8882 ECDF ;--------------------------------------------------------------------
8883 ECDF DC 7E ldd temp20 ;
8884 ECE1 C3 00 0E addd #$000e ; d = StartInterruptTime + $0e (56us)
8885 ECE4 8F 16 01 01 L1663 brclr port5, #$01, L1664 ; Branch as long as CAS bit is clear (CAS signal is set)
8886 ECE8 3B rti ; CAS bit was set, Bail of interrupt
8887 ECE9 1D 29 L1664 cmpd1 t3_clock1 ; Compare current time to time stored when we started the interrupt processing
8888 ECEB 2A F7 bpl L1663 ; Loop if t3_clock1 < (temp20 + $0e (56us)), i.e. if its been less than 56us since interrupt was called
Looks like 1G DSMs with the photo sensor also have the (almost) same timing control delay (56 uSec instead of 60).
Re: Chrome V3, need a place to organize my thoughts
Posted: Wed Aug 28, 2019 3:38 am
by Monochrome
[quote=""DCIV""]I have a 92 with a cas.
Coop[/quote]
Grab your timing light, hook it up to the #1 spark plug.
Hook up your laptop to your car, open EVOScan, start your motor and connect. In the custom request box type D9 or C3 (doesn't really matter) and hit enter. This will fix the ignition timing to 5 deg.
Shoot the light at your crank. The light will flicker every time the plug fires which will be when the notch on your crank pulley lines up with the #5 on your lower timing belt cover. Have someone rev the motor to redline.
Report back if the light changes from 5 degrees.
Re: Chrome V3, need a place to organize my thoughts
Posted: Wed Aug 28, 2019 8:29 am
by DCIV
[quote=""Monochrome""]Grab your timing light, hook it up to the #1 spark plug.
Hook up your laptop to your car, open EVOScan, start your motor and connect. In the custom request box type D9 or C3 (doesn't really matter) and hit enter. This will fix the ignition timing to 5 deg.
Shoot the light at your crank. The light will flicker every time the plug fires which will be when the notch on your crank pulley lines up with the #5 on your lower timing belt cover. Have someone rev the motor to redline.
Report back if the light changes from 5 degrees.[/quote]
This sounds like fun actually. I know the timing stuff, Ive done that a lot. The custom requested box might be interesting but I will let you know what happens.
Coop
Re: Chrome V3, need a place to organize my thoughts
Posted: Thu Oct 31, 2019 8:40 pm
by Monochrome
Just stopped by to update what's going on with Chrome V3. I'm still not finished but here's a glimpse of what's taking so long.
The goal with V3 is I want to release every single 1D, 2D and 3D table in the ROM. Used, disabled, not used... All-of-them.
The ROM is 196570 bytes in size.
All the 1D tables start at byte 800 and end at byte 155C in the ROM. This means 3420 1D tables alone (all these tables are then repeated on another Page but that's a side track). Again, many are disabled or not used but thanks to disassembling many other H8 Mitsubishi ROMs, I've been able to figure out what most of the unused ones are for.
2D and 3D tables are grouped together and start at 1800 and go to 13BB1. I've lost track of exactly how many there are but there's hundreds of them.
To give a perspective of how large of a challenge this is, these are the tables from Chrome V2 pertaining to just idle. Just about all the tables beyond these I disabled or were disabled in the ROM stock to keep it simple.
Only 15 tables.... Very easy right? Well yes except that's not even close to the whole story of all that goes into idle. Especially since Chrome V2 lost ATX and aftermarket throttle body compatibility.
Here's the rest of the story:
If this was a story, those would just be the chapters. Here's the tables in just chapter 1!
Here's what I can fit into one single screen shot:
Just for idle there are 336 1D tables and 52 2D tables. So... 388 tables total just for idle.... Again, some are disabled or not used.
It took me a month straight (figure about 32-40 hours per week) just to dissect each and every one these. Adam (Jesters) was a HUGE help in poking around at pins on a bench ECU to find out what flags they trigger. We were on the phone for at least 2-3 hours at a time more than a few times to figure a lot of these flags out.
As you can see, this is no easy task.
Where I'm at now is finishing up the disassembly of the tables (about 65% done) and cross referencing them with other Mitsubishi ROMs because I want to bring in features from those ROMs into ours. For example I want to bring in the Code that operates the VICS motors from the DOHC NA cars so they can use the TT ROM in their NA cars. I did this with features such as Lean Spool in Chrome V2. That actually came from an EVO 6 ROM.
I also have several of my own mods that I want to code and also revise a couple of the mods I had in Chrome V2 (such as the Active Exhaust and Custom switched outputs)