gunio checkpoint 4/25/08
 

Open to suggestions and improvements, might need to trim down for 1.0

HARDWARE:
freeduino board and 2x16 display from nkcelectronics.com. Choose serial or usb freeduino to taste and to available ports on your computer (hint, a laptop compatable setup might prove useful in the early stages):

LCD ($9.99) :
** http://www.nkcelectronics.com/16x2-l...backli162.html

rs232 serial freeduino ($16.99) :
** http://www.nkcelectronics.com/arduin...omplete-k.html
OR
USB freeduino ($27.99) :
** http://www.nkcelectronics.com/freedu...elease-bo.html

Three button interface: scroll left, select, scroll right.
+ misc transistors/resistors ($8)

MAIN SCREENS:
Mainscreen
Line 1, top level trip and function
Line 2, scrollable list of selectable trip functions, + "Setup"

Setup
Line 1, Setup
Line 2, scrollable list:
** Go Back, configuration items list (many sub screens there), utilities

CONFIGURATION ITEMS:
injector settle time
number of injector pulses for 2 revolutions
number of vss tics per mile
injector flow rate
fuel tank size
contrast
brightness
fuel adjustment
distance adjustment
time adjustment (would just affect main loop)
vehicle weight (for auto-coastdown CDA computation and hp calculations)
top display (scroll through all the trips and functions and select the ONE to display on the top line of the main screen)
bottom display (scroll through all the trips and functions and select/unselect the ones to scroll on the bottom line of the main screen)

UTILITIES
follow onscreen directions

*Quick setup
** MPG, estimate your mpg at 50mph
** Injectors, hold 2000 rpm, press select, and hold 2000 rpm for 3 seconds.
** Distance, maintain 50mph, press select and hold steady 50 mph for 3 seconds.


*Compute CDA
** accelerate to 50, coast to 40 in neutral w/no brakes, decelerate to somewhere above 5mph and coast (neutral and no brakes) to a complete stop. If you entered the weight and other configuration items correctly you should see a pretty good approximation of your CDA. Repete and average.


AVAILABLE TRIPS
//trips
instant
current
trip1
tank


AVAILABLE TRIP FUNCTIONS
instant: mpg, mph, rpm, gph, update, reset
current: miles, gallons, hours, mpg, mph, rpm, gph, update, reset
trip1: miles, gallons, hours, mpg, mph, rpm, gph, update, reset, save
tank: miles, gallons, hours, mpg, mph, rpm, gph, dte, update, reset, save

** will need to update all the trips once a second. The time for all trips needs to be associated with computing when the "current" trip is over, i.e. no signals for 15 minutes. So if the end of the current trip is computed 15 minutes after the car is shut off, then 15 minutes will need to be subtracted from ALL the persistant trips (just tank and trip1 for now) before saving their state to the eeprom.


ERROR DETECTION
it is easy to go overboard in this category, but some thoughts:

*Pop up lcd messages for:
** cpu at 100% (i.e. no time left when we go to wait for the remainder of a second at the bottom of loop(), so the time tracking will be off).
** exceedingly short/long injector open times

pop up for a second (or whatever the refresh time is).

This step will be problematic for people without tachs. They'll have to figure out a workaround (calculate gearing/speed @ 2k RPM).

Great feature idea!

What if the device displayed your RPMs in the setup screen?

Can't compute RPM till you know how many injector pulses there are per revolution.

Maybe quick setup is a list of questions,

1. how many cylinders do you have?
2. Is your car TBI (one or two injectors just by the throttle body)?
3. make an initial guess at your mpg at 50mph
4. how big is your tank
5. calibrate speedo/injectors, accelerate to exactly 50mph on level ground in no wind, press select and maintain 50mph for 10 seconds.

calibrate will take the number of vss pulses received in the next 10 seconds and use that to determine the vss pulses per mile. (multiply vss pulses by 7.2)

calibrate will also try to match the injector flow rate with the amount of fuel that would have been required at the estimated mpg for those 10 seconds at 50mph.
flow rate: ((10/72)/estimated mpg) gallons/sum of injHI time as minutes. This should get trued up at fillup time.

Or we make some initial guess on the flow rate based on the car or vin or?, and/or slap a web utility to give people a list of setup items, or?

how about this for calculating fuel flow, rpm isn't needed for something like this. I haven't had time to mess with the ide everyone is using but it is still C so it should be similar to the codevision stuff I know.


unsigned long int timecount = 0; //global time counter, or at least the left 8 bits of one
unsigned long int period; // total amount if time the injector is open
unsigned long int time;
unsigned long int openstartcount;

