Release Two Workspace (/Fork name TBD)

[dcb]

Last thoughts (sorry if this turned into a hijack)

Weight between tests has to be consistent (within 1% would be nice, 30lbs for a 3000lb car, more than 3 gallons of gas). This part will take a bit of ritual, i.e. jump on the scale clothed, only test after a careful fillup , keep same weight of objects in car (can substitute items, but put on a bathroom scale to determine weight change). Also important to reweigh (i.e. truckstop) occasionally to validate your techniques and throw out or correct any previous tests since the last valid weigh in if your approach is off. Store current weight in configuration

The timing of crr (and cda) would not be on strict mph boundaries because of the low pulse counts from the vss, but rather should be based on average pulse lengths within a precalculated range of pulse lengths and the time between the first and last pulse in the average.

It is correct that temperature and Crr are interrelated, but it is probably safest to just redo the crr portion first in the same session as the cda tests, and again at the end of the cda tests.



So "simple" test procedure is (after weight is determined) without hardware changes or custom web appliances:
*warm up
*update the temperature and barometer settings in the configuration (i.e. from weather.com)
*locate your long flat test spot
*fillup
*activate the cda/crr routine with the menu, follow prompts
*in one direction
*do a crr test i.e. 5-3mph
*do 3 cda tests i.e. 55->50 in a row
*do a crr test i.e. 5-3mph
*turn around
*do a crr test i.e. 5-3mph
*do 3 cda tests i.e. 55->50 in a row
*do a crr test i.e. 5-3mph
*read your cda, which should be about as accurate as your weight and temperature/pressure readings and your ability to drive in a straight line. Within 1%? not entirely sure. probably more likely if you have an accurate barometer/thermometer in the car and are really careful about weight and fillup procedures.

from 0 degrees C to 35 degrees C, the density change swing is a total of about 11%
so any errors in temperature measurement will likely be reduced to 11% of the original error when expressed as a density error. Every degree centigrade is about a %0.35 change in density.

For pressure it is a similiar story, if the typical pressure range is 1010 to 1034, that is a total density swing of 2.5% and a 2% error in absolute barometer readings is a %0.05 error in density.

If I recon correctly. It seems chances are good of getting reasonably cheap, easy, and accurate CDA to me though that doesn't need any extra hardware.

[FalconFour]

dcb! Nice to see you back Thanks for contributing - and yeah, I'm really still in awe at a lot of the creative (in a good way) things done with the MPGuino code... it's just a lot of things I see in the code that are either done just plain goofy, or just that I don't understand the hack yet... for example, the #defines are littered all over the code, making it really hard to track where things are defined (is it a variable or a define?, that's always bugging me), and the "loose" C bracketing
{
like this;
or if (this)
... do that;
}
... just drives me up the wall when trying to follow a program flow. A good 3/4 of my time so far has been spent trying to follow the program flow so I can understand exactly to the binary digit what's going on in its head, and so far I've ended up having to boil a lot of stuff down because I just don't get it. That's my biggest concern...

You've gotta give Arduino some credit though. Unlike the re-implemented utility functions in MPGuino, the Arduino code is continuously updated to fully implement and support the latest hardware, and implemented in a very flexible way (admittedly, with a little performance overhead, but considering the ATmega328 is idling so much as it is). From what I find, the LCD interface is the most time-consuming part of the loop, and everything else (interrupts) are resource-independent (as long as I don't do too much cli() and sei()), so as long as I'm frugal with LCD updates - plan twice, write once - I think we have lots of wiggle room with timing

However, I have already run into conflicts between the custom AVR code and the Arduino core libraries... the way interrupts are implemented in each, breaks delay() and any functions that internally rely on it (I haven't checked delayMicroseconds though but it seems delay() is now timed like delayMS). I might have to "choose a path" soon, and either go all-AVR, or convert the whole MPGuino code (interrupts, timing, etc) to Arduino code... I don't much like the latter idea due to the incredibly stable way it runs already. But we'll see...

Sorry I haven't posted much in the past week, as I really only get a chance to work on this on weekends. Portal 2 came out on Tuesday, after all!

I really just need to find a good, clean work area to sketch out a flowchart and pseudocode. I went the "quick and dirty" way with the new settings menus in my modded code (the clock menu is really pathetic, but it works). In the new code I plan to implement everything inside the running loop if at all possible (multithread-emulating scheduler?), so the UI remains predictable and prevents the menus and alt modes from interrupting the main loop's functions (using instant to update current/tank, for example). It's going to be a lot of fun.

BTW, I never got any feedback on my UI mock-ups... I'm still planning on implementing that basic system (with just very minor changes I've thought of since that night):
http://ecomodder.com/forum/showthrea...tml#post227195

