I do have read out averaging (but only for 4 of them, let me not dive into this now) and plausibility checks / DTC / check-engine things. For a directly connected sensor it is much simpler, either the signal is there, or not. If not, for 2 seconds or so, the ECU limits the load to safe ranges. It's just about stabilising the readout on start up due to air pockets. The idea of EEPROM storage has crossed my mind, but then this is good for stable fuel type usage (you run on E85 only and you use the sensor to compensate for the seasonal ethanol content variations). My use case is frequent fuel switching, the EEPROM value becomes irrelevant when you fuel up with different fuel. Or so I think.

OK then, seems I will have to reconsider the EEPROM storage.

I do have signal debounce, if I get interrupts more often than 0.25ms I quit the routine right away. And otherwise it is very time optimised (hence the 4 readout averaging, I do it without muls/divs). And with low enough interrupt priority to allow the other important things run first. Preliminary tests with giving it high priority crashed the bench ECU right away with no engine attached, could not even keep the CAN communication.

But then again, if it is low frequency, what's the danger with proper interrupt? Same load as with counters (these have to be serviced some time too, no?). These things are programmed and designed with slack, and honestly, an interrupt routine with literally a handful of instructions (it essentially records quadruples of periods / frequencies) with each instruction =~cycle should not do any harm. The actual signal processing / conversion / fault recording is done periodically every 100ms, not in the interrupt routine. I talked to an electronics engineer about this earlier on, and he said 50 to 150 Hz is not a frequency I have done much more risky things on much more stringent architectures

But, let's leave the conclusion until I am sure it all actually works in all conditions, right now it is an academic talk

I don't know how it is on your car.

But ME7 on many VAG runs the pump when a door is opened in the vehicle - a priming pulse.
All that is needed is extending that priming pulse until a stable signal is there...

Shutdown EEPROM storage and purely depending on that is a horrible idea, because the car could have been fueled up in the meanwhile.
If you have fuel tank level in ECU, then no problem, you can check for this condition, but if not, you will have a no-start every time you change fuel.

Dwelled a bit on prj comment about fuel tank level. Found the variable that stores it, I could possibly make the wait time on the fuel pump dependent on fuel up. Fueled up - short wait time - the car most likely was just running (when you fuel up you typically just drove to the station) and there should be fuel in the line, so no need to wait that long for a correct reading. Not fueled up - wait longer, but instead rely on previously stored E-content in EEPROM. There is just one problem - the fuel level information is received through CAN, and I do not know when, not sure I'd have it available when I needed it - essentially right away after boot. Will have to devise a way to test it, cannot do that on the bench.

This is excellent man. Nice work. Something I've wished for for ME7.5 for a long time. Keep it up!

First fill up of E85 done, 11 litres into the 45 litre tank. I cannot remember last time I was so anxious In the end that resulted in 22-24% ethanol content. All looks good so far. First, my fill up detection seems to work. I made an ECU internal log of first 10 seconds of E-content readouts and got them out through CAN later, so 100 samples altogether from boot (they are suspended when the fuel pump is not running and 1 second after it starts):

4.0, 4.1, 4.7, 4.7, 4.7, 4.7, 4.7, 5.0, 5.1, 5.0, 5.0, 5.0, 5.0, 5.0, 5.0, 5.0, 4.8, 4.9, 4.8, 4.8, 4.8, 4.8, 4.8, 4.8, 5.0, 5.1, 5.1, 5.1, 5.1, 5.1, 5.0, 5.0, 5.0, 5.0, 4.9, 4.9, 4.9, 4.9, 5.4, 5.3, 5.3, 5.1, 5.1, 5.4, 5.8, 5.7, 5.8, 5.9, 6.1, 6.7, 6.8, 7.2, 7.7, 8.2, 8.8, 8.9, 9.4, 9.6, 10.0, 10.5, 10.8, 11.1, 11.4, 11.8, 12.0, 12.3, 12.7, 12.8, 13.3, 13.5, 13.7, 14.0, 14.3, 14.5, 14.8, 15.1, 15.3, 15.5, 15.8, 16.0, 16.2, 16.5, 16.7, 16.8, 17.0, 17.1, 17.2, 17.4, 17.5, 17.6, 17.6, 17.7, 17.8, 17.8, 17.9, 17.8, 17.8, 17.9, 18.0, 17.9

The first 4.0 is the previous value from EEPROM, the next one the first reading after 1s of fuel pump priming and around next 10 are also from the priming phase. Then I was setting up my stuff with the ignition on, when I started the engine there was another 1s wait to get the readouts and then they continued. So, to cut the story short, I had about almost ~2(prime)+4(start) seconds of the new mix not hitting the rail, then it started, aggressively. At this stage I declare my method working, but obviously more verification is needed.

Short term trims and long term multiplicative trim look acceptable also. The latter got from 1.001 to 1.002 (momentarily to 1.003) only after several minutes of running / driving. (Stupidly, I do not log additive short fuel trims, I will rectify this tonight, they are the whole point as the drive was rather light). The only thing is the relatively large STFT drop down to 0.9 or below. Both spots happen when the car was idling at traffic lights. Since I never made a log like this with regular fuel (should have done that), I am not sure if it is normal (it is also relatively hot around here, ~26*C). Higher load (short spell only for the first test) AFR seems good too.

Complete log from the first drive and magnified lines of interest attached

To be continued...

Either I am logging the wrong variable for additive ltft (rka_w), which is unlikely (but possible), or everything is spot on. Additive correction is absolutely minimal, 0/-1 once -2 in unconverted values, the multiplicative one stays in 0.999-1.002. All that after adaptation reset (due to another flash). The overall stft variates ~0.95-1.05 in most cases, in places ~0.9-1.1. I guess it simply is this way. I'll spare you the log, it is 19 minutes and 3.2MB in size, but a picture overview shot of the stft correction instead.