) |
) |
) |
| Outside ECM - waterproof case | Inside ECM - circuit board and MemCal | MemCal |
) |
) |
) |
| GM HEI module | GM/Vauxhall MAP sensor | GM (not Vauxhall) CTS |
) |
) |
) |
| Emerald (RS) TPS | My DIY IAT sensor | Vauxhall XE CTS |
This page describes my ongoing project to convert my Fury from distributor ignition and carburettor fueling to full engine management, with electronically controlled ignition timing and fuel injection.
Rather than do this the 'easy' and expensive way (by buying an aftermarket engine management system), I have chosen to adapt an engine management system that used to be fitted to productions cars made by General Motors in America. GM don't make these any more. Mine came out of an american scrapyard.
In order to perform optimally (i.e. provide an acceptable compromise of good: power, economy, and longevity) an engine needs to be supplied with different ignition timing and fuel quantities to meet its exact needs at any instant in time. This is best achieved by controlling these inputs using a computer. In order to estimate what the engine needs, the main things that the engine management computer needs to know are: what the engine speed is and what the driver wants it to do (known as: load). This information is supplied to it by sensors, attached to the engine.
Engine speed (RPM) can be measured directly. Engine load is more illusive and there are different ways of estimating it, which I will talk about later. By experimentation (e.g. using a rolling road or wideband lambda probe) optimum ignition timing and fuel quantity can be determined, for a given engine, under all speed and load conditions. These are then stored in a 'look-up' table in the memory of the engine management computer. When the engine is running, thousands of times a second, the computer takes measurements from the speed and load sensors and uses these to look up the best ignition timing and fuel quantity to supply to the engine, at that moment.
I am currently using a scrap american engine management computer (GMECM) with part number 16149396. This is a 'P4 generation' ECM and is identical to the common (and better documented) 1227727, except that the 16149396 has additional SRAM (which makes it much more useful). According to this site, the 16149396 was used from 1991 to 1994 in 3.1 and 3.4 litre V6 engined Buick and Pontiac cars, whereas the 1227727 was used in cars powered by 3.4 litre V6 and 5.7 V8 engines (including the Chevrolet Corvette). All the P4 generation units have, at their heart, a micro-controller which is based on the Motorola 68HC11. The fact that the 16149396 was fitted to 3.1 and 3.4 litre V6 engines is irrelevant to its reuse - it's the software that really matters (see next section). There is only one tiny change required to the (MemCal) hardware to make the whole ECM run happily on a 4 cylinder engine.
The ECM case is designed for engine bay ("under hood") use, consequently it is waterproof - which is pretty handy.
The table below shows pictures of the ECM and some of its peripheral sensors.
|
|
|
| Outside ECM - waterproof case | Inside ECM - circuit board and MemCal | MemCal |
|
|
|
| GM HEI module | GM/Vauxhall MAP sensor | GM (not Vauxhall) CTS |
|
|
|
| Emerald (RS) TPS | My DIY IAT sensor | Vauxhall XE CTS |
The GMECM software 'code' and look-up tables 'calibration data' all reside on a single EPROM. In the case of the 16149396, this is a 32K x 8 bit (27C256) 'chip', but other GMECMs use 16K x 8 bit (27C128) EPROMS. The software is written in the native assembly language of the 68HC11 micro-controller. This makes it much faster and more space efficient than if it had been written in a high level language, such as 'C', and cross-compiled. A sample of GM 68HC11 assembly language can be seen below:
F5E6: LF5E6 SUBA 0,X F5E8: PSHB F5E9: PSHX F5EA: BCC LF5ED F5EC: CLRA F5ED: LF5ED SUBB 1,X F5EF: BCC LF5F2 F5F1: CLRB F5F2: LF5F2 PSHB F5F3: LDAB #$10 F5F5: MUL F5F6: PSHB F5F7: LDAB 2,X F5F9: PSHB F5FA: MUL F5FB: ABX F5FC: INX F5FD: INX F5FE: INX F5FF: PSHX F600: TSX F601: LDAA 4,X F603: LDX 0,X F605: JSR LF5BC F608: PSHA F609: TSX F60A: LDAA 5,X F60C: LDAB 4,X F60E: STAB 5,X F610: LDAB 3,X F612: LDX 1,X F614: ABX F615: JSR LF5BC F618: TAB F619: PULA F61A: PULX F61B: PULX F61C: JSR LF5CC F61F: INS F620: PULX F621: PULB F622: RTS
The above is actually the table look-up routine from the software that I'm currently using.
GM designed different versions of software to run on fundamentally the same hardware, but the greatest variation from one GM EPROM to another is the contents of the look-up tables - which are, of course, engine specific. The software versions are known by the hexadecimal representation of an 8 bit number (e.g. $8D, $58) - which is stored near the beginning of the EPROM address space. (However, this is a bit of a simplification. Strictly speaking, these hexadecimal numbers refer to the configuration of the calibration data, and it is possible for different software to share the same calibration data. So, for instance, not all $8D software is necessarily identical.) Complete chips are known by 4 letter names - e.g. ANHT, AYBN. This is printed on the EPROM label. The complete contents of a chip can be stored on a PC as a binary file.
As you might expect, there's a reasonable amount of similarity between all the software versions - so lessons learned from 'hacking' one version can usually be applicable to the version that you're using (and hacking!). As the micro-controller is based on a Motorola 68HC11, the freely available disassemblers and assemblers for this processor can be used.
GMECM software uses many many look-up tables, arrays, and values that combine as adjustment upon adjustment to fine tune ignition timing and fuel quantity (far far more than aftermarket ECUs). Getting these set correctly is one of the major challenges of using it.
A given version of GMECM software is either configured for throttle body injection (TBI) or port fuel injection (PFI). In TBI, the fuel is injected upstream of the throttle butterf[ly/ies]; whereas in PFI it is injected downstream of it/them. TBI can use only a single injector, but PFI uses one injector per cylinder (which can be 4, 6, or 8).
For the first few years that I used a GMECM, to control my engine's ignition, I adapted and ran the $8D software - as it has probably the most commented, freely available hack (and it runs PFI - which is what I want). The hack includes the calibration data from the hacker's application (a V8 Chevrolet Corvette of the early 90's), and is consequently referred to by the Corvette chip name 'ANHT'. (Note: $8D was used for all GM 1990-1992 5.7 litre V8 engines.) Despite the fact that the software was originally used for a V8, GM provided the ability for it to be configured to work for a 4 cylinder engine. A binary file, containing the whole of the original ANHT EPROM can be downloaded by clicking here, and a disassembled 'hack', created by 'ECMGuy', can be found as a .PDF file here.
However, despite being well hacked, $8D is one of the most complex GM software versions (using almost the full 32k EPROM space) and its look-up quantities are not as well understood (by the hacking community) as those for the $58 software (as was used in the 1987-1990 Pontiac Sunbird 2.0 Turbo and the 1991-1993 GMC Syclone/Typhoon 'trucks'). Consequently, since I am preparing to adapt my engine installation for fuel injection, I decided to change to software that was better understood, to save myself many many hours of hacking and testing (this project had already taken hundreds of hours of my time...). The Sunbird software (as I shall call it, from now on) still has many many adjustments, though, as can be seen by clicking here. A binary file, containing the whole of the original Sunbird EPROM can be downloaded by clicking here. It also runs PFI.
The Sunbird software originally ran on 1227749 hardware, which used a 16K x 8bit (27C128) EPROM. GM never installed it on my particular variant of ECM hardware (although there is a very great deal of similarity between the two), which makes life a little more difficult! The most fundamental thing that has to be done to run this software on my hardware is to load it into the higher (bottom) 16k of the 27C256. However, this is not all; the Sunbird software uses different registers from ANHT to control certain functions, so some ECM pins change function. This renders the (well documented) Corvette ECM pinout partially invalid (with the 'partial' bit ill-defined!)
For my engine, another undesirable aspect of the Sunbird software is that it's look-up values are configured for a turbo application, using a 2 bar MAP sensor. Fortunately, for some reason, GM gave the software the option to run with a 1 bar MAP sensor (like the one I have - which is optimal for a naturally aspirated engine). However, there are a number of look-up values which are set for a 2 bar sensor and require changing to ensure correct operation with a 1 bar sensor.
Despite the above, I seem to have the Sunbird software running my engine's ignition with no obvious problems, and, after a bit of ignition table tuning, and one GM 'bug' fix, my engine is pulling better than ever before. :-)
The 16149396 hardware has just one injector driver - so all the injectors are driven from this - but there are two individual firing schemes: 'synchronous' and 'asynchronous', which work together to give the engine the fuel it needs under all conditions. In pure synchronous mode, the injectors are normally 'fired' every crank revolution; but, if the injector pulse width is very short (e.g. < 1ms), the injectors are only fired every 2 crank revolutions - and for twice the computed pulse width. Asynchronous injector pulses augment synchronous pulses to provide extra fuel under certain conditions.
GMECM software (in conjunction with its hardware) has other good features; it can control up to two fans, provide an upshift light, and can control the EFi pump. I use all these features. The beauty about fan control is that you aren't at the mercy of off-the-shelf fan switches; you can set the exact ON and OFF temperatures that you desire (and fine tune the CTS look-up values, if you're as geeky as me!). The shift light feature avoids having to buy and install additional hardware; and the EFi pump control (which turns the pump off if the engine stops - for whatever reason) provides an element of safety in the event of a crash.
I've also written software to display engine parameters on a PDA which I fit to the inside of the windscreen. This is to reduce the likelihood of me driving on the wrong side of the road - as I sometimes found myself doing when trying to read the screen of the lap-top (located in the passenger seat)!
) |
) |
| Numbers page | Health page |
The software determines the basic amount of ignition advance to apply to the engine by using a look-up table. On one axis of the table is the engine speed (RPM), sensed by the distributor (which must not apply any ignition advance itself, other than a small static amount via its mounting angle). On the other axis is engine load. Engine load measurements are provided by an inlet Manifold Absolute Pressure (MAP) sensor which, in my application, is connected to all four inlet tracts, via the carburettor, by vacuum hose. Use of MAP based engine load in conjunction with engine speed to determine engine conditions is known as 'Speed-density' (although the term is normally used to describe the way that MAP measurements are used to compute the correct amount of fuel to add, based on the ideal gas law). For a naturally aspirated engine, MAP never exceeds atmospheric pressure (~100kPa, or 1 bar). Most of the time the pressure is less than this, so there is actually a vacuum in the inlet manifold.
The cylinder trigger sensor in the distributor is directly connected to a remote GM ignition module (HEI). The HEI requires a trigger signal from a reluctor sensor. (Unfortunately, no reluctor sensor based distributor that fits my engine was fitted to UK GM cars, so I had to fit the reluctor sensor from one Vauxhall distributor into the casing from a different type. I also had to have the advance mechanism welded up to stop the distributor from applying ignition advance itself.) The HEI is connected to the ECM, and so the ECM knows the engine speed and position of the engine relative to the next cylinder firing event. The HEI is also connected to the coil, which is connected to the distributor cap and hence to the spark plugs. According to the spark timing, the ECM tells the HEI to dump the coil, and the appropriate plug is fired, due to the alignment of the rotor arm and the internal reluctor sensor in the distributor. It is necessary to make sure that the distributor itself doesn't apply any advance via its internal weights and vacuum. The best way to stop the weights from applying advance is to weld them up. Simple disconnection of the vacuum hose to the diaphragm is enough to disable the vacuum advance. In my case, I disconnected the hose from the distributor vacuum advance unit and connected it to the MAP sensor, instead.
The GMECM software uses a Throttle Position Sensor (TPS) for small corrections to the base map, such as when you plant the throttle - when more ignition advance and fuel are beneficial. There are many other corrections/modifications to the main ignition, depending on what is going on...
GMECMs use the Speed-density system to determine the amount of fuel to inject into the engine. In this system, the basic mass of fuel to inject is computed to provide a specific air/fuel ratio - based on the computed mass of air entering the engine at any given time. The air mass is computed from the ideal gas law (PV = nRT), which uses pressure measurements from the MAP sensor, temperature measurements from the MAT sensor, and a volumetric efficiency look-up table (which is engine specific). Based on user-supplied information about the grammes/second flow rate of the injectors being used, the required basic injector 'on' interval (pulse width) is then calculated. In practice, of course, many other factors are taken into account.
Engine management systems that use the Alpha-N system, to determine the amount of fuel to inject in the engine, do not calculate the amount of fuel, they simply use a value from a look-up table. Typically, this look-up table provides the injector pulse width directly. This is a compromise, for the following reasons:
(1) As an engine is effectively just an air pump, and air obeys the ideal gas law, the amount of air that the engine draws in (and therefore the power that it produces) is a direct function of the air pressure (MAP). The throttle is the indirect means by which the driver controls the power produced by the engine, by its affect on the MAP, and this affect changes when atmospheric pressure - or any part of the engine's induction or exhaust system - changes (either by deliberate modification, or wear and tear). The most significant short term change is atmospheric pressure. Alpha-N systems go out of calibration when the atmospheric pressure differs from that on the day when they were mapped. This is particularly a problem when driving at higher altitudes. In this situation, the Alpha-N system does not know that atmospheric pressure has changed (unless it is supplemented by a barometric sensor - but even then this provides a crude correction mechanism). Consequently, the accuracy of the mapped relationship between throttle position and MAP is reduced, resulting in the wrong look-up table values being used - therefore the engine runs sub-optimally.
(2) With Alpha-N, if the TPS is rotated at all, or changed for one with different calibration, then all the look-up values based on it will be in error. MAP sensors have no such alignment problems (and are much easier to fit than a TPS!)
(3) Changes in throttle position can control MAP only upto the point where opening the throttle further doesn't make any difference. Let's call this the throttle position threshold. (You can experience this easily just by driving: Starting from a closed throttle and slowing opening it, find the least open throttle position where acceleration stops increasing. Alternatively, starting from a fully open throttle and slowing closing it, find the most open throttle position where acceleration starts to decrease. The two methods should lead to the same throttle position, given identical conditions. Be reasonably quick with both methods as the engine state is changing all the time, which means that the throttle position threshold will move.) What is surprising is that the throttle position threshold occurs at low throttle openings up to quite high RPM. Consequently, at these RPM, very small changes in throttle position cause a large change in MAP and therefore significantly different ignition and fuel requirements by the engine. So a linearly mapped TPS-based look-up table has low resolution (i.e. provides coarse adjustments in ignition and fuel supplied to the engine) over a very important part of the RPM range. This can result in sub-optimal engine performance. Furthermore, the look-up table entries for medium-high TPS values at these RPMs are effectively wasted space, and, if mapped correctly, they should all contain the same values since the engine demands do not change over this range.
The above is demonstrated in the following plots, taken from data that I recorded on a single, normal (i.e. ordinary road) journey:
This plot and this plot indicate what proportion of time was spent at each TPS value - so it is clear that very little time is spent at throttle openings over 30%. This plot and this plot indicate what proportion of time was spent at each MAP value - which clearly shows a greater spread than a TPS. This plot indicates the relationship between TPS and MAP values when the inlet manifold pressure is near its maximum (i.e. the vacuum is near its minimum). The green line shows the minimum throttle opening that gives rise to maximum inlet manifold pressure, for each RPM. This throttle opening is the throttle position threshold. You can see that the throttle position threshold is 20% of maximum throttle opening at RPMs upto 4000!
This plot shows the areas of the map that are most commonly used. Note the peak around 800/1000RPM, when the engine is idling and the car is at rest. Apart from that, in normal road conditions, the 1600-3600 RPM band is where the engine spends most of its time, and therefore needs the most precise tuning.
The 'down' side to MAP sensors is that they can produce noisy measurements, particularly in highly tuned engines where high-overlap cams are used. However, hardware and software mechanisms exist which can smooth out this noise, and the noise is most significant at lower RPM.
Just in case you are worried that you might be stranded in the middle of nowhere if this system should let you down, the clever ignition module has a 'limp home' mode. Up to 2000RPM, the engine will receive the static advance that the distributor is set to. Above 2000RPM, the ignition module applies an extra 10 degrees of advance. This is surprisingly effective, and very driveable.
| Part | Cost me |
| (used) GM (not Vauxhall) ECM (waterproof) | £30 (but can be bought for less these days) |
| (new) Emerald (RS) TPS & bracket | £25 |
| (used) GM (not Vauxhall) ignition module (HEI) | £10 |
| (used) GM/Vauxhall MAP sensor | £10 |
| (used) GM/Vauxhall connectors | free |
| (new) Wire - to extend ECM wires | ~£10 |
| (used) Distributor (requires fitment of reluctor sensor from another distributor) - to provide speed input | ~£20 |
| Welding up of above distributor to prevent any mechanical advance | ~£5 |
| (new) 27C256 EPROM to program ECM (but I was lucky enough to find a few spares in a skip, at my work place) | ~£5 |
| (new) Waterproof dash connector to interface ECM to lap-top | spare from where I work, so - free |
| (used) Vauxhall CTS (arguably not absolutely essential for ignition alone) | came with my engine, so - free |
| Total | ~£115 |
| Item | Cost me |
| Very old (486 25MHz) lap-top PC (for connection to the GMECM via the diagnostic data stream) | thrown away from where I work, so - free |
| Diagnostic data stream (ALDL) RS232C interface circuit (to change from TTL to RS232C standard voltage levels) | reject board from where I work, modified by me, so - free |
| ALDLMON - Diagnostic data stream (ALDL) monitoring & recording software (MSDOS). This is written to work with Mask $8D ECM software, but is available with (Pascal) source code, so that you can make corrections/changes. (I no longer use it as have written my own version for the $58 code, in 'C'.) | freeware - including source code |
| WinBin - ECM EPROM configuration software (MS Windows) | freeware |
| Lots of small, data interfacing/manipulation/analysis programs (MSDOS) | written by me, so - free |
| EPROM programmer, supporting 27C256 | thrown away from where I work, so - free |
| EPROM (UV) eraser | thrown away from where I work, so - free |
| Strobe light (for viewing ignition advance at the crank pulley) | I had one of these anyway, so - free |
| Oscilloscope (for viewing ignition and injector firing pulses) | thrown away from where I work, so - free |
| Registered copy of PROMgrammer (for ease of modifying $58 calibration data) | $10 |
| Total | $10 |
Having painted what might seem like a 'rosey' picture at this point, I must point out the problems with use of GMECMs:
(*) However, GMECM software can be changed to read any of its calibration data (including look up tables etc.) from RAM instead of ROM. To exploit this, I modified my ECM software to accept commands (va ALDL) to change values in RAM, and wrote PC software to provide a user-friendly means of changing RAM values on-the-fly, in the style of COTS packages. This setup is currently configured for the main ignition advance and volumetric efficiency tables - as these need to be iteratively modified to exactly suit the engine. The best place to do this is on a rolling road - where the values can be optimised for maximum engine power and mapping is made easier by being able to hold engine load and speed constant (to get enough data to optimise a given cell of the look up table). However, road tests in conjunction with a wide-band lambda based real-time mixture sensing system, can achieve similar performance, but takes longer. My PC software allows the improved table values to be saved to disk - which can then be transferred to EPROM for long term use.
So, you can see that using GMECMs is not for the technophobe, but within easier reach than when I started. To get to this point I have had to go through a steep learning curve, which has taken years and hundreds of hours, much to the disgust of my wife...
| Part | Cost me |
| (used) Vauxhall Cavalier 2.0 8v injector rail, injectors, and regulator | £20 |
| (used) VW EFi 'swirl pot' | £10 |
| (used) 2 x DCOE 40 to convert to TBs | £55 (minus £55 that I got for the jets and stuff) = £0 net |
| (new) Thermistor that matches the GM MAT (and CTS) resistance curve - to use as a MAT sensor | £1.38 |
| (new) VW (Bosch) EFi fuel pump - fits inside swirl pot | £135 |
| (new) EFi fuel filter - fits to swirl pot | £7.36 |
| (new) Short length of aluminium bar - to make injector bosses for my DCOE inlet manifold | £5 |
| (used) Volvo 760 Turbo injector rail, injectors, and regulator | £15 |
Thanks to Bill Shurvinton for the idea, acting as an agent for the provision of the american GM hardware, and his early suggestions about the $8D software.
Thanks to Ward Spoonemore AKA ECMGuy (RIP) for his substantially commented hack of the 1227727 Corvette ECM software.
Thanks to Steve Ravet for the GMECM Email list.
Thanks to Shawn R. Lin at the W-Body page for the ECM and MEMCAL pictures.
Thanks to Eric Aos for WinBin.
Thanks to Carsten Meyer for ALDLMON and his ALDL interface circuit diagram.
Thanks to Donald Whisnant for his code-seeking 68HC11 disassembler.
Thanks to Orgler Electronic for their 68HC11 assembler (which no longer appears downloadable).
Thanks to Bill Calcagno for PROMgrammer (I have a registered copy).
Thanks to Wabasoft for Waba.
Thanks to other GMECM gurus e.g. Bruce Plecan (RIP), Robert Rauscher, Peter Gargano, Shannen Durphey, Ludis Langens, and others...
Thanks to my colleague, Geoff Hatto, for his PC-based 'C' serial data and cursor positioning software.
I accept no responsibility for the accuracy or inaccuracy of any of the information on these web pages, nor any problems/damage resulting from the use of it.
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}