t vago's MPGuino workspace thread

[t vago]

Added 4 new bargraph displays -

• Fuel Economy vs Speed
• Total (tank) time travelled vs Speed
• Total (tank) distance travelled vs Speed
• Total (tank) fuel used vs Speed

[josemapiro]

Another fantastic work
How is the indication of the amount of fuel in the tank, must be placed amount of fuel manually?

Thank you
José Rodrigues

[t vago]

Originally Posted by josemapiro

Another fantastic work
How is the indication of the amount of fuel in the tank, must be placed amount of fuel manually?

Thank you
José Rodrigues

Thanks! I am rather proud of the time/distance-to-empty functions, myself. They do not randomly jump around.

The tank size is a parameter that can be edited in the settings, just like metric mode, the inactivity timeout, and that humongous microseconds per fuel quantity number. I think it was present in the original 0.86 code, but it was never really used. The tank size parameter is affected by metric mode - if metric mode is set, the tank size is displayed and entered/edited as liters. Otherwise, it's in US gallons.



I changed the display coding a bit, to enable a somewhat higher resolution graphic display. I simply despised those blocky bar graph characters. Now it's easier to see the characteristic MPG curve as a function of vehicle speed. The above picture was from my commute into work today. I managed to squeeze in 17 different speed segments into that display. The fuel used / speed, time / speed, and distance / speed graphs look similar, but they do not have that nice curve that I wanted to show. The fuel economy / time screen also uses the above graph coding.

Tonight or tomorrow, I am going to add EEPROM parameters to select the speed range, enable saving this data to EEPROM, reset it by itself (currently, it resets when the tank trip is reset), and examine it from the shown screen.

The differential fuel economy / time graph (like the one below, from the ScanGauge E) does not appear to work yet. I probably miscoded something simple.

[nickdigger]

If you want a bigger, readable bar graph, just upgrade to a 20x4 LCD. Reprogramming the CGRAM on-the-fly is a neat idea, but the gap between rows 0 and 1 is kinda off-putting, whereas it's not really noticable with the bigger, wider block characters. On my 20x4, the graph is 15 columns wide, and the 16x2 has 11.
In my own experience, i put a graph on mine about 3 years ago, but rarely, rarely view it. The last time was a couple weeks ago on a 100-miler, and i only used it to verify the code still worked. There were enough fluctuations in the traffic that wildly skewed the graph, where a single data point at 100+ mpg (caused by EOC deceleration to change freeways), that all the other 30 minutes' data all looked the same in comparison. I kept watching the graph, anticipating the 100+ point to fall off the chart, and once it finally dropped, I got another one just a few minutes later when I EOC'd to exit the freeway. Who knew that averaging 100mpg (for 2 minutes) could be so frustrating?
Also, the slightest incline or descent will be reflected in the data. Which makes the graph look interesting, but just makes you realize that so, so much of your MPG performance on the road is completely out of your control, and is dictated to you by the terrain and the general traffic flow.
Not trying to discourage your work. Just sharing my experiences. Mostly, these days, I just watch my auto-resetting Trip2 screen, and keep a mental note of my personal-best trips to common destinations, and try to match them as circumstances permit.

[t vago]

Originally Posted by nickdigger

If you want a bigger, readable bar graph, just upgrade to a 20x4 LCD.

If I wanted better fuel economy, I should just get a Prius. Sound familiar?

Originally Posted by nickdigger

Reprogramming the CGRAM on-the-fly is a neat idea, but the gap between rows 0 and 1 is kinda off-putting, whereas it's not really noticable with the bigger, wider block characters. On my 20x4, the graph is 15 columns wide, and the 16x2 has 11.

