Having looked through the Toyota repair manual, it specifies the injection flow rate as a range from 76 to 91 cubic cm per 15 seconds, translating to 304 to 364 cubic cm per minute, should I choose the median or the maximum for fuel calculations?
Yes, flow is dependent on voltage and manifold pressure. Usually flow rates are given with constants like 13.3V@3bar.
RealDash does not use the injector size for anything but fuel consumption IF (and only IF) injector pulse width is received from the vehicle. This is very rarely the case with OBD2 connections, assuming you are using one.
Noted and understood, I am using injector pulse width from OBD2, although admittedly whilst I have the correct PID, the formula has been trial and error. I refill the vehicle weekly, so just plan on making weekly adjustments until I get reasonable accuracy between the pulse width and the injector volumes.
1 Like
By way of an update, I managed to confirm the PID and formula I had selected aligned with Car Scanner Pro; this being PID 213C with formula (B0*256+B1)/1000 ms, this also validated with the measured idle values of 2.4 – 2.8 ms mentioned in the Toyota service manual.
So having set the injector size to 275 cc/min and after my 28 km commute to work this morning I recorded 2.2 litres of fuel (which I think should be circa 3.0 – 3.2 litres).
Before my return home commute, I adjusted the injector size to 300 cc/min and on my return commute of 27.8 km recorded only 1.2 litres of fuel, this has left me a little confused as to what had affected the calculations.
@realdashdev I am experiencing a very strange problem with the injection pulse width fuel calculation, specifically underestimating fuel consumption. I have trip B fuel consumed and instant km/L showing on RealDash and once I reach highway cruising speed (~100 kph) I am showing >18 km/L; this is not possible with this 4.0 L vehicle. Whilst driving at cruising speed, if I switch on datalogging, instant fuel consumption drops to around 9-11 km/L which is where I would expect this to be. I have the injection pulse width on a skipCount=1 so it is being read frequently. Any ideas?
Are you reading fuel pressure or MAP sensor? Those will also affect the consumption calculations with pulse width.
Also, the total flow is calculated as:
totalFlow = injectorFlow * numCylinders * numInjectionsPerCycle
And litres per second:
litersPerSecond = (rpm / 60.0 * cycle) * (pw / 1000.0) * (totalFlow / 1000.0 / 60.0);
Where cycle is 0.5 for 4 stroke and 1.0 for 2 stroke engines.
I am not reading fuel pressure but I am reading the following PIDs (also not using these in my Dash display), would these affect the calculation? (10E) Spark Advance, (10F) Air Intake Temperature, (110) Manifold Air Flow, (111) Throttle Position, (133) Barometric Pressure
@realdashdev is it possible that when I switch on datalogging this additional CPU activity is causing the calculation method to fallback to the MAF method instead of injection pulse width?
I don’t believe that is happening. The extra load could potentially cause the PW info come in slower and thus make the calculations less precise, but error should still not be that high.
@realdashdev this morning I commented out the injector pulse width entry in my xml file, which I assume would default to the MAF calculation this recorded 3.4 litres for the same 28 km journey which recorded 2.4 litres on injection pulse width method yesterday
So, which one is correct? Or neither?
@realdashdev I believe the MAF method is closest albeit slightly over estimated. I refill every weekend so I plan to run with MAF for all of next week to see the accuracy on next refill, then I can switch to pulse width the following week for comparison.
1 Like
As an update, I decided to go with Pulse Width and I had the below list of readings for distance (km) and fuel (litres) over the last week, and until my return commute today I was getting reasonably good consistency, however, this afternoon’s results were not good and I observed instant km/L readings of > 20 whist driving which is impossible. I could not see anything different in the readings for Pulse Width, MAP, or MAF of significant. With all of these parameters aligned with their targetId’s is there a risk of RealDash using multiple calcs?
28.4 – 3.7, 27.5 – 3.4, 28.3 – 3.4, 27.1 – 3.7, 28.2 – 3.8, 28.2 – 3.7, 28.1 – 2.0
It should not use multiple calcs, as there is pretty clear selection tree for the consumption algorithm. I can test on the simulator to make sure.
@realdashdev by way of an update, I now have pulse width / MAP (both from OBD2) signals achieving 1-2% fuel consumption accuracy when compared to my weekly visit to the filling station.
As part of my overall plan to migrate as much as possible from OBD2 to CANBUS, I automatically start a log on each trip for comparative purposes i.e., to reverse engineer working OBD signals against unknown CANBUS frames / signals. Early last week, I concluded Pulse Width is not available in any broadcast CANBUS frames and decided to remove Pulse Width value from my log file. During the following journeys, I started getting erroneous impossible instant fuel consumption figures (km / L) on my dash.
I subsequently, added Pulse Width as a gauge (hidden) to my dash and it is now working fine again. It just seems as if the Pulse Width signal is not getting used by RealDash (logging it or displaying it) the use of its value in fuel calculations appears unreliable.
This is a special case with OBD2. As OBD2 is slow as you basically have to ask every value one by one, requesting a lot of different values just makes this worse. Because of this, RealDash checks if there are no gauges showing this information the request is not sent to OBD2 at all. Idea is that if you do not see the value, there is no point wasting time asking it from OBD2.
Thanks @realdashdev, understood and now makes perfect sense why I was experiencing the problem I mentioned