DIY LTCC or similar system for LT1s

[kur4o]

Here is a source code that has retard limit removed. Now you can command up to 60 degrees of retard and test all kind of scenarios.
Beware of possible engine stall if you go too far with the retard.

[spfautsch]

Thanks! Does this require patches to the bin / a reflash of PCM?

With as much overlap as my cam has I suspect even 1 degree ATDC spark would cause an almost immediate stall. But I can log the controller and tell if it's firing the coils correctly - if it doesn't it will probably blow the coil fuse after four coils are energized simultaneously.

You have a PM from me BTW.

[kur4o]

No need to apply a patch. Just removed the spark control safety feature of +-15 degrees.

[spfautsch]

Thanks, I figured it out when I started compiling and noticed bin_file.cpp was dated from October. Will try to test tonight. Nice work on the edit: C/L tuning controls - kind of a shame I won't be able to test that any time soon.

Update - very useful, thank you. No blown fuses and engine operation was sustained through short bursts of negative timing so no critical problems. It also offered a handy single-button stall trigger for testing stall recovery (as well as pedal clearing the subsequent flood condition).

Turned up a slightly confusing scenario however.

R1064:A27:D0.51:C7:M372:V14.35:T23:E1:L0:S16
R1058:A27:D0.51:C2:M365:V14.40:T24:E1:L0:S16
R1045:A0:D0.51:C1:M360:V13.05:T25:E1:L0:S16
R1036:A0:D0.24:C8:M362:V13.10:T26:E1:L0:S16
R1014:A0:D0.24:C4:M364:V13.07:T27:E1:L0:S16
R1003:A0:D0.24:C3:M369:V13.05:T28:E1:L0:S16
R989:A0:D0.24:C6:M371:V13.03:T29:E1:L0:S16
R978:A0:D0.24:C5:M369:V13.03:T30:E1:L0:S16
R963:A0:D0.24:C7:M376:V13.09:T31:E1:L0:S16
R947:A0:D0.24:C2:M383:V13.05:T32:E1:L0:S16
R918:A1:D0.24:C1:M379:V13.61:T33:E1:L0:S16
R890:A0:D0.25:C8:M394:V13.10:T34:E1:L0:S16
R866:A0:D0.24:C4:M396:V13.05:T35:E1:L0:S16
R851:A0:D0.24:C3:M405:V13.05:T36:E1:L0:S16
R835:A0:D0.24:C6:M417:V13.09:T37:E1:L0:S17
R818:A0:D0.24:C5:M425:V13.05:T38:E1:L0:S17
R805:A0:D0.24:C7:M426:V13.40:T39:E1:L0:S17
R786:A0:D0.24:C2:M440:V13.03:T40:E1:L0:S17
R761:A1:D0.14:C1:M461:V14.03:T1:E0:L0:S17
R731:A1:D0.15:C8:M471:V13.72:T2:E0:L0:S17
R714:A-1:D0.15:C4:M472:V13.14:T3:E0:L0:S17
R708:A-1:D0.13:C3:M482:V13.21:T4:E0:L0:S17
R700:A-1:D0.13:C6:M498:V13.19:T5:E0:L0:S17
R685:A-1:D0.13:C5:M506:V13.17:T6:E0:L0:S17
R666:A-1:D0.13:C7:M519:V13.10:T7:E0:L0:S17
R643:A-1:D0.13:C2:M532:V13.12:T8:E0:L0:S17
R633:A-91:D0.13:C1:M539:V13.09:T9:E0:L0:S17 < these two lines are troubling
R614:A8:D215.29:C8:M545:V13.10:T10:E0:L0:S17 < note the 215 tdc counts in the subsequent dwell lookup
R580:A17:D0.22:C4:M563:V13.10:T11:E0:L0:S17
R563:A25:D0.31:C3:M581:V13.16:T12:E0:L0:S17
R579:A26:D0.39:C6:M587:V13.21:T13:E0:L0:S17
R603:A26:D0.42:C5:M593:V13.21:T14:E0:L0:S17
R639:A25:D0.42:C7:M609:V14.42:T15:E1:L0:S17
R662:A27:D0.40:C2:M609:V14.37:T16:E1:L0:S17

Not sure how that can be happening. I initially thought of a possible race condition caused by either the high or low res interrupt handlers, but global interrupts are supposed to be disabled inside of ISRs. Copying the (global) degree count to a local variable didn't help either. It'll give me a puzzle to solve tomorrow.

[spfautsch]

Think I've found all the sources of the weirdness with ATDC timing tests. Couple logs attached (both controller and eehack logs). If you take a look at them, the one named 1107-3.log is the controller output in raw format (i.e. rpm and voltage not converted to human-readable). You'll notice an asterisk getting pumped out in the negative timing test sections - this is the stall detection coming in.

EDIT: No, it's not, duh. In cleaning up the code I realized I added the asterisk to pinpoint the one race condition I hadn't accounted for between the low res, est and high res interrupts that was happening at ~0 spark advance.

When this timer overflow is hit it invalidates the sequencing so the controller will want to re-detect sequence before it will continue dwelling coils. Interestingly, it wasn't stalling (i.e. actually dying) this time and sequence is detected and the controller carries on with the next firing event.

Anyway, long story short I can probably increase the stall timeout to improve that. But I'm also going to re-check my math b/c I don't see the low res interval time anywhere near where I calculated the stall timeout should be triggering.

What I was somewhat baffled by is that regardless of how many degrees I removed in the eehack control UI, the least spark advance aldl data reported was 0, and the least the controller detected was -1 which is around the average error (+ / - 1 degree) I've been seeing across the board on the controller side. So perhaps there's another limiter in the calibration that's preventing ATDC timing. For the purposes of testing what the controller does, I'm happy with it's behavior at this point.

If I can get my powered usb hub wired into a decent power source and working reliably I'll try to take a short drive tomorrow before I start dismantling it to pull the engine. I'd really like to know if the intermittent miss I was feeling is resolved.

[spfautsch]

Wanted to drop in an update that the test drive was mostly a bust. Same hesitation was happening, apparently in the places where dwell begins near a TDC / low res signal (i.e. around 90, 180, 270 degrees of dwell). 0.9.12 exhibited similar stumbling but it was much less pronounced. If you accelerate past that range it runs great. So more work is needed there.

Hope to have it back together and running before the end of the year but I might try building a test rig out of my spare opti so I can at least attempt to make some progress while the car's out of commission.

[steveo]

i got my parts kit to build one of these things, no time to do it right now but our winters are long and boring so i'll be sure to get 'er done soon.. that'll inspire me to help with the coding end of things.