What vehicle is it? the MPG function is a bit hit and miss which is why it was removed from the main display. I think the main issue is whether or not the reported injector pulse width includes the dead time, if it does then that introduces an error into the calculation, that error is then compounded because the ECU implements a different number of squirts pr cycle depending on engine speed and load.
I have an update to implement shortly so I will check the maths, its not a function that I normally use, I pretty much forgot about it. I will also check the differences between the dashboard and the DataViewer, I have not seen that. I usually use the DataViewer so I'm fairly confident that is correct.
__________________
1984 Suzuki SJ413K pick up, 1.6 16V Baleno engine 2000 Suzuki Vitara 1.6 8V, many mods 2004 Suzuki Ignis 1.5VVT 4Grip 2006 Suzuki Jimny 1.3VVT JLX+ and many more.
This is interesting topic although the latest conversation was back in 2011. I just got the cable last week and it works well (Thanks Rhinopower). I have played around a few functions and one of them was to monitor the MPG (I did replace the IAC with MPG in the dash board).
Today, I did a test and found that on the main screen. MPG always sat at 50 but it was at 98 on the data logger. (I also noticed that a few parameters have reported different values between the data viewer and the data logger - will raise another ticket separately).
50 mpg is equivalent to 21km/l and 98 mpg is even better. This is too good to be true. Having checked the engine specification (the injector flow rate is 46-52 cc/min, thus your fixed value at 210 in the notepad seems about right). Two questions.
1. Is this algorithm fairly correct?
2. Why did I get different MPG between the main screen and data logger?
I would ecxpect that to be accelerator pump/auto choke type enrichment. The gradual increase is caused by too much filtering on the value, that can be modified in the config. file but I should change the default. I thought I had changed the algorithm to read 0 when stationary but I will check that.
I did a few code modifications and broke the code so I need to get that fixed and then I can release a new build with a few more mods in it.
__________________
1984 Suzuki SJ413K pick up, 1.6 16V Baleno engine 2000 Suzuki Vitara 1.6 8V, many mods 2004 Suzuki Ignis 1.5VVT 4Grip 2006 Suzuki Jimny 1.3VVT JLX+ and many more.
I don't know if I mentioned it before but in the current release, the algorithm doesn't seem to know when the vehicle is stationary - it will indicate a figure that increases in jumps until it "full scales", rather than going to zero which I think would be correct.
I haven't played with this for a while, this has been a bit problematic. On some ECUs the injector fires twice on each cycle during fuel enrichment, the MPG display then displays half the correct MPG.
I'll put the l/kmh into the next release and you can try it out. I may also provide an option to switch that meter to another function.
__________________
1984 Suzuki SJ413K pick up, 1.6 16V Baleno engine 2000 Suzuki Vitara 1.6 8V, many mods 2004 Suzuki Ignis 1.5VVT 4Grip 2006 Suzuki Jimny 1.3VVT JLX+ and many more.
Whoops - I don't know why, but I thought you had already implemented averaging.
I have but I haven't released it yet. At the moment real work has to take priority. I also have a few ECUs here for repair and hacking, once thats sorted I will release a new version with the averaging and the datalogging implemented. I also have a few more ECU IDs that need to be included in the config files.
__________________
1984 Suzuki SJ413K pick up, 1.6 16V Baleno engine 2000 Suzuki Vitara 1.6 8V, many mods 2004 Suzuki Ignis 1.5VVT 4Grip 2006 Suzuki Jimny 1.3VVT JLX+ and many more.
Currently there is no averaging it is instantaneous. The next release will be a rolling average of n samples, which I think is what you mean, in DSP terms its a moving average. I'll probably make the number of samples user configurable.
__________________
1984 Suzuki SJ413K pick up, 1.6 16V Baleno engine 2000 Suzuki Vitara 1.6 8V, many mods 2004 Suzuki Ignis 1.5VVT 4Grip 2006 Suzuki Jimny 1.3VVT JLX+ and many more.
Ok - it's not as jumpy as it was before, but at the same time, it's still not as stable as I think it needs to be.
I have an idea on how to approach it, but I think I might need a drawing or sketch to explain it - it's essentially a change in how the averaging is done.
I'm assuming that you're averaging a batch of samples, and then another batch of samples - kind of like this (Sn would be an individual sample) ...
S1+S2+S3+S4 - average samples, display result; S5+S6+S7+S8 - average samples, display result.
How difficult would it be to change it to this..
S1+S2+S3+S4 - average samples, display result; S2+S3+S4+S5 - average samples, display result; S3+S4+S5+S6 - average samples, display result; S4+S5+S6+S7 - average samples, display result
Sort of using a circular buffer to hold the samples and averageing the contents of the buffer - am I making sense here?
Yes it was a rental car, hired for the day because I had to go away for some business training. Previous rental cars that I've had have had average mpg displays which were quite stable, at the time I wasn't that interested in it. On this occasion I didn't have time to learn how the computer worked to change the display set up to show average mpg or any other functions. I'll be interested to hear how you get on because you have no closed loop operation. Closed loop drives the mixture rich and then lean alternately and was clearly responsible for a lot of the 'jumping around'
__________________
1984 Suzuki SJ413K pick up, 1.6 16V Baleno engine 2000 Suzuki Vitara 1.6 8V, many mods 2004 Suzuki Ignis 1.5VVT 4Grip 2006 Suzuki Jimny 1.3VVT JLX+ and many more.
I'm guessing that a "hire car" to you would be a "rental car" to me - essentially a vehicle that you hire or rent (and drive yourself) for a short period of time, let's say whilst visiting another city or country (or even whilst yours is being repaired) - that would be the sum total of my experience with cars with trip computers - a series of different rentals whilst in Florida over the past few years.
The displays I've seen haven't "leapt about continuously", at least not that I've noticed, but, at the same time I usually have my attention focussed on the traffic unless I'm on a highway where of course the speed and consumption would be fairly constant.
Next Sunday I'll be making a trip to the local airport, which is one of the easier ways to get a decent constant speed run, and I'll have another person at the wheel and take a laptop along with me - I'll let you know how stable Rhinoview's mpg display is, given a reasonably stable road speed to work with.
I drove a hire car today that had an instantaneous mpg display, the mpg figure leapt about continuously so its reassuring to see that its not just my software. The nice thing was that when stationary it changed from mpg to gallons/hr.
__________________
1984 Suzuki SJ413K pick up, 1.6 16V Baleno engine 2000 Suzuki Vitara 1.6 8V, many mods 2004 Suzuki Ignis 1.5VVT 4Grip 2006 Suzuki Jimny 1.3VVT JLX+ and many more.
Off the cuff - it sounds like a good idea. How frequently does it sample?
At the moment the timing is done on the system timer. It should request 4 bytes of data every 0.1s but its at the mercy of Windows. Currently it polls 44 addresses so it should update each address every 1.1 seconds, this is where I need to implement address selection so unwanted addresses can be turned off increasing the poll rate for selected addresses. This would mean that the mpg would be averaged over approx. 22 seconds. The next release will have the datalogging facility so you can drive round the city and examine the data later.
__________________
1984 Suzuki SJ413K pick up, 1.6 16V Baleno engine 2000 Suzuki Vitara 1.6 8V, many mods 2004 Suzuki Ignis 1.5VVT 4Grip 2006 Suzuki Jimny 1.3VVT JLX+ and many more.
Off the cuff - it sounds like a good idea. How frequently does it sample?
The other comment I want to make is that trying to get an idea of instantaneous mpg whilst driving around the city is probably not the greatest of ideas - among other reasons, it is going to be contantly changing.
I'm going to tweak this for the next version. I'm considering a simple averaging over 20 samples, it should then be close to instantaneous mpg but with a little of the jumpiness taken out. What are your thoughts on this?
-- Edited by Rhinoman on Monday 22nd of March 2010 08:36:06 PM
__________________
1984 Suzuki SJ413K pick up, 1.6 16V Baleno engine 2000 Suzuki Vitara 1.6 8V, many mods 2004 Suzuki Ignis 1.5VVT 4Grip 2006 Suzuki Jimny 1.3VVT JLX+ and many more.
Yesterday evening I came across someone else's design for an mpg meter, intended to be connected to an OBD2 port, and he does his calculations based on airflow and speed, which I found a little unusual.
He assumes the a/f ratio to be stoich which I believe is not necessarily correct.
Injector pulse width isn't a standard OBD2 PID so they have to make an approximation, obviously if you are outside of open loop operation then it won't be very accurate. I think that it mainly works because people who buy it are more interseted in MPG and therefore don't drive that hard.
__________________
1984 Suzuki SJ413K pick up, 1.6 16V Baleno engine 2000 Suzuki Vitara 1.6 8V, many mods 2004 Suzuki Ignis 1.5VVT 4Grip 2006 Suzuki Jimny 1.3VVT JLX+ and many more.
Yesterday evening I came across someone else's design for an mpg meter, intended to be connected to an OBD2 port, and he does his calculations based on airflow and speed, which I found a little unusual.
He assumes the a/f ratio to be stoich which I believe is not necessarily correct.
My original interface had a PIC24F processor to handle the polling of the OBD port and convert the data to a format based on NMEA 0183 which I used on my own ECUs. I also have code to drive a 16 x 2 LCD, it wouldn't too hard a task to combine the two, its something that I've had in mind for some time (too many projects!). I'll send you the code if you like. Meanwhile heres something for you to check:
Now that you mention it - it is obvious - average mpg probably wouldn't make much sense with a laptop handling the computational & display functions. I wasn't planning on using a laptop though.
I'm toying with the idea of a basic trip computer - the functions I have commonly seen (on factory OEM in rental cars in the US) are instantaneous & average consumption, distance to empty and what I think is distance since last reset (I believe you're supposed to reset when you fill up).
Theoretically these are not too difficult to do with a micro-controller and could be displayed on a little LCD.
The calculations should be based on injector pulse width, RPM and vehicle speed. This was something that I added as an afterthought in the last version and the maths is wrong somewhere. I will have a think about this and try and correct this in the next version. MPG is displayed as an instantaneous value only, averaging is possible but is anyone going to drive any distance with a laptop plugged in? I did do some testing of the graphing functions at the weekend but I wasn't happy with a few items so I will do some more work before I release it.
__________________
1984 Suzuki SJ413K pick up, 1.6 16V Baleno engine 2000 Suzuki Vitara 1.6 8V, many mods 2004 Suzuki Ignis 1.5VVT 4Grip 2006 Suzuki Jimny 1.3VVT JLX+ and many more.
One of the functions in the Rhinoview software is supposed to be an MPG calculation - would you mind sharing the algorithms behind this? Were you planning on instantaneous or average consumption - or perhaps both?
Instantaneous consumption.
What I have mind is to derive the fuel usage based on the injector pulse width and the rpm, assuming the injector flow rate to be contant - something along the lines of flow-rate x pulse-width x rpm x no-of-cylinders/2 - this should give the amount of fuel injected per minute.
The next step would be to take the speed and convert it to "per minute" so we now have both distance travelled and fuel injected per minute, and we can then calculate the consumption as it varies on a minute by minute basis.
For simplicity the above neglects the need to convert imperial to metric, but I'm aware it will need to be done - does this sound like a reasonable way to go?
Average consumption
I can think of two approaches to this - one being to accumulate the instantaneous readings and average them, and the other being to accumulate the individual fuel and distance measurements and then calculate an average. This last would also allow for displays of distance travelled since last reset, last fillup, etc.
