Bringing TBI and Multi Port Fuel Injection to a New Level.     EFI Conversions and Tuning! Seattle to Portland! E-mail Tuning Consultant!
Page 41 of 41 FirstFirst ... 31363738394041
Results 601 to 613 of 613

Thread: DIY LTCC or similar system for LT1s

  1. #601
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    556
    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
    835
    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
    49
    Posts
    216


    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; 4 Weeks Ago at 05:33 PM.

  4. #604
    Fuel Injected!
    Join Date
    May 2019
    Location
    Vancouver, WA
    Posts
    20
    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
    49
    Posts
    216
    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; 4 Weeks Ago at 09:53 PM. Reason: more ideas.

  6. #606
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    556
    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
    Posts
    556
    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
    835
    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
    Posts
    556
    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
    835
    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
    Posts
    556
    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
    835
    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
    Posts
    556
    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.

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
  •