Bringing TBI and Multi Port Fuel Injection to a New Level.     EFI Conversions and Tuning! Seattle to Portland! E-mail Tuning Consultant!
Page 20 of 20 FirstFirst ... 10151617181920
Results 286 to 293 of 293

Thread: DIY LTCC or similar system for LT1s

  1. #286
    Fuel Injected! vilefly's Avatar
    Join Date
    Sep 2017
    Age
    47
    Posts
    93
    According to my research, peak pressure must occur at 16 deg. ATDC, regardless of stroke, but I do wonder about this with different fuels and such. Might have to play with it, but I have no dynometer.....the researchers had one. Just one thing, it lost the ion sense signal above 3500 rpm. Should still be useful, since racing engines are at max timing 3000rpm and up.

  2. #287
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    178
    Quote Originally Posted by Terminal_Crazy View Post
    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.

    Quote Originally Posted by vilefly View Post
    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).

  3. #288
    Fuel Injected! vilefly's Avatar
    Join Date
    Sep 2017
    Age
    47
    Posts
    93
    Quote Originally Posted by spfautsch View Post
    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
    Last edited by vilefly; 18 Hours Ago at 10:30 PM. Reason: another picture

  4. #289
    Fuel Injected! Terminal_Crazy's Avatar
    Join Date
    Oct 2015
    Location
    Lancashire England
    Posts
    185
    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
    '95 Z28 M6 -Just the odd mod.
    '80 350 A3 C3 Corvette - recent addition.

  5. #290
    Fuel Injected!
    Join Date
    Jan 2012
    Location
    Poland
    Posts
    106
    Glad I could help :)

    Quote Originally Posted by spfautsch View Post
    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:
    Code:
    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.
    Last edited by dzidaV8; 13 Hours Ago at 03:33 AM.

  6. #291
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    178
    Quote Originally Posted by vilefly View Post
    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.
    That's easy enough - I'll add something for this to take over the tach output pin b/c I don't think it will be needed on any of the flash based cars. Or there are four other spare outputs.

    Fair warning, the arduino only has one ADC that uses a multiplexer. The ADC itself is fairly slow to stabilize after you switch the multiplexer input from one analog pin to another. So if you need to look at all eight cylinders in real time it might necessitate 8 AVRs each polling one analog pin.

    Quote Originally Posted by Terminal_Crazy View Post
    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.
    This is 8 bit all the way. You make a valid point. The only math that's happening to this are comparisons and additions. I'll have to look into the instruction set to see how many cycles a 16 bit add consumes. At 16 mhz each cpu tick takes 0.0625 us.

    What really gets ugly is doing floating point operations, which is one of the reasons I didn't try any smoothing / interpolation on table lookups.

    Quote Originally Posted by dzidaV8 View Post
    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.
    I noticed this immediately when I tried accessing the array directly. Oddly I didn't notice anything like this when using a static initializer on my 0.9.6 version, but it's possible I didn't test thoroughly.

    Quote Originally Posted by dzidaV8 View Post
    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:
    Thanks for mentioning this as I probably would have overlooked it. I guess I need to look at the compiler options in arduino and make sure it's not suppressing any. Either way it's nice to have another set of eyes on my work.

    Quote Originally Posted by dzidaV8 View Post
    Without volatile, compiler could optimize out some output pin operations.
    This could explain why my stall detection wasn't turning the coils off.

    Quote Originally Posted by dzidaV8 View Post
    One more thing, of course I mislabelled RPM_TO_MS macro - it should be called RPM_TO_US.
    We won't sweat the small stuff. Also that formula was off by a power of 10. This gives results similar to what the populate routine was outputting.

    Code:
    #define RPM_TO_US(x) (( 250000UL * 60UL / ( x ) ))
    Sunday I found a small rounding error caused by casting the float on the right hand side of the formula into an int.

    Code:
    dwellDegrees = uint16_t (((CRANK_DWELL_TGT + VOLT_COMP_8) * 1000) / (rpmTable[i] / 90));
    This gave more exact results.

    Code:
    dwellDegrees = uint16_t (((CRANK_DWELL_TGT + VOLT_COMP_8) * 1000.0) / (float (rpmTable[i] / 90)) + 0.5);
    What I did to test all these is to convert the populate routines to dump routines so I could see what the mcu was seeing.

    Code:
    dump of rpmTable[RPM_DIVS] = {
      600000,  300000,  200000,  150000,  120000,  100000,  85714,  75000,  37500,  25000,  18750,  15000,  12500,  10714,  9375,  8333,  7500,  6818,  6250,  5769,  5357,  5000,  4687,  4411,  4166,  3947,  3750,  3409,  3125,  2884,  2678,  2500,  2343,  2205 };
    
    dump of dwellTable[RPM_DIVS][VOLT_DIVS] = {
      { 0,  0,  0,  1,  1,  1,  2,  2,  5,  12,  16,  21,  25,  29,  33,  37,  42,  46,  50,  54,  58,  63,  67,  71,  75,  79,  84,  92,  100,  109,  117,  126,  134,  142 },
      { 0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },
      { 0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },
      { 0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },
      { 0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },
      { 0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },
      { 0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },
      { 0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },
      { 0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },
      { 0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 }
    };
    This is what I'm expecting (output of my previous populate routine).

    Code:
    const uint64_t rpmTable[RPM_DIVS] PROGMEM= {
      600000,  300000,  199999,  150000,  119999,  99999,  85714,  75000,  37500,  24999,  18750,  14999,  12499,  10714,  9375,  8333,  7499,  6818,  6249,  5769,  5357,  4999,  4687,  4411,  4166,  3947,  3749,  3409,  3124,  2884,  2678,  2499,  2343,  2205 };
    
    const uint8_t dwellTable[VOLT_DIVS][RPM_DIVS] PROGMEM = {
      { 1,  2,  3,  3,  4,  5,  6,  7,  13,  25,  33,  42,  50,  58,  66,  75,  83,  92,  100,  108,  117,  125,  133,  141,  150,  160,  168,  186,  203,  216,  238,  255,  255,  255 },
      { 1,  1,  2,  3,  4,  4,  5,  6,  11,  22,  29,  36,  43,  50,  58,  65,  72,  80,  87,  94,  102,  109,  115,  122,  130,  140,  146,  162,  176,  188,  207,  222,  231,  250 },
      { 1,  1,  2,  2,  3,  4,  4,  5,  10,  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,  2,  2,  3,  3,  4,  4,  9,  18,  24,  30,  36,  41,  47,  53,  59,  65,  71,  77,  83,  89,  94,  100,  107,  114,  120,  132,  144,  153,  169,  181,  188,  204 },
      { 1,  1,  1,  2,  2,  3,  3,  4,  8,  16,  22,  27,  33,  38,  43,  49,  54,  60,  65,  70,  76,  82,  87,  92,  98,  105,  110,  122,  132,  141,  155,  167,  173,  188 },
      { 1,  1,  1,  2,  2,  3,  3,  4,  7,  16,  21,  26,  31,  36,  41,  47,  52,  57,  62,  67,  73,  78,  83,  88,  93,  100,  105,  116,  126,  134,  148,  159,  165,  179 },
      { 1,  1,  1,  2,  2,  2,  3,  3,  6,  14,  19,  24,  29,  34,  38,  43,  48,  53,  58,  63,  68,  73,  77,  82,  87,  93,  98,  108,  118,  125,  138,  148,  154,  167 },
      { 1,  1,  1,  2,  2,  2,  3,  3,  6,  14,  18,  23,  28,  32,  37,  41,  46,  51,  55,  59,  64,  69,  73,  78,  83,  88,  93,  103,  112,  119,  131,  141,  146,  158 },
      { 1,  1,  1,  1,  2,  2,  2,  3,  6,  13,  17,  22,  26,  30,  35,  39,  43,  48,  52,  56,  61,  65,  69,  73,  78,  84,  88,  97,  106,  113,  124,  133,  138,  150 },
      { 1,  1,  1,  1,  2,  2,  2,  3,  5,  13,  17,  21,  25,  29,  34,  38,  42,  47,  51,  55,  59,  64,  67,  71,  76,  81,  85,  95,  103,  109,  121,  130,  135,  146 }
    };
    I can live without the extra rounding fix, but unless I'm doing something dumb iterating the array it looks like the array is only getting populated in one dimension / subscript.

    In case your'e wondering about the zeros in the first thee cells of the 17v subscript - I had the populate routine artificially rounding those up. But I can change the getDwell() routine to handle turning zeros into ones.

    Snippet of dump routine - sorry, I know it's terrible spaghetti.

    Code:
      // print out the dwell table to uart
      Serial.println("dump of dwellTable[RPM_DIVS][VOLT_DIVS] = {");
      Serial.print("  { ");
      for (int i=0; i<RPM_DIVS; i++) {
        Serial.print(pgm_read_word(&dwellTable[i][0]));
        if (i < RPM_DIVS - 1) Serial.print(",  ");
      }
      Serial.println(" },");
      Serial.print("  { ");
      
      for (int i=0; i<RPM_DIVS; i++) {
        Serial.print(pgm_read_word(&dwellTable[i][1]));
        if (i < RPM_DIVS - 1) Serial.print(",  ");
      }
      Serial.println(" },");

  7. #292
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    178
    Quote Originally Posted by spfautsch View Post
    it looks like the array is only getting populated in one dimension / subscript.
    This is solved. There were too many parens around the fill macro definition.

    Replaced this:
    Code:
    #define FILL_DWELL_COLUMN(rpm) {(((CALC_DWELL(rpm, 8)),  \
                                     (CALC_DWELL(rpm, 9)),  \
                                     (CALC_DWELL(rpm, 10)), \
                                     (CALC_DWELL(rpm, 11)), \
                                     (CALC_DWELL(rpm, 12)), \
                                     (CALC_DWELL(rpm, 13)), \
                                     (CALC_DWELL(rpm, 14)), \
                                     (CALC_DWELL(rpm, 15)), \
                                     (CALC_DWELL(rpm, 16)), \
                                     (CALC_DWELL(rpm, 17))))}
    With this:
    Code:
    #define FILL_DWELL_COLUMN(rpm) { (CALC_DWELL(rpm, 8)), \
                                     (CALC_DWELL(rpm, 9)),  \
                                     (CALC_DWELL(rpm, 10)), \
                                     (CALC_DWELL(rpm, 11)), \
                                     (CALC_DWELL(rpm, 12)), \
                                     (CALC_DWELL(rpm, 13)), \
                                     (CALC_DWELL(rpm, 14)), \
                                     (CALC_DWELL(rpm, 15)), \
                                     (CALC_DWELL(rpm, 16)), \
                                     (CALC_DWELL(rpm, 17))}
    Thanks for this - I'd never in a million years figured out how to do this with the precompiler!

    I just need to convert the accel comp table to using this method and test.

    Found this in arduino/preferences.txt: compiler.warning_level=none Switch none to all and lots of ugliness popped up. Very helpful.

  8. #293
    Fuel Injected! vilefly's Avatar
    Join Date
    Sep 2017
    Age
    47
    Posts
    93
    Quote Originally Posted by spfautsch View Post
    That's easy enough - I'll add something for this to take over the tach output pin b/c I don't think it will be needed on any of the flash based cars. Or there are four other spare outputs.
    I think I will keep the tach output to "arm" the ion sensing circuitry, and the separate 16*BTDC output to disarm/reference it.

Similar Threads

  1. Which TBI system is better?
    By KeyAir in forum GM EFI Systems
    Replies: 39
    Last Post: 01-13-2016, 12:18 PM
  2. Hard start 93 LT1 with LTCC Ignition Mod
    By beestoys in forum GM EFI Systems
    Replies: 0
    Last Post: 05-17-2015, 10:58 PM
  3. ABS system?
    By K1500ss4x4 in forum Gear Heads
    Replies: 3
    Last Post: 02-05-2014, 08:21 PM
  4. Vortec EGR System?
    By EagleMark in forum OBDII Tuning
    Replies: 40
    Last Post: 06-02-2013, 12:07 PM
  5. Quicker way to do Spark Hook test on the street for LT1s and others?
    By sherlock9c1 in forum Fuel Injection Writeups Articles and How to New and Old
    Replies: 15
    Last Post: 03-02-2013, 03:52 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •