opengauge development: gunio technical considerations

[dcb]

The stand alone opengauge (aka MPGGuino, or guino for short), has a number of issues to consider:

Display:
1. [deleted my 8 bit ramblings, suggest using the 4 bit library that is being worked on:] http://www.arduino.cc/playground/Code/LCD4BitLibrary

2. Display Size.
Displays in general, the more the better. 20x4 would be my vote (or 1024x768), but I am only starting to understand the technical limitations facing a bigger display. But it should be at least as big as the arduino so we can hide the arduino behind it.

3. Display Interface.
[deleted interface stuff, 4 bit libraries look sufficient, moved flow to organization]

Development Environment
I like the ease of the arduino ide, and how it can drop down to AVR with relative of ease. I also like that there are a lot of people using it and posting solutions to real world problem. I also like the fact that it is free, and open source (so you can look and see how millis() is implemented) and the free version is not deliberately crippled.


Persistence:
The atmega specs list the 512 byte EEPROM memoy (where we will keep the trip data that persists when the atmega is turned off) as only allowing 1000000 writes, then apparently it turns to dust. This means we do NOT want to save the persistent trips once a second!!! One logical solution would be to save them when the key is turned off, but we will need a digital pin tied to ignition power to do that.

Trip Organization:
With only 512 bytes of persistent data storage, we need to think somewhat carefully about what we save from run to run. If we have a persistent tank trip and a handful of other trips, they should each take about 20 bytes, assuming a similiar structure as below, which means about 26 persistent trips maximum, that get updated when the ignition is switched off.

//things will start rolling over @ about 1900 hours
class Trip{
unsigned long seconds;
unsigned long injHi;
unsigned long injHiOverflow;//need more precision on the injectorHI time
unsigned long injCount;
unsigned long vssCount;
}

in the one second loop()...
make a copy of the instant trip and reset it
clear lcd
if(english)
print("MPG<TAB/>MPH<TAB/>MLS<TAB/>HRS");
else
print(something besides english);
go to next lcd line
for(int trip = 0; trip < NumLines; trip ++){
trips[trip].printData();
go to next lcd line
}

in Trip.printData(){ //functions handle conversions to english/metric
printConsumption();
printVelocity();
printDistance();
printTime();
}

add setup options to hide the header row, and to keep the instant trip row always viewable.

[dcb]

[deleted my 8 bit ramblings]

re: LCD hardware.
A bigger display would be nice, but the source we have for the freeduino only has a 16x2 offering for $10. http://www.nkcelectronics.com/16x2-l...backli162.html Simplified ordering is nice too.

Ok, I bought one of those 16x2 to play with. AND an $18 20x4 from http://www.sparkfun.com/commerce/pro...roducts_id=256
(100 or more= $14.36!!)

[dcb]

Also want to look into simple to make touch sensitive switches: http://www.bytecraft.com/Touch_Sensitive_Switch

char touch_switch (void)   {
  pb_direction = output;
  pb.0 = 0;    // Discharge the pin     
  delay_Ms(1);          // Wait
  pb_direction = input; // Turn on the Constant current source     
  delay_Us(5);          // Wait for 5 u_seconds     
  if (pb.0 == 1) return (0);         // No touch detected     
  else return (1);         // Touch detected   
}

Ok, I'm going back to the palmpilot stuff. Just had to get all that out before I left atmega land for a while.

[dcb]

Last thing for now, thought this was kind of cool

the dCoreDuino

[dcb]

Ok, it looks like all the action is on the 4 bit arduino library. Lots of people are working on that and the library compiled out of the box for me, and apparently it is supporting multiple lines and 20x4 displays. And it uses less pins than the 8 bit one:

http://www.arduino.cc/playground/Code/LCD4BitLibrary

It looks like the most promising solution at this point in time, better than the 8 bit solution.

[larrydag]

This is a howto from Ladyada.net for LCD's and *duino's. This should be helpful for us to learn the best methods.

http://www.ladyada.net/rant/2008/04/...to-an-arduino/

[MetroMPG]

So, are you still thinking the 16x2 LCD mentioned in post #2 is the one to get? If so, I'll order one too. I'm a bit out of my depth, but I can at least be beta testing along side you guys.

Also, the Guino is boring with only a blinking LED to program.

[dcb]

I don't know 2 or 4. Ease of ordering vs more data display area. how about keeping gunio 1.0 simple and get the 2?

it isn't much to work with though, but it's cute

some examples, (the *'s are buttons outside the LCD area)

  INS 045mpg   mnu*  
 *< CUR 047mpg   >*

  INS 045mpg   mnu*  
 *< TNK 045mpg   >*

  INS 045mpg   mnu*  
 *< INS 2200rpm  >*

not married to it, just putting it out there as a starting point.

[MetroMPG]

Agreed: cheap & simple are good goals for 1.0.

I just ordered the 2x16 - came to $13.29 US including shipping to Canuckistan.

Your sample display interface looks good & makes sense. I like it.

[Whoops]

Ok, I've got a couple of thought's, for consideration.

In thinking about it, if we are only looking to update the display or send out the serial data, once per second, then the code and hardware don't really need to sample either the speed, injector on time or frequency any more quickly. Consequently, the code could reasonably sample the speed for 10 cycles, average that and store it. The same thing is true for the injector on time and frequency. Statistically this would give us some pretty highly reliable intervals for calculation and display. It should also make the code pretty straight forward.

One request was for RPM to be displayed. In thinking about the above, the RPM can be inferred, largely, from the frequency of the injector pulse. The exception to this would be if the injector is not turned on, as it is not when my rpm is above about 1200 and I have my foot off of the throttle.

Third, one of the things I would like to have is the ability to see if my speed is going up or down and whether my fuel mileage is going up, or down.

On the display, it may turn out that we have to not update the screen, to frequently, as at some rate of change it may become jibberish.

Although I ordered my freeduino a week ago, I still haven't received it.