ECU functionality



Re: ECU functionality

Postby grumpyvette » January 21st, 2015, 9:19 am

GREAT INFO GENTLEMEN!
IF YOU CAN,T SMOKE THE TIRES AT WILL,FROM A 60 MPH ROLLING START YOUR ENGINE NEEDS MORE WORK!!"!
IF YOU CAN , YOU NEED BETTER TIRES AND YOUR SUSPENSION NEEDS MORE WORK!!
grumpyvette

User avatar
Site Admin
Site Admin
 
Posts: 14105
Joined: September 14th, 2008, 1:40 pm
Location: florida

Re: ECU functionality

Postby bytor » January 21st, 2015, 8:03 pm

Strictly Attitude wrote:I just read a book on gm fuel injection


What GM fuel injection did you read? There's a few of the out there and I'm always looking for a good read.
My 383 build photos
bytor

User avatar
 
Posts: 379
Joined: March 30th, 2010, 9:13 am
Location: Simpsonville, SC

Re: ECU functionality

Postby bytor » January 23rd, 2015, 8:06 am

Table Lookup & Interpolation

As mentioned in the MAF post, the ECM uses an interpolation subroutine for just about all of it’s table lookup functions. Why? Well it would be very inefficient to build table with entries at every possible data point. Think how big these tables would be and how much memory they would take up. The ECM in the 80’s had very small memory space available. The ECM used a single interpolation subroutine formula for all it’s table lookups.

Using the example from the MAF post:
Lest say the MAF is putting out 1.49 volts. As you can see below this falls in between the 1.46 and 1.55 entries in the MAF table. How does the ECM deal with this? It uses an interpolation function to calculate the exact table value that would correspond to 1.49 volts. All the tables in the ECM are handheld this way. This makes for a very efficient use of memory.


Value VDC gm/sec
------------------------
119____1.46__22.3
133____1.55__25.0



This writup from the ThirdGen.org forum describes how GM's 2D and 3D table lookups operate.
http://www.thirdgen.org/forums/diy-prom/175570-table-lookups-introduction.html


These tables would include the timing table, the knock retard tables, the VE table, MAF scalar tables, TCC tables, and a host of others. A 2D table is a one dimensional array of values while the 3D table is a 2 dimensional array of values. In the P4 ECMs the maximum number of rows and columns for a table is 17.

For a 2D table a single argument (arg) is used to locate the proper value within the table. A 3D table has 2 arg's in order to locate the proper value within the table. The value of the argument can span from 0 to 255, a single byte value. Most of the time the arg value does not fall directly on a row or a row/column intersect. Because of this the lookup routine interpolates between the row & column table values.

The arg terms may be any number of different sensor or internal values. Some common ones are RPM, CTS, TPS, AFR, MAP, MAF, battery voltage, and knock counts.

A 2D table of 17 rows is the easiest to understand. It is used in the following example. With 17 rows there are 16 steps and 16 arg increments between each row. This 16 * 16 = 256.

Bascially speaking the ECM code will do a 16 point interpolation between the rows.

Here is our example 2D table:

Code:
;--------------------------------------
; XYZ ; rpm
;--------------------------------------
XYA: FCB 70 ; 0
FCB 65 ; 400
FCB 69 ; 800
FCB 69 ; 1200
FCB 71 ; 1600
FCB 91 ; 2000
FCB 102 ; 2400
FCB 122 ; 2800
FCB 127 ; 3200
FCB 132 ; 3600
FCB 133 ; 4000
FCB 164 ; 4400
FCB 185 ; 4800
FCB 196 ; 5200
FCB 205 ; 5600
FCB 245 ; 6000
FCB 255 ; 6375

The lookup arg is RPM. In this case the ECM value for RPM is RPM / 25. So an RPM of 2450 is: 2450 / 25 = 98, the 98 being the value that the ECM uses internally for that RPM.

Note how the table rows are labeled, starting at 0 RPM, then the next row being 400 RPM, the next being 800 RPM. There is a 400 RPM difference from row to row.

This is because of the 16 arg increments between each row:
16 * 25(rpm per increment) = 400(rpm between each row).

Staying with 2450 RPM what is the looked up value?

