DIY LTCC or similar system for LT1s

[spfautsch]

... run in parallel both opti and 8 coils setup and compare with a scope or visual leds the firing events under different conditions.

This would be simple - omit R3 and substitute a 10k resistor in place of R4 and you could run it in parallel with the stock distributor setup. You would only need one coil as the spark event will begin at the same time with one, eight, or no coils connected.Then compare the time delta between the beginning of distributor spark and the test coil.

Can we set the ltcc to act as an external Ignition control module to the PCM, and made the pcm to calculate dwell. That way LTCC will only need to sequence the coils.

I guess that will work fine on lower rpms. If I am correct, The ESC signal will be high during dwell and get low at triggering.
Anyone knows the dwell bounderies of stock single coil setup. The pcm can operate at max of 7200 rpm and that will be around 2.07ms between 90 degrees crank rotation.
So we need a coil that operates safely at 2-2.5ms range to make it work.

I discussed this topic with vilely ad-nauseum some 100 posts back. It's as pointless as light beer, or "diet" donuts. I see no reason to discuss it further.

The ICM mode can be run with 6ms dwell coils below 2500rpm, At higher rpms it can swicth to LTCC built in dwell calculation mode.

That can be totally unnecessarily if we have a dead spot on spark events. Just giving some ideas.

I have immense respect for you so please don't take offense, but this idea seems kind of like the plot of a really bad Stephen King movie.

Science is good. The only thing I enjoy more than scientifically presented information on some technical problem I'm trying to solve is a blind study confirming the initial information. By all means, I beg you to please scientifically find flaws in the design. Then we try to improve the design in the most elegant and well-informed way possible. Running two ignition systems in parallel or some hybrid of such is the polar opposite of this idea.

Edit: If I've misunderstood your motives please forgive me and my insensitive opinions. At the end of the day I have nothing to gain or lose from this project - my car is running as well as it ever has and at that I'm content so when I say I really don't care if anyone else has success with the controller it's not hyperbole. I have a wife of 25+ years, a daughter, and a recently widowed mother to care for as well as a full time job, and a large stable full of used cars to maintain with the newest vintage being a 2013 Equinox. In the small window of time I have left for myself I enjoy sleeping, drinking good coffee and bourbon, and doing things I genuinely enjoy. So my attention span for fixing timing errors on the order of a few microseconds admittedly takes a back seat to (pretty much everything).

[kur4o]

No offense taken. In the path for perfection I might have overthought some of the concepts.
I aim for dead spot on spark only because spark scatter is the main source for bad running engine. Even 2 degrees is too much sometimes.

Since I haven`t check the actual capabilities of the LTCC board yet, I will give more ideas when manage to install it and get some viable running data.

For now the only thing that can be offered is some new spark offset table vs rpm to compensate for any errors due to lag in the signalling circuit.

There are also some free input/output pins that can be used for interaction between pcm and ltcc. It will open new LTCC controller features.
There is even factory output pin with pwm modulated signal of TPS position that is used for traction control.

[spfautsch]

I aim for dead spot on spark only because spark scatter...

I think I PM'd you a zip of the source that's flashed on your AVR. Attached is an object dump of the resultant .elf binary before it was repackaged as intel hex. To do this yourself you can hold down shift before compiling (you can use the verify function - button with a checkmark - to compile without attempting to upload to the AVR) and note the build info in the lower pane of the IDE. Near the end you should see it mention the full path to the generated .elf code. I haven't used Arduino on windows in ages so no idea if they include avr-objdump.exe but this is how I generated the attached dump on linux:

avr-objdump  -S /tmp/arduino_build_639568/diy_ltcc_0_9_18.ino.elf > output.txt

The EST line is using the highest priority external interrupt (except the reset interrupt) so when a falling edge signal is caught on pin 2 the AVR datasheet says there could be a maximum of 4 instructions executed before the INT0 ISR begins. This potential delay, and the instructions at 0x07fc prior to the register being toggled off should be the only points spark delay should be introduced by the controller.

There is an input debouncer check, and a few other checks to accomodate ATDC spark timing. Here are the instructions that toggle the output register.

      *sequencer[sequenceIndex].portAddr &= ~sequencer[sequenceIndex].bitMask;
     80e:    60 91 05 01     lds    r22, 0x0105    ; 0x800105 <sequenceIndex>
     812:    30 91 05 01     lds    r19, 0x0105    ; 0x800105 <sequenceIndex>

If this entire ISR could be optimized in assembly I think I can inline it directly in the source file.

For now the only thing that can be offered is some new spark offset table vs rpm

Curious if you know the address of this table in $ee offhand. I'm relatively sure this was intended to compensate for "lost" high resolution interrupt counts.

There is even factory output pin with pwm modulated signal of TPS position

I think I'm already using all the timers that would enable measuring a PWM signal, but there are available analog inputs so reading the TPS voltage directly would probably be easier and more efficient for the AVR since it has a dedicated ADC that works asynchronous of the main loop. Unfortunately it's multiplexed so reading TPS would have to share time with ignition voltage and MAP measurements.

[kur4o]

Curious if you know the address of this table in $ee offhand. I'm relatively sure this was intended to compensate for "lost" high resolution interrupt counts.

I am thinking of adding that table, since it doesn`t exist yet.

