DIY LTCC or similar system for LT1s

[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

[spfautsch]

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.

The issue here is that I defined the table with 8 bit cell values in hopes of saving memory, which for unsigned values limits the maximum value to 255 (binary 11111111) = 256. It's not a problem - what I said at the end is I can make the table store each cell in 16 bit 'buckets' and that will fix the clipping - B1111111111111111 = 65536.

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.

I don't want to get lost on a wild goose chase here, but if you can give me a birds-eye-view of what you're wanting to do here or point me to where you explained it / posted info that would help. If I can at least try to wrap my head around what you're needing to do electrically and logically it would help. If I have a handle on what you need to support your goal it will help so that the next round of optimizations doesn't eliminate the possibility of meeting those goals.

Incidentally, ATDC isn't currently tracked, nor is angular velocity at any resolution higher than every 90 degrees. As the code stands now, it counts down from 90 after each TDC (low res rising edge) signal. So 16 ATDC would be 74 degrees BTDC (of the next cylinder).

[vilefly]

I don't want to get lost on a wild goose chase here, but if you can give me a birds-eye-view of what you're wanting to do here or point me to where you explained it / posted info that would help. If I can at least try to wrap my head around what you're needing to do electrically and logically it would help. If I have a handle on what you need to support your goal it will help so that the next round of optimizations doesn't eliminate the possibility of meeting those goals.

Incidentally, ATDC isn't currently tracked, nor is angular velocity at any resolution higher than every 90 degrees. As the code stands now, it counts down from 90 after each TDC (low res rising edge) signal. So 16 ATDC would be 74 degrees BTDC (of the next cylinder).

Well, technically all I need is an output pulse every 16*ATDC (74*BTDC) as a single point of reference for all the cylinders. I will either manually scope or "arduino-scope" the ion sense signal to find out if peak pressure occurs at the right time using a second arduino-pro to do so. Eventually, it may evolve into a closed loop system that can more accurately detect knock as well. It might be worth something to others to make that output timing changeable so that they can enact their own evil plans triggered by this pulse.
ion sense ignition waveform.jpg
ion-sense-ignition.png
The ion-sense power supply/circuitry might change to the Delphi method of capturing the 400v kickback and using it to power up the spark plug, but for now, this is a crude representation that has already worked for me in the past......but my 300v power supply was very noisy last time, and I will see about regulating it and smoothing it out.
delphi ion-sense ignition.jpg

[Terminal_Crazy]

The issue here is that I defined the table with 8 bit cell values in hopes of saving memory, which for unsigned values limits the maximum value to 255 (binary 11111111) = 256.
It's not a problem - what I said at the end is I can make the table store each cell in 16 bit 'buckets' and that will fix the clipping - B1111111111111111 = 65536.

I don't know the chip architecture but I thought i'd read this was speed ctritical.
Is the chip 16 / 32 bit on the data bus?
Is reading a single 8 bit and multiply noticably faster than reading a 16 bit value or not? I don't know.
Older 8 bit micros could take half a dozen cycles to calculate a 16bit no.

Mitch