First divide the 98 (2450 / 25) by 16: 98 / 16 = 6.125, with the ECM keeping 6 (no fractions allowed, although the code will round to one place: 10.6 becomes 11).

1) Multiply 16 * 6 for a 96 and subtract that from 98 (the arg) for a 2.

2) Go to row 6 and get the value 102 (at 2400 rpm).

3) Go to row 7 and get that value: 122 (at 2800 rpm).

4) Sub the row 7 & 6 values: 122 - 102 = 20

5) Divide 20 by 16(increments between rows): 20 / 16 = 1.25, or 1

6) Multiply the 1 * 2 (from step A): 2 * 1 = 2

7) Add the 2 (from step F) to the 6th row value of 102: 102 + 2 = 104

** 104 is the final value and is the value the lookup routine returns.

In step 1 the value of 2 means that the lookup is 2/16's of the way to the next row.


The 3D lookup routine does the exact same math three times. Once each for the two sets of rows, then once again between those values (for the column interpolation).


Now for the tricky stuff: not all tables are like the one above.

Here is a table that has been compressed:

Code:
;--------------------------------------
; XYZ ; rpm
;--------------------------------------
XYA1: FCB 8 ; row count

FCB 70 ; 0
FCB 69 ; 800
FCB 71 ; 1600
FCB 102 ; 2400
FCB 127 ; 3200
FCB 133 ; 4000
FCB 185 ; 4800
FCB 205 ; 5600
FCB 255 ; 6375