There is only built in 16bit scalar at $12048.
It works like this. the scalar must be converted to ms. In stock case that is $510*0.015234 = 19.74ms
Now you take opti low res signal in ms.
The spark adder will look like this [19.74/low res signal [ms]]/2=spark advance adder
19.74/1=19.74ms[750-1520rpm]=1 degree/2=0.5
19.74/2=9.87ms[1520-2279rpm]=2 degrees/2=1
19.74/3=6.58ms[2279-3042rpm]=3 degrees/2=1.5
19.74/4=4.93ms[3042-3807rpm]=4 degrees/2=2
19.74/5=3.94ms[3807-4559rpm]=5 degrees/2=2.5
19.74/6=3.29ms[4559-5319rpm]=6 degrees/2=3
19.74/7=2.82ms[5319-6097rpm]=7 degrees/2=3.5
19.74/8=2.46ms[6097-6849rpm]=8 degrees/2=4
19.74/9=2.19ms[6894-7228rpm]=9 degrees/2=4.5

There is also some rounding on that numbers so there is no halfs.

Can we derive some lag info from this and convert it to 1 degree error vs time vs rpm.
Increasing the scalar can account for the lag but alot of people will freak out when they see 40 degrees at WOT.

[spfautsch]

I guess I misunderstood what you were getting at with the rpm spark advance adder. It seems a little like you're trying to fix a problem before you know it exists. Take it from someone who's done that quite a bit lately - science is your friend.

Whatever the case, since we made the firmware and can modify it to our liking, the first, most obvious place to start trying to fix deficiencies is in the controller firmware, not the PCM. This was the first "commandment" I adopted when I decided to give this a shot - no tuning changes should be necessary. Even if only to avoid a CEL that's easily disabled - a problem that was fixed by finding the right set of resistors (thanks be to vilefly). If users disagree with this and want to take my code and fork it in a different direction you have my blessing and encouragement, just call it something else and keep your sources publicly available.

So, I'm hoping to reel you back in on how the spark fire event happens - there's nothing going on in the controller firmware other than the code I posted in the disassembly. This is the highest priority interrupt on the AVR so when the PCM drives the EST line low within four clock ticks all other code execution is pushed down the stack and the ISR that fires the controller's coil is executed. To quantify exactly how much delay that is would require stepping through the disassembly and figuring out how many clock cycles the instructions eat, then dividing by 16mhz. In summary - it doesn't matter how fast the engine is spinning, when the PCM commands the EST line low the AVR stops what it's doing and handles the coil firing.

Edit: going by the instruction set summary it looks like this comes out to a maximum of 14 clock ticks for BTDC spark timing. Adding the worst case of 4 before the ISR begins executing that looks to be 1.125 microseconds (0.000001125s). Check my math, but at 8000 rpm doesn't each crankshaft degree represent about 20.8 microseconds? If that's correct the coil firing delay introduced by the controller would be about 0.054 degrees? So if there is any delta it should be too small to observe at any engine speed the PCM is capable of.

I mean this in a positive and joking way, but I think you might have an addiction to patching. If you're jonesing for a new challenge there's somebody over here asking for a lean cruise strategy for $ee. This would interest me immensely but it's not something I'm capable of and wouldn't have time to test until spring of 2020. It seems to be right in your wheelhouse.

In case anyone's interested, my personal roadmap / goals as they pertain to this project are:

1) replace my wideband and control power to it so it's not being heated without the engine running - should get this done this weekend

In no particular order other than how they're popping out of memory:

*) get my tune to a solid, consistent baseline so I can work on improving and optimizing the diy-ltcc firmware without having to second-guess the cause of any problem - pretty sure this is done but would like to verify with reliable wideband data
*) gather igniter current and target dwell data on some of the most common coils that will be used here
*) improve and optimize the firmware as mentioned, including possibly adding misfire detection, verifying dwell times, etc.
*) add an in-circuit programming header and jumpered ground planes for the leds, and order another, larger batch of boards
*) build an arduino based injector flow bench - I know, this has nothing to do with the project - just a pipe dream I wanted to share

[kur4o]

Since the LTCC fires immediately after it gets low on ESC line, there shouldn`t be any spark advance error. The ICM module should also have some delay so if these 2 match, we will have dead spot on spark advance.
The only problem that may arise will be that dwell time is not optimal when the fire event is executed. You can shed some more light on that part.
At 7200rpm which is the built in opti software limit, 1 degree rotation will be done in 0.023ms.


I looked at the dwell code the pcm use. There is some built in limit which is opti signal - 0.60936ms. So I guess the coil needs at least 0.60936ms off time or it could be some lag compensation. A dwell adder when engine is cranking is at 0.437ms and the dwell is calculated different above 3400 rpm[some extra calculations are done].

[spfautsch]

I believe I read somewhere there is also a small delay for the coils - the magnetic field doesn't collapse at the same rate after power is cut to the primary winding depending on the size of the core and winding specifics, etc.

I'm really not terribly concerned with how the $ee PCM manages dwell because it's designed to work within the constraints of a single coil and distributor. There may be things to learn from it but I'd be more interested in what the newer coil per cylinder tunes do. I have yet to really dig into this subject other than skimming over (and being largely confused by) the dwell table for the tune you posted that uses the 8183 coils I have.

The dwell time is really the thing I want to research, test and improve upon. The way the dwell logic works is based on degrees - the lookup table is the target dwell time converted to crankshaft degrees vs engine speed. There is a voltage compensation table applied also that is somewhat generic and should probably be customized based on test data for different coils. Lastly there is a map adder that adds a fixed amount of dwell for large drops in map - sort of a "pump shot" type adder with a timer. Ultimately I think I want to change this to a map adder table which would give more predictable, linear results.

The dwell lookup routine finds the desired degrees of dwell for engine speed, voltage and map and then adds current spark advance to this to return the degree count where dwell should begin. It also has an overflow function for instances when dwell needs to start before the previous cylinder (or two, three cylinders) has reached TDC. If you enable logging and look at the data you'll see dwell specified as:

R906:A29:D0.61:C1:M458:V13.61:T30:E0:L0:S0
R901:A29:D0.62:C8:M520:V13.65:T31:E0:L0:S0
R900:A27:D0.62:C4:M585:V13.59:T32:E0:L0:S0
R910:A26:D0.60:C3:M678:V13.66:T33:E0:L0:S0 < dwell begins at 60* BTDC
R923:A23:D0.58:C6:M794:V13.66:T34:E0:L0:S0
R1055:A12:D0.45:C4:M930:V13.45:T40:E0:L0:S0
R2153:A24:D1.4:C4:M934:V13.52:T40:E0:L0:S0
R2772:A29:D1.38:C4:M153:V12.95:T40:E0:L0:S0 < dwell begins at 128* BTDC
R2402:A29:D1.23:C4:M112:V13.12:T40:E0:L0:S0
R1984:A27:D1.4:C4:M157:V13.33:T40:E0:L0:S0
R1636:A27:D0.80:C4:M205:V13.42:T40:E0:L0:S0
R1326:A27:D0.67:C4:M268:V13.44:T40:E0:L0:S0
R1099:A27:D0.69:C4:M337:V13.61:T40:E0:L0:S0

Note that this data is filtered through a conversion script so you'll see raw timer #s for RPM and raw adc counts for voltage.

I've been thinking about how to switch to time based dwell after sequence has been detected, but there are bunch of pitfalls that I'm not sure how to work around. Particularly the part where dwell needs to begin one or more low-res / TDC signals before the firing cylinder is on it's compression stroke.