Page 41 of 55 FirstFirst ... 31363738394041424344454651 ... LastLast
Results 601 to 615 of 825

Thread: DIY LTCC or similar system for LT1s

  1. #601
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Good info, thanks for posting.

    Quote Originally Posted by kur4o View Post
    ... since it is dot welded to the base on my unit.
    That's unfortunate. I hope you can get it off without destroying it. Speaking from experience it's very difficult to get whatever stainless alloy they used for these to relax once it's been wrinkled even slightly.

    Quote Originally Posted by kur4o View Post
    So the dtr is used only for firmware updates, For normal use can I leave it disconnected.
    Correct - the DTR line is used to pull the AVR's reset pin low so the programming utility (avrdude) can access the bootloader to upload to the flash.

    Quote Originally Posted by kur4o View Post
    Why not use the high voltage side to ground a pin on #1 to the avr.
    I'm not sure how you're going to get a clean signal from the rotor to one of the cap electrodes - isn't there an air gap between them? Or were you thinking of rigging a hall effect sensor in there?

    Quote Originally Posted by kur4o View Post
    Time based is freaking hard to imagine and a feat to get it done
    I've been bouncing ideas around on how to accomplish time based dwell. I never said it was impossible. It may not even be particularly difficult, I just haven't had the proverbial light bulb come on with an elegant method to implement multiplexing one timer that handles all 8 coils, tracks spark advance (as well as ATDC spark timing), and overlap. The high res timer I'm currently using is just a simple counter timer that runs at a pre-determined divisor of the system clock - 1/64th of 16mhz at the moment. This timer uses a capture interrupt tied to the low res input for a trigger to measure engine speed between the TDC edge signals. There are also two compare registers available with interrupts that can be used with this timer, for instance to initiate dwell. But I'm trying to keep the ideas for this on the far back burner at the moment because I don't want to get too distracted.

    I'm currently working on building out the dwell table logic, and I want to get this milestone figured out before moving on. I think the dwell tables will store desired time in a single byte, 0-255. A fixed scalar of 0.048828125 will convert the desired dwell from milliseconds to the raw table value. This gives a maximum of 12.5 ms dwell before MAP and RPM multipliers. I think this will be adequate for all real-world scenarios for all the coils I've tested.

  2. #602
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    I'm currently working on building out the dwell table logic, and I want to get this milestone figured out before moving on. I think the dwell tables will store desired time in a single byte, 0-255. A fixed scalar of 0.048828125 will convert the desired dwell from milliseconds to the raw table value. This gives a maximum of 12.5 ms dwell before MAP and RPM multipliers. I think this will be adequate for all real-world scenarios for all the coils I've tested.
    That`s exactly what I did to get a higher resolution from 8bits tables and the idea was borrowed from the prime pulse math. The scalar defines the resolution of the 8bit table. So with this setup a 0.048ms resolution can be used. If you don`t need that precision increasing the scalar is an option. On starting conditions a fixed adder can be added to the final dwell, I guess anything over total of 20ms dwell will be too much. I am getting really good with 8 bit tables and conversions. I managed to rescale the ign voltage to 1volt increment for table lookup. I am sure 8bit hex math will be much more precise, efficient and simple to implement. I will try to help as much as I can.


    I found more links with opti internals, There a bunch more of a varieties than I thought.

    link1
    and link2 taken from link1. Some foreign language there but great pictures and some components p/n with opti schematic.

    I didn`t expect the gap is that big between rotor and cap. It is upto you to evolve the idea for sequence detection from high voltage side.

    link2 translated
    https://translate.google.com/transla...5D0%25B0%2F%26
    Last edited by kur4o; 02-20-2020 at 03:41 AM.

  3. #603
    Fuel Injected! vilefly's Avatar
    Join Date
    Sep 2017
    Age
    53
    Posts
    217


    All this dwell talk can get intimidating. I was wondering....why not adopt the HEI method of dwell control? Set the ignition transistor to shut off @10A peak coil current, using a shunt on the ground side or positive side of all coils to measure current. Have the processor measure the difference between turn on and shut off, and keep it "in mind" for the next event to compensate for any timing error it may cause. A closed loop dwell control. I have been looking up dwell control patents and such. I'll bet this simple analog strategy is what the original ltcc unit employs. Lookup tables could store the learned dwell if you like, this way you could even mix and match individual coils if you had to. Voltage won't cause an error, because it is ignored......just a current reading is all that is required. The only problem I see is with overlapping dwell, in which case, you go with the lookup table.
    Will this solve the problem? I hope so, because I like simplicity.
    Last edited by vilefly; 02-29-2020 at 05:33 PM.

  4. #604
    Fuel Injected!
    Join Date
    May 2019
    Location
    Vancouver, WA
    Posts
    24
    The coils GM uses for coil-per-cylinder ignition have dwell limiting built in so there's a hard ceiling on primary current to keep the coil and switching unit from burning up. Adding in coil current measurement would increase complexity in this instance. I do like the targeted-coil-current method as described for the automatic voltage compensation, but with the coils being used it doesn't meet the "more simple" approach.
    Joshua
    1994 Corvette, 6MT, Z07

  5. #605
    Fuel Injected! vilefly's Avatar
    Join Date
    Sep 2017
    Age
    53
    Posts
    217
    The hard current ceiling is coil protection, not coil optimization.
    All one would have to do is to run the v+ supply (or ground) to the coils go through the control box first, so it can be monitored with a current shunt or fuse. Not that hard, really. All coils monitored with one simple circuit. This would allow for self diagnostics, with future programming. Even allow for Ion Sensing, if that comes to light. Small price, I say.
    Last edited by vilefly; 02-29-2020 at 09:53 PM. Reason: more ideas.

  6. #606
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Quote Originally Posted by vilefly View Post
    Will this solve the problem?
    I don't feel like this is still a problem needing solved. Even with a fixed dwell target it wasn't that much of a problem, but I wanted to allow for temperature compensation anyway.

    What you haven't considered is that the off-the-shelf coils this will drive have vastly different current waveforms than a bare coil with external ICM. It's not as simple as measuring current to a point and then considering it at saturation. Unlike a bare coil, with most of the tests subjects I found current starts out high and tapers off until dwell limiting. It's a neat idea, but not necessarily viable unless you want to build bespoke coils and ICM circuitry.


    I've been wanting to drop in with a progress update, but I also don't want to get sidetracked with a million questions and / or suggestions. So I'll keep it brief, and encourage you to keep your suggestions under wraps for the time being. I have a working build that uses two 3d tables for dwell. One is dwell vs coolant temp vs voltage, and the other is a dwell multiplier vs map vs rpm. In rewriting for these features I've identified and fixed a handful of bugs, optimized some code, and revamped the uart routines to allow interaction with the controller while the engine is running (including interactive logging). I was able to get a short test drive in yesterday running this build. As I had anticipated, there are newly created problems to work out. That's all I'm going to tell you for now.

    I'm going back to coding on the firmware. Please, no more talk of closed loop spark here unless you're also volunteering to handle the design and coding, and want to buy my stock of printed circuit boards.

  7. #607
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Brief update - the temperature compensated build with two 3d tables is finally working well. I'm embarrassed to say I'd moved a single line of code without fully thinking through the requirement for the state machine it's used for. That one line's been kicking my backside for the past three weeks.

    I'm working out some additional tweaks to logging and polishing up the code base. After that all that remains is to build out base dwell vs temp vs voltage tables for the four remaining coils I have data for. Hoping to get close to an official release over the weekend.

    kur4o I have a question relevant to this post from Tom's obd-2 reverse engineering thread (from page 12). I didn't want to spam that thread for something not necessarily relevant to current progress.

    Quote Originally Posted by kur4o View Post
    Is it possible that tside runs on different frequency. I made some calculations but could`nt get it right. I might be missing something there. The engine run time counter there is known to increase each second but I managed to calculate a 0.8seconds increment. Which doesn`t look correct.
    Curious if you uncovered any more info on this. If not, please don't waste a bunch of time doing so, but I'm trying to make timekeeping in the controller firmware match that of the PCM for the purpose of having a way to associate the logging data.

    I've never paid very close attention, but for example I noticed this morning that eehack is showing 52.1 minutes of data. By my math that should be around 3126 seconds of runtime, but the last frame of data in the log shows runtime of 3153. Unfortunately I didn't check what the controller had counted, but if my math is correct it should be no more than 8.5ms slow per hour. I'll keep closer track this evening and try to speed up the controller's timekeeping to at least get in the ballpark.

  8. #608
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    Quote Originally Posted by spfautsch View Post
    Curious if you uncovered any more info on this. If not, please don't waste a bunch of time doing so, but I'm trying to make timekeeping in the controller firmware match that of the PCM for the purpose of having a way to associate the logging data.
    Didn`t investigate it further, the eside clock is spot on but tside used some other scalar for the system timer and it didn`t matched nice. Some rounding is needed.

    Usually you get a increment each second, I will dig out the timers so you can confirm the run time increment.

  9. #609
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    It's not worth going to a bunch of trouble, was just asking in case you figured it out and didn't post any more about it.

    I've been looking over old logs, overall the runtime from the datastream is consistently higher than eehack shows for the log time. Obviously there's some skew based on how long eehack is connected vs when the engine is started, but it looks like it's consistently about 30 seconds fast per hour.

    Edit: Interesting - on the back of the napkin that works out to 8.333ms error per second and my timekeeping timer is generating a 15.626ms interval. Hmmmm

  10. #610
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    I did some more calculations and still can`t get the correct values.

    OC4I runs each
    317.9ns * 614[ticks] *16[prescaler] =3.12305ms

    The engine run timer is updated each 160 cycles
    3.12305ms*160=499.688ms
    [7c=0] at 499.688ms

    We know for sure that engine run time is at 1 second interval. SO something is half off. I guess something with the base frequency or the eclock divisor.

    I think only Tom H can shed some lights here.

  11. #611
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    That's still only 0.7ms error per second so yeah - something's off. But don't spend any more resources looking. I figured out a count routine that will give an average 0.992187s interval and that should be close enough for this timer. It's not being used for anything critical. There are two other timers for more important stuff. I'll test it in a few minutes when I head home.

    Speaking of timers, I thought of a potential solution for running time based. It's just an idea at the moment but I think it could work by using one of the compare match interrupts for timer1 - the one that measures RPM from low-res pulse.

    The impending financial doom and gloom here has spurred my employer to cut 1/3 of the company loose, and though I should be safe for now, anything could happen. I'm hoping to hammer through and get as close to finished as possible with a release candidate this weekend because it will be tough selling the car with an unfinished and experimental ignition system.

  12. #612
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    It needs figuring out, since all timer stuff on tside runs out of it. At least we know it is 50% off, so it can be assumed it is correct for the 999.376ms interval. That explains the slight off time on longer longs.

    The doom is inevitable all around so just stay healthy.

  13. #613
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Actually it seems like the 999.376ms interval may be correct. I timed engine runtime (ALDL) for 20 minutes against a stopwatch and couldn't identify a definite skew. At that interval the error would be about 2.5 seconds per hour, which seems plausible. The difference between the log time and runtime could be dropped connections / eehack reconnecting. No biggie, I'll try to find a counting scheme that comes close.

    Unfortunately there's another gremlin to shake out.

  14. #614
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    This is the current progress - I'm calling this an official beta release if that means anything. Note that the source archive is attached to this post, and I will change my .sig to point to the most current version on my vanity domain. The github repository is no longer current.

    This uses a 3d table for max dwell target vs temp vs volts, and another 3d multiplier table for multiplier vs map vs rpm. The controller is applying the multiplier and converting the target dwell from time to degrees based on current RPM on the fly. This has added significant cpu load compared to previous releases using fixed degree based tables. Because of this I profiled most of the lookup, multiplier and conversion routines against data sweeps to get things done with the least possible number of processor instructions.

    Interactive logging has been improved immensely so as to reduce the possibility of causing time-sensitive procedures from being delayed excessively. I forgot to add it to the readme in this release but if you experiment with logging be cautious of including too many pids that require conversions such as [V]oltage and [R]pm because these conversions are more taxing on processor than ones that report raw data or table indexes.

    Warning: there are two known issues / bugs I have yet to resolve to my satisfaction.

    The first is a slight miss that with my test mule occurs at approximately 3400 rpm, and then re-occurs much more pronounced around 4200-ish. It is only evident when slowly accelerating through the RPM range under load. I suspect this is a timing issue caused by routine starvation that I hope to be able to eliminate by initiating dwell from within the high-res interrupt routine (i.e. event-based).

    The second issue is an intermittent crank-no-start condition that I suspect is being caused by the ect table sensing missing on the first attempt due to an invalid first spark advance #. It's only happened to me 3 times out of several hundred starts, and unfortunately I only have one debug log of the problem to give me clues. When it has happened, a second blip of the key has always produced a start. This should be simple to resolve but I just haven't been able to reproduce enough to come up with a possible solution.

    The zip contains much more info now - see README.txt and RELEASE_NOTEES.txt, for details.

    The source has been split up into different files to eliminate the need to scroll through all 1600 lines. User settings are now in config.h and custom setting files can be specified by editing the #include statement i.e. #include "config_spfautsch.h" (see README.txt).

    Ultimately I'd like to put together a complete assembly and installation manual including pictures, etc. when time permits. But...

    As much as I hate to, I'm rushing this out due to growing economic uncertainty as the virus continues to spread. If what my employer is telling us is to be believed the situation is dire. Things could change without warning so I wanted to get this in people's hands now in the event my ability to continue testing and developing is compromised due to loss of income. If things go to hell I will be scrambling to find all sorts of solutions to problems, least of which will be hosting for my vanity domain and keeping gas in my garage queen. Also, the offer of a $50 Amazon gift card has been rescinded due to wages being cut. However, I will do my best to get kits out if there's any new interest for them.

    Edit: I forgot to mention that the lower voltage cells for the dwell tables where no dwell limiting could be observed during testing contain hand-interpolated values. There is a spreadsheet in the archive that I used to generate the tables if anyone would like to customize their tables. If you look back to the post containing the test results you can compare that spreadsheet to see which cells were interpolated. In particular the D514a table contains a large amount of this data. It shouldn't pose a problem as the system generally wont be operating below 11 volts for extended periods, but I thought it important you know.
    Attached Files Attached Files

  15. #615
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Believe I found the crank-no-start problem - a purely boneheaded oversight on my part in the general timekeeping interrupt resulted in no dwell target for the first couple firing events.

    This has not been road tested but I don't anticipate any problems as the change was extremely minor. Will try to test the day after tomorrow and report back.

    Edit: Road testing today was successful. I'll start working on the miss issue in a day or two.
    Attached Files Attached Files

Similar Threads

  1. Which TBI system is better?
    By KeyAir in forum GM EFI Systems
    Replies: 41
    Last Post: 05-13-2019, 09:39 PM
  2. Hard start 93 LT1 with LTCC Ignition Mod
    By beestoys in forum GM EFI Systems
    Replies: 0
    Last Post: 05-18-2015, 08:58 AM
  3. ABS system?
    By K1500ss4x4 in forum Gear Heads
    Replies: 3
    Last Post: 02-06-2014, 06:21 AM
  4. Vortec EGR System?
    By EagleMark in forum OBDII Tuning
    Replies: 40
    Last Post: 06-02-2013, 10: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-03-2013, 01:52 AM

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
  •