Notice how each row increments by 800 rpm. It is a 9 line table as shown by the row count (yes, they don't match and is correct). In this case the lookup routine will properly handle the table while doing a 32 point interpolation between rows.


Another case is where the table starts at at 0 RPM with a maximum of 3200 RPM:

Code:
;--------------------------------------
; XYZ ; rpm
;--------------------------------------
XYA2: FCB 70 ; 0
FCB 65 ; 400
FCB 69 ; 800
FCB 69 ; 1200
FCB 71 ; 1600
FCB 91 ; 2000
FCB 102 ; 2400
FCB 122 ; 2800
FCB 127 ; 3200

The code will first check if the RPM is over 3200 and if it is set the arg to 3200 RPM (128). The lookup routine is then called. It will do the regular 16 point interpolation.

*********************************************
*********************************************


Here’s another snippet from http://carprogrammer.com/Z28/PCM/FAQ/ECMTuningNotes.htm describing the table lookup process.

Topic: 3D table lookup

It's a 3-way, 16-point interpolation between the table values.

Think of the point of 53kpa map & 1700 rpm as being someplace inside of a box. The four corners of that box, are the four table values
that surround the defined point. The distance from that point, to each of the four walls is estimated, with the final result based on those
four values.

Works something like this...

Part of main SA table:

map> 50 60
rpm
1600 20 24
1800 22 26

If the map is 53 and the rpm is 1700, first lookup gets the 20 & 24 degree values @ 1600 rpm, and interpolates between them. The difference
between these two are divided into 16 points:

24deg - 20deg = 4deg, 4deg / 16points = .25 deg per point

60map - 50map = 10map, 10map / 16points = .625 kpa per point.

53 map @ 1600rpm => 20deg + (3map / .625) * .25 = 21.2 deg.

So, 21.2 deg is the 16 point interpolation of 53 map @ 1600 rpm.

(Note: On a 2D table, we would be done, and this value returned).

The 3D lookup, however, calls the 2D routine a total of three times. In this example, the first call we already completed.

The routine then advances a full row to interpolate between the 22 deg and 26 deg values found at 1800rpm.

So, using the same math as above, 23.2 deg is the 16 point interpolation of 53 map @ 1800 rpm.

The third and final interp. is done between the answers of the first two lookups: 21.2 deg & 23.2 degrees (@ 1600 & 1800 rpm).

The rpm is divided into 16 points the same. For this example, it's right in the middle of table values 1600rpm and 1800rpm,
with 1700 actual.

So, 21.2 deg & 23.2 deg => 22.2 deg as the actual returned, looked up finalized interpolated value to be used.

*********************************************
*********************************************



Cool stuff isn't it.. To me this is another important operational point to understand how the ECM functions. Im sure this same process is used in modern ECM's as well just that tables are larger and have better resolution.

Related Links:
Here’s a video showing the detailed explanation of table interpolation. (lots of math here)
https://www.youtube.com/watch?v=6WAeqE41-1Y

Here’s an interesting video describing how to do interpolation in Excel,
https://www.youtube.com/watch?v=LFUd5qF8nyE


My 383 build photos
bytor

User avatar
 
Posts: 379
Joined: March 30th, 2010, 9:13 am
Location: Simpsonville, SC

Re: ECU functionality

Postby bytor » January 29th, 2015, 3:36 pm

From the INT/BLM discussion a few posts back. I uploaded a PowerPoint animation I put togeather that shows the INT and BLM in action the way I understand it to work.
The action starts about half way through the video.

The scenario depicted is the engine is in closed loop mode and some event caused the exhaust AFR to go lean. The INT responds immediately to compensate. After a certain amount of time in this state, the BLM will kick-in and put the INT back at 128 (short term fuel trim). The new BLM will be stored in the ECM memory and continue to adjust the AFR for that given RPM/load range or BLM cell in the future (long term fuel trim).

https://www.youtube.com/watch?v=b7yZpzaUnKA&feature=youtu.be
My 383 build photos
bytor

User avatar
 
Posts: 379
Joined: March 30th, 2010, 9:13 am
Location: Simpsonville, SC

Re: ECU functionality

Postby bytor » February 6th, 2015, 3:49 pm

The next thing I was curious about functionality wise was the ignition timing operation. Starting with the HEI module, I wanted to understand a bit deeper what was going on especially around how the timing advance was controlled. Here’s the basic 7-pin HEI module block diagram.

HEI1.jpg


I’ll focus on the R, E, and B pins on the HEI module,

The R pin is the reference pulse sent to the ECM. If the engine is turning, the HEI module continually sends this reference pulse to the ECM. The ECM uses the signal for ignition functions but also RPM, fuel injector timing and other functions. It’s a key signal the ECM needs to function. The important thing to remember about this signal is it’s always being sent to the ECM and the frequency changes with RPM.

HEI2.jpg



The B pin is the EST bypass control. The bypass signal is zero volts during cranking (less than 400 rpm or 5 to 15 seconds), then there is 5 volts on this pin after the engine starts to signal the 7-pin module that it should use the signal on the R pin to control timing. When 5v is ‘not’ applied to this pin the HEI module is In bypass mode. Basically meaning the module is operating autonomously and not under the control of the ECM. The pick-up coil signal is the trigger signal for the ignition coil. When the engine is cranking below a predetermined threshold (400 rpm), the computer has no control over the timing. Only when RPM reaches the threshold speed, does the computer take over timing and 5v is applied to the B pin. At this point, the ECM is in full control of the timing advance.


In starting (By-Pass) mode
HEI3.jpg


In run mode (ECM providing timing control)
HEI4.jpg



Pulses and other neat stuff:

The following is info from the Megasquirt site that goes in-depth describing the HEI and interfacing it to their ECM. I modified the section below some to be a bit more generic as I assume the GM ECM works in a similar manor.
http://www.megamanual.com/ms2/GM_7pinHEI.htm

More related info and ECM advance & dwell calculation details. http://www.megasquirt.info/HEIgn.htm

Another detailed HEI write up http://chevythunder.com/ignition_systems_hei_operation.htm

The 4-pin HEI uses a negative-to-positive transition, while the 7/8-pin uses a positive-to-negative transition (though this *might* have changed in some applications). Thus polarity of the reluctor signal is critical to proper function.
In the GM 7/8-pin HEI, the module converts the AC signal from the variable reluctor pick-up {on pins P & N} in the distributor to a 'square wave' tach signal {on pin R} suitable ECM.
HEI does not use the reluctor for dwell control, this is accomplished in the module. Dwell needs to be independent of RPM. Variable reluctor output is RPM dependent with regard to both its width and amplitude of its output. The only thing constant with a variable reluctor output is the location of the zero crossing point with respect to the passing tooth.
Be sure to get the variable reluctor pick-up wires connected properly. Reversing the variable reluctor sensor wires and thus the polarity of the sensor causes the leading voltage to go negative first and the electronics ignores the positive going transition. Thus trigger signal, if ever recognized, is the falling edge of the voltage as the end of the tooth passes.

The only way to get proper triggering at the center of the tooth is to have the positive ½ cycle first (tooth approaching) and the negative ½ cycle last.
The 7/8-pin HEI uses a "next cylinder" advance calculation method. That is, you get the square wave out of the module at (say) 10° BTDC which is used for cranking and limp home mode. To advance the timing ECM waits until the NEXT cylinder to fire to provide an altered signal to the coil.

Reference (tach) pulses come into ECM from pin R at 10° BTDC. At each reference pulse, the period between it and the previous reference pulse is calculated. The difference is used (with a time interpolation technique) to set up the timing pulse for the next ignition event. Specifically, the reference period is added to the time of the current pulse, a calculated amount subtracted for the advance, another amount subtracted for the dwell to determine the rise time.

When the signal is 'high', current flows. When the signal is pulled low, current stops, the magnetic field in the coil collapses, and a spark is produced. Thus, the HEI module fires on the 'trailing edge' of the advance signal. The advance signal is generated by ECM from the tach signal by modifying its duty cycle (pulse width). Larger duty cycles mean less advance, as the spark is delayed by a larger amount. The timing of the trailing edge determines the amount of advance: a longer pulse width means a more delayed, 'retarded' spark, while a shorter pulse width means an earlier 'advanced' spark.

The paragraph above is the key part I was trying to figureout. There is not much out there on this. I figure if this is how the Megasquirt interfaces to the 7-pin module and controls the ignition advance, the GM ECM must send the same modified pulse width signal to the module as well.

heiest (1).gif


Timing Advance Calculations for GM HEI Modules:
This info again is from the Megasquirt site and I assume the GM ECM timing is determined in a similar manor. I’m digging into that now.
In order to fire the coil, the coil must have a dwell period that ends when the advance timing for a spark is correct. The dwell itself must fall within certain limits, or the coil will overheat if dwell is too long, and produce a weak spark if the dwell is too short. So the spark is controlled by the start and stopping of current to the coil. In the MegaSquirtII code:

adv_deg = ign_table(rpm, kpa) + adv_offset + cold_adv_deg

Note that the adv_deg is relative to the trigger, not to TDC. However, MegaTune's ignition table corrects for this, and you fill the table with values relative to TDC. Futhermore, the advance reported by MegaTune is with respect to TDC.

In any ignition system, all of the required events must take place within the time available:

time available = latency time + dwell time + advance

In the MegaSquirtII code, this is calculated as:

dtpred = charge_time + coil_dur + adv_us

It is important to note that we need to estimate dtpred in order to have the correct amount of igntiuon timing advance. The better we estimate dtpred, the more accurately our actual timing will reflect the table and other parameters.

The process of determining the timing events (coil charging and coil spark) is performed as follows:

first, MegaSquirtII predicts the amount of time until the next TDC reference pulse (dtpred). This is done using the time between the last two pulses, the amount by which that time has changed since the pulse before that (the first derivative - dtn), and the amount that the 'change' has changed (second derivative - ddtn).

The equations are:
dtn = tn - tn-1
ddtn = (dtn - dtn-1) / ((dtn + dtn-1)/2)
ddtn-1 = (dtn-1 - dtn-2) / ((dtn-1 + dtn-2)/2)
dddtn = (ddtn - ddtn-1)/((((dtn + dtn-1)/2) + ((dtn-1 + dtn-2)/2))/2)
ddtpred = ddtn + dddtn * dtn
dtpred = dtn + ddtpred * dtn = dtn + (ddtn * dtn) + (dddtn * dtn * dtn)

MegaSquirtII also uses a Kalman filter random error correction algorithm to filter out noises in the ignition signal. The Kalman filter correction is proportional to the difference between current dt2 and last predicted dt2.

Next, the desired amount of ignition advance, in engine degrees, is determined from the appropriate cell of the spark advance table, and converted to µsec based on the current speed of the engine. This value is adv_us.

Finally, the time required for ignition coil dwell (coil_dur) is calculated. In order to optimize both the spark energy and the coil life, MegaSquirtII controls both the firing point (ex. the trailing edge) as well as the charging point (the leading edge) of the signal to the coil. The pulse width of the square wave is the dwell, and it is held within specific limits by MegaSquirtII. Typically, dwell time is between 2.0 milliseconds and 4.0 milliseconds for most ignitions systems.

For the OEM HEI coils set the dwell to
3.5 milliseconds for an in-cap coil (7-pin module),
2.5 milliseconds for a small cap distributor with an external coil (7-pin module).

If the amount of desired dwell is longer than the remaining amount of time available (i.e. coil_dur + adv_us > dtpred, and charge_time = 0), the coil_dur time is shortened and the amount of time available is used (otherwise the timing would be increasingly delayed).
The coil is supplied with 12 volts when the charge_time has passed after the TDC signal from the distributor/crank sensor. It begins to charge. When a further time equal to coil_dur has passed, the current to the coil is shut off, and a spark is produced. Both charge_time and coil_dur vary based on engine rpm (dtpred), desired spark advance (adv_us + adv_offset), and dwell parameters.

MSIItime.gif


You do not have the required permissions to view the files attached to this post.
My 383 build photos
bytor

User avatar
 
Posts: 379
Joined: March 30th, 2010, 9:13 am
Location: Simpsonville, SC

Re: ECU functionality

Postby Indycars » February 6th, 2015, 5:02 pm


Your going to have another college degree when you finish with this thread. ;)

