• Hello Guest, welcome to the initial stages of our new platform!
    You can find some additional information about where we are in the process of migrating the board and setting up our new software here

    Thank you for being a part of our community!

Fuel/Spark tuning for LH 2.4/EZK with TunerPro!

Note: I'm using the constant 1,2,3,4 order from TunerPro; esmth is using a different order:
View attachment 34943

In more detail, here's my current guess for the fueling equation (before lambda trims) and the main injector constants:

The AMM sensor reading is used to calculate a base "load" value, which is the injector pulsewidth needed to give a 14.7 AFR. The main fueling table is a rpm/load based correction added to the base load.
load = K * cur_rpm_period_H:M:L * InjConst4 * AMM_AVG_H:L = injector pw in 2us timer ticks for 14.7 AFR
fueling = (InjConst1 * 2/256) * (load * (1 + (fuel_table[]-InjConst2)/512))

InjConst1 (8bit K_92 0x383c) - overall fueling multiplier *2/256
InjConst2 (8bit K_94 0x383e) - correction table offset (above offset is positive, below offset is negative)
InjConst3 (16bit K_da 0x3884) - min injector open time
InjConst4 (16bit K_dc 0x3886) - K/injector_flow_rate, K is approx 750,000

The pulse width of the ECU-to-EZK Tq signal, in 2us steps, is calculated as the 12-bit load value times a Tq scaling constant (8bit K_93 0x383d), with a hardcoded min limit of 0x13 (aka 38us min Tq) and a max limit from the constants table (8bit K_97 0x3841).

First of all, thanks for your dedication and willingness to share.

Question:

If "load" is a function of injector constant 4, modifying this could alter the load signal to the EZK for a given engine operating condition, correct?
If so, one should adjust the EZK load factor scaling accordingly.

Or is load to EZK a different parameter?
 
I hadn't thought about this, but I think you're right, or my understanding of the LH2.4 fueling is wrong. I'll try an experiment with my benchtop setup later this weekend to verify what happens.
 
I ran the benchtop tests, and yes, for the same AMM voltage (aka the same airflow) changing InjConstant #4 rescales the internal Load value and the ECU-to-EZK Tq pulse width. I think this means that all ECU tables that use the Load value need to be reviewed after changing injector constant #4. It may be possible to change some ECU constants to keep the ECU-to-EZK Tq pulse width unchanged for a given AMM/Airflow rate - I haven't looked at the details for this.

Here's some graphs from the benchtop tests with 3 lines for different InjConst#4 values: 3889 Stock NA, 2443 Stock Turbo, 1945 half of NA. I varied the AMM voltage from 2.0volts (below idle) to 5.0volts (maxed out) and measured Injector PulseWidth (in ms), Tq PulseWidth (in us), and the 8bit version of the Load. All were run at 2500 RPM, on a 951 ECU, with Lambda adaption disabled.

InjPW Load Tq vs AMM and Airflow.png
 
Hardware Mods for LH2.4 Monitoring and Logging with TunerPro

The factory LH2.4 ECUs and firmware include a simple serial port interface that can read the internal ECU RAM values. To use this interface, you need some hardware mods and a suitable USB-to-serial adapter for your PC. As a bonus, there's an unused ADC (analog-to-digital) pin on the LH2.4 ECUs that can be used for the AFR signal from a wideband oxygen sensor (WBO2).

With these mods, and a custom TunerPro .adx file, you can monitor and log basic ECU parameters in real time using TunerPro. The completed logs can be played back later within TunerPro, or exported to a .csv file that can then be viewed in MegaLogViewer, or similar apps. With a modified .xdf file, TunerPro supports real time table entry tracing using the logged values. Table tracing is also supported during log playback. See the previous posts for some example TunerPro screenshots.

This setup seems to be pushing the capabilities of TunerPro, but is much nicer and more useful than the limited Moates Ostrich address tracing capabilities. I especially like having the VSS vehicle speed sensor (aka MPH) included in the logs. It makes it much easier to match up the log sections to the drive session.

