Go Back   EcoModder Forum > EcoModding > Instrumentation > OpenGauge / MPGuino FE computer
Register Now
 Register Now
 

Reply  Post New Thread
 
Submit Tools LinkBack Thread Tools
Old 03-23-2011, 12:08 AM   #11 (permalink)
dcb
needs more cowbell
 
dcb's Avatar
 
Join Date: Feb 2008
Location:
Posts: 5,032

pimp mobile - '81 suzuki gs 250 t
90 day: 96.29 mpg (US)

schnitzel - '01 Volkswagen Golf TDI
90 day: 53.56 mpg (US)
Thanks: 156
Thanked 264 Times in 207 Posts
I can entertain that, but understand that I do have "standards" for reliability and etc.

Also it really need some help on the low impedence injector front, some simple circuit that works. And the buttons could use better debouncing, was thinking of the event scheduler for that (schedule a re-enable of the button after x ms). And I know folks like the sparkle, but a bsfc indication (perhaps only accurate on the flatlands w/no wind) and CDa calculators could actually be useful for modders.

__________________
WINDMILLS DO NOT WORK THAT WAY!!!
  Reply With Quote
Alt Today
Popular topics

Other popular topics in this forum...

   
Old 03-23-2011, 12:26 AM   #12 (permalink)
EcoModding Lurker
 
FalconFour's Avatar
 
Join Date: Sep 2010
Location: Fresno, CA
Posts: 78

LEAF - '11 Nissan LEAF
Thanks: 4
Thanked 9 Times in 7 Posts
Haha... well, I'm a UI and software guy, the hardware side of things has always eluded me. It took me weeks just to track down the bugs in my home-etched Arduino S3V3 (single sided serial v3) board wasn't working... perhaps because I used different value capacitors over the crystal? Yeah, I'm pretty bad with the electronics side. But the UI side, I spend minutes sitting here thinking about every permutation of where the characters on the screen should go, and every condition they would be used in (like sitting at a stop light, filling at the gas station, getting into the car, getting out of the car, etc)... then I consider the best way to put them on the screen. That's where most of my effort is going: making the UI easier to use. And debouncing the buttons is definitely something I plan on implementing in the software, I see that a lot already, especially when exiting my config menu, always seems to adjust the brightness (another thing I plan on menu-izing).

As for reliability, absolutely highest priority to me. Nobody wants an unstable gauge, as the unexpected power-cuts and accidental tank-reset-key-combo presses have caused me huge amounts of frustration in the past (those "arrrgh!" moments I mentioned). The mods on my mpguino (sure you've seen the thread ) have been 100% stable so far, even down to the clock ticking to the exact second weeks later (I had to update it for daylight savings time!). I should be able to carry the same reliability over to the new code, no small thanks to the excellent work you've already done with the timing and interrupt routines. Much of the same structures I plan on porting over to the new UI, like the 500ms screen looping and timing. That stuff works amazingly well, judging by the fact that my flawless-to-the-second clock is timed by the number of display refresh cycles!

Not sure about "And I know folks like the sparkle, but a bsfc indication (perhaps only accurate on the flatlands w/no wind) and CDa calculators could actually be useful for modders." though I've lately been thinking of an acceleration calculation, and merging that with the GPH data to show "how much gas it's consuming to make me go this much faster", but is that what you're referring to?
  Reply With Quote
Old 03-23-2011, 01:47 AM   #13 (permalink)
EcoModding Lurker
 
FalconFour's Avatar
 
Join Date: Sep 2010
Location: Fresno, CA
Posts: 78

LEAF - '11 Nissan LEAF
Thanks: 4
Thanked 9 Times in 7 Posts
Alright. Here's the general layout of the various screens. Yeah, talk about fun, cramming all this info in there!



The system is centered around the "main screen" (see [START]). There is always a "position indicator" on the side of the screen showing where you can go, in all menus, in all screens. I know, it wastes 1 of 16 characters, but it really helps gain a point of reference in the UI. The parameters can be changed on-screen, so you can show the combination you want to see - personally, I like showing instant MPG with instant GPH, as most of my gas seems to be wasted idling. (oh, crap, I forgot idle in the current/tank stats - I'll fit those in.) But I occasionally want to glance at my current stats and tank stats. Those would be accessible with a combo key press (center+l or center+r), which breaks out of "instant mode" and lets you flip through the modes, unless the selection times out (goes back to instant mode) or is confirmed with center (goes to that mode). Then, you can view the page until you hit center to exit and go back to instant. That's the system I think would be most useful, as it's rare I would stare at the "current" screen for any extended period of time while driving.

"Idle" or "Screensaver" mode would dim the screen (configured level) and display a clock and a graphic (maybe - we have 8 custom chars to work with, just enough space). It would alternate between remaining miles (based on tank MPG and tank gallons), and tank average MPG. It would go into this mode in the same way as it currently dims the screen... but the big problem with the current mode is that it also clears all "current" values (what if I wanted to view my last trip's info?). It'd wake up on any button-press (without performing that button), but wait until it receives a VSS or injector pulse before clearing the current data.

"Settings" would be a list of configurable options, both preferences and system settings. Simple enough... select from the list and it enters the config menu as it currently does, just a little easier to "escape" from (just hit "X" and it backs out to the menu). Some menus would be application-specific, like "contrast", which would load custom characters and display a "bar" that no longer has us poking around various digits and getting our screen messed up for tweaking the wrong digit

And last (so far) but not least, "Big" mode of course employs the "improved large font" for easier readability, and perhaps if I can shuffle custom characters around, I can also display a small "peak meter" using the remaining 4 characters on the lower line. Or something. That may not be doable, but it's a thought.

Thoughts?
  Reply With Quote
The Following User Says Thank You to FalconFour For This Useful Post:
TOOQIKK (03-23-2011)
Old 03-29-2011, 12:46 PM   #14 (permalink)
EcoModding Lurker
 
mcmancuso's Avatar
 
Join Date: Mar 2010
Location: TN-USA
Posts: 61

Green Metro - '99 Chevrolet Metro LSi Sedan
90 day: 32.78 mpg (US)

Metro Vert - '91 Geo Metro LSi Convertible
90 day: 50.52 mpg (US)
Thanks: 0
Thanked 1 Time in 1 Post
I just got my MPGuino and have been working on these changes as well, incorporating the round big font into the .86 build I did just last night, and I started on incorporating the save to eeprom/graphs etc.. functions. I can send you my code, either complete, or just the changes. Here's the modified (changed to proper .cpp format) code for the round big font (copied from the hacks page with corrections):


Start by adding this line near the top of the mpguino.pde file:

#define CFG_BIGFONT_TYPE 2 // 1=Default 2=Modified

By setting this to '1' before you compile, you'll get the current font. Set it to '2' and then recompile, and you get the new, 'rounder' big font. The big font adds about 20 bytes to the compiled code size.

Find the declaration for bignumchars1 and bignumchars2. Delete these lines. Now add the following code near the top of the file, probably right underneath the CFG_BIGFONT_TYPE line you see above.

#if (CFG_BIGFONT_TYPE == 1)
//32 = 0x20 = space
const unsigned char LcdNewChars = 5;
const unsigned char LcdCharHeightPix = 8;
char bignumchars1[]={4,1,4,0, 1,4,32,0, 3,3,4,0, 1,3,4,0, 4,2,4,0, 4,3,3,0, 4,3,3,0, 1,1,4,0, 4,3,4,0, 4,3,4,0};
char bignumchars2[]={4,2,4,0, 2,4,2,0, 4,2,2,0, 2,2,4,0, 32,32,4,0, 2,2,4,0, 4,2,4,0, 32,4,32,0, 4,2,4,0, 2,2,4,0};
#elif (CFG_BIGFONT_TYPE == 2)
//255 = 0xFF = all black character
const unsigned char LcdNewChars = 8;
const unsigned char LcdCharHeightPix = 8;
char bignumchars1[]={7,1,8,0, 1,255,32,0, 3,3,8,0, 1,3,8,0, 255,2,255,0, 255,3,3,0, 7,3,3,0, 1,1,6,0, 7,3,8,0, 7,3,8,0};
char bignumchars2[]={4,2,6,0, 32,255,32,0, 255,2,2,0, 2,2,6,0, 32,32,255,0, 2,2,6,0, 4,2,6,0, 32,7,32,0, 4,2,6,0, 2,2,6,0};
#endif

The above will eventually tell the LCD how to represent the new characters. bignumchars1 is line 1 of the LCD, and bignumchars2 is line 2. Each grouping of four numbers ("null-terminated" with a zero) points to the new characters we will define next. So for example, the large font number zero consists of:

Special character 7, 1, and 8 on line 1, and special characters 4, 2, and 6 on line 2.

Entries above like 255 and 32 point to already-existing characters in the LCD. 255 (or 0xFF in hex) points to a character that is a solid block. 32 (0x20) is a space (empty character).

Now find the chars[] declaration. Delete it, and replace it with this:

#if (CFG_BIGFONT_TYPE == 1)
static byte chars[] PROGMEM = {
0b11111,0b00000,0b11111,0b11111,0b00000,
0b11111,0b00000,0b11111,0b11111,0b00000,
0b11111,0b00000,0b11111,0b11111,0b00000,
0b00000,0b00000,0b00000,0b11111,0b00000,
0b00000,0b00000,0b00000,0b11111,0b00000,
0b00000,0b11111,0b11111,0b11111,0b01110,
0b00000,0b11111,0b11111,0b11111,0b01110,
0b00000,0b11111,0b11111,0b11111,0b01110};
#elif (CFG_BIGFONT_TYPE == 2)
/* XXX: For whatever reason I can not figure out how
* to store more than 8 chars in the LCD CGRAM */
static byte chars[] PROGMEM = {
0b11111, 0b00000, 0b11111, 0b11111, 0b00000, 0b11111, 0b00111, 0b11100,
0b11111, 0b00000, 0b11111, 0b11111, 0b00000, 0b11111, 0b01111, 0b11110,
0b00000, 0b00000, 0b00000, 0b11111, 0b00000, 0b11111, 0b11111, 0b11111,
0b00000, 0b00000, 0b00000, 0b11111, 0b00000, 0b11111, 0b11111, 0b11111,
0b00000, 0b00000, 0b00000, 0b11111, 0b00000, 0b11111, 0b11111, 0b11111,
0b00000, 0b00000, 0b00000, 0b11111, 0b01110, 0b11111, 0b11111, 0b11111,
0b00000, 0b11111, 0b11111, 0b01111, 0b01110, 0b11110, 0b11111, 0b11111,
0b00000, 0b11111, 0b11111, 0b00111, 0b01110, 0b11100, 0b11111, 0b11111};
#endif

The above are binary representations of the pixels for the custom characters that we will upload to a special scratch area in the LCD. Each 'block' above is a number in the character generator RAM starting with 1 and going up to 8.

Now find the code that looks like this below, and either alter it so it looks EXACTLY like this, or just delete it and replace it with this:

/* write the character data to the character generator ram */
for(byte x=0;x<LcdNewChars;x++) {
for(byte y=0;y<LcdCharHeightPix;y++) {
LcdDataWrite(pgm_read_byte(&chars[y*LcdNewChars+x]));
}
}

I could not figure out how to cram more than eight characters into the LCD's CGRAM. If anyone can help with this I would add a few more characters to make this font even nicer. By following the above structure, you can see how to add a CFG_BIGFONT_TYPE 3, and create your own font variant.
(adapted from skelly)


I can also provide the complete .cpp with this change already in it, or the .cpp with this change and the "Save Current Tank Data / Archive Tank Summary / Track Gas-Used per Speed Range" code added(this part of code still has some errors, but its all in the right place ready to be corrected)

Last edited by mcmancuso; 03-29-2011 at 12:52 PM.. Reason: typos
  Reply With Quote
Old 03-29-2011, 12:48 PM   #15 (permalink)
EcoModding Lurker
 
mcmancuso's Avatar
 
Join Date: Mar 2010
Location: TN-USA
Posts: 61

Green Metro - '99 Chevrolet Metro LSi Sedan
90 day: 32.78 mpg (US)

Metro Vert - '91 Geo Metro LSi Convertible
90 day: 50.52 mpg (US)
Thanks: 0
Thanked 1 Time in 1 Post
oh yea, I also put together a working makefile for assembling this in linux which I'd also be happy to share with whomever would like it.

The only extra bit of code I'd like to see is a miles remaining to empty (based on full tank upon reset of tank) As I do a lot of long range driving and my gas gauge is less than spectacular(Metro gas gauges suck)

Last edited by mcmancuso; 03-29-2011 at 01:00 PM..
  Reply With Quote
Old 04-15-2011, 12:25 PM   #16 (permalink)
EcoModding Lurker
 
Join Date: Sep 2010
Location: Minnesota
Posts: 14
Thanks: 0
Thanked 0 Times in 0 Posts
Any updates on this? I would love to have more features on my preassembled MPGuino. How difficult would it be to wire up a usb port on my MPGuino and just flash this new firmware?
  Reply With Quote
Old 04-15-2011, 01:09 PM   #17 (permalink)
EcoModding Lurker
 
mcmancuso's Avatar
 
Join Date: Mar 2010
Location: TN-USA
Posts: 61

Green Metro - '99 Chevrolet Metro LSi Sedan
90 day: 32.78 mpg (US)

Metro Vert - '91 Geo Metro LSi Convertible
90 day: 50.52 mpg (US)
Thanks: 0
Thanked 1 Time in 1 Post
Its a PITA to attach a USB to the MPGuino, its easier to use an arduino board(as a socket and power supply) and a tinyUSB to flash the chip, especially since the MPGuino chip does not have a bootloader on it. I'm still working on the conversion for the additional features, I'm not a very good programmer and its taking me a long time to figure out the intentions of the writers of the other features. Trying to figure out where to put additional code into the existing code is complex and confusing.
  Reply With Quote
Old 04-15-2011, 01:35 PM   #18 (permalink)
EcoModding Lurker
 
Join Date: Sep 2010
Location: Minnesota
Posts: 14
Thanks: 0
Thanked 0 Times in 0 Posts
I suppose that would be easier. Do you have a dropbox with the code you have and progress you have made? I'm not much of a programmer but I could see if I can help. My knowledge doesn't go much further than VB and HTML but who knows. I also my know some people that could help.

Possibly once the code gets to a point where its stable maybe offer a preflashed ATMEGA328 chip to existing mpguino preassembled units? Just a thought.
  Reply With Quote
Old 04-15-2011, 01:47 PM   #19 (permalink)
EcoModding Lurker
 
mcmancuso's Avatar
 
Join Date: Mar 2010
Location: TN-USA
Posts: 61

Green Metro - '99 Chevrolet Metro LSi Sedan
90 day: 32.78 mpg (US)

Metro Vert - '91 Geo Metro LSi Convertible
90 day: 50.52 mpg (US)
Thanks: 0
Thanked 1 Time in 1 Post
yeah, I actually keep all my work on this in dropbox, PM me your email address and I'll share it.
  Reply With Quote
Old 04-17-2011, 10:25 PM   #20 (permalink)
EcoModding Lurker
 
FalconFour's Avatar
 
Join Date: Sep 2010
Location: Fresno, CA
Posts: 78

LEAF - '11 Nissan LEAF
Thanks: 4
Thanked 9 Times in 7 Posts
Agh, I need to check back here more often.

I've been starting work on the MPGuino rebuild, centering first around cleaner code, more tightly integrated into the Arduino platform, to enable more people to participate in its development (and take better advantage of the new 328 chip).

I'm first working on moving over the essential functions of MPGuino - the core loops of calculating the raw figures used in the program, initializing the LCD (hopefully using Arduino LCD library), interrupts, I/O, etc. MPGuino's strong point is that it's very accurate and reliable, and its weakest point is its poor user interface design. I'm working first on duplicating that accurate and reliable point, and then working on re-writing the entire user interface to be more usable (see the previous scanned page for the UI plan).

Now that I finally started on it, you can probably expect some kind of code post either later tonight or a little later in the week... I expect this to go pretty quick once I actually start really working on it

  Reply With Quote
Reply  Post New Thread


Thread Tools




Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.5.2
All content copyright EcoModder.com