• 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 23 [edit: typo has been fixed] 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]
 
Last edited:
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
 
I have been trying to change the ignition cut/ hardcut for a while and just don't understand what I am doing wrong. I have the 219 ezk and in tuner pro it says "Increasing this constant will increase rpm limit
stock value in bin :
208 = 0x66 (102) = 6500 rpm 7000 = 142
177 = 0x72 (114) = 6650 rpm 7500 = 181
140 = 0x5F (95) = 6410 rpm 8000 = 221
169 = 0x5F (95) = 6410 rpm 8430 = 255
When this is set to max value 0xFF (or 255 as integer) the rpm limit will be raised to appx 8400 rpm.

It will be hard cut of all sparks so best to have LH limiter 1-200 rpm lower"
So I have put the fuelcut at 7000 rpm (for testing) and then changing the hardcut to 6410 rpm(140 and 169) but nothing changes it just cuts on fuel. I have read that some also have the same problem but no solutions so please help.
 
What RPM do you want ignition cut? and what RPM for fuel cut?

For the EZK '219, you need to use the "EZK 219_207_175_147 Basic A.xdf", not the "EZK 208_177_169_146_140 Basic B.xdf"
and then change the four "xxxx RPM Limiter Hard Cut (207 +219+175)" values

Around 6000 rpm, found my first fault and I needed ezk 148. I tried to change every table there is and put zeroes everywhere just to see something happen but nothing changes, I am using a 148 bin and 148 xdf but nothing happens.
 
"... nothing happens."
Do you have the original factory EZK daughter card installed (the one with the white Bosch logo), or an aftermarket add-it-yourself daughter card? The aftermarket cards have a 3-pin jumper that selects between the original factory firmware in the processor chip and the firmware in the daughter card EPROM. If the jumper is in the wrong position, you'll be running original code no matter what you put in the EPROM.
 
"... nothing happens."
Do you have the original factory EZK daughter card installed (the one with the white Bosch logo), or an aftermarket add-it-yourself daughter card? The aftermarket cards have a 3-pin jumper that selects between the original factory firmware in the processor chip and the firmware in the daughter card EPROM. If the jumper is in the wrong position, you'll be running original code no matter what you put in the EPROM.
I do have an aftermarket daughter card, and had no idea that it had a 3-pin jumper. How do I select the right one? Although when I have put in an empty EPROM I got no spark.
 
Last edited:
If you have a blabla / Bijlsma card, jumper in the 1-2 position is factory / processor internal code, and 2-3 is external EPROM - link
For other boards, you'll need to look at them and they should say on the front or back which position to used for EPROM.
 
Injector constant #1 (map multiplier) seems to me, to be the best one to edit for larger injectors - however, I've noticed that I've had to adjust some maps quite a lot anyway. I run 1200cc's which is some type of modified bosch injector from a reputable firm where I live. The main map is honestly pretty close - I am of course not expecting one variable to be able to fully adjust the ecu for injectors more than four times the flow of the original ones. constant #4 is obviously not where I would want to make the course adjustment for the injectors as this would skew some of the already mentioned calculations the ecu is doing by a large amount (load value..tq ezk..). In other words, tuning for BIG injectors is absolutely not an easy task on lh2.4 as you will have to do a lot of remapping. For instance, I have greatly changed the ramp of my amm map, because it would flow an absurd amount of fuel at higher maf readings - even though I got pretty close with the injector constant #1 on idle fueling.
 
  • Like
Reactions: Led
Hi guys !

Ive read most of the thread (yes, over multiple days...)

I am the proud owner of a 91, 2.3 16V wagon, running E85 and LPG.

Two questions :

First
, EZK : I found, and edited the dwell table, to suit my wasted spark (running Toyota coils)
These like 2ms, no more. With my map, above 2000 revs, I can reach that, so Im good. However, no matter how low (or high) I set the integer in the bottom of the map, Idle dwell sits at around 5/6ms.