WBO2 Mods
To monitor the WBO2 AFR value, one resistor in the ECU needs to be changed and, for some ECUs, another resistor added. The WBO2 gauge can either be wired in using a newly added pin in the factory ECU wiring harness, or, since you're adding wires already, can be added as a separate wire coming out of the ECU box directly (no need to disassemble the 35-pin ECU harness-side connector to add a pin+wire).

The resistor(s) are on the bottom of the circuit board, so the board needs to be unscrewed from the housing and popped off the plastic standoffs. Be very careful popping the board off the standoffs. I think I bricked one of my ECUs by overly flexing the PCB, and possibly the ceramic hybrid, during removal.

The standoffs have a plastic retention pin within the center of the standoff. To remove these, push down firmly on the top of the standoff using the flat side of a flat blade screwdriver. The center pin should pop down slightly. From the other side, grab the pin by hand and pull it down the rest of the way. Repeat for all 3 standoffs. Next, use a toothpick to lightly oil the crack between the standoff and the PCB. The standoffs become overly stiff after 30 years, so a little oil helps with removal. Using needle nose pliers, squeeze the 2 sides of the standoff together while lifting up on the circuit board. Again, be careful not to twist the PCB too much. Repeat until all 3 standoffs are free. Re-installation is easy, just make sure the retention pins are fully down first.

LH2.4 PCB standoff.jpg

There are 2 resistors used in the ADC2 circuit, R107 (866ohms gray-blue-blue-black-brown) is a strong pullup to +5volts, and R108 (14700 ohms brown-yellow-violet-red-brown) is a series resistor to the CPU ADC input pin. There are at least 2 different build variations used for the LH2.4 9xx series ECUs. In my stock '937 and '967 ECUs, both R107 and R108 were populated. In my '951 ECU, only R107 was populated.

R107 needs to be removed and replaced with a 100K resistor. This prevents the ADC2 input from floating when the WBO2 isn't connected. [side note: floating inputs are generally a bad hardware design practice, but can be OK with some chips. My '951 ECU did not have R107 installed, so it had a floating input from the factory, but I couldn't find anything in the CPU datasheet to suggest that this was OK. If you don't have a 100K resistor, and will always have the WBO2 connected, then R107 can be left empty.]

If R108 is not populated on your ECU, it needs to have a 10K resistor added to connect the WBO2 signal to the ECU pin. R108 was not populated on my '951 ECU, but was on the '937 and '967 ECUs.

LH2.4 ADC2 WBO2 resistor mods.jpg

Serial Port Mods
The CPU chip used in the LH2.4 ECUs includes a UART serial port, operating with 5volt signal levels. To connect this to your PC, there are 2 options:
1) wire the CPU 5volt Rx/Tx signals directly to an appropriate serial-to-USB converter module, or
2) wire the CPU 5volt Rx/Tx signals to a RS-232 converter chip wired to a DB9 connector, and then use a standard USB-to-DB9 adapter cable.

Option #2 - 5V Serial to RS232
I chose the 1st option because I had the parts in my closet, but I like the 2nd option better because it can be more robust. There are small RS-232 converter boards available that include the DB-9 connector (link or search for "MAX3232 DB9").

MAX3232 DB9 Adapter Board.png


If this can fit within the ECU box, it would be a clean setup, but I don't know if there's enough room for an external DB9 serial connector behind or on top of the ECU box. It might need an Amazon "90 degree DB9 cable" to fit.

There are also small RS-232 adapter boards without the DB9 connector that could be wired up inside the ECU box, with a small cable to an external DB-9 connector (link or search for "MAX3232 converter"]. The cable for these can easily come out any side of the ECU box. I still like this better than option #1 because the direct to CPU connections are all kept within the ECU box. Only the converted RS232 signals go out of the box.

MAX3232 mini adapter board.png

