So I think I understand where the disconnect is...
So need to revisit the multi-processor approach. Lets stick with main processor and I/O co-processor for now. The I/O co-processors handles synchronous events such as injectors and spark (SI example), based on crank angle.
When ECU starts up, let's say a very simplified of the following happens;
* Main processor starts and performs what ever it needs to in-order to be in a valid and safe running state.
* Main processor then goes and initializes I/O co-processor with appropriate configuration and tells it to "Run".
* Presumably main processor goes back and verifies I/O co-processor is running and everything is valid or no faults present.
* At this time if above is true, it can write "Initial Values" to co-processor, such as a "safe" ignition timing value(s). As an example 5 degrees of advance can be written. NOTE, 5 degrees is being commanded, but engine is not running or cranking. AND may be displayed on scanning tool/software (I'd want to see it).
* I/O co-processor has decoded cranking engine crank/cam and now immediately fires spark(s) at pre-configured angle.
What makes above relevant is - when co-processor correctly decodes crank and cam and is correctly resolving crank angle in degree or rotation, it "can" then fire spark instantly. Why would you fire off spark before adding fuel? Clear a flood, someone squirted in fuel or starting fluid, many reasons...
* Main processor is checking/polling co-processor to see if it has detected motion (crank is turning).
* Main processor sees crank angle resolving and then writes any other variables required such as injector pulse width and updates spark to appropriate value(s).
Above is obviously drastically oversimplified. In short I/O co-prrocessor handles critical events in a robust, deterministic and very repeatable manner. The main processor does the heavy lifting. The two are loosely coupled, therefore allowing main processor to run more complex code with an OS (operating system) without imposing large interrupt latency hits (again oversimplified). Or what needs to happen no mater what is handled by co-processor, variables can be pre-written, updated as required, and both do there own thing. It's a big departure from single processor super loop of days gone by.
The thing is you don't need any of this (over) complication to make an aviation engine or automotive race one run well. The CPU operates much faster than the relative glacial pace that mechanical events in the engine occur at. The proof is that SDS is on the fastest EFI equipped vehicle in the world- Andrew Findlay's 2 time Reno winning Lancair- over 430 mph on telemetry. This engine runs on the ragged edge of destruction, so it's a challenging environment.
Again Congrats.
For MAP, you simply take multiple samples in software and average them before the injection event. Crank angle doesn't need to be considered.
Lets agree to disagree. I'm in crank angle camp.
You are coming back to justifying these display errors here. There is zero fuel flow and airflow with the engine not running- period, end of story. To display anything other than zero is erroneous.
Again, lets agree to disagree. Refer to my ignition advance example above.
Typically with throttle closed (SI), we shut off the fuel in automotive applications so there is no fueling to worry about there. With a throttle plate, we don't care what upstream pressure is because that's separated from the engine and the MAP sensor anyway.
You lost me.
SDS displays all sensor inputs, engine running or not but they all read correctly at least. Why wouldn't MoTec?
So does the Motec. All analog inputs are sampled, run through transfer function and updated, regardless of engine state. They may change sampling trigger(s), but run all the time.
The 20mg fuel that was observed is NOT an analog input. It is some sort on offset, very likely created by PM. It could be a MINIMUM fuel to inject per event/cylinder.
MoTec makes some of the best ECUs around, no argument there, but you simply need the AFR and spark timing to be correct- period. We've run SR20 race engines back to back on the dyno, SDS vs. MoTec and the result was no difference in power.
Peter's fiddling may have resulted in this FF display error. I certainly don't know enough about MoTec to say but at least with SDS, the user cannot manipulate anything with programming to have FF display anything other than 0 with the engine not running, so I'd say that's something in the MoTec architecture which could be addressed.
I get it, you own SDS, congrats. That 20mg really bugs you... it is not measured fuel flow, it is not trying to turn on injector, it is some offset that got baked in (very likely by PM to get air conditioning running without an engine stall, ie minumum injector mass flow per shot or who knows). I turn my home heating/cooling electronic thermostat to off position, it's setpoint is 72 degrees F, by your logic that 72 degree setpoint should disappear or not be displayed???
