Release Two Workspace (/Fork name TBD)

[msc]

I like the goals of the project and have a few comments.

Keeping the code so it can be configured to run on the existing MPGuino hardware is a good thing. Limiting it to only running on the existing hardware would limit the potential of the effort.

The existing MPGuino hardware does a great job of keeping the hardware cost to a minimum so it's important to support. Keeping the code flexible to run on alternate hardware will help support hardware updates that would be necessary for some additional features like throttle body injection and voltage display. By alternate hardware I mean different I/O configuration/features but sticking with the same processor.

The two main features I see as beneficial to add would be support for pulse & hold injectors and support for throttle body injection. The pulse & hold injector support is strictly a interface circuit issue. For throttle body injection support both injectors would need to be monitored so there are hardware and software changes that would need to be made.

I don't have much in the way of programing skills to contribute but I have a lot of experience developing interface circuitry and building hardware.

I'm picturing a spinoff version of the hardware that adds support for extended features. Voltage is an easy add. PWM type pulse & hold is simple to support. I have some thoughts on the linear drive pulse & hold and could do some testing if there is demand. Clock would be a great add, for my needs the software clock would be fine but there are some advantages to going with the RTC option. I would like the USB port for software updates and it might also be used for streaming data.

It's important to not get too carried away with features or the cost and board size get out of control.

Mike

[FalconFour]

The limitations I'm dealing with right now are that the existing hardware uses unusual pin placement that seems to almost require custom (non-Arduino) AVR code to implement the interrupts properly... whole boatloads of freaky stuff in the setup routine like "EICRA = (EICRA & ~((1 << ISC00) | (1 << ISC01))) | ((parms[injEdgeIdx] == 1 ? RISING : FALLING) << ISC00);". Stuff that could probably be implemented in Arduino language with attachInterrupt() if it were on a different pin. So I'm completely copying over the functions of handling pulse-tracking and basically the whole data-monitoring core of MPGuino, straight from v1 to v2. That ensures the 100% reliability of the existing system carries over to the new code, and leaves UI and computation up to the imagination. It also means we're really limited to what we can change in hardware. Even the difference between delay2() and delay() is huge, since something in the MPGuino code affects usage of delay() (hint: it doesn't delay anymore since timer2 is modified). And that might affect other things. So it becomes a tangled mess of inter-related functionality that just complicates things...

But it can still be done. Last night I was just concentrating on making the existing code work right, and I spent over an hour going over why it wasn't working before I found that the genius decision was made to add a main() loop as WELL as a setup() loop (I had just copied "setup" over), and main() was what initialized the interrupt modifications. Now that it's up and running I can concentrate on changing things to work better and more flexible, implementing Arduino code whereever possible (since it's already being added to the code, why not use those, which are actively developed, and drop the custom utility routines).

Planned features:
- A streamlined, user-friendly UI with much more flexibility and ease-of-understanding than the existing UI (this is the most complicated part)
- A menu system for configuring parameters/settings, and UI preferences
- A software "real time clock" (currently working 100% accurate for weeks on my MPGuino mod), that is used in various places, including in statistics (instant/current/tank)
- Tank save/load to/from EEPROM whenever it goes to "screensaver mode" - no more lost tanks, ever.
- Screensaver mode - idle mode that displays a small graphic, the current time, and various configurable stats like a RSS ticker. (still not 100% sure on how to best implement the stats display, but graphic is a done deal, yes, on the current 16x2 MPGuino display; see "duck" in my mod)
- Flexibility to add more features for anyone that knows how to code

[FalconFour]

BTW, anyone got any ideas for what to name this thing? I really have no idea. MPGuino v2 would be nice for its "officialness", but dcb doesn't want the MPGuino name used for "forks" like this (I really wish it weren't a fork... oh, open source spirit, wherefore art thou)... plus I really find "MPGuino" very difficult to actually talk about since it's an unusual mashup that can be neither pronounced, nor spelled, without sounding awkward. I'd really love to hear any ideas... because "FalconFour's MPGuino v2.00" is sure as hell not what I'd want to put on the screen =P

I really like the idea of expressing "OpenGauge" as the hardware platform we're designing the software to run on, and the name we come up with represents our version of the software that "runs on" the OpenGauge device. So "for OpenGauge" might add a nice ring to whatever we come up with

[mcmancuso]

How about OpenGaugeFF

[steffen707]

How about FalconEco or EcoFalcon

[dcb]

Lol, how about a CDA or BSFC calculator?

[bobski]

Originally Posted by dcb

how about a CDA or BSFC calculator?