Set a timer to count at whatever clock speed you are needing 10khz or whatever. Usually they are only 8 bit or whatever so you have to manipulate the bits to get a larger number.

set an interrupt for the timer overflow.
if (timecount == 16777215) timecount = 0; else timecount += 1;
what this does is make 2 numbers the timecount variable is the left 8 bits and the timer itself is the right set of bits. It is checking to make sure timecount doesn't overflow with the if statement. And when it does it starts it back at 0.

now set a pin to interrupt on going high and a pin to interrupt on going low. It is ok to connect the two pins together on the circuit. Or one interrupt could be used and when it goes high it changes the interrupt to low and when it interrupts low it sets the interrupt to high.

interrupt [EXT_INT0] void ext_int0_isr(void) //this would be when the injector fires (pins go low)
{
time = timecount<<8;
time = time + TCNT0; // shift the timecount left 8 bits and add the timer to the right half so you have a 16 bit timer
openstartcount = time; // this sets the start time that the injectors are open. I know this could be simplified but it is easier to follow hopefully.
}


interrupt [EXT_INT1] void ext_int1_isr(void) //this would be when the injector closes (pins go high)
{
time = timecount<<8;
time = time + TCNT0; // shift the timecount left 8 bits and add the timer to the right half so you have a 16 bit timer :)
if (time > openstartcount) period = period + (time - openstartcount);
else period = 4294967295 - time + openstartcount;
// this if statement is making sure that the time hasn't overflowed and started at 0 again. If it hasn't then it adds the current injector open time to the total open time. If it has overflowed and started back at 0 it knows that the largest number is 42... and time was something before that so it needs that amount of time plus however much has passed since starting back at 0 to get the correct number for period.

With that it gives you total injector open time. So the easiest thing would be to set a timer that is about 3/4 to 1 second interrupt. In this one it knows the vss signal that would be just a simple counter and it knows the total amount of time the injectors are open so it would be a simple matter of saying for miles per gallon, miles = # of vss pulses * some factor / injector open time * some factor. and for L/Km or whatever units you want just do the same thing basically. It would need a way to check to make sure the injector isn't currently open and then zero out the period variable. If it was open a small routine could be added to the injector close time to calc the mileage on injector closing for that time.

I didn't check all that code for overflowed variables or anything so I don't guarantee it will work more than just a way to show how to do this without needing rpm. It should basically work and could be tested with a function generator putting out a square wave if anyone has one handy.

Also another way to calculate it would be for the 3/4 to 1 second interrupt time to just set a variable like

{
calculate = 1;
}

then on the next injector close operation it could have this on the end of the function

if (calculate == 1){
mileage= (vsscount * vsscorr) / (period * injcorr) // the counts * the corr
// factors for each of them to get them to miles and gallons. time isn't really
//important. just distance and gallons so calibration could be just drive 1 mile
//using highway markers and use that for calculating the corr factor.

period = 0;
calculate = 0;
vss = 0; // clear everything for the next round of calculations in one second.
}


the gallons corr factor could be a routine to just count total injector open time continuously for a full tank of gas. Then figure out how much is squirted per unit time by that fill up information.

You are Correct that we don't actually need RPM. In my head I thought it would be a nice sanity check that the injector signal processing was working correctly, but if we have (or can attain) confidence in the interface circuit and the signal processing then we can leave it out for now.

Can you take a peek at the signal processing thread? http://ecomodder.com/forum/showthrea...979#post17979?

Ok, well, lets take a look at things onced stripped down to the bare essentials, instant, current, and tank MPG.




Screens:
Main Screens (using right button to switch screens, left button reverses order):
Inst MPG 0000.0
Curr MPG 0000.0

Inst MPG 0000.0
Tank MPG 0000.0

Inst MPG 0000.0
Curr Miles 00000

Inst MPG 0000.0
Curr Gallons 000

Inst MPG 0000.0
Current Reset

Inst MPG 0000.0
Tank Miles 00000

Inst MPG 0000.0
Tank Gallons 000

Inst MPG 0000.0
Tank Refill

Inst MPG 0000.0
Quick Setup

Tank Fillup Screen: (repeating buttons would be nice here,
left scroll button decreases by .1, right scroll increases by .1
Fillup Gallons:
10.7 gallons

Tank Fillup Confirmation Screen (scroll to change option, select to choose):
Save changes?
ok

Save changes?
cancel

quick setup screens, scroll left/ right to change by 1, select=next screen
1:
est mpg @ 50mph?
25mpg

2:
hold 50mph and
press select

3: grab a few vss pulses and injector pulses and if the signals look ok, then figure out the internals and go to the main screen.



Hows that for starters?

I looked at that other code you mentioned but didn't know what to do with it since it looked ok to me :)

On the setup screens for the basic version I think the only thing needed is the tank fillup gallons and pulses for a set distance. So for the setup could we have an input for gallons per hour on the injector and pulses per mile? Gallons per hour could be estimated from the factory service manual for the car then fine tuned over a few tanks of gas. Pulses per mile could be calculated easily by driving the car a mile on a highway with mile marker signs.

If the gas was done in gph and they put in a number to start with when they fill up again it would say it thinks so much has been used and then they can adjust the gph value till it matches what has been actually used. So for the setup screen it could be something like:
GPH XX.X
Total ??.? gal

Then the pulses per mile could be like this
PPM XXXXX
# Pulses ?????

The gph one could recalculate the total gal used as the number is adjusted. The ppm could start at 0 for # of pulses then they drive for one mile and that is the number that they input on the top. maybe one digit at a time then hit the middle button to advance to the next digit?

Just an idea but I am not sure if that is the best way to do it or one of the other ways would work out best. Since I am mainly just popping up here and there posting random code that won't compile with the software everyone is using :)

Yah, I can go for the just enter/adjust the flow rate and the vss tics per mile too and just a reset on the tank. If the users can solder together an arduino, they can figure those parameters out and make adjustments accordingly by looking at the tank gallons before resetting, and maybe an online database to look up the values for common vehicles.

So we would have:

Screens:
Main Screens (using right button to switch screens, left button goes in
reverse order, select only works on resets and injector/speed adjust):
Inst MPG 0000.0
Curr MPG 0000.0

Inst MPG 0000.0
Tank MPG 0000.0

Inst MPG 0000.0
Curr Miles 00000

Inst MPG 0000.0
Curr Gallons 000

Inst MPG 0000.0
Current Reset

Inst MPG 0000.0
Tank Miles 00000

Inst MPG 0000.0
Tank Gallons 000

Inst MPG 0000.0
Tank Reset

Inst MPG 0000.0
Speed Adjust

Inst MPG 0000.0
Injector Adjust

So that is 10 items to scroll through on the main screen, with a scroll back button that is probably fine.

Speed Adjust screen (scroll buttons to adjust +-1 , maybe hold for +- 10 every .3 seconds?)
VSS Tics/Mile?
3200

Injector Adjust screen (scroll buttons to adjust +-.1 , maybe hold for +- 1.0 every .3 seconds?)
Max Gals/Hr?
20.1


I'm not sure if 1/10 a gallon/hour will be fine enough resolution. But we can go with it for now.

Or???
 

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:
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.

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.

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.

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.

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.

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.

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.

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. ;)

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 :)

