Thanks for the update! I wanted to update as well and say I've finally been able to order my coils, and they should be here this week. So best case I may be able to try this sucker out next weekend. Realistically it'll be two weeks. But I have a big list of stuff to fix on the '95, so it's the prime candidate to test this sucker out on for now.
Will keep an eye on this thread!
Thanks for the pictures - it's somewhat irrelevant but the 431 marking means 43[1] where [1] indicates the number of following zeros. So technically those are 430 ohm resistors, and it's very interesting to see 8 on the 411 PCM and 6 on the two V6 PCMs and almost literally be able to trace them directly to the external connector pins. If you can confirm the location of the noise filtering caps being on the chip side of the 430 ohm resistors this indicates the 11124 chip very likely has additional in-line protection resistors, else the outputs would be susceptible to shorting into the discharged caps.Originally Posted by kur4o
I think it's safe to assume this chip's VCC is +5v, so Ohm's law seems to indicate the absolute maximum igniter current these PCMs would be capable of sinking is 5/430=0.011627 or 11.6 milliamps. The 411 in the LS1 applications was driving D580 coils, correct? That seems to indicate the 470 ohm resistor in the diy-ltcc circuit shouldn't be a limitation, nor should the AVR's current sink capability.
Would the V6 applications use a waste spark setup also, or were they coil per cylinder / cop?
Excellent find!
I wish I had your ambition.
I had to order a tpms tool and went ahead and got a replacement LSU4.9 wideband sensor from the big "A". I had a few points built up on my card so I also put a D585 and a D514a coil in the shopping cart. I didn't get Delco / Delphi units due to cost, but these are from AIP Electronics and I've dealt with them in the past and know they stand behind their products. So I should have a couple coils to test later this week.
The coils just arrived today. The number imprinted on the side is 12573190--the coils you thought you had originally, and of course not the ones advertised as the part number in the ad I bought them from because this is eBay and that would just plain make too much sense. In addition while the ad I bought them from says they're Delphi brand, the ad description says they came off a GM engine...and there's no GM stamp on the coil anywhere. In fact the only stamps are a serial number and the part number.
Should I go ahead and return these, or did you want to experiment with the 12573190? I guess I have a set of 8 now, so.
I have one of those ordered from Amazon, but the order has yet to ship so I have no idea when I'll have it in hand. If you want to wait I will test as soon as I get them.
Those could be delphi parts - I have no idea what OE coils look like in that part / body. But the 8183 coils I got had the GM logo molded into the upper rim of the case near the epoxy potting.
Yeah, I saw photos of your coils online with the GM logo molded in.
I’ll go ahead and hang onto these for a bit, I should have a month or so.
Good luck!
It seems like I sounded the alarm bell for nothing.
Coils arrived yesterday - I bought the following pieces branded as AIP Electronics (search for their store on Amazon).
C414 / 21-072018 which is visibly identical to and lists the following as compatible OEM part #s:
12573190 << GM
8125733190
CLS1078
UF414
5C1554
5C1555
C1512
178-8407
E894
D514A << ACD
6737104
GN10165
1788407
CUF414
C262 / 29-300719 which is visibly identical to and lists the following as compatible OEM part #s:
C585
5C1082
UF262
GN10119
D585 << ACD
E254
19005218 << GM
8104577300
C1251
I can post pics if anyone's interested, but other than the AIP logo and part # etched on them they're absolutely identical in appearance to the Delco coils here.
My test bench was driven by my original prototype board using 570 ohm resistors in locations R10-R17. I connected my scope across R13 (coil #7) and measured the waveform while spinning my spare opti base with a drill at around 900 rpm (simulating 1800 at the crank). I did not attempt to determine spark energy and ideal dwell due to lack of time and test equipment.
All three coils (including the 12658183 coils I've been running) produced about 220 mv across R13. So somewhere in the neighborhood of (0.220 / 470 = 0.000468085) 468 microamps (0.468 milliamps) for igniter current. This poses absolutely no problem for the AVR.
After measuring igniter current I warmed up the buggy and then substituted the test coils for #2, running each for a little over 2 minutes. My controller is set to a target dwell of 3.3ms.
The only thing I witnessed worthy of some concern is that the D514a type coils produced a discharge when connecting and disconnecting power to the controller circuit while the coil was still receiving power. The other two did not exhibit this behavior. This shouldn't pose a problem however - in a normal use environment the controller should always be powered by the same circuit that powers the coils.
When I have time to complete my test rig I intend to measure each coil for spark energy vs dwell time, as well as observing how their dwell limiting circuitry behaves. I will probably try to acquire a few more coils for testing, such as the original LS1 D580 coil and possibly others depending on how thin my wallet is at the time.
vilefly the coils you have must be anomalies. At the moment I don't anticipate buying one for testing, but would be happy to give one a shakedown if you wouldn't mind loaning me one.
Edit: additionally, the 470 ohm resistors for R10-R17 should be very close to ideal for their intended purpose - noise dissipation and current limiting. Into a dead short the maximum current drawn through them would be 10.6 milliamps (5v / 470). Adding in approx 4 milliamps for the indicator leds this is well within the AVR's capabilities. In a nutshell even if you were to wire the coils up completely wrong, as long as the high tension side isn't connected to the controller somehow it's highly unlikely anything would sustain damage.
Last edited by spfautsch; 11-23-2019 at 11:47 PM.
Excellent to hear! So what I'm reading is that I don't have to many any changes code-wise or circuit-wise in order to run the coils I have? If so, then that's great. I'm waiting on coil harnesses, then I need to fab up some wiring for the board itself to do things like connecting to the Opti outputs and such. I'll figure out mounting brackets down the line, I'm sure there are plenty of off-the-shelf solutions for that.
Correct. I would at the very minimum customize the voltage divider constants to the measured values. Just be sure you have the uart lines easily accessible so firmware updates can be flashed. I fully intend to try adding table interpolation, possibly misfire detection as well as other goodies in the future.
None that I'm aware of - if you do find some please share with the class. I think the guys selling the 24x conversion kits make brackets for the D585 coils, but they're very proud of their work as well they should be.
I see some good progress here.
Since I haven`t got deep enough in the code I was wondering can we benefit from tuning out some of the stock dwell settings in the PCM. Like zeroing the dwell settings, Do we know if the lag between stock setup and 8 coils conversion is the same. There is some spark adder that is related to lag time. It adds 1 degree every 1200-1500 rpm to compensate for some lag in the ? ICM module or in the opti.
The stock dwell settings are based on multiple variables. Mainly voltage, map and rpm.
The stock dwell settings aren't observed by the controller whatsoever, so there's little point messing with them in the PCM. The controller has it's own dwell table that's similarly compensated on voltage, map and rpm. The only requirement for the EST signal is that it's high for 2 crankshaft degrees before the falling edge, at which time the isr fires the coil for the cylinder on the power stroke.
I'm sure you may be on to something as far as "fine tuning" with the lag compensation, but if the original LTCC module functioned properly without requiring changes to the tune I don't see it as something that should be thought of as necessary. I would be interested in seeing the lookup table for this however - it could make sense to add a similar function in the controller to compensate the start of dwell.
The hardest part will be to confirm that actual spark matches commanded spark by the pcm. Some timing light and crankshaft pulley marking will be needed.
Another viable test will be to run in parallel both opti and 8 coils setup and compare with a scope or visual leds the firing events under different conditions.
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.
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.
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.
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.
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).
Last edited by spfautsch; 11-26-2019 at 04:48 AM.
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.
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:
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.Code:avr-objdump -S /tmp/arduino_build_639568/diy_ltcc_0_9_18.ino.elf > output.txt
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.
If this entire ISR could be optimized in assembly I think I can inline it directly in the source file.Code:*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>
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 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.
Last edited by spfautsch; 11-26-2019 at 08:48 PM.
I am thinking of adding that table, since it doesn`t exist yet.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 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.
Posting Permissions
Reply With Quote
Bookmarks