Ipdown website mentions "dwell constant", anyone understands/knows how the dwell calculation works ?
https://web.archive.org/web/2019111.../index.php/EZK#B204FT_ignition_map.2C_208_EZK
Couldnt find these in the 208 EZK at the mentionned positions, with the data view or in HEX editor directly. Unsure about the validity of this claim

How the f am I supposed to fix that nasty nasty low rev/idle dwell ?

Second, regarding 928 ECU, the 16v one. Yes, I know, I'd rather get my hand on an 8V ECU, but still, I read my 928 chip and the data is... junk ? nothing even closely ressembling a fuel MAP. Same thing with all the 928 bins I managed to find online. If anyone has an idea/knows why, I'm curious. Its mostly to have a "base map" to copy. Without an ostrich (hard to find nowadays, and pricey) it's hard to strat from scratch.

I need to change the injector constant values (running 5cyl injectors) and cold start behaviour to suit E85 better.

Could go standalone but f wiring and idk how the LPG will react with that. I do have access to the LPG software and fuel MAP, so that's not an issue. Also I spent the standalone money on a penta bottom end, so theres that :)

Pic of the average junk inside that 928 chip

 
What xdf are you using? I can take a look at the bins i have saved when im at my computer again, and see if i have a working xdf. Otherwise ill take a look at the source code to see where the main table is located.
 
RE: EZK 208 dwell
The constants on the ipdown archive site are addresses to the beginning of the multi-byte instructions you need to modify, not the actual data location. The actual data are at addresses 0x1400, 0x1406, 0x1411, and 0x1416. They should be changed in pairs, meaning 0x1400 should be changed with 0x1411 and 0x1406 should be changed along with 0x1416. Notice the two paired datas always add up to 255. Keep it that way. I do not know how to decode these into real time units, but if you have a scope or something you should be able to modify them to get your idle dwell in line. They are just floor/ceiling threshold checks to make sure the output of the dwell calculation doesn't go too long or too short.


RE: LH 928 maps
It is a crazy coincidence that you asked about the 16v/928 bin today. I had just happened to be looking into it for other reasons just this morning. The 16v fueling logic (specifically how the MAF is interpreted) is a lot different than 8v to the point that IMO it is not worth starting with. It doesn't have the fueling constants in the same way that the 8v bins do, but I am sure there exists some semblance of them somewhere in there.

I am not sure of an xdf file that decodes this bin properly, which is why you're getting junk data as pictured.
If you need the maps to look, the main fueling map is located at 0x3ba4 and it is an 8 bit, 16x16 correction map that i am assuming is used similar to the 8v one, but the axis are calculated differently and idk what they are, other than RPM and cylinder load.
Screenshot 2026-04-10 at 19.11.45.png

The MAF map is the spicy one, located at 0x39a4 and is 16 bit which is funky and 16x16 sized. The Y axis is RPM and the X axis is a number of pulses from the hardware voltage-to-frequency converter chip on the PCB that is somehow correlated with the MAF.
Screenshot 2026-04-10 at 19.11.26.png
 
Oh wow that's great, I was so stuck on that dwell issue...

Do you know if those adresses are ezk 208 specific or not ? The 950 Lh is different hence the question. So I can modify my ezk 148 bin accordingly. Do you have an xdf with those constant parameters? If not, I'll modify those myself. I do have a portable o-scope, so I will report back on the effect of those constant !

Here you can see, 4ms at around 1200 revs, which is way too much.


928 ECU : so it's best that I source an 8v ECU. Either NA or Turbo, I don't mind. More money out of the window, however
 

Attachments

  • Screenshot_20260406_231606_Gallery.jpg
    Screenshot_20260406_231606_Gallery.jpg
    312 KB · Views: 6
This make sense to me. I like the overall driving on the stock 16v/928 map top. Compared to the stock 951 map Bottom. 1993 240. But really, I'm gunna mess it all up to my liking.

