DIY LTCC or similar system for LT1s

[vilefly]

I am constructing a test bench setup, now that I have my coils, so that I might be able to post some waveforms as I try to follow along. Debating whether or not to dig up a distributor to spool up using a drill/motor or use a signal generator to get my input signals for the system. I suspect I should use the distributor approach to keep reality in the game. Haven't had much time as of late to do anything.

I take it that the MAP sensor input is a prequel to setting up a spark table of some kind in the future. I wonder if there should be some optional code for a 2-bar map sensor. Just divide a regular map sensor reading by 2. This, of course, is not a priority.

I hope to catch up, and provide some help on the matter soon.

[spfautsch]

I'm glad you finally acquired some coils.

My intention with the MAP input is to use it as a trigger for compensating dwell - adding a few degrees with large increases in load (edit: for hotter spark under acceleration). I have no intention of specifically dealing with boosted applications - though it would certainly be possible. The MAP input is just reading the ADC value (0-1023) so some configuration of thresholds will be needed - again the user will be able to specify whatever they want relative to their particular MAP sensor output.

Edit: Just to be clear, there is no version of this that I will produce that includes a spark advance table of any kind. Dwell is a different story.

I haven't had a chance to test or do much work with the controller firmware, as I'm battling a valve that I believe is sticking when hot due to insufficient stem to guide clearance. I also think my clutch friction disk may be bent as it shakes the car so violently at mid-engagement that I'm afraid of busting the bellhousing. I'm not a happy camper thinking that I'm going to have to yank the engine back out to change the friction disk.

Sadly all I can report at the moment is that the circuit design seems to be sound, and that it's starting and running reliably and no codes are being set in the PCM. I've had a few short test drives and no hesitation was experienced. Unfortunately I've made significant changes to the code since the last version that was uploaded to github, and I'd rather not put a flawed version up there until I have a chance to iron out all the issues. As it stands currently there are excessive degree count and dwell lag errors, but my time (not to mention funding) is getting squeezed from all directions and I'm more concerned with getting the mechanical issues sorted out now that the thing runs.

[spfautsch]

Version 0.9.12 uploaded to github (link in sig).

MAP sensing for acceleration compensation is working but needs complete testing as do the ion sense options.

This build starts and runs reliably, but should still be considered highly experimental due to my inability to test extensively. I may have three to four hours of runtime on it with less than an hour of real-word driving. Lots of bugs have been identified and most permanently fixed while others require minor to major rewrites and / or profiling to further determine possible fixes.

There are several "big" issues to iron out - dwell lag (coils being charged late) is still being witnessed sporadically. I think a major rewrite to make dwell a more event-driven function could improve this.

Hoping to have engine back in and running in couple weeks - will likely add a cylinder balance function at that point and then event based dwell and machine code level optimization will be next on the list. Another minor rewrite may be in order to accommodate negative spark timing from the PCM.

[vilefly]

On this page, you will find the EST signal delay time programmed into the ecm.
http://www.gearhead-efi.com/Fuel-Inj...E-xdf-(EEXTRA)

Look at post #5. It says:

"Here's what I have on file.
Hi Jonathon,
This is the EST system time lag and is meant to correct for the latency in the spark system. It is a fixed value in usec:

lag (usec.) = N x 0.08477

Of course since the time lag is a fixed time value the correction in terms of degrees will depend on RPM.
Best regards,
TC "

I believe this should explain the dwell errors you have been experiencing. It could be said that the limitation might be the ecm itself, but should be able to be compensated for in this case. Not sure what "N" represents, though.

[kur4o]

It is basically a scalar to low resolution signal in ms. The lower the low resolution signal[higher rpm] the higher the spark advance added.

I even made a chart with stock setting[too bad I cant find it], how much advance was added. It was something like 1 degree every 1500 rpm.

The added spark is the mystery spark adder at WOT. It represents the difference between main spark table advance and the commanded spark advance. Usually 3-4 degrees at WOT.

[spfautsch]

I believe this should explain the dwell errors you have been experiencing.

I appreciate that you took the initiative to look, but it doesn't explain the dwell lag - this is solely a construct I'm tracking within the controller and has very little to do with spark advance as commanded by the PCM and absolutely nothing to do with PCM commanded dwell. What you mention has to do with the PCM compensating for the switching delay of the old ignition module and such. Not that it couldn't be tweaked to better match the particular coils being used with this setup.