To calculate Cd you need to know:
ρ (rho), the density of the fluid (constant). In this case air. Check.
v (velocity). VSS frequency, or averaged pulses over time. Check.
A (frontal area). Although inconvenient, this can be measured. Check.
Fd (drag force). I'm not sure how this could be actively measured.
Maybe replace an engine mount with a strain gauge? That would still require calibration. Even then, we would be measuring net drag rather than aerodynamic drag.
If you know the vehicle's mass, I suppose you could do a coast-down on level ground, tracking the vehicle's speed along the way (F=M*a). The rate of deceleration at very low speeds (where aero drag is negligible) should let you gauge mechanical drag. Once the fixed drags are known, they can be subtracted from measurements taken at higher speeds where aero is playing a significant role.
While it would certainly be a useful instrument when working on aero mods, I don't see it having any use during day to day driving. Altering your speed, throttle behavior or drafting won't affect your Cd or Cd*A.

What would be useful IMO is a bar graph of where energy is going. Typical physics class stuff: kinetic, potential and other (drag) bars. This would require some way to gauge engine power output. BSFC (brake-specific fuel consumption) is basically fuel consumption / power output, so that requires some means of gauging power as well. Kinetic energy is easy - mass and velocity... Mass is fairly fixed, and velocity is easily measurable. Differentiating between drag and potential energy would require either directly measuring drag (via a strain gauge or something), or directly measuring vertical changes. An altimeter would probably be the cheapest but least accurate method, due to pressure changes from wind buffeting and such. GPS is probably the most expensive, but not terrifically accurate. A 6 degree-of-freedom accelerometer/gyroscope chip could be used in conjunction with the vehicle speed to judge when the car is traveling up or down hill... Expensive for a bar graph though.

Maybe a pitot tube could be useful?

[msc]

A few thoughts and comments on naming conventions.

To help guide the name of this effort I think it would be helpful to establish what exactly the names OpenGuage and MPGuino apply to and perhaps who they belong to.

I haven't read enough of the early project posts to know if OpenGauge was originally envisioned to be the name of one instrument or possibly a family of instruments.

It seems clear MPGuino was meant to be the name for an Arduino based MPG instrument.

I understand dcb's concern about name confusion and if other initiatives use MPGuino in the name it will lead to headaches for him as others expect him to resolve technical problems he had nothing to do with. But does any contributor to an open source project really have claim to the name or any design details? Is there a GPL referenced for the opengauge project that says anything on the subject? As a courtesy to someone who has made a major contribution to the project it would be good to respect dcb's wishes on the use of the MPGuino name.

From the standpoint of branding and naming conventions this is what makes sense to me. Use OpenGauge as the brand name for a grass roots effort to develop open source instrument designs for the masses. Use MPGuino as the name for the Auduino family of MPG instruments developed by this group.

What doesn't make sense to me is restricting the use of the name MPGuino to a version of software that no longer supports the Arduino platform for which it was named. Shouldn't that now be called MPG.ccp?

In the end I think the best thing that could happen would be if the rewrite proves to be stable and easier to use, eventually winning dcb's approval to call it "MPGuino 2.0".

There was a kit for another version of MPGuion hardware. There is a wiki that has directions for assembling an MPGuino from an Arduino board. And of course there is the current assembled version of the MPGuino. If there is an obvious name for a software update that will run on these devices it's going to include MPGuino.

If the obvious name can't be used I toss out the following ideas: MPGspork, OpenGauge Code 2, or Arduino Gauge.

I'll watch from the sidelines and leave the political debate to those who care. I would suggest a separate thread to discuss naming conventions so that this thread can focus on technical details of improving the instrument.

Mike

[dcb]

Originally Posted by bobski

...
While it would certainly be a useful instrument when working on aero mods, I don't see it having any use during day to day driving. Altering your speed, throttle behavior or drafting won't affect your Cd or Cd*A....

That isn't the point. Having a menu function to determine your CDA is meant to enable folks to make aeromods, because they are such an important part of modding for efficiency. Even if it is a relative number, that is useful information(same for bsfc improvements). It can make some assumptions about current air pressure and temp and just do some precise coastdown monitoring and display the results.

[bobski]

Originally Posted by dcb

It can make some assumptions about current air pressure and temp and just do some precise coastdown monitoring and display the results.

Why even bother with the Cd calculations then? Just make it measure coast-down time, broken into a series of measurement windows; perhaps in 1 or 2 MPH increments. Deceleration can be directly calculated from those values, or you can just look at the times... Longer times means slower deceleration means lower drag. Boiling it all down to a single Cd number is great for bragging, but really provides less useful information to the tinkerer.