gunio checkpoint 4/25/08

[dcb]

Or we can go completely spartan, no buttons, one screen, reprogram the device to change the injector flow rate and vss tics per mile, hit the reset button to reset the tank:

the screen would look like:

I000.00  C000.00
T0000.00m 00.00g

Upper left is instant MPG
Upper right is current MPG (resets after 15 minutes of inactivity)
Bottom row is Tank Miles and Tank Gallons.

No eeprom, no buttons, no menus, etc.

To calibrate, you jot down the mileage at a fillup and note the change in mileage and the gallons used at the next fillup, go into the program and tweak the vsspulsespermile and injectorflowrate up or down by the percentage that your actual mileage and or fuel use is off.
Then reload the program on the freeduino.


Ok, lets start there anyway.

[Coyote X]

I am all for as simple as possible for the v0.1 release

Getting the actual calculation routine debugged and the input circuit seems a lot more important than playing with the menu system to start with.


One thing I was thinking of is since the atmel has limited writes would it be reasonable to attach external memory like a 24c164 type of chip to it and save all the data there? 1 million writes seems like a pretty good lifetime to me. I don't know if there are libraries available to interface with it, but if not it would be a lot of work and probably not worth the effort to build them.

[dcb]

the atmega168 has 512 bytes of internal eeprom, which should be manageable, and the arduino libraries are pretty sweet for the eeprom, and serial I/O. The lcd library needs some help though.

[awillard69]

I've been watching this project/thread with interest.

I have a comment regarding the VSS and ticks per mile. Would it be easier to find a common value, say average the value from as many common vehicles as possible and use that as a starting point? Then you could use the tank reset to create a "calculation offset value" stored for future use. If you were to verify the miles driven and the fuel total, you would know, within a close percentage, what the offsets need to be. They could be refined with each fillup.

You could provide a listing of the common offsets for a set of vehicles so that starting out, someone can set a relatively good starting offset - part of initial setup. Since it's open source, data gathering would come from those interested in expanding the project.

[dcb]

The average value is an interesting approach. But once we have that kind of data, I would like to ask some nice web hosting type person to put up a page where you can look up the specific vsstics and flow rate numbers by vehicle.

Then one can plug in those numbers when they load the program onto the guino as a more accurate starting point.

[awillard69]

Why not add it as a module with the source? Then SourceForge becomes the host.

And I'm not sure they need to be VSS or Flow rates, just "Offsets".

Sure the geeks will probably just hunt down their values and modify the source directly. They won't need the fancy offset interface.

I know it seems like a bit of dumbing down, but then it would reach more people, easier. Lay the ground work for the future.

[MetroMPG]

Originally Posted by dcb

To calibrate, you jot down the mileage at a fillup and note the change in mileage and the gallons used at the next fillup, go into the program and tweak the vsspulsespermile and injectorflowrate up or down by the percentage that your actual mileage and or fuel use is off.
Then reload the program on the freeduino.


Ok, lets start there anyway.

I like that best as well. Keep it simple. And it recognizes that the people who are going to be using v1.0 are probably going to be the most comfortable with hooking the thing up to their computer and making small changes to the code/reloading.

[MetroMPG]

Originally Posted by dcb

The average value is an interesting approach. But once we have that kind of data, I would like to ask some nice web hosting type person to put up a page where you can look up the specific vsstics and flow rate numbers by vehicle.

Do you mean create a DB of values by vehicle that successful guino users can populate for the benefit of future users?

[awillard69]

Originally Posted by MetroMPG

Do you mean create a DB of values by vehicle that successful guino users can populate for the benefit of future users?

Not so much a database, I'm in IT so that has other connotations, but a listing of settings and their associated vehicle configurations.

Kind of like when you buy a universal remote, what values do you set to make it work with your TV or VCR. You don't have to compile and download its software, just enter the values and off you go.

But, yes, as more people use it, they can contribute their settings so that other users can jump in and have reasonably accurate readings from the start.

This would make it possible to update the guino's software with enhancements and not affect how it actually calculates. Assuming any software changes didn't require a fundamental change to the values stored.

[dcb]

re: spartan, ok. I'll spend a little time to try and make the lcd code boot reliably first then stitch the signal processor and lcd code together with some controlling/organizing logic.

re database, yah just a page (or even a post) with the parameters by make/model/year will be fine for starters. If by some miracle we get hundreds/thousands of data points then it might need a better tool. We are already directing the sourceforge folks this direction anyhow.

re: re-compile, it's not a big deal to modify the initial values before hitting the verify button in the ide. If you have gotten a freeduino and run blinky you know what I mean. There is no plan to distribute binaries for this project since it is easy enough to just cut and paste a program into the arduino IDE and update a couple constants at the very top of the program and then download it to your guino. It will be obvious what to change and what not to touch.

We will get to the in-process adjustment of the parameters and other quick and easy setups and a host of other nice to haves eventually.


Note: I've also been wondering how to organize this code. Libraries are sort of nice, but add some awkward steps if you only use them once. I'm thinking just one big file with everything you need for the program will be the simplest for the users to just cut and paste that into arduino, rather than fetch zip files of libraries and figure out how/where to extract them, etc. I think just big comment blocks and/or classes will suffice. And hey, it can't get too bad with only 14k to work with