DIY LTCC or similar system for LT1s

[spfautsch]

On key on engine off, I got -40 temp and 5 for voltage[pcm read 12.0 at the same time].

PID 3 is the voltage index for the dwell table lookup. So 5 would be correct for the 12v column. If you want to see actual sensed voltage add a 'V' to your logging request. Just bear in mind asking for a lot of human readable conversions on the logging data adds cpu load.

Temperature sensing relies on seeing initial spark advance to know which voltage divider the ecu is using so you'll need to at least attempt to start before it knows what lookup table to use. Did you copy your crank spark advance table from 12075 into the definition of crankSpkTable in config.h?

[kur4o]

I didn`t need to copy to crank spark advance table since it was the same for some reason.

I hope to get some logs later today.

Where I can get the index vs voltage table.

[spfautsch]

The voltage index is the x axis of the dwell table. Open d514a_dwell.h.

However, you should be safe to use C and V together. Just don't get crazy with the capital letter PIDs because they almost all involve floating point math.

[kur4o]

SOme logs I managed to take.

How can I tell the commanded dwell by the log. Is the last row, the final dwell in usec.

I feel that the dwell is not optimal right after starting. Very weak spark. Giving the higher map reading. I would like to boost it up some to see if there is any imporvement.

I switched to iridium spark 41-110 over the copper ngk, I guess the extra resistance really need higher energy.

[spfautsch]

Looks like ECT is more or less in agreement with what the ecu thinks it is. There might be a little noise there but will have to compare to some of my old logs to know if it's an anomaly we need to worry about.

As far as the possible causes of your issue, it's entirely possible I have some boneheaded oversight that's letting the controller think it can dwell a coil more than 720 degrees minus advance and recovery time and that would explain what you described. But only if it went away when the RPMs dropped. However, if it ran like crap long after you were below redline, there must have been something else going on.

Curious what your battery voltage reads at rest. When you first connect eehack the ecu is seeing 11.9 before you hit the starter. Do you have your fans set to run on high all the time? If not, that battery is as dead as dog excrement. A six cell lead acid battery at 12.0 volts resting is at 0% state of charge.

PID 6 is raw dwell target, in units of timer2 ticks. To convert that to milliseconds multiply by 0.004. If you find improvements by fattening up dwell please send me the dwell_*.h file and I'll use it in place of mine. The 514a coils gave me the least useful amount of data during sweep testing of all the coils because their dwell limiting mechanism quickly tapers off to zero below about 12.5 volts (temperature was also a large factor). I think the data I was able to obtain only amounted to about 40% of the cells in the dwell vs volts vs temp table.

[kur4o]

Can you give more details, how dwell build. How it is looked up and what is the main table and if the map vs rpm is applied and when.

I might try give it a shot with factory dwell settings if I manage to get some useful data for conversion.

The battery is almost new. It reads higher at rest, When I turn on ignition the voltage drops till it reach the pcm for some reason.
I also measured alternator output and it is solid 13.7. I guess it is time to rebuild it again.

[spfautsch]

Look in the zip for a spreadsheet: Proposed Dwell vs Coil Temp.xlsx This will let you convert milliseconds to timer2 ticks.

The simplest explanation of how it works - it's been a while since I've touched the code so some of my details may be slightly off.

The dwell tables are to be considered absolute maximum numbers. In the main loop after a low resolution semaphore has been set and all the interrupts have been handled, the main loop goes to the dwellMain array (defined in *_dwell.h) and grabs the maximum dwell target based on the current voltage and temperature indexes. This is a zero based array so the first row / column is index 0 (zero). This number is the dwell time we're shooting for in blocks of 4 microseconds. The reason for this unit is because it's the interval of the main 16 bit timer/counter. When I add time based failover routines that will take over if the high resolution signal is lost, using this unit for dwell time will allow drop-in logic with no conversion being required.

// D514a dwell vs temp vs volts                             7v    8v    9v   10v   11v   12v   13v   14v   15v   16v   17v
const uint16_t PROGMEM dwellMain[ECT_DIVS][VOLT_DIVS] = {{2620, 2401, 2182, 1950, 1718, 1513, 1250, 1075,  950,  850,  775}, // -20c
                                                         {2645, 2425, 2206, 1974, 1743, 1538, 1275, 1100,  975,  868,  800}, // -10c
                                                         {2706, 2486, 2267, 2048, 1840, 1663, 1313, 1125, 1000,  888,  788}, //   0c
                                                         {2730, 2511, 2291, 2072, 1865, 1688, 1325, 1113, 1000,  875,  800}, //  10c
                                                         {2767, 2547, 2328, 2108, 1901, 1700, 1363, 1125, 1000,  875,  793}, //  20c
                                                         {2803, 2596, 2377, 2157, 1950, 1750, 1413, 1163, 1025,  888,  800}, //  30c
                                                         {2840, 2633, 2413, 2194, 1987, 1788, 1425, 1213, 1038,  900,  800}, //  40c
                                                         {2901, 2706, 2486, 2267, 2060, 1863, 1500, 1288, 1050,  925,  813}, //  50c
                                                         {2998, 2815, 2596, 2377, 2169, 1975, 1613, 1400, 1138,  963,  850}, //  60c
                                                         {3120, 2949, 2730, 2511, 2303, 2113, 1750, 1538, 1213,  975,  875}, //  70c
                                                         {3144, 3096, 2876, 2657, 2450, 2263, 1900, 1688, 1250, 1038,  888}, //  80c
                                                         {3254, 3230, 3010, 2791, 2572, 2388, 2013, 1800, 1375, 1075,  938}, //  90c
                                                         {3352, 3327, 3108, 2888, 2657, 2475, 2100, 1888, 1463, 1113,  950}, // 100c
                                                         {3473, 3425, 3254, 2974, 2742, 2500, 2188, 1975, 1550, 1163,  975}};// 110c

Next the multiplier is grabbed in a similar fashion from the dwellMultTbl array that's defined in map_v_rpm_mult.h. This number is applied to the max dwell exactly like the BLMs or individual cylinder trims in the ecu logic - 128 is a 1.0 multiplier.

The resultant number (max dwell x dwell multiplier) is then converted to crankshaft degrees based on current RPM. This is then used to determine when to start dwelling the next coil.

Does that give you enough to work with?

[kur4o]

That make it clear enough to do some math.

That is what Gm will be targeting for the coils at 14volts.

Volts RPM
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000 6500 7000 7500 8000
14 3.43 3.43 3.41 3.34 3.24 3.13 3.02 2.91 2.80 2.69 2.56 2.44 2.30 2.17 2.04 1.91 1.82

temp multiplier

Volts Deg. C
-40 -25 -10 5 20 35 50 65 80 95 110 125 140 155 170 185 200
14 0.989 0.989 0.989 0.989 0.977 0.962 0.954 0.958 0.962 0.966 0.981 0.985 0.989 0.989 0.989 0.989 0.989

I see the current tables are way off of that.

What I find best as coil response on my test car. Cranking dwell fixed at 7-10ms[based on coil type]. And using stock dwell times. Even slightly off gives some weird response and engine sound.

Now we come to the question. How hard will be to reconfigure the base dwell table to be rpm vs volts. And use the multiplier table for temp vs volts correction.
I can work with the current setup but it will be pain in the ass to dial the volt vs rpm, since it will be multiplier for the base table.

Just for the record. Is the commanded dwell have been compared with actual dwell with some kind of scope.

Now on the interesting part.

How the hell the coils survived.

On the gm chart. at 800 rpm I am looking for 3.42 ms *0.977 at 20*C and *0.962 at 80*C at 14volts
which is 3.32 at 20*C and 3.29ms at 80*C.
I guess these coils are temperature stable and the only correction is made between 20-50 *C with voltage below 12volts.

Looking at the log at 20*C the commanded dwell is 1107*0.004= 4.42 ms
and at 80*C we got almost double 1688*0.004=6.75 with some spikes on higher map upto 2013*0.004=8.052ms.

Now I extracted some data to see what we have at 6000rpm, 95kpa map at 80*C 1688*0.96=6.48192ms at 14volts
while gm targets 2.3*0.962=2.21ms at 6000rpm,14volts

Lets see whats happen at 12volts 2263*0.96*0.004=8.68ms
gm calls for 2.85*0.962=2.74ms.

I think the coils might really get fried on that wot pull, at least the dwell limiter will have suffered, with 20ms crank cycle at 6000rpm it was like almost 50% off-50%on. Getting some off time might help cool them out and recover.

I think we should rework the suggested dwell tables to some stock values and of course keep the max values measured by you for the max output enthusiasts.
Adding some fixed crank target will be awesome too.

I noticed the lookup tables do almost none interpolation between the cells. It takes fixed values from the closest cell. I am not sure if some interpolation is possible and how much burden will put on the processor. Maybe another future idea for improvement. I did notice on my tuning experience that engine don`t like abrupt changes, almost all values have some smoothing and the engine is happy and really smooth on transitions.

