Bringing this back from the dead.

I'm currently writing a LC for my ME17, i successfully cut spark at desired RPM(with changing dwell output). It doesn't always refer to the dwell table while sitting on launch RPM and seems to push past the desired launch RPM. My ECM calls a couple functions from SPRAM for outputting coil triggers, and i haven't figured out how those functions get copied to SPRAM yet so i can't follow them to see what exactly they do and or see the ECM trigger the coil's(they do it over SPI to a seperate IC inside the ECM).

So i'm investigating doing launch by changing timing. How far are you retarding/advancing timing, my ECM limits timing to 54 degrees of advance but i can set LC timing after that check. Timing on my ECM is set in an 8-bit signed int, so the max i can advance is 127 degrees. My though is to advance so far that the spark plug sparks before any fuel is injected, causing a spark cut essentially. is this correct thinking? 127 BTDC is still after fuel is injected.

Is my thinking correct, or am i way left field on this?

Thanks.

Thank you for the reply. I don't have a fr to go off of, this is all just by studying the ecm.

Yes, i followed the Dwell table (Batt V / RPM) and found the address in RAM that is stored with the table output, that gets multiplied by 3 and then that gets read into a core special function register within the function. Is the stratified output within the same function possibly?

I believe i found the calculation for dwell temp output, but it gets bypassed by a bit in the configuration area.

Edit: I looked a little deeper. Hooked up an oscilloscope to the coil trigger wire. Set dwell to 0 and fed the ecm a simulated crank trigger. Found when setting dwell to 0, it still pulled coil trigger wire to low and instantly back. Found where it called a function that passed the coil dwell time to a register and set/bypassed that and now it does not pull the coil control low. Thanks for the help.

There are plenty of ways to approach this.The "right way" is to build your own table, put it into a function that uses zwmin and then trigger it based on a condition.

As far as ignition Cut goes there are also 2-3 ways to do it...Again the somehow "Right way" is the ignition fade in/out function while "forcing" an overrun condition as ignition fade in/out functions are triggering fuel cut.You could also make certain functions disregard fuel cut while you are on LC.

That said it would be good to set one more table for boost control and make sure that the functions you are hijacking are disabling misfire recognition otherwise you will have to do it yourself.

Setting a manual value to Szout_w is not always a bad idea and mostly depends on the coil type. Some immo functions on bosch ecus are inducing fuel and ignition cut so you could study that as well.

BTW fuel cut is just for show. I use retard via zwout_syns (or syncs0 ) function and hlsdem on newer vag based cars to achieve such results for rolling launch or launch control.

https://www.youtube.com/watch?v=4zjhuW_C4nM

Thanks for all the pointers. I got most of what you said, the problem is that the ignition fade in/out procedures are total mystery to me. I did disable misfire detection and knock detection (just to be safe) "manually", so these should not be a problem. And there is a WG duty cycle control on top of things too (essentially the code is a complete mirror of what I have done for ME7.9.10 some years ago and posted somewhere here). Just that ME17 is more stubborn it seems.

So for now I am sticking with reducing szout_w, but now I also forcefully reset fubaanz to 0 when cutting spark. As for ZW, I moved from zwgruhom to your way posted here, there was a problem with this though, on ME17 zwcalcar has a complement array for monitoring (did not see this in your listing), so both of them have to be modified. Long story short, most optimal way was to do it "slightly" elsewhere than you did it to avoid hooking up in two places in a contrived way. If this works, I will post some details here for future generations I am not the tester of this, so now I have to wait for the next results.

As for the "soft" solution, the "kids" want to be really loud it seems (and then collect pieces of their engines from the ground, but that's not my concern), the client is always right...

Find this and analyze it "ignFadeStatBits_w"

I do not doubt the quality of the translation, just that copying and pasting it piece by piece is a bit of pain... Anyhow, now I got my hands on the actual FRs for the ECU I am working with, and in the right language too.

OK, this seems easier than I thought (or I am totally wrong), there are dedicated functions I can call to turn the ignition off and on, for all cylinders or selectively. So another direct question, I know that you know what I mean, which one of these patterns will work the best:


I do not want to test all of them, my money would go on CYLCUTOFF or DMDZAG.