You are digging up some great info!!!

Rick
Too much is just enough!!!

- Check Out My Dart SHP Engine Project: viewtopic.php?f=69&t=3814
- Need a Dynamic Compression Ratio Calculator: viewtopic.php?f=99&t=4458
Indycars

User avatar
Forum Admin
Forum Admin
 
Posts: 4424
Joined: May 25th, 2010, 8:58 am
Location: Yukon, OK

Re: ECU functionality

Postby grumpyvette » February 6th, 2015, 9:43 pm

YES a DARN IMPRESSIVE BIT OF INFO WITH GREAT GRAPHS AND DETAILS MOST GUYS HAVE EITHER OVER LOOKED OR IGNORED
IF YOU CAN,T SMOKE THE TIRES AT WILL,FROM A 60 MPH ROLLING START YOUR ENGINE NEEDS MORE WORK!!"!
IF YOU CAN , YOU NEED BETTER TIRES AND YOUR SUSPENSION NEEDS MORE WORK!!
grumpyvette

User avatar
Site Admin
Site Admin
 
Posts: 14105
Joined: September 14th, 2008, 1:40 pm
Location: florida

Re: ECU functionality

Postby bytor » February 11th, 2015, 11:36 am

MAT Relocation, does it do anything????

Interesting observation, I have seen a lot of info on the internet regarding relocation of the Manifold Air Temperature (MAT) sensor out of the plenum to the air filter plenum providing a cooler air signal to the ECM. This thinking is this tricks the ECM into advancing the ignition timing a bit and provides richer fueling. On the 87/88 TPI Vettes, I’m not sure that’s the case. I have been poking around in the actual ECM code and there are two places where the MAT temperature is programed.

