DIY LTCC or similar system for LT1s

[spfautsch]

The last stable version is 4.7. I am working on some version labeled 4.9 but is far from ready. Anyway my improvement will be only on added mode 4 controls and some clean up of the patches.

Thanks for the explanation. I'd seen mention of 4.9 in your patches thread and wasn't sure what was going on.

Quick question for you or anyone that might know - I'm relatively sure there aren't any calibrations that call for it, but is it possible for the PCM to command negative (atdc) spark timing? I'm thinking about how to implement some self-diagnostics, and wondered if atdc timing was a possibility for the EST signal.

Lastly wanted to update that I started it four times today, the first round the ECT was at 10c / 50f and it fired right off as did the three subsequent times. I think my longer cranking times were mostly a side effect of my battery getting ready to roll over dead on me. I did have a particularly long crank last night that I'm sure wasn't imagined, but I probably caused that when I yanked the injector fuses to simulate a stall. Ambient was also easily 6c / 10f colder.

[vilefly]

Quick question for you or anyone that might know - I'm relatively sure there aren't any calibrations that call for it, but is it possible for the PCM to command negative (atdc) spark timing? I'm thinking about how to implement some self-diagnostics, and wondered if atdc timing was a possibility for the EST signal.

I think when the ABS is triggered, the ignition timing could be retarded that far, but I have no proof. Would have to scope/datalog during an ABS stop. If it were a chrysler, it would happen between shifts, but not in the case of a 90s chevy.
Interesting question. Did you have some kind of misfire detection based on a second spark strike attempt by the ecm in mind?

I do know that most misfire detection is based on degrees of crankshaft acceleration after spark. (deg/second,etc)
I might have an opportunity tomorrow to scope a 2010 chevy truck ignition "fire" signal to a coil. What I am looking for is feedback or no feedback on the line. Some coil drivers provide feedback on the "fire" line, with a magnitude of 5v max, which allows the "burn time" from the secondary side to be measured and compared to the rest off the cylinders.

[spfautsch]

I think when the ABS is triggered

Good thinking - I didn't realize ABS used torque limiting but that got me thinking about ASR. I took a look at the traction control table and I think it's possible to have a condition where negative spark advance could be commanded.

Can anyone confirm the correct scalar for the 0x123A1 table? I have some xdfs with (0.062500 * X) and some with (0.250000 * X). If 0.0625 is correct there are only a few essentially "unreal" load ranges where negative timing might be commanded such as at 400 rpm and 100 map. If the other one's right there's a significant range.

Did you have some kind of misfire detection based on a second spark strike attempt by the ecm in mind?

Sorry, nothing quite that ambitious. In it's current state I would characterize the maturity of the code as "nearly mastered crawling". I merely want to add some minimal failsafe logic so if the controller doesn't see a signal on the EST line in x amount of degrees it considers it a system fault and shuts everything down. That way if the EST circuit does happen to get broken it doesn't dwell more coils than the IGN circuit fuse can tolerate. Additionally, I didn't account for the possibility of negative spark advance so it could cause unexpected behavior if the PCM were to command it.

[kur4o]

Can anyone confirm the correct scalar for the 0x123A1 table? I have some xdfs with (0.062500 * X) and some with (0.250000 * X).
Additionally, I didn't account for the possibility of negative spark advance so it could cause unexpected behavior if the PCM were to command it.

The correct conversion is x*0.25.
I am still exploring the possibility of the PCM to command negative spark.
It converts degrees to some {90-sparkadv}+some high resolution counter. The result is transfered to TPU where dwell is substracted[dwell might be converted to some high res degrees too}

Spark advance is positive value above 0. When you need retard below 0 it goes to FF for -1 and is counted backwards from FF. How is that transferes to TPU in degrees is still unclear.
Some logs of the high res counter can give some hints.

If you use 180 degree reference instead of 90 degree might be better for negative spark. 90 will be midpoint or 0 degree advance.

[spfautsch]

The correct conversion is x*0.25.

Thanks for confirming.

If you use 180 degree reference instead of 90 degree might be better for negative spark. 90 will be midpoint or 0 degree advance.

I can always use a signed integer typing on this to handle ATDC counts. But accounting for negative timing would require the program to track the high res counter on two cylinders - the one that's recently passed TDC and the one approaching TDC. Not impossible, just another added layer of complexity.

I'm thinking about trying to use the DFCO retard at 0x128C3 set at some ridiculously high # like 120 and then logging to see if it causes negative commanded spark. My sequencing state machine was built with the assumption the PCM was incapable of commanding negative timing. I'm going to go over some of my old log data first just to be sure, but I don't recall offhand seeing a negative or anything strange like wraparound #s here (255 = -1).


To update other progress, I've moved the populate<table>() functions to conditional - when enabled they now generate static initializers for these arrays that can be pasted into the source to reduce startup time and ram requirements. I also changed the main dwell table to a two dimensional array so the initializer is easier to read. Added an accel compensation table also to give a dwell adder when RPMs are trending higher.