For option #2, you must use a FTDI (real or fake) USB-to-RS232 adapter cable (try Amazon "USB to RS232 DB9 serial cable FTDI", e.g. link). Cables with other chips (Prolific, CH430, won't work).

Option #1 - 5V Serial Direct to USB
For option #1, you need a FTDI USB-to-serial adapter board. They're commonly available with either USB-C or Mini-USB connectors. Note, almost all of the "FTDI" boards on ebay use a fake FTDI chip, but the fake chips seem to work OK for this application ( link )

FTDI USB-to-serial adapter board.jpg

The adapter board needs to be modified slightly for direct wiring, and to change from USB-provided +5volt power to ECU-provided +5volt power. If USB-provided power is used, the USB adapter can back-power the whole ECU board through the Tx/Rx signals, which is bad for reliability. To modify the adapter, remove the 0ohm resistor by the top of the USB connector, remove the 2 sets of header pins, and direct jumper for +5volt Rx/Tx signal levels.

FTDI USB-to-serial adapter board - wires.jpg

On the LH2.4 circuit board, the Rx trace going across the pads of B303 needs to cut in half. Use a sharp Xacto knife to cut the copper and dig a tiny trench in the board to break the trace, or you can use a Dremel tool with a small bit, but be careful to not damage anything nearby. Use an ohm meter to confirm the trace is fully cut.

There are 4 wires that go to the USB adapter board: +5volts, ground, Tx, Rx. I used some small stranded 24 gauge wire, and ran the wires through a hole in the heatsink as a strain relief. You can disassemble an Ethernet patch cable, or a fatter USB cable, to get some small gauge wire, but the insulation on those is pretty soft and tends to melt easily when soldering – you gotta' be quick. Or next time you're at the salvage yard, cut off the first ~3 feet of a modern ECU's wiring harness (bring a hacksaw blade holder).

LH2.4 serial adapter details.jpg

1,2) The easiest place to pick up +5volt and ground is to connect to the ends of capacitor C505. See the green ground wire and red +5v VCC wire in the picture.

3) Rx Signal – there's a PCB via just above the left (CPU-side) pad of B303 that goes to the Rx pin on the CPU. I find it easier, and more robust, to solder in a bit of bare solid wire (aka scrap of resistor lead) into the via, then wire to that via stub instead of connecting to the bare B303 pad. See the yellow wire in the picture, which goes to Tx pin of module.

4) Tx Signal – there's a PCB via just below the bottom right corner of BS203 (near pin 10) that goes to the Tx pin on the CPU. Again, solder a bit of bare wire into the via and then wire to the stub. See the blue wire in the picture, which goes to Rx pin of module.

WBO2 – For the WBO2 signal, I found it easier to solder a wire onto pin 32 of the internal ECU connector instead of adding a new pin&wire on the harness-side 35pin connector. See the white wire the in picture.

Add a zip-tie around the wires by the heatsink to help as a strain relief from any tugging on the external cable/module. Add some shrink wrap around the wires, route them out of the ECU case and to the USB adapter module (hole in the back of the case not shown in the pictures). For protection, wrap the module and USB cable in electrical tape and/or big heat shrink or sleeving.

LH2.4 serial adapter wires.jpg

LH2.4 ECU with USB-to-serial adapter.jpg

[continued in next post]
 
Hardware Mods for LH2.4 Monitoring and Logging with TunerPro – continued

Optional section – serial protocol details

TLDR – you must use a USB adapter/cable with a FTDI chip.

The serial port protocol used by the LH2.4 ECU is uncommon in a couple ways. First off, it runs at 187,500 baud, which is the CPU 12MHz clock divided by 64. This baud rate is not a standard rate, but is supported by the FTDI FT232R USB-to-serial chips (both the genuine ones and the more common fakes). It doesn't seem to be supported by the Prolific or WCH CH304 chips. The protocol also uses 9-bit characters with no parity (9,N,1). Almost nothing supports 9-bit characters, but some chips, including the FTDI ones, support Mark (1) or Space (0) parity with an 8-bit character (8,M,1 or 8,S,1), and this can be used instead of the 9th bit.