One is the MAT sensor voltage hi/low ALDL code 23 & 25 determination programing.

The only other reference to the MAT temperature in the entire ECM code is in the EGR programing. The MAT variable is used to disable the EGR operation if MAT is below a certain temp.

That’s it, the MAT is not used in timing and fueling decisions at all..
Based on this, all the MAT relocation kits don’t do squat with improving performance related to timing and fueling. This is my observation only on 86/87 setups. On later L98’s and LT1’s I’m’ sure the MAT plays more in the ignition and fueling.
My 383 build photos
bytor

User avatar
 
Posts: 379
Joined: March 30th, 2010, 9:13 am
Location: Simpsonville, SC

Re: ECU functionality

Postby 87vette81big » February 11th, 2015, 2:06 pm

Have you found or read any work done by DR. J Bytor.
Used to read his posts. Knows C4 TPI.

Have you found the BIN FILE FOR TPI WOT FULL FUEL ENRICHMENT ?
AFR GOES TO 9.0-10.0 :1 FOR 3-5 SECONDS.
SO THE FIBERGLASS FLOORPAN DON'T CATCH ON FIRE FROM THE SUPER HEATED MAIN CATALYTIC CONVERTER.
WHY THERE IS A HIGH SPEED BOG IN ALL TPI CORVETTES EHEN MASHING THE GAS DOWN INSTANT.
NOT A TRUE BOG BUT ACCELERATION DROPS .
THEN PUCKS UP AGAIN.
FUEL QUENCHING .
87vette81big