I'm currently working on tidying up a few other things and will try to upload the current build to github later today.

DigiKey shipment came yesterday and I was able to test and confirm the values of R3 and R4 work to prevent the EST line DTCs. I may try a 2.4k ohm for R4 because the diagnostic ADC channel was reading 205-206 (about 4 volts) with 5.6k / 2.2k.

I also spotted an error on the schematic posted earlier - the 4.7k pull-down resistor on the hi-res input should be a pull-up (connected to vcc instead of ground). Will try to post an updated version soon.

[dzidaV8]

There you go, I tweaked the code a bit, but I don't have the arduino at hand to try and debug it, so no guarantees here.

[spfautsch]

Thanks, is really good stuff! A little difficult for me to read but that's my shortcoming, and one that is completely dwarfed by how the compiler is handling the math for the table generation. Very cool.

I'd like to incorporate most of your changes but I've made a few significant changes myself so I'll have to spend some time combining these. I'll upload 0.9.6 to github after I can test tonight but it may be several days before I can get these two merged.

Quick question - it should probably be obvious but why are you using these read functions 'pgm_read_word(&rpmReference[rpmIndex])' to read the table cells?

One of the issues I found was an oversight on my part to use the correct typing in the microseconds to degrees calculation. When I fixed it I found a notable amount of "clipping" on the higher rpm, lower voltage (upper right in this illustration) corner of the dwell table when I used dwell data for the LS1 / D580 coils.

// for ls1 / D580 coils
#define DWELL_TGT 6.1       // dwell target in milliseconds - edit to your liking
#define CRANK_DWELL_TGT 3.6 // dwell target for cranking / startup
#define ACCEL_COMP 0.6      // for accell comp table

const uint8_t PROGMEM dwellTable[VOLT_DIVS][RPM_DIVS] = {
  { 1,  2,  3,  4,  5,  5,  6,  7,  14,  31,  41,  51,  62,  71,  82,  92,  102,  113,  123,  133,  144,  155,  163,  173,  185,  198,  207,  230,  250,  255,  255,  255,  255,  255 }, << last cell should be 346.9
  { 1,  2,  2,  3,  4,  5,  5,  6,  12,  27,  37,  46,  55,  64,  73,  83,  92,  101,  110,  119,  129,  138,  146,  155,  165,  177,  185,  205,  224,  238,  255,  255,  255,  255 },
  { 1,  1,  2,  3,  3,  4,  5,  5,  11,  25,  34,  42,  51,  59,  67,  76,  84,  93,  101,  109,  119,  127,  135,  143,  152,  163,  171,  189,  206,  219,  241,  255,  255,  255 },
  { 1,  1,  2,  2,  3,  4,  4,  5,  10,  23,  31,  39,  47,  55,  63,  71,  78,  87,  94,  102,  110,  118,  125,  133,  141,  151,  159,  176,  191,  203,  224,  241,  250,  255 }, << last cell should be 265.3
  { 1,  1,  2,  2,  3,  3,  4,  4,  9,  22,  29,  37,  44,  51,  59,  66,  73,  81,  88,  95,  103,  111,  117,  124,  133,  142,  149,  165,  179,  191,  210,  226,  235,  254 },
  { 1,  1,  2,  2,  3,  3,  4,  4,  8,  21,  28,  36,  43,  50,  57,  64,  71,  79,  86,  92,  100,  107,  113,  120,  128,  137,  144,  159,  174,  184,  203,  219,  227,  246 },
  { 1,  1,  1,  2,  2,  3,  3,  4,  7,  20,  27,  34,  41,  47,  54,  61,  67,  75,  81,  88,  95,  102,  108,  114,  122,  130,  137,  151,  165,  175,  193,  207,  215,  233 },
  { 1,  1,  1,  2,  2,  3,  3,  3,  7,  19,  26,  33,  39,  45,  52,  59,  65,  72,  78,  84,  92,  98,  104,  110,  117,  126,  132,  146,  159,  169,  186,  200,  208,  225 },
  { 1,  1,  1,  2,  2,  2,  3,  3,  6,  19,  25,  31,  38,  44,  50,  57,  63,  69,  75,  81,  88,  95,  100,  106,  113,  121,  127,  141,  153,  163,  179,  193,  200,  217 },
  { 1,  1,  1,  2,  2,  2,  3,  3,  6,  18,  25,  31,  37,  43,  49,  55,  61,  68,  74,  80,  86,  93,  98,  104,  111,  119,  124,  138,  150,  159,  176,  189,  196,  213 }
};

I was starting to think this wasn't worth doing correctly because these are some fairly dumb operating ranges (< 10.49 volts, > 5600 rpm), but making the dwell table a 16 bit uint only uses another ~300 bytes of flash but I've also found a few things I can optimize and a few routines that can be eliminated so it will only cost a hundred bytes or so.