DIY LTCC or similar system for LT1s

[vilefly]

All this dwell talk can get intimidating. I was wondering....why not adopt the HEI method of dwell control? Set the ignition transistor to shut off @10A peak coil current, using a shunt on the ground side or positive side of all coils to measure current. Have the processor measure the difference between turn on and shut off, and keep it "in mind" for the next event to compensate for any timing error it may cause. A closed loop dwell control. I have been looking up dwell control patents and such. I'll bet this simple analog strategy is what the original ltcc unit employs. Lookup tables could store the learned dwell if you like, this way you could even mix and match individual coils if you had to. Voltage won't cause an error, because it is ignored......just a current reading is all that is required. The only problem I see is with overlapping dwell, in which case, you go with the lookup table.
Will this solve the problem? I hope so, because I like simplicity.

[Joshie225]

The coils GM uses for coil-per-cylinder ignition have dwell limiting built in so there's a hard ceiling on primary current to keep the coil and switching unit from burning up. Adding in coil current measurement would increase complexity in this instance. I do like the targeted-coil-current method as described for the automatic voltage compensation, but with the coils being used it doesn't meet the "more simple" approach.

[vilefly]

The hard current ceiling is coil protection, not coil optimization.
All one would have to do is to run the v+ supply (or ground) to the coils go through the control box first, so it can be monitored with a current shunt or fuse. Not that hard, really. All coils monitored with one simple circuit. This would allow for self diagnostics, with future programming. Even allow for Ion Sensing, if that comes to light. Small price, I say.

[spfautsch]

Will this solve the problem?

I don't feel like this is still a problem needing solved. Even with a fixed dwell target it wasn't that much of a problem, but I wanted to allow for temperature compensation anyway.

What you haven't considered is that the off-the-shelf coils this will drive have vastly different current waveforms than a bare coil with external ICM. It's not as simple as measuring current to a point and then considering it at saturation. Unlike a bare coil, with most of the tests subjects I found current starts out high and tapers off until dwell limiting. It's a neat idea, but not necessarily viable unless you want to build bespoke coils and ICM circuitry.


I've been wanting to drop in with a progress update, but I also don't want to get sidetracked with a million questions and / or suggestions. So I'll keep it brief, and encourage you to keep your suggestions under wraps for the time being. I have a working build that uses two 3d tables for dwell. One is dwell vs coolant temp vs voltage, and the other is a dwell multiplier vs map vs rpm. In rewriting for these features I've identified and fixed a handful of bugs, optimized some code, and revamped the uart routines to allow interaction with the controller while the engine is running (including interactive logging). I was able to get a short test drive in yesterday running this build. As I had anticipated, there are newly created problems to work out. That's all I'm going to tell you for now.

I'm going back to coding on the firmware. Please, no more talk of closed loop spark here unless you're also volunteering to handle the design and coding, and want to buy my stock of printed circuit boards.

[spfautsch]

Brief update - the temperature compensated build with two 3d tables is finally working well. I'm embarrassed to say I'd moved a single line of code without fully thinking through the requirement for the state machine it's used for. That one line's been kicking my backside for the past three weeks.

I'm working out some additional tweaks to logging and polishing up the code base. After that all that remains is to build out base dwell vs temp vs voltage tables for the four remaining coils I have data for. Hoping to get close to an official release over the weekend.

kur4o I have a question relevant to this post from Tom's obd-2 reverse engineering thread (from page 12). I didn't want to spam that thread for something not necessarily relevant to current progress.

Is it possible that tside runs on different frequency. I made some calculations but could`nt get it right. I might be missing something there. The engine run time counter there is known to increase each second but I managed to calculate a 0.8seconds increment. Which doesn`t look correct.

Curious if you uncovered any more info on this. If not, please don't waste a bunch of time doing so, but I'm trying to make timekeeping in the controller firmware match that of the PCM for the purpose of having a way to associate the logging data.

I've never paid very close attention, but for example I noticed this morning that eehack is showing 52.1 minutes of data. By my math that should be around 3126 seconds of runtime, but the last frame of data in the log shows runtime of 3153. Unfortunately I didn't check what the controller had counted, but if my math is correct it should be no more than 8.5ms slow per hour. I'll keep closer track this evening and try to speed up the controller's timekeeping to at least get in the ballpark.

[kur4o]

Curious if you uncovered any more info on this. If not, please don't waste a bunch of time doing so, but I'm trying to make timekeeping in the controller firmware match that of the PCM for the purpose of having a way to associate the logging data.

Didn`t investigate it further, the eside clock is spot on but tside used some other scalar for the system timer and it didn`t matched nice. Some rounding is needed.

Usually you get a increment each second, I will dig out the timers so you can confirm the run time increment.

[spfautsch]

It's not worth going to a bunch of trouble, was just asking in case you figured it out and didn't post any more about it.

I've been looking over old logs, overall the runtime from the datastream is consistently higher than eehack shows for the log time. Obviously there's some skew based on how long eehack is connected vs when the engine is started, but it looks like it's consistently about 30 seconds fast per hour.

Edit: Interesting - on the back of the napkin that works out to 8.333ms error per second and my timekeeping timer is generating a 15.626ms interval. Hmmmm

[kur4o]

I did some more calculations and still can`t get the correct values.

OC4I runs each
317.9ns * 614[ticks] *16[prescaler] =3.12305ms

The engine run timer is updated each 160 cycles
3.12305ms*160=499.688ms
[7c=0] at 499.688ms

We know for sure that engine run time is at 1 second interval. SO something is half off. I guess something with the base frequency or the eclock divisor.

I think only Tom H can shed some lights here.

[spfautsch]

That's still only 0.7ms error per second so yeah - something's off. But don't spend any more resources looking. I figured out a count routine that will give an average 0.992187s interval and that should be close enough for this timer. It's not being used for anything critical. There are two other timers for more important stuff. I'll test it in a few minutes when I head home.

Speaking of timers, I thought of a potential solution for running time based. It's just an idea at the moment but I think it could work by using one of the compare match interrupts for timer1 - the one that measures RPM from low-res pulse.

The impending financial doom and gloom here has spurred my employer to cut 1/3 of the company loose, and though I should be safe for now, anything could happen. I'm hoping to hammer through and get as close to finished as possible with a release candidate this weekend because it will be tough selling the car with an unfinished and experimental ignition system.