[spfautsch]

I will not be rewriting it to change the indexes used for the dwell and compensation tables lookups. It makes absolutely zero sense to do so because in order to measure each unique coil's thermal and electrical characteristics via a sweep test outside a system being propelled by the combustion process, MAP and RPM are phenomenon that do not, cannot, and should not come into play. This is why I was so incredibly confused with why GM structured their tables this way. If there's a logical reason they chose to do this, it eludes my wildest imagination.

This is the reason why, after analyzing the modern tables you were so kind to spoon feed me, I chose to say F-it and spent days worth of lab time and considerable cash outlay gathering my own data that makes sense for a system where we want the coil selection to be the most easily modular component. It's not the absolute best data I could have gathered, but it's what I could afford on a beer budget. This is not a business and never will be. I'm conservatively $1200 in the hole with where this is at - possibly closer to $1800, and that's simply cash outlay that speaks nothing to the amount of damage I've sustained with coding, testing, speeding tickets and the resultant attorney fees, marital discord, etc.

How the hell the coils survived.

On the gm chart. at 800 rpm I am looking for 3.42 ms

Looking at the log at 20*C the commanded dwell is 1107*0.004= 4.42 ms
and at 80*C we got almost double 1688*0.004=6.75 with some spikes on higher map upto 2013*0.004=8.052ms.

