|
There is another random thought here that ought to be tested prior to implementation, that is timing.
Current MPGuino code relies on direct reading of the Injectors and VSS - this is all fine and dandy, does what the ECU does.
When you are using a diagnostic setup, such as ALDL, OBD-II, or the Mitsubishi request / response protocol, the timing of the VSS pulses for example, are just not there (at least I don't think so.. hmm.. maybe that is what my Speed reading above is?) - back to where I was going - when MPGuino is getting the data directly, it has no issue - the current fuel consumption data is being provided to it for it to calculate and display.
When it has to take steps to ask for this information, the delay added would affect the accuracy of the data.
I think of it like this (I'm yet to test, but keen to see what comments appear (i.e. dcb - looking at you!), if the data is requested, and then you open wide throttle, the next update could be many ms away, so use of the MPGuino might ot be suitable for that purpose?
I will try and get some testing done tomorrow to find how long each request roughly takes (I'll remove the 10ms delay and make the code very efficient), and see how many responses to my requests are possible - this would all be without any calculation workload - which would delay updates further.
Are the delays going to be a problem at all??
The data stream for other cars (i.e. 160-baud and 8192-baud appears to be a stream from posts, so even this is delayed by the ECU's choice of when to send the data and in what order).
Am I wrong?
|