The LH2.4 serial protocol is very basic. The ECU has a total of 256 bytes of internal RAM. Some versions have another 256 bytes of external RAM. To read a byte of memory, the protocol simply sends a 9bit character to the ECU as the memory address. The ECU responds with the 8bit memory value at the 9bit address. The last or 9th bit of the character selects between internal (0) and external (1) RAM.

A TunerPro session can be configured for 8-bit characters with Mark or Space parity, but not both within the same session. This makes it difficult to use if you need access to both internal and external RAM. Fortunately, the '937 and '951 ECUs don't have any external RAM, so all serial accesses can use 8-bit characters with Space parity. The '967 ECU has the external RAM but most of the values of interest are still in the internal RAM. The current DTC codes may? be stored in external RAM in the '967 – I haven't dug into the code to see where they moved to. If you _really_ need to run a .bin version with external RAM, you'll need to tune with an internal-RAM-only .bin (aka '937) and then copy the results to the other .bin.

For any folks who want to connect an Arduino, or other small processor board, to the ECU serial port, I have a few comments. The Arduino ATmega processors support 9-bit characters but the standard Arduino configuration library doesn't. I think you can get around this by rewriting the USART control register after Arduino initialization. The ATmega processors don't support an exact 187,500 baud, but the supported 181,818 baud may? be close enough (~3.0% slow). If needed, the LH2.4 ECU serial code can be modified to use 8-bit characters, which gives ~10% better baud rate tolerance.

A Raspberry Pi RP2040 can support a baud rate close to 187,500 and Space parity (called Stick parity in the docs). The standard UART is 8-bit, but the PIO code could be modified for 9-bit characters. Since the RP2040 is a 3.3v part, a level translator is needed on the 5volt ECU Rx/Tx signals (maybe this https://www.sparkfun.com/sparkfun-logic-level-converter-bi-directional.html ?)

I looked around and none of the common HC-05/HC-06 serial-to-bluetooth converter boards support 187,500 baud with mark/space parity.

Other Comments
For diagnostics, the standard LH2.4 ECUs support basic DTC blink codes by holding down a button on the diag box. Due to the cut Rx trace, and running a .bin file that has serial debug enabled, the diag box (ECU socket #2) isn't supported. I've traced most of the DTC codes in firmware and have included them in the TunerPro monitors, but there's no way to clear them without disconnecting the battery. The dashboard CEL light still operates normally.

Long ago, beepee developed a special .bin file that included a different serial debug interface. This interface worked without any hardware changes and used a VAG-COM ALDL cable connected to the diag box. The .bin file for this is still floating around, but I haven't seen any documentation on how to use and modify it (plus it sounds a bit flakey). It may have been documented on the long-gone, and not archived, ecuproject web site.

Once I trace more of the LH2.4 fueling algorithms, I'll post a chart of the known RAM addresses and associated conversion equations. These are all buried in the TunerPro .adx file, but will be useful for anyone who wants to write their own software.

If you're looking for FTDI adapters or cables, ignore anything about Windows compatibility. You can, and should, download the latest drivers from ftdichip.com. They'll support all versions of Windows, and will support the fake FTDI chips too. (For a brief while, the FTDI drivers would change the device ID on the fake FTDI chips, which essentially bricked them. After vigorous pushback, FTDI backed off and continues to support the fake chips.)

-----------

I'm still working on some good TunerPro .adx setup files, and on finding/tracing some additional RAM values. I keep running into TunerPro quirks that I need to work around. The basics are OK, but I'm hoping to improve the usability some. Overall, it's much better than no logging at all, or the limited Moates Ostrich tracing, but is a far cry from what's available with any aftermarket ECU.

-Bob
 
Back
Top