I think the coils might really get fried on that wot pull, at least the dwell limiter will have suffered, with 20ms crank cycle at 6000rpm it was like almost 50% off-50%on. Getting some off time might help cool them out and recover.

No, they didn't (melt / get fried / stressed). Because as I've been telling you for year/}s{/, all these coils have integral dwell limiting features. This is why "the hell" they survived. Please stop crying wolf when you're seeing a mouse your brain doesn't recognize as a mouse. If you'd like, I'll go turn one on and dwell it 24x7 until it melts (if it ever does). I'll even do this in my basement so there's a great personal risk involved if it catches the house on fire.

You picked the very worst possible coil to test with. I would have to dig pretty deep back in time to find the test data but as I reiterated just a day or two ago, these coils have a strange dwell limiting system that becomes very difficult to identify on a scope below 12.5 volts, and the temperature skew was also ridiculously pronounced and nonlinear. As such, I was able to observe the least amount of usable data from this coil model compared to the others. But I did the best I could with what I had to work with.

[spfautsch]

It makes absolutely zero sense to do so because in order to measure each unique coil's thermal and electrical characteristics via a sweep test outside a system being propelled by the combustion process, MAP and RPM are phenomenon that do not, cannot, and should not come into play. This is why I was so incredibly confused with why GM structured their tables this way.

Just to more completely explain my position on this, temperature and voltage are variables that primarily (in the case of voltage, strictly) impact the coil's electro-mechancial performance. Another way to explain this is that voltage and temperature are more analogous to environmental parameters. They don't generally change in rapid and direct correlation to instantaneous changes in overall system condition. Relate these to the ecu's barometric corrections.

I chose to use RPM and MAP for the axes of the multiplier table because neither of these directly correlate to a coil's electro-mechanical performance. They're resultant and / or situational parameters that are intended to be used to adjust spark strength to the engine's current power demand / production metrics.

[spfautsch]

Here's the data from the 514a coil I tested

Temp / Volts  8      9      10     11     12     13     14     15      16       17
-20 / -4     n/a    n/a    n/a    n/a    n/a    n/a    n/a    n/a     n/a      n/a
-10 / 14     n/a    n/a    n/a    n/a    6.15   5.10   4.40   3.90    3.47    3.20
0 / 32       n/a    n/a    n/a    n/a    6.70   5.25   4.50   4.00    3.55    3.15
10 / 50      n/a    n/a    n/a    n/a    6.75   5.30   4.45   4.00    3.50    3.20
20 / 68      n/a    n/a    n/a    n/a    6.80   5.45   4.50   4.00    3.50    3.17
30 / 86      n/a    n/a    n/a    n/a    n/a    5.65   4.65   4.10    3.55    3.20
40 / 104     n/a    n/a    n/a    n/a    n/a    5.70   4.85   4.15    3.60    3.20
50 / 122     n/a    n/a    n/a    n/a    n/a    6.00   5.15   4.20    3.70    3.25
60 / 140     n/a    n/a    n/a    n/a    n/a    n/a    5.60   4.55    3.85    3.40
70 / 158     n/a    n/a    n/a    n/a    n/a    n/a    6.15   4.85    3.90    3.50
80 / 176     n/a    n/a    n/a    n/a    n/a    n/a    6.75   5.00    4.15    3.55
90 / 194     n/a    n/a    n/a    n/a    n/a    n/a    7.20   5.50    4.30    3.75
100 / 212    n/a    n/a    n/a    n/a    n/a    n/a    n/a    5.85    4.45    3.80
110 / 230    n/a    n/a    n/a    n/a    n/a    n/a    n/a    6.20    4.65    3.90

It should be clear that a large amount of the primary operating range had to be extrapolated, and I'm certain the extrapolated data is nowhere near accurate. Additionally, as the voltage was reduced below 13 the dwell limiting signature became very difficult to observe, and so I do not place a great deal of faith in the accuracy of the 11 and 12 volt data. This is why I encouraged you to give the engine what makes it happy.

Additionally, the temperature data is only marginally accurate if your coils are mounted directly to the engine in a way that causes them to be heated / cooled by it, and thus remain more or less at coolant temperature. If they're not, interpolating the correct temperature compensation curve is going to be nearly impossible. In this case I would simply populate the entire range above 60c with the data from 60c.

One logical explanation for why GM built their tables this way which I had thought of initially is that it was in order to obfuscate the data to protect it from the aftermarket. I have no interest in playing that sort of game here.

Edit: to address a couple of your other ideas that I didn't read very carefully yesterday:

I do think there's sufficient cpu speed to do some cell interpolation on the dwell target before applying the multiplier.

It's incredibly unlikely you damaged anything electrically with your wot pulls. The coils were seeing that 50% duty cycle for all of a few seconds. It's possible that if they're being grossly over-dwelled that spark strength is suffering simply because the magnetic field begins to dissipate due to how the dwell limiters work on these. It generates a completely different waveform than all the others.

From looking at your comparisons I'd take the max dwell table and multiply it by 0.6 or 0.7. If you want to make the rpm / map multiplier look more like GMs then tone the numbers down in the 70-100 kpa columns and high rpm rows

If you want a lot more dwell during cranking fatten up the 100 and 200 rpm rows in the multiplier table. Hell, max them out. The engine spends an insignificant amount of time running in these cells.

[kur4o]

Some quick update.

After I realized the suggested dwell is alittle too much to my taste and the overall soft feeling of the car, I build a new table from scratch, using some data from Gm calibration.

I fatten the cranking dwell around 8ms, and reduced all other areas to around 2-4 ms based on rpm and temp.

Did some very intense driving, putting the engine in any possible range you can imagine. What I didn`t test yet is heavy WOT with very rapid deceleration.

Overall no issues at all. Wot pulls finally behave like a real cop system. I looked at some old opti logs and compare the 60-125mph times.
The Coils on plug cut roughly 2.3 seconds and at high rpm shifting I can feel the trans is starting to have a very hard time to keep up with the extra torque.
SO FAR, THE BEST BOLT ON MOD I PUT ON THE CAR.

What else I noticed. ALmost any knock retard I got all the time during WOT pulls disappeared, the engine run much cooler on heavy pulls.

To get on the technical stuff. I would really like to test some interpolation between cells on table lookup.

What I also want to discuss is how the lt1 likes the spark. Bigger gap and longer spark duration or less gap and shorter spark duration.
If the cpu can handle it some initial multispark can also make wonders on fuel economy.
It will be something like that main spark, wait minimum amount of time[spark duration]charge 1-2ms second, discharge. It will be weaker spark for sure, so a faster coil is a must.

[spfautsch]

Glad things feel better - this makes me think these coils (and possibly all the "D" models) are getting 10-20% more dwell time than they need. Or in other words the dwell limiting which is what my tables are based on, only comes into play well past ideal dwell. Did your stuttering when blipping the revs up improve with more dwell or less?

When I get the dash buttoned up and can get mine back on the road I'll try to make some time to try some cell interpolation.

Multi-spark shouldn't add significant cpu overhead. Once I have some basic interpolation working I'll start thinking about the simplest way to implement it. Offhand it shouldn't be much of a challenge. I'm just not very optimistic because the OEMs aren't doing it (as far as I'm aware).

[Terminal_Crazy]

Overall no issues at all. Wot pulls finally behave like a real cop system. I looked at some old opti logs and compare the 60-125mph times.
The Coils on plug cut roughly 2.3 seconds and at high rpm shifting I can feel the trans is starting to have a very hard time to keep up with the extra torque.
SO FAR, THE BEST BOLT ON MOD I PUT ON THE CAR.

What else I noticed. ALmost any knock retard I got all the time during WOT pulls disappeared, the engine run much cooler on heavy pulls.

What level of power are you putting down?

TIA
Mitch

[kur4o]

What level of power are you putting down?

TIA
Mitch

Never really measured the output, Just standart stock engine with mods, cam, headers, CAI and other small pieces.
We can use the maf reading to calculate power, but again not sure how acurate is the reading of the maf..
On second wot pull, it reach 320g/s, I remember on first have seen upto 350g/s.


I think lt1 will highly benefit of multispark. Looking at GM they have multispark in code on all 2014+ pcms. Just the tables are zeroed for some reason. Coil not support or no real gain in emissions.

On our rough burning, inefficient combustions and AIR-fuel mixing LT1 engines, multispark might provide better as a secondary burning of what`s left in the cylinder.
Not sure how the coils will like it. That might be the reason GM drop it. Development of highly expensive, exotic coils with faster charging.

I also forget to mention that with beefed up crank dwell the starting feels much faster and healthier.
Still cant` assist for the slight miss on light rapid ,throttle application, I think I am having some fueling issue too. On heavy throttle application at idle, the sound and revving is brutal, compared to old opti revs.

Overcharging the coils definitely leads some other unknown variables into play, reducing total spark output. Some realtime control for the dwell, can gives us the minimum dwell the coils will start to miss, at least on idle and slight reving.

On my test mule with d580 coils I hack the pcm to command custom +- delta dwell to find the lowest you can go. Definitely some good dynamic data can be observed.