Bringing TBI and Multi Port Fuel Injection to a New Level.     EFI Conversions and Tuning! Seattle to Portland! E-mail Tuning Consultant!
Page 19 of 25 FirstFirst ... 91415161718192021222324 ... LastLast
Results 271 to 285 of 366

Thread: DIY LTCC or similar system for LT1s

  1. #271
    Fuel Injected!
    Join Date
    Jan 2012
    Location
    Poland
    Posts
    111
    I see your point with the DIY-friendly side of Arduino, and probably can agree. You are also right not to make this topic a discussion about pros and cons of different IDEs, so I won't. I just couldn't have helped myself to make that point. :)
    I'll work on your code to move more work on precompiler and clean up the lookups when I'll find some spare time.

  2. #272
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    239
    Just so I'm understanding, you're saying you can build precompiler directives that will perform the function of the populate routines so users can edit the following macro definitions / constants and end up with a custom dwell table?

    Code:
    #define DWELL_TGT 4.5       // dwell target in milliseconds - edit to your liking (using 4.5ms for standard ls2 coils)
    #define CRANK_DWELL_TGT 3.2 // dwell target for cranking / startup
    
    #define VOLT_COMP_8 2.4     // adds / subtracts from dwell target at given input voltage
    #define VOLT_COMP_9 1.5
    #define VOLT_COMP_10 0.9
    #define VOLT_COMP_11 0.4
    #define VOLT_COMP_13 -0.2
    #define VOLT_COMP_14 -0.4
    #define VOLT_COMP_15 -0.7
    #define VOLT_COMP_16 -0.9
    #define VOLT_COMP_17 -1.0
    Or are you talking about making the tables statically initialized variables like the RPM table?

    Code:
    int rpmReference[RPM_DIVS] = { 25, 50, 75, 100, 125, 150, 175, 200, // the rpm reference
      400, 600, 800, 1000, 1200, 1400, 1600, 1800, 2000, 2200, 2400, 2600, 2800, 
      3000, 3200, 3400, 3600, 3800, 4000, 4400, 4800, 5200, 5600, 6000, 6400, 6800 };
    Also, I'm always a proponent of optimizing code but flash and memory resources aren't in short supply at this point.

    Code:
    Sketch uses 9816 bytes (31%) of program storage space. Maximum is 30720 bytes.
    Global variables use 1013 bytes (49%) of dynamic memory, leaving 1035 bytes for local variables. Maximum is 2048 bytes.
    Lastly, I don't see a point in trying to run this on a lesser mcu. This isn't a project focused on profitability, so saving a dollar or two on the mcu only to limit what can be added in the future seems counter productive. One of the reasons I developed a fondness for the adafruit clones is because they developed a bootloader mod that allows no-wait program startup while maintaining the ability to flash the chip over uart hands-off. This is important - I want the user to be able to update the firmware easily in the same way they can tune flash based PCMs. I also want it to be easily customizable, even if that means something as trivial as the end user printing their name or VIN # to uart on startup.

    Latest changes tested and uploaded. Link to github repo is in my signature.

  3. #273
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    239
    Partial schematic interfacing to an Arduino compatible device. Sorry for the bunching on the input side, I'm still learning how to use this drawing soft.

    Wire colors on the input side are only confirmed on the Y chassis code. Others may use different colors.

    EDIT: schematic removed - will upload to github - see link in sig

    The LED + limiting resistor on pin 13 are usually present on all Arduino-like devices so I didn't number them. My ultimate goal is to develop a complete schematic and turn that into a single plane PCB with the Atmega (28 pin dip) directly onboard instead of using the Arduino device as a "daughter board". If that works out maybe we can arrange a group buy for a large quantity.

    I'm hoping it's obvious, but just to be safe the the ancillary output circuitry on pin 4 (coil #1) needs to be duplicated for the other 7 cylinders.

    Edit: R3 and R4 (the famous impedance matching network) is an approximation of potentiometer measurements from this post that produced ~4.29 volts on the EST line's diagnostic ADC channel. Testing and possible fine-tuning may be required (I can't find a 5.6k resistor in my substantial collection of "stuff").

    Attached Images Attached Images

  4. #274
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    239
    Quote Originally Posted by kur4o View Post
    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.

  5. #275
    Fuel Injected! vilefly's Avatar
    Join Date
    Sep 2017
    Age
    47
    Posts
    111
    Quote Originally Posted by spfautsch View Post
    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.
    Last edited by vilefly; 01-18-2018 at 06:43 PM. Reason: another theory

  6. #276
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    239
    Quote Originally Posted by vilefly View Post
    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.

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

  7. #277
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    239
    Quote Originally Posted by dzidaV8 View Post
    I'll work on your code to move more work on precompiler...
    Relative to my question in post #272, if the dwell tables can't be dynamically generated by precompiler directives - the idea crossed my mind of creating another conditional mode of operation to generate the initializers could be a better solution. That way the user could set the compiler directive and customize their dwell targets. Then when the mcu boots in this config mode the populate functions would spit out their customized tables to the uart as static initializers to be pasted directly into the source. That would eliminate the populate functions from being run at bootup in normal mode, shortening start time by 10ms or so, as well as alleviating the need to create yet another external spreadsheet tool to generate the tables.

    If I don't hear from you I'm going to code toward that goal as it's a very simple change.

  8. #278
    Fuel Injected! vilefly's Avatar
    Join Date
    Sep 2017
    Age
    47
    Posts
    111
    This is the coil trigger signal from a 2010 5.3L silverado, no open circuits. So technically, we only know that it pulls down to exactly 4V, not sure what open circuit voltage is, due to a lack of time at the end of a friday....so I didn't think to do so...damnit. This engine uses the barrel shaped coils like spfautsch used in his videos.

    2010 silerado ign trigger.jpg

    So there is no feedback on that signal line to worry about when it comes to this type of coil.
    I will venture a guess that a 5V signal suffers a 1v-.8v semiconductor based voltage drop on one leg of a transistor tied to ground.
    Last edited by vilefly; 01-19-2018 at 08:10 PM. Reason: more theory

  9. #279
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    406
    Quote Originally Posted by spfautsch View Post
    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.

  10. #280
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    239
    Quote Originally Posted by kur4o View Post
    The correct conversion is x*0.25.
    Thanks for confirming.

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

  11. #281
    Fuel Injected!
    Join Date
    Jan 2012
    Location
    Poland
    Posts
    111
    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.
    Attached Files Attached Files

  12. #282
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    239
    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.

    Code:
    // 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.

  13. #283
    Fuel Injected! vilefly's Avatar
    Join Date
    Sep 2017
    Age
    47
    Posts
    111
    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.

  14. #284
    Fuel Injected! Terminal_Crazy's Avatar
    Join Date
    Oct 2015
    Location
    Lancashire England
    Posts
    206
    Quote Originally Posted by spfautsch View Post
    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.

    Code:
    // 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
    '95 Z28 M6 -Just the odd mod.
    '80 350 A3 C3 Corvette - recent addition.

  15. #285
    Fuel Injected! Terminal_Crazy's Avatar
    Join Date
    Oct 2015
    Location
    Lancashire England
    Posts
    206
    Quote Originally Posted by vilefly View Post
    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.
    Now that does sound cool!
    OOI is that value the same for both banks (I presume 350 chevy) and would that change if the stroke is altered?

    Mitch
    '95 Z28 M6 -Just the odd mod.
    '80 350 A3 C3 Corvette - recent addition.

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
  •