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.

[MetroMPG]

Mine took over a week to arrive. The donkey train across the border into Canuckistan is facing swollen rivers & streams from the spring runoff, dontcha know.

EDIT: Whoops, whoops. I read your post and thought it was from fellow hoser Who. Thus you can ignore this post entirely.

[dcb]

Whoops, the occasional sampling of the injectors would be reasonably accurate, but then you need to add tight timing control around the code that would enable the timer interrupts and disable them. And then make an exception for the vss signal, because on my vehicle, it is more than a second between pulses at low speed and you wouldn't want to miss one of those.

I don't think it would make it more straightforward though, since it adds code, but it would be a good optimization, a strategy to consider if reacting to the button presses and displaying prove to be too time consuming. But I think we are ok and might even be able to shorten the 1 second display rate and keep microsecond accuracy.

if you wanted to plug into the serial processor as it stands today:
http://ecomodder.com/forum/showthrea...7979#post17979
Basically in the middle of loop, get rid of the serial calls and replace it with

updateTrips(tmpInjHiMS, tmpInjCount, tmpvssCount );//quick addition in the trip objects
updateDisplay()



updateTrips might look like:
void updateTrips(long injHiMS, injCount, vssCount ){
instant.reset();
instant.update(injHiMS,injCount,vssCount);
current.update(injHiMS,injCount,vssCount);
tank.update(injHiMS,injCount,vssCount);
trip1.update(injHiMS,injCount,vssCount);
trip2.update(injHiMS,injCount,vssCount);
}

and the trips themselves would provide functions like:
current.mpg(), instant.kph(), instant.mph(), tank.dte(), trip1.lper100km()

now updateDisplay() is tricky, as well as keeping track of the button interrupts and deciding the next screen. Might want to look at how coyote did his for starters.

[larrydag]

Originally Posted by 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.

I'm with you MetroMPG in that this is a little out of my league. But there is hope for us. I strongly suggest checking out the Arduino code library and tutorials

http://www.arduino.cc/playground/Mai...ralCodeLibrary

This should help to understand a lot of the nuances in coding the *duino.

As a project to learn coding I'm trying to figure out how to wire up a Battlestar Galactica Cylon scanning eye. I know its a cheesy LED thing but it should be a good first step to learn about *duino's.

[dcb]

Whoops, one more note, there was a caution about the lcd and interrupts at: http://www.arduino.cc/cgi-bin/yabb2/...m=1173553276/3

it is summarized as follows:
1.) Never use a delay or any library which introduces a delay while in an interrupt (like the Wire library or LCD libraries). Serial communication, or any communication requiring a clock will also fail.
2.) Use an external pull-up on the interrupt line.

re: 1. not a problem if updateDisplay is called directly in loop() as I'm suggesting.
re: 2. This is an external hookup issue.

Also I did some scratching and I think worst case scenario (i.e. a v8 with tbi doing 150mph at 8000RPM), there should be about 10 milliseconds of overhead for all the interrupts, which leaves .99 seconds to figure out what to display and display it.

P.S the 2x16 showed up today, I still can't tell if it is the one with less built in characters but more user definable characters or not.

[dcb]

Sorry, I couldn't resist playing with the lcd. The library didn't work for me, wound up poking at it in arduino ide till I got somewhere. All those somewhat arbitrary hokey delays need to be replaced with a status check on the lcd (i.e. LCD? are you ready for another command or piece of data?) I also moved the pins all around to keep the timer1 and 2 pwm pins open (and the serial ports open).



I call this configuration the boreduino

[MetroMPG]

Awesome! I love it! Can't wait for mine to come too.

I also love that you're not not blowing the project budget on mounting hardware/shields.

(Correct me if I'm wrong, but a "shield" is Arduino-speak for separate circuit boards that you mount additional electronics on and then connect to the 'duino, right?)

[dcb]

Originally Posted by MetroMPG

I also love that you're not not blowing the project budget on mounting hardware/shields.

Thanks I like this setup because the LCD is secure, the pins are still easy to get to, and it is low profile when sitting on the dash. Also it would be simple enough to add sides and a top after things become less experimental, and stain or paint it if desired. But hot glue and bits of wire and a chunk of balsa are good enough for me. Just need to sort out the buttons.

FYI, radio shack had a bag of 4 little buttons for $2. I'll probably mount them flush with the LCD face on the sides with some long leads for now. Or maby along the top right where it would be easier. Yah, I like easy, that looks like a plan.

Edit: easiest mounting turns out to be to jam them in under the LCD. Now how many? 2, 3 ,4? Each button takes a pin

4 buttons should be easier to navigate. I.e. a select, 2 scrolls and a back.

3 buttons isn't too bad either, I e a scroll in either direction (so you don't have to cycle through all the options if you pass it) plus a select button, but "go back" becomes a thing you have to select.

2 buttons is the easiest to hook up and simplifies the design choices. Harder on the users as there's lots more clicking, but not a big deal.


Ok Pin check: We don't have any sensors plugged in yet or buttons (or a piezo speaker), but after the LCD we have:

4 pwm pins
2 "serial" pins 0,1, I think we can give up 0, but TX might be useful for debugging.
6 analog/digital read pins
(yep, sorry blinky fans, I took pin 13 for the LCD)

So that leaves us 11 pins without buttons or car signals.

we need 3 digital read pins to talk to the car. vss,inj,ign power.
and each button will need a pin, so maybe 4 there.
piezo speaker for another 1, would be good for the "your mpg is dropping" alert.

[MetroMPG]

Can we combine 2 buttons simultaneously pressed for some fuction, such as "home"? That could let us get away with 3 buttons with 4 button functionality (assuming just one "combo" button). Might not be the best usability though. Just a thought.

[dcb]

I think the answer to the number of buttons happens to be 3 And they will be in the upper right corner.

I sat it in the car, it is the same height as a scangauge but about two inches narrower, and fits. I pretended to use the buttons, and am of the conclusion that a small cluster of them is better than spreading them around.

upper right corner was the easiest place I could get to them and still see the screen.

3 because that is what fits in the upper right with sufficient space between the buttons, with sitting flush with the lcd and not increasing the profile.

So just need to glue down a block there of the right thickness, solder up the switch leads, with a common ground and three signals, and glue them to the block.

edit: re chording buttons. I was actually looking at those earlier today, that is weird. I think the only chord that people might intuitively know is the soft reset, where you mash everything down.

[MetroMPG]

Agreed about combining buttons. Probably not the best (intuitive) idea.

I also agree that a cluster is best - as Trebuchet pointed out earlier, you'll learn which ones you need to press and eventually will be able to do it without looking. Cluster = useful tactile feedback for selecting the right one.