DIY LTCC or similar system for LT1s

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

[vilefly]

Yep, I have to agree it is most triumphant, since I was going to ask where the dwell variable was so I could change it for whatever coils I had available.

This will allow me to set up ion sense ignition with 1 degree accuracy. I just need to sift through the code and find the cylinder specific degree counters in it, so I can have the ion sense subsystem target 16 deg. ATDC, or at the very least, tell me hit or miss so I can narrow down the changes I will make in the timing tables. But that, is another project for another thread.

[Terminal_Crazy]

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.

Hi
can you not just scale the values in the table?
I can see the end of the 1st line reads: should be 346.9 which is the highest value ithink in your table.
If you scaled the table by 2 it would allow 512 range of units in 2's.

I don't know how that would affect the lower values.

Or if you need the fine control use values under 128 *1 and over 128 *2

Just a thought.

Mitch

[dzidaV8]

Glad I could help :)

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?

When you place data in program (flash) memory (PROGMEM attribute), you have to inform the code that tries to read it, that the data is in fact in flash, not in RAM. That's why we use pgm_read_xxx functions. Without this, the program would fail as the code would try to read from RAM using FLASH addressing.

Important thing I noticed and changed. There even were warnings about it during compilation. When using pointers to port addresses in "cylinders" structure, you MUST retain the volatile attribute for port addresses:

typedef struct {
  int cylNo;          // user readable cylinder no
  int armed;          // set to 1 = armed for dwell, set to 0 = est signal caught - prevents dwell routine from dwelling recently fired coil
  volatile uint8_t *portAddr;  // used at a pointer to the output registers so coil drivers can be controlled directly (faster than using digital[write/read]() arduino functions)
  byte bitMask;       // the bit mask of each output pin - see the ATmega datasheet for more info on this and timers
} cylinders;

Without volatile, compiler could optimize out some output pin operations.

One more thing, of course I mislabelled RPM_TO_MS macro - it should be called RPM_TO_US.