I hate using "for instance" to explain something, but that's probably the best method here. So, say spark advance for the last cylinder firing is stored at 31 degrees within the controller ram. RPM is likewise stored based on the last low res rising edge interval - say for example it equates to 2000 rpm. At a system voltage of 14.4 this resolves to a dwell requirement of 48 degrees for a 4.0 ms target dwell. The dwell lag error statistic is accumulated based on when dwell is actually started for a cylinder versus when it's supposed to. So in this instance dwell for the next cylinder that's going to fire should start dwelling at 79 degrees btdc. Lag is accumulated whenever that happens after 79 degrees - say it starts at 74 that's counted as 5 degrees of lag. I keep track of this in a global variable and reset it every N engine revolutions (currently 10). I really need to profile the code execution to get a better picture of what's going on here that's causing lag - interrupts firing take precedence over code running in the arduino "loop()", where the dwellCoils routine is called from. I've also discovered how to allow portions of the ISRs (interrupt service routines) to "nest" so code with lower priority can be stored on the accumulator (i think that's the correct terminology) and executed after all other higher priority ISR code. Another way to do it would be to calculate the degree where the next cylinder needs to start dwelling after each tdc signal, and then call the dwellCoils() routine from the high res / degree countdown ISR, at that particular degree count. This is probably the "right" way to do this, but it get's a little sticky when the coil that needs to be dwelled is three combustion events away, and I just haven't put the thought into doing it this way and keeping all the possible pitfalls in focus.

To put it in perspective, from the standpoint of writing event driven code for a mcu, I've just mastered walking slowly. Now I need to learn how to tie my own shoes. At the end of this I hope to be able to drive to the store and buy more shoes. I'd love it if somebody who already has their license and a car would swoop in and take on these tasks so I can concentrate on making a pcb, but oh well.

Back to the state of things - don't read too much into this lag figure. My concern may be overstated - I'd like to have everything as perfect as it can be, but in reality that's rarely how it works out. It could very well be "good enough for government work" as it currently stands. I simply haven't had a chance to focus on the ignition system because of all the mechanical issues. Edit: so just to clarify, were you to build out your own prototype and do as I have and gutted the high voltage side of your optispark, I can tell you with 99% certainty that you would be able to start and drive it within the confines of the OE rev limiter, and probably not be able to tell a difference. Unfortunately (for me) I've learned the hard (and rather expensive) way that not all optispark pickups are built the same. My older AIP sensor behaved completely different from what the new one does.

Since I found such a large difference between the noise floor on the low res line after getting the engine back in, I'm seeing far more instances of degree count errors - where the count from 90 down to 0 between tdc signals doesn't end at 0. I suspect this is because the noise rejection circuitry on the capture interrupt for the HR signal is adding 4 cpu cycles worth of delay after considering a rising edge "not noise". Because of this I think it makes sense to track an average of the degree count error and add a few degrees to the stored spark advance as a function of that.

[vilefly]

Ah. Well, I stumbled across that post while still trying to catch up on my learning curve, which is still lagging behind. Wish I found the forum years before, when I was still burning chips with now outdated software. Still have my Pocket Programmer eprom burner and its original DOS program disk, heh. Back then, the new LT-1 didn't exist. Crap, I'm getting old.
On the bright side, I still haven't woke up with my underwear destroyed.

[spfautsch]

Wanted to drop in an update since getting things put back together again. I'm still battling valve noise, so I'm probably going to have to yank the even bank cylinder head off again. This has significantly hampered my ability to make progress with the controller firmware. Because I'm scared to run the car too much testing has been very limited and I haven't even been logging data but merely feeling and listening (mainly for valve noise). I do occasionally hear a stumble or misfire, but nothing I can reproduce consistently. Overall it runs well and throttle response is nearly as good as before the tune changes to compensate for cam timing.

I did have a chance to download and start learning how to use Eagle a couple weeks ago. This looks like a project in and of itself (designing a pcb). I'm going to be on vacation next week and hope to spend some of my down time working on converting the schematic to Eagle and possibly starting on a board layout.