If this was a computer based system I would say build up some libraries and just call the functions as you need them. But for embedded stuff I always liked to minimize the function calls and stick with the standard libraries for whatever ide is being used.

Having a huge number of functions might in theory make the code more modular but it also makes it take longer to run and takes up more memory. So I say make a main loop do the extreme basics like update the display only and let the interrupts do the bulk of the work.

My vote is for the absolute basic features for the first revision and once that actually works then go wild with adding stuff on to it :)

I agree. The 1.0 version should have minimal features to get it working. We can always work on the bells and whistles after we have a functional device.

Fair enough.

As for the library consideration - that's officially over my head.

Here's the layout, a little more finished. I tried 4 digits for tank miles and 2 for gallons, but it just looks better lined up I think. And it will be a little simpler to have a function that formats numbers as all NNN.NN.

INstant and CUrrent Miles/Gallon on top
MIles and GAllons for the TanK on the bottom

http://planetchampions.org/diympggauge/spartan1.JPG

Enough messing around with the display :)

Looks good. But, I don't think you need that many decimal digits. Anything beyond NNN.N may be too inaccurate to matter and take up space. All the numbers are going to be based on calculations, so rounding and precision will make them useless.

I understand and considered it, but I am shooting for that degree of precision. a 100th of a gallon is a noticable amount (about 1/6 of a cup), at least it is noticable at the high end of the mpg spectrum. I could go a whole mile on that :) . Also, there are many vss tics in a 10th of a mile (way more than 10), so I think the data environment supports at least 2 digits after the decimal point.

Besides, I don't know what else to put in the space at the moment :) I'll be posting the source shortly.

this stuff is sounding good! tell me when you have a prototype ready to run, cause I wanna test it out! :D