Just from what I have gathered, the ECU uses interruptes to actually fire the plugs.

The crank signal has a falling edge at 5* BTDC that it uses to sync the interrupt. This is of interest because if the timing advance desired is higher then 5 degrees, the ECU has to estimate when to fire the plug without an actual interrupt. I would imagine it keeps the falling edge constantly monitored to verify it falls when it expects it to. Part of this likely has to do with the P0300 test even.

The leading edge of the signal happens at like 75* BTDC, based on measuring the crank trigger plate.

The alignment of the cam and crank signals is unique. I beleive at any point, it can tell which set of plugs to fire and within like 70 degrees or so, the ECU can determine exactly which cylinder is approaching TDC.

 

No the same code but we could make them.

My question was due to possibility to fiddle with the scaling 90/256, but there are physical/electronical limits as what can be
reasonable value.

Thank you both for the explanation.

 

Another interesting findings. Thanks, Mrfred. Subscribed. I changed MUT05 to log AirFlow 2byte, but I guess I will try this one.

 

wasted spark eh?

 

haha Ceddy,
I wasn't actually referring to the message. I was simply saying that you wrote what I said over the course of two paragraphs in one sentence. Oh the hillarity!

 

Sequential injection.

The ECU knows which cylinder is which...despite being wasted spark on the ignition.

 

Quick question for you guys...couldn't find the answer with a quick search.

Tephra's 1 byte load...is it the baro+temp compensated load or is that raw load? I think it may be raw load.

I just want to make sure so that I can log the appropriate load. I want baro+temp, not raw, since baro+temp is used almost exclusively for fuel lookup and for ignition lookup below 77F.

EDIT: I thought my loads were off with respect to table lookups, but I wasn't looking at my altmaps (doh). But I still want to know for reference what the 1byte load is.

 

So it looks as if sequential spark and possibly spark cut (instead of fuel cut) would be physically electronically, and coding wise possible. Fractional timing adjustment would be icing on the cake. I hate the fuel cut, costs me motors .

 

It's RAW. At extreme temperatures or altitudes, it is way off. Under load it'll be 20+% off for me. I've found it to basically unusable.

d

EDIT: https://www.evolutionm.net/forums/7053791-post56.html

 

I don't think there is any available outputs to implement sequential spark?

Rev limiters based on spark cut would be nice, but likely require a lot of coding changes? I imagine the ignition stuff doesn't care about RPM limits at all?

 

Egr and fuel pressure solenoids are outputs, just gotta check if they are fast enough. A lot of coding though I'm sure, and waste spark is fine for most people anyways.

On a 1g ecu the code for rev limit fuel cut just does a RPM compare if equal to or greater then jumps to a subroutine. Write a subroutine to cut spark and jump to that instead of cutting fuel.

 

Rigormortis :

Has anyone ever written a code to cut spark or retard ign adv based on a set of conditions?

 

Ignition retard would be easy to do. Ign cut might be more difficult.

 

but what do you think ign cut is possible ?

2 3D tables RPM and TPS on the 2 axis, one for IGN retard and one for IGN cut ?
It would be a nice real antilag feature !

 

Anything is possible, but not necessarily easy.