As for features, I also forgot to mention, yes, the improved big font as well. Don't know if there's much I can do to improve on that, other than drop the padding 0's... but that's another fun thing I'll have to figure out an interface for... I didn't really address that very well in the UI mockup. I rarely use Big in the car, because it's so hard to get to! :P

[FalconFour]

Oh, also... I'm'a leave room in the UI functionality for some new features like this "cd" thing, but until I even understand what CD refers to , I'm'a just be concentrating on improving the core MPGuino features (and re-implementing the ones I already use in my modded code). There'll be plenty of free space for new code, I'm sure.

What I'm getting stuck on (and the reason for busting out a flowchart) is that I have this:
- need to drive LCD faster than 500ms when the UI is triggered (button presses should update *immediately*)
- need those updates to branch outside the main "maintenance/runtime" loop to prevent "over-maintenance"
- need the cursor on screen to be an accurate visual cue for functionality, and update accordingly
- need to generate a wide variety of displays within a "function tree" of various display modes and sub-modes, such as (main) -> switched to options menu -> selected clock settings -> entered clock settings menu. There should be dedicated code for most screens, but the screen handler needs to be flexible enough to avoid "reinventing the wheel" inside each function, and each function can re-use a basic library of functions.
- need to maintain timeouts for some screens, so it will default back to the "running" gauge display after X seconds.
- need to maintain the configuration of the gauge display, perhaps in EEPROM during tank saving
- and since we'll be updating the EEPROM much more frequently, need to dust off my old EEPROM wear-leveling algorithm and figure out how to implement it for data instead of booleans Also, yeah, apparently wear-leveling does help EEPROM wear since each byte address is an individual cell according to the research I did (any Google search these days turns into "research" itself, ugh, Google's getting pretty bad). Wear leveling will ensure it never goes bad!

Loooots of fun stuff. Yeah, I've thought a lot about how usability could be improved with *absolutely zero* changes to the existing hardware

Oh, and as far as a name... hm. I dunno, I feel a bit hesitant to slap my name on the thing (even though I'm responsible for the PC-repair-tech phenomenon "FalconFour's Ultimate Boot CD" - heh). I kinda wanted to give it a catchy and abstract name that indirectly reflects its exact function, reflecting that it's a fuel efficiency computer for older cars (mainly), bringing new efficiency and technology to cars people generally regard as gas-guzzling clunkers. Something (easy to say) like "retromiler", "neogauge", "fueltrix"... or just dropping the descriptive name completely, maybe just calling it "Falcon" like a software code name. I'd be cool with that for sure

[bobski]

Originally Posted by FalconFour

- need to generate a wide variety of displays within a "function tree" of various display modes and sub-modes, such as (main) -> switched to options menu -> selected clock settings -> entered clock settings menu. There should be dedicated code for most screens, but the screen handler needs to be flexible enough to avoid "reinventing the wheel" inside each function, and each function can re-use a basic library of functions.

All figured out and implemented in my code. There's what amounts to an array of display-page-functions with a variable that selects which one is active and controlling the screen at a given time. It's really an array of function address pointers, but dealing with referencers and dereferencers makes me confuse myself, so it's easier to just say it's an array of functions.
There's a similar 2D array of button functions. For the MPGuino hardware, it would be 4 elements wide (3 for button-pressed functions, 1 for idle state), and as long as you have display-page-functions. When a button gets pressed, a snippet of code looks up the button column and current-page-number row, and executes the associated function. That way you can have simple button press functions that are unique to a page, or shared by many pages.
For instance, a next page button would just be currentPage++;.
Or, if you want a button to jump to a non-sequential page, currentPage = (pageNumber);.
A menu system is then just a matter of giving a group of pages button functions that pass around control in an orderly manner.
You could create a page that is only visible so long as you're holding a button by giving the button idle state a function that sends control back to the previous page. Pressing the button makes the page show up, releasing it goes back.

[msc]

Originally Posted by FalconFour

BTW, I never got any feedback on my UI mock-ups... I'm still planning on implementing that basic system (with just very minor changes I've thought of since that night):
http://ecomodder.com/forum/showthrea...tml#post227195