928 951.JPG
 
I looked at the EZK dwell code briefly and I have a guess how it's setup, but my benchtop tests don't exactly match. The hand-coded RPM and voltage values used in the TunerPro dwell table may be off some?

EZK '208 dwell table.png

I think the main dwell table is dwell in degrees of crank rotation, e.g. 1400rpm/12.5v uses 65 degrees of dwell, or 7.7ms (60/1400 * 65/360).

After getting the table value for current rpm&volts, the value is limited to the range 0x1c to 0xac (28deg to 172deg). The code fragment is:
Code:
                             MainRoutine4_1909                               XREF[1]:     CODE:1806(c) 
       CODE:1909 78 82           MOV        R0,#0x82
       CODE:190b e6              MOV        A,@R0=>MEM82_volt_for_tbl_lookup
       CODE:190c f8              MOV        R0,A
       CODE:190d a9 40           MOV        R1,MEM40_rpm_for_tbl_lookup
       CODE:190f 90 1d 80        MOV        DPTR,#0x1d80                             ; 3x16 dwell table (volt x rpm), dwell in degrees???
       CODE:1912 51 28           ACALL      TableLookup_Nx16                         ; 8-bit interpolated lookup result returned in A
       CODE:1914 f5 f0           MOV        B,A
       CODE:1916 24 e3           ADD        A,#0xe3                                  ;   0xe3 = 0xff - 0x1c
       CODE:1918 50 0c           JNC        LAB_CODE_1926                            ; jump if dwell < 0x1c (28dec)
       CODE:191a e5 f0           MOV        A,B
       CODE:191c 24 53           ADD        A,#0x53                                  ;   0x53 = 0xff - 0xac
       CODE:191e 40 0b           JC         LAB_CODE_192b                            ; jump if dwell > 0xac (172dec)
       CODE:1920 e5 f0           MOV        A,B
       CODE:1922 f5 38           MOV        MEM38_dwell,A
       CODE:1924 80 08           SJMP       LAB_CODE_192e
                             LAB_CODE_1926
       CODE:1926 75 38 1c        MOV        MEM38_dwell,#0x1c                        ; if dwell < 0x1c, set to minimum of 0x1c (28dec)
       CODE:1929 80 03           SJMP       LAB_CODE_192e
                             LAB_CODE_192b
       CODE:192b 75 38 ac        MOV        MEM38_dwell,#0xac                        ; if dwell > 0xac, set to maximum of 0xac (172dec)
                             LAB_CODE_192e
       CODE:192e 22              RET

In theory, I understand that max dwell needs to be less than 180deg, or else there's no time left for the spark to fire and burn out.

I don't know why there would be a minimum dwell that's different from the table. During cranking, spark advance does go negative (i.e. retarded after TDC), so maybe there's a math limitation with negative advances?

You can change the 0x1c dwell limit (change the 0xec byte at 0x1917 and the 0x1c byte at 0x1928, and the other 3 code copies), to a lower value and see if it's happy at idle and when starting at higher voltages (e.g. on a jump pack or big battery charger).
 
Is that a 928 xdf ?
May I get a hand of it ? So I don't have to buy an 8v ECU
This make sense to me. I like the overall driving on the stock 16v/928 map top. Compared to the stock 951 map Bottom. 1993 240. But really, I'm gunna mess it all up to my liking.

View attachment 37839

Boby, I have to look into it, but of the two constants provided earlier, made two test chips and found which one limits the maximum dwell. Managed to bring idle dwell from 6 to 3.5ms (used ipdown's values)

Now I gotta try some more. Times premium these days but I'll report back and I'll share the modified xdf with those who want to run different coils !

Tables in tunerpro are slightly off, as the current curve is not really linear. Made a linear version and now I have 1.8ms at mid revs and 2ms at high revs. So theres a "dip" of some sort. I had no dips in the dwell before doing that "linearisation"
 
  • Like
Reactions: Led
Back
Top