Just as not everyone can justify (or afford) spending $10 on a Parallax 5-position button, not everyone can justify (or afford) upgrading to a 20x4 LCD display. Anyone who currently owns the bone-stock MPGuino hardware (JBD or meelis11 or anything else directly based on dcb's work) can run this software, with no hardware modifications to speak of.

Okay, granted, AtMega168 owners who wanted this graphic display would not be able to do their own display screen edits, or use a clock, or take advantage of late-model Chrysler pressure-corrected fuel readings, or sped-up serial datalogging, or have the ability to calculate their fuel factor without the use of an Excel spreadsheet. (oh, wait - they couldn't do that to begin with) They'd have to pick and choose what they wanted out of the code, which was how they had to do it before (they just had to figure out and add the programming themselves, instead of uncommenting a single line). However, the base code (without all of the extra bells 'n' whistles I've added, which is already much improved over the 0.86 original) should run on a 168 with no problems, which is something you just can't say about 0.86. Besides, I'm working on shrinking the code. Seems to be a pattern - get it to work, then shrink it.

Not that it matters, because anyone wanting to get a 5-position switch, or a 20x4 LCD, should be able to afford an AtMega328 for $2.88 plus shipping.

In any case, this graphical ability will visually reinforce many of the things that other EM'ers have said here on this board, and will convince people (who use this gauge) to drive more economically. For instance, fuel economy drops as speed increases. Makes sense, right? Now, with this code and the MPGuino hardware, you have a graph that shows this - that you yourself generated as you drove! Can that be done with a ScanGauge or an UltraGauge? (which, by the way, only work on OBDII cars?)

As you mentioned, I do not expect that fuel economy over time would really be sought after, but fuel economy over speed? Or fuel used at a given speed? Or distance at a given speed? I dunno - I've been wanting that for over a month now, and just now got around to coding it in.

[Ardent]

Have you uploaded any updates other than the one posted earlier in this thread? I tried it, but for some reason only the clock would display. Button presses would cause ghost lettering to appear for a ms before reverting to the clock.

[t vago]

Ghost lettering! Cool!

What hardware are you using?

(current MPGuino code version is at first post of this thread)

[nickdigger]

If I wanted better fuel economy, I should just get a Prius. Sound familiar?

It wasn't a general suggestion for everyone, it was for you. You already spent $10 on a button, and were considering a TFT upgrade, so 20x4 wouldn't be out of line. Anyhow, as I mentioned, the block character graphing is still passable on 2x16's too. The same number of bone-stock MPGuino owners will upgrade their screens, as will rewire their buttons -- not a damn one. But whatever, it's out there.

an AtMega328 for $2.88 plus shipping.

Wow, I had no idea those were available. Now if only I can find a DIP-to-TQFP adapter socket, desolder my 168 and mount the new one, I'll be in business.

Believe me, I knew from the start that the easy way out was to just buy a new 328 board for $25, but sticking with the 168 forced me to streamline the code (base functionality < 8k) and was well worth the learning experience. No regrets. And if I can't squeeze rudimentary OBD2 op's into my remaining 1k, I'll have no choice but to use one of my 328s, also without regret.

I do wish you didn't take every comment as a blood-libel, personal insult. It is tiresome, and leaves only one way to avoid it. A general hostility to ideas was on this project long before, too. Ever wonder why 0.86 never made it to 0.87? It could also be, that no one drives pre-96 cars anymore, but in this economy, that's doubtful.

[t vago]

Originally Posted by nickdigger

I do wish you didn't take every comment as a blood-libel, personal insult. It is tiresome, and leaves only one way to avoid it. A general hostility to ideas was on this project long before, too. Ever wonder why 0.86 never made it to 0.87? It could also be, that no one drives pre-96 cars anymore, but in this economy, that's doubtful.

Somebody else, not too long ago, tried to put together an MPGuino with a Parallax serial LCD display, and your answer was... go buy the correct part. You didn't try to point the individual toward a good reference, like others in this thread have done, and you didn't try to interact with him to try to solve the problem. Had I known then what I know now about MPGuino, I would have tried to help that person get his board to run with a serial LCD. Hey, my code happens to support that particular serial LCD now! Too bad that person got discouraged at the response you gave him.

It's much the same as with the other things in this MPGuino forum - all of the things I've done or added to the code, are in response to things that other people here have asked about, or tried to implement. One really big example stands out... Returnless fuel support!

Point is, the idea behind this thread is to make available a next-generation MPGuino software that will run on existing hardware, that can easily be adapted to new commercially produced hardware, and that will add features that will make MPGuino more attractive to people that are looking at a $150 OBD gauge that is not as accurate. That means, in part, being able to use the existing hardware, even as flawed as it is.

So - about this "blood libel" comment of yours - When I read arrogant ((example 1, 1st half), (example 1, 2nd half)), lazy ("I thought cli also shut off timers", "I haven't taken a closer look at the specs.. doesn't sound promising"), dismissive ("I'm not sure it really makes a big difference.", "too bad it costs so much", "a neat idea, but... offputting") comments, I tend to get put off by the commenter after a while. That's just the way I am.

[AndrzejM]

t_vago - you've done a tremendous job to upgrade MPGuino's software. And I really appreciate the effort. Pity I can't test it right now for one simple reason... Berta is just standing in a garage and waiting for me... I'm riding my bike all the time, because there's no need to drive a car. But hopefully soon I'll be able to go for a round trip through "my" offices across Europe and I'll test your code throughly. Of course with a proper feedback.

One suggestion for you, maybe worth to consider in a next version of your code. I was changing the "Canadian" version of MPGuino, and I've embeded the code for coast down tests. Up and down speeds are edited with global parameters, and when I go to the proper screen it's showing the exact time and distance that car was coasting from one given speed to the other. It's very accurate and much more convinient than reading time and distance from your speedo and a stop watch.