Add seconds counter for cumulative injector open time

[honsch]

Can be used by external dashboards to determine how much fuel has been burned since the lat ECU reset. Integer seconds are plenty precise enough for a fuel burn gauge, The code uses a U16 accumulator, enough for ~18 hours of injector open time before rollover.

The reason I added this is or our endurance race car that now has a UA4C running it and the in-tank fuel gauge is useless while the car is in motion due to fuel slosh. We know how much fuel the tank holds and knowing how much has been burned lets us know when we need to pit.

[muuris]

This kind of addition is nice also for fuel consumption tuning.

Just a couple of thoughts: -Having nice-to-know calculations in scheduler? Different approach could be using ie rpm and pw to sample pw at (fixed) intervals -For approximating used fuel, this doesn't take in account the non-linear part of the injector flow as the cumulative sum hides actual pulsewidths. Not a problem if one is always far a way from non-linear zone.

I've done used fuel calculations in an external controller using fullstatus data, frequent sampling and a 2D table for pw vs injector flow. Gives quite a good accuracy.

[honsch]

Muuris, The scheduler is the only place the injection time can be accumulated with any accuracy, Because the RPMs can change quickly and non-linearly any sampling method will introduce unacceptable errors. I do agree about the short open time issues, I did see a pull request for adding an injector pulse width correction. If there's support for reverse table lookup it could be added although it's probably too slow to add it to the scheduler. There would need to be an addition to the FuelSchedule structure to pre-compute the true injector open time. The reality is that if the injector open time is truly accurate to a few percent when racing it's plenty good enough for my needs.

[muuris]

I understand that, just personally don't like it being there even though currently it's the only place it can be in that way. And really it shouldn't be that much of an issue as it's just a simple increment. As you've stated, reverse lookup there wouldn't be good even though it would fix the non-linear issue.

With sampling method, the error that rpm change introduces greatly depends on sampling frequency. Not having non-linear flow taken in account the results can (will) be skewed as well.

Would be interesting to try this out and compare the differences.

[honsch]

As a side note, does the injector pulse width compensation also do the large pulse width non-linearities?

[muuris]

If you're referring to the old pr of mine, it doesn't. The consumption calculations I have in external controller do take in account (simply 2D table pw vs flow).

[Autohome2]

What might be useful is to save the value in eeprom so it is saved. Unfortunately as this should only be done during shut down to save wear on the eeprom it would either need to have a periodic( say every minute for example) or a save button in TS. Another good reason for controlled/managed ECU shut down

[honsch]

I agree it would be nice to burn the data into EEPROM periodically, with an input pin toggle to reset the value back to zero. On an ST board the battery backed SRAM could be used, I don't know if there are any Arduino or Teensy that have that capability. A controlled shutdown isn't always possible. Our race car has a master kill witch that is required to instantly cut all power to the vehicle. Perhaps one of these could be added to future hardware for persistent data: https://www.microchip.com/wwwproducts/en/23LCV512

[ric355]

I have been testing this change for the last couple of days as I wanted to add MPG calcs to my custom dash. I can report that it works well. There are a couple of things that need to be understood about it;

1. Since it accumulates seconds of time each channel is active, then you have to realise that the amount of fuel it represents is dependent on how many injectors you have on each channel. In my case I run a V8 paired, so I need to multiply the seconds by two. An alternative is to just double the injector flow rate value in the calculations of course. Either works; I don't think there is any need to accommodate that in the number generated by Speeduino as it would just make it over complicated given all of the possible configurations.

2. Obviously for a true MPG on a daily, you have to externally accumulate the time between engine starts, since it always starts at zero when the speeduino board is powered on. Again that's not an issue for me as I have a consuming application pulling the data via secondary serial anyway.

I'd like to see this pulled into master if possible. It has absolutely no effect on performance - unlike configurable outputs for example, which has also recently been pulled in.

[noisymime]

@honsch I think one of your recent merges may have broken this. There are only a few small changes showing in the PR now.