DIY LTCC or similar system for LT1s

[spfautsch]

Last night I put waterproof connectors on my prototype's pigtails and it's ready to go in the car after I seal the case with some silicone. In finishing all this I wanted to test out the extra input I wired for the MAP sensor. I'm happy to report that it looks like manually interfacing to the ADC section of the microcontroller yielded much more reliable and faster results than I had using the arduino analogRead() function with other projects using multiple analog inputs. Unless there's some other unforeseen issue I think this will work very well. And since I retooled the code to eliminate floating point math pretty much everywhere, I built a bash script to convert the raw datastream to human readable values (voltage and rpm, map will follow).

pic1
pic2
pic3
pic4

Getting to this milestone, I have to ask kur4o if he might be able to pick apart the portions of the $ee program pertinent to how MAP effects dwell and explain it in laymen's terms. I'm sure anything I come up with for this will be better than no dwell compensation, but I'd like to utilize this additional input's data in the most efficient way possible.

I'm jonesing for an email from Lloyd telling me my heads are on their way back. In the mean time I'll try to finish the schematic and see what options there are for pcb design. I found this on Monday, but haven't gotten as far as building it or trying it out.

[kur4o]

So are you adding second map sensor or using the stock one with shared wire. First check for interference between PCM and arduino. Maybe some isolation will be needed.
What I remember it uses some delta map value to find out when the engine was accel and decel mode. The dwell was added only in accel mode. I will dig through it more thoroughly and write back shortly.

[spfautsch]

The intention was shared wire to the factory map sensor. The ADC inputs on the arduino are fairly high impedance (100M ohm) and using the internal reference voltage will give 0-5v range so no voltage divider will be needed. I don't anticipate a problem doing this, but I will test by disconnecting the map wire from the controller while running and observing if the PCM is reporting a change.

By delta are you saying it stores the most recent map value in a variable and then compares the next reading to the stored one? That sounds simple enough. I'll probably want a deadband around the stored delta value or use some hysteresis logic to prevent oscillation.

[spfautsch]

After pulling most of what little hair I have left out, I'm happy to report it's finally running again.

Spent the last two weeks beating my head against a wall trying to figure out why I was getting noise on the low res input. Since everything important has changed - new opti pickup, major wiring harness revision, prototype controller board - there were plenty of variables to weed out. I'm still not sure, but I think the optical sensor had the biggest effect. In the end I found that some of the input capture code I used for the timer that measures rpm via the low res signal had some problems that were disabling the noise canceling section of the timer. One line of code was the difference between starting and stalling immediately, and running.

The map sense line appears to work without affecting the PCM's analog input. Also the major code revision removing all the voltage and rpm conversions to human readable values (thus eliminating the floating point math burden from the mcu) seems to work fine. I hope to test another version tomorrow that gives 4us instead of 16us timer ticks for rpm tracking which should give better resolution there. Also hoping to get a test drive in to see if there are any signs of hesitation like the initial test drive.

There's still a bunch of code cleanup and optimization to do, and I still haven't had a chance to finish the schematic or put any effort into designing a pcb. Even worse, I have to reverse some of the changes I made to the prototype board trying to eliminate possible sources of noise so I can verify the entire circuit works as designed.

[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.