When I tried to look at the image all I got was fuzzy blobs. I don't know if that was a problem with my browser or the image you posted.

Originally Posted by dcb

Pretending? If you go to the truck stop and weigh your car, wait for a calm day to do your tests, and the program helps get current air density data off the web for your test site to come up with reasonable figures, how is that pretending? Most obd gauges come within 3%, would you say they are "pretending too"?

Forgive me, I did not mean to belittle the effort. I thought this was a discussion about how to maximize the potential accuracy of the measurements that can be made with this proposed new feature.

To clarify the point I was trying to make.

Option A: Collect weather data and enter it with a 3 button interface then have the instrument generate numbers for CDA and CRR that have no record of the mass and weather values used to generate the number. Record these numbers as the only data you have with your notes.

Option B: Only collect the basic coast down timing data on the instrument and log this along with all the weather data and other variables on a spread sheet that can also serve as an electronic note book for research notes.

So the choice as I see it is tedious entry and checking of data each time the weather or mass changes and don't keep track of the raw data. Or you can just enter the raw data into a spread sheet where you can organize all the data and notes as an aid in understanding what the data really means. This makes it very easy to recognize and correct errors like a change in mass because you added or removed a tool box or spare tire but forgot to update the value in the instrument before collecting data. When things like the weather data and derived values are displayed together it's much easier to discriminate between which points to believe and which to toss out in a very noisy data set.

To me option B offers much greater flexibility and ability to process any data gathered ultimately leading to greater accuracy and confidence in measurements made. It also makes the instrument code very simple rather then having to code the UI for entering, displaying, and editing all the weather information.

As dcb points out the key to accuracy is careful attention to detail and consistency in the data collection routine. Well organized notes and test logs are a great way to document the testing as well as cross check for silly errors that come up.

FWIW I have 30 years experience in the automotive research field as part of a team that develops specialized Data Acquisition Systems (DAS) to support research programs. Generally on projects I'm working with programmers, engineers, professors, and research scientist that don't get defensive when I suggest there may be a better way of doing something.

Mike

[FalconFour]

Originally Posted by msc

When I tried to look at the image all I got was fuzzy blobs. I don't know if that was a problem with my browser or the image you posted.

Probably your browser... ImageShack isn't an obscure website, they're pretty well known and popular from what I've seen :P

But at any rate, I posted it on my own hosting site (hostfile.org), so here's another link:

(click it...)

And while I'm slightly discouraged by the ongoing chatter about a function I'm about 1% interested in implementing this early in the game... considering the discussion of UI design is 95% of the reason I'm doing this project and have gotten only a tiny bit of feedback about it... I do find this:

Originally Posted by msc

Generally on projects I'm working with programmers, engineers, professors, and research scientist that don't get defensive when I suggest there may be a better way of doing something.

... quite relevant

[dcb]

Originally Posted by msc

...
Option A (monastary)
Option B

I don't think that entering current temp/press via the button interface is too much of a hardship. You can get a "good enough" temp/baro for less than $10 WEATHER STATION ,TEMPERATURE, BAROMETER,HUMIDITY | eBay

or even weather.com in a pinch.

Obviously there is still some honor system here, and someone who understands the limitations can do more tests more quickly without messing with it under the right conditions. Still I would give them an estimated cdA and cRR readout, as that is far more meaningful to a human than random timings (not a lot of lab coats here). The goal of course is to find what works, and the quicker the better.

I'm less inclined to entertain the integrated online application to standardize results, mainly because it complicates things and would certainly delay implementation.

In any option you cannot be so sloppy to not account for adding/removing toolboxes though, that would be like saying "I forgot I put the snoblower gas in the tank while calibrating my mpg reading".