User avatar
 
Posts: 3278
Joined: February 28th, 2012, 12:34 am
Location: Central Illinois

Re: ECU functionality

Postby bytor » February 12th, 2015, 2:11 pm

87vette81big wrote:Have you found or read any work done by DR. J Bytor.
Used to read his posts. Knows C4 TPI.

Have you found the BIN FILE FOR TPI WOT FULL FUEL ENRICHMENT ?
AFR GOES TO 9.0-10.0 :1 FOR 3-5 SECONDS.


I have seen some of DR. J's stuff but not the CATALYTIC CONVERTER QUENCHING stuff.

Sounds interesting, I'll take a look..... Thanks.
My 383 build photos
bytor

User avatar
 
Posts: 379
Joined: March 30th, 2010, 9:13 am
Location: Simpsonville, SC

Re: ECU functionality

Postby 87vette81big » February 12th, 2015, 4:24 pm

bytor wrote:
87vette81big wrote:Have you found or read any work done by DR. J Bytor.
Used to read his posts. Knows C4 TPI.

Have you found the BIN FILE FOR TPI WOT FULL FUEL ENRICHMENT ?
AFR GOES TO 9.0-10.0 :1 FOR 3-5 SECONDS.


I have seen some of DR. J's stuff but not the CATALYTIC CONVERTER QUENCHING stuff.

Sounds interesting, I'll take a look..... Thanks.

Look on CFC4 RACE TUNING ARCHIVES Bytor.
About 2009-2010.
Dr. J is also involved in a few Hotrod magazine Race engine builds featured.
87vette81big

User avatar
 
Posts: 3278
Joined: February 28th, 2012, 12:34 am
Location: Central Illinois

Re: ECU functionality

Postby bytor » February 16th, 2015, 11:53 am

This discussion got me wondering how I could use my LM-2 wideband O2 to see whats going on with the AFR while I drive the car. I didn't want to install another bung in the exhaust so I wondered if the Innovate LM-2 could emulate a narrowband O2 sensor and sure enough it can. The analog outputs on the LM-2 can be configured to output an equivalent narrowband signal derived from the LM-2 wideband OS sensor.

So, the idea is....
> Remove my stock narrowband O2 sensor and install the wideband O2 sensor in it's place.

> Make pigtails for my MAF, TPS and HEI and connect these signals to the LM-2. The pigtails will allow me to split the signals to the LM-2 and ECM at the same time. Also, no wire cutting required. When I'm done, take the pigtails out and everything is back to normal.

> Install the LM2 so I can log the AFR, MAF, TPS and RPM while driving.

The LM2 will be providing the correct O2 signal to the ECM while at the same time I can see the actual AFR. It will be intersting to see the fuel curve for the MAF TPI engine. This would also be a good aid while working on a custom tune for a modified engine.

I have the connectors for the pigtails on order and will report back once everything is hooked up.

LM2.jpg
You do not have the required permissions to view the files attached to this post.
My 383 build photos
bytor

User avatar
 
Posts: 379
Joined: March 30th, 2010, 9:13 am
Location: Simpsonville, SC

Re: ECU functionality

Postby Indycars » February 16th, 2015, 12:56 pm


It will be most interesting to see the relationship between the MAF, AFR, TPS
as the ECM responds to engine demand. It should be good practice for me that
will help when I get back on the road this summer and logging data with the AQ-1.


Rick
Too much is just enough!!!

- Check Out My Dart SHP Engine Project: viewtopic.php?f=69&t=3814
- Need a Dynamic Compression Ratio Calculator: viewtopic.php?f=99&t=4458
Indycars

User avatar
Forum Admin
Forum Admin
 
Posts: 4424
Joined: May 25th, 2010, 8:58 am
Location: Yukon, OK

Previous

Return to Electrical and Ignition: Repairs and Modifications

Who is online

Users browsing this forum: No registered users and 3 guests