Truck scales are not all that convenient. If there were only some way is a way for the home budget modder to get reproducable weight results with like a bathroom scale... I bet you there is Getting a reasonably accurate handle on weight has other benefits besides CDA (i.e. bsfc under acceleration).

I think we (or you, since you have a problem with it) should get a handle on the margin of error here, how inaccuracies in temp/press/weight manifest themselves. I haven't seen a response to the figures I posted earlier, so I will assume that we agree that you can be off by a bit on temp/press measurements and still be in the ballpark on cDA. Having the computer do the timing will be the biggest accuracy improvement for most users around here, the rest is completely doable. Also, not having users rely on fuel consumption data to determine the effect of a given aeromod will be an improvement.

30 years of spending other peoples money is impressive, hopefully you will be able to contribute something constructive But as the newcomer here, hopefully you will be open to ideas that they don't even consider in the data aquisition ivory tower. Also have a look at the modders bible thread:
http://ecomodder.com/forum/showthrea...ery-11445.html We know these are imperfect conditions.

There are more than average constraints/compromises on shoestring budgets here also. Your typical user is not on some funded research project, just an average schmoe trying to SAVE fuel (and money), and the easier we can help them get meaningful results the more people will figure out ways to save fuel. Some loss of precision is expected in such circumstances. And since folks are going to be playing in traffic on crowned roads etc there is going to be some fudge, get used to it. Again it is well understood that these are less than ideal conditions.

But that is not an excuse for people to be sloppy in their methodology, even if there is some inherent error in the accepted procedures (those procedures being the result of a compromise of a large number of factors). If conditions change dramatically between A-B-A or between mods then throw those results out, and don't "publish" uncorrected STD cdA figures in a serious context.

Ideally someone else will have the same model car and be in a position to validate your results for a given mod.

So yah, initially the 3 button interface to prompt for current temp/pressure (and weight is already in the configuration) is the way to go, and use the procedure I listed earlier for the test.

You *could* go completely over the top with probes and anerometers and wind direction sensors and pressure/temp sensors and figure out how to mount them well in front of your vehicle, but that would put the "solution" out of reach of most users and require a bunch more stuff that has to be occasionally recalibrated and etc. So I don't think that option is suitable for the masses.

[dcb]

Originally Posted by FalconFour

...
And while I'm slightly discouraged by the ongoing chatter about a function I'm about 1% interested in implementing this early in the game... considering the discussion of UI design is 95% of the reason I'm doing this project and have gotten only a tiny bit of feedback about it...

My concerns, as the proprietor of opengauge and mpguino, is to try to focus people on expanding the feature set to include tools that are accurate and will help "the masses" make meaningful modifications, and that do not incur significant cost or complications so that they will be used by the widest possible audience. The greatest strength in a forum like this is just the large number of potential participants who should be able to "keep each other honest" about what mods work or not.

Also, please understand that to me it isn't early in the game at all. I also, for good reason, tend to favor using the remaining cpu resources to implementing enabling changes. I've run it out of resources before, there isn't room for much fluff.

P.S. regarding pin assignments, it was not random, it was selected for a specific orientation to an lcd with a *duino (hide the guts behind the lcd), which of course seems a little silly now perhaps. The contrast had to be moved to pwm, but the rest are a straight shot, while leaving multi purpose pins open.



I do like the anolog button idea bobski mentioned. My saturn has a steering wheel switch like that for the cruise control (and cruise wasn't programmed on my manual ECU).

[dcb]

What about adding a battery current/voltage monitor? I.e. for EV's and hybrids (or folks who want to watch their 12v battery)?

Is there a cost effective hall-effect solution for current? How hard could it be to get a custom clamp (ziptie) inductor made for one?

Is buying (or building) and operating a shunt a hardship?

[bobski]

A shunt would be a no-go for most hybrid owners. It would require tapping into the high voltage line from the battery, or one of the lines between the motor and motor controller. Proprietary connectors and unsafe voltages would surely be involved.
A hall effect setup might work... I suspect Honda electronic load detectors work that way. An inductive pickup would work on AC lines such as the above motor lines, assuming it's done safely.
Wait... Hybrids are all OBD2, so shouldn't this info be available via the diagnostic port?