Announcing a complete solution to mapping engine efficiency

[ECONORAM]

ummm. WOW! I cannot seem to view the pdf, but this is fascinating. Very impressive. I am curious, but not sure I want to try one out yet.

[RobertSmalls]

Bump.

Tasdrouille, have you received your AVRDragon? Had a chance to play with it?

I still need a cheap 2+ channel datalogger with a high sample rate. Accelerometers would be a bonus. Kubark's MATLAB scripts would be awesome.

[tasdrouille]

Nope, no news from Kubark.

[Funny]

This is the kind of scientific data that one enjoys after having two cups of coffee and has a dictionary handy, I Love it! Thanks for posting this and please come back with an update!

[IamIan]

Originally Posted by kubark42

Repeatability is repeatability. I’m not a fluids expert, but I do expect that the gas station pump is accurate to beyond 0.1%.

While that would be nice ... your a bit off.

In the U.S. the department of weights and measures for each state sets , monitors , and enforces the standards for acceptable error.

There is a sticker on the pump that indicates when that specific pump was last inspected.

The old standard was 6 cubic inches per gallon ... which was pretty good ... pumps had to be within +/- about ~2.5% ... if they were off by more than that the pump would be closed down until it passed and the operator would get fined ... most states did not fine more than about ~$500 ... but it does vary from state to state.

The new standard allot of states in the U.S. are going to now is +/- 6 cubic inches per 5 gallons ... which pushes the pumps to being +/- about ~0.5% ... it still varies from state to state... some places still use the older standards ... others have lower or higher fines etc.

But while 0.1% error rate is possible ... I do not know of any state in the U.S. that has a department of weights and measures that requires that level of accuracy.

So if a pump were off say ~50% when it was tested once per year... the owner might get fined ~$500 ... ... and have to close that specific pump until it was fixed ... but no notices or refunds to any customers... who might have been ripped off.

azcentral.com/news/articles/2008/07/01/20080701biz-gaspumps0630.html

add www in the beginning

In 2007 about ~9% of the gas pumps in Arizona failed to pass and were fined ~$300 each ... Arizona checks the pumps in the state once every ~3 years...

A disparity of 6 cubic inches draws a citation, Meissner said. There are 231 cubic inches in a gallon.

Among some of the major offenders, according to The Arizona Republic's record search:

• Six high-flow diesel pumps at Sunmart in Ehrenberg were off from 120 to 200 cubic inches in May 2007.

So for as long as 3 years there was a pump that was off 200 cubic inches out of 231 cubic inches ... a horrible ~86% error ... for sometime less than ~3 years ... and in Arizona pumps have a maximum fine... $5,000 if a pump is still off beyond that ... they reach the limit ... and in Arizona Operators have maximum fines as well ... and some maxed them out... and even though they were still in violation and their pumps were still inaccurate ... they were not allowed to be fined any more.

It depends on where you live ... I recommend contacting your state department of weights and measure and see what their policies are for pump accuracy ... and what kind of fines ... etc.



- - - - - - - - - -

Originally Posted by RobertSmalls

Hmm, produce power until you have enough energy to coast across the finish line, leave the engine off whenever it's not required, cycle the engine off and on to keep the vehicle speed such that the engine speed is at the peak of the efficiency curve. What am I missing?

Just keep in mind that while that may be efficient for the engine... speed fluctuations are inherently inefficient in terms of aerodynamics ... so there is eventually a break even point where the losses outweigh the benefits.

Originally Posted by RobertSmalls

The Insight's current sensor outputs about 25mA per amp of battery current. Battery voltage varies from ~140V to ~168V at rest, and probably varies more under load. If you log both channels and consult a motor + inverter efficiency map (efficiency is a function of RPM and torque), it should be possible to estimate electric drive torque. Whether that estimate will be accurate enough to be useful, I don't know.

FYI ... there is a fellow Gen 1 Insight driver in the U.K. who has done a fair amount with the Insight's IMA battery pack and electronics... including a BCM display for you to be able to see allot of that kinda of data.

solarvan.co.uk/index_files/Page577.htm
add www in the beginning.

[oldbeaver]

I read yr paper but really couldn´t understand what does this instrument performs.

If you can answer some questions, I may give an opinion:

a) What is the objective of this "instrument"?
b) What are the input signals?
c) What are the output results? How are they shown if no screen?
d) How are these outputs used? How can one take advantage of them?

My first impression is that the paper is more academic than practical. Notation is scientific. Maybe too academic.

On my side, I have some ideas that I cannot turn into practical results. I tried, but I failed. Maybe you can.

Making a cruise control that uses a different input control signal than speed. This may be a range of mpg, a constant throttle, some rpm range, etc.

Taking this to a second derivative level, we may set the onboard computer to choose from several cruise control options to choose the one that is best for some driver objective or preferences.

In a third level, we may ask the computer advice for a particular route trip. For instance, given some driver input criteria, such as "I want to get there at best mpg but in less than one hour" and the X, Y, Z route map, order the computer to drive under the best driving pattern.

The computer may say "not feasible". Then should report where are the constraining unfeasibilities or suggest a relax of some (like increase time to get there).

Maybe these developments may improve cruise controls a lot and save fuel.

Oldbeaver

Originally Posted by kubark42

(Acknowledgement: This project was inspired and made possible by the MPGuino.)

As part of an extensive research project in optimal control, we have developed a sensor suite that we think can be used to map the engine efficiency of YOUR particular car. The engine efficiency is derived from logging data under normal driving conditions for any individual car. In fact, engine efficiency is probably a misnomer, as we are actually calculating complete system efficiency, including drivetrain losses, etc...

While similar to the MPGuino, this project has some notable differences: 1) no screen, 2) GPS logging, 3) accelerometer, and 4) saving data to an SD card.

The principle and application is described in short here:

http://www.eissq.com/ponthy/preprint.pdf (I had to resort to the obscuring the HTML because of the anti-spam features. I'll delete them as soon as the website says I have enough posts to have the right to post links.[Thanks MetroMPG for fixing it.])

As indicated in the above pdf, the solution is comprised of two parts: a hardware logger (shortly described above, with more details later) and a software package based on an Extended Kalman Filter.

The software package is complete, and is more or less in fire-and-forget state. It’s in alpha because documentation is lacking and it would take a few back-and-forths with me to properly set up your Matlab environment.

The software outputs the engine fuel efficiency, and gives you some other nifty outputs, such as the included Google Earth trip tracking (where color indicates speed).

I have full hardware schematics available, and will distribute the originals on demand. I am providing the jpgs for those curious.

In continuing this research, I would like to extend this project to cars outside the few we are already following. We are looking for people who would like to help us out. We are giving away the Eagle schematic and AVR code base in hopes that some of you will be motivated to build your own, with technical assistance from us. In theory, anyone can build one of these, although in reality the two SMC components (ATMega chip and accelerometer chip) are much easier with an oven. The overall parts cost, not including the GPS and board, can be brought in at well under $20. The GPS can be anything that can output NMEA sentences over a serial port. (I use a FV-M8 at 5Hz.)

As of this moment, I have ~10 circuit boards that are completed and tested, and another two for an upgraded model that awaits soldering. I will give these away for free to anyone interested in installing these units. I will include the AVR, the accelerometer, and the SD Card adaptor, as these might be hard to find. The rest are OTS components: resistors, capacitors, etc… I ask only that people pay shipping.

I also have a new version already written and debugged for the XMEGA, which solves some of the limitations of earlier models. It simply remains to finish the circuit schematic and fabricate the boards. If someone were to complete the circuit schematic for the XMEGA, I would be able to run off 10 or so boards, and then distribute them for free.

This could also be ported to the Primer2 or STM8S-Discovery platforms, if someone were so inclined. Thus you have the convenience of the MPGuino with the power of the Kalman Filter. I can offer a bit of assistance on these projects, but not as much as for the Primer2.

For those of you who have a CAN bus, I also have code for a $75 CAN reader, one where you have nothing to solder but one single 8-pin chip.

If it happens that any of you are in Luxembourg, Luxembourg or Auxerre, France, then I can give you a free working model and help you install it.

If anyone in the community is interested in the programming side of this project, the biggest help would come from converting some of the matlab files into C, Python, or some other language that can run on anyone's computer, without having a multi-thousand dollar software license.

I am interested in any and all comments that can help us improve this. (Notably, I am struggling to explain why I get a fuel efficiency that is globally too high, even if the shape of the curve seems to be spot-on. Which in the end is all that is important, as relative efficiency between engines and engine operating points is far more useful than absolute efficiency.)

As I get an idea of the community and internet’s reaction to this project, I will make a website that explains it a bit better. I admit that this post is a bit disorganized, but alas such is the limitation of forums. Unfortunately, as a result of having spent years on this project, I suffer from being too close to the problem and thus am likely assuming that things are clear when they are anything but. Don't be shy, let us know what you're thinking!

[RobertSmalls]

Ian,

That post of mine was an answer to a strictly academic puzzle posed by Kubark, which involved a car running (on bottled oxygen or chemical oxygen generators?) in a vacuum.

Beaver,

I'm very sorry to say that this appears to be a "dead project", but perhaps I can answer some of your questions.

As I understand it, the intermediate goal was to have a datalogger that gathers enough data to infer road load, and measure fuel consumption. This is enough to plot BSFC versus various conditions, including throttle position, RPM, engine temperature, etc. You could also plot road load versus time. Analyzing your shift pattern and your commute in this detail would be extremely helpful.

Someday, this might lead to development of a real-time BSFC gauge. That, plus a road load gauge, would be the holy grail of instrumention.

[oldbeaver]

I am a little confused about who did the new instrument design and paper. Sorry for that, that´s why I am not labeling this email to a person.

Let me think as I write: From what I understand, mapping the behavior of a particular car with respect several or all the variables that condition it's fuel yield, would allow us to graph everything. Ok.

We may even model (mathematically) all this behavior as a multivariant model (for example), having fuel yield (but not only that) as the dependent variable (or vector) that we want to estimate, under several driving conditions, represented in the model by variables like wind, slope, curves, and some control variables like throttle, speed, rpm, etc.

I continue thinking... then we may study this model and discovery or determine the best driving pattern for my car, given certain conditions, goals and restrictions.

Sumarizing, I may study my trip previously, and choose how I will drive to attain my objectives for that trip, for example, drive with minimum consumption from A to B under certain conditions, for example, in not more than 1 hour and with a minimum speed of 30 miles/hour and a max speed of 70miles/hour.

Is that the idea? Sounds very interesting.

I continue thinking: suppose you succeed with this project, and I and several others install this beauty in the car, and a file with data come out as a output. What happen then?

By the way, can you tell what is the meaning of BSFC?
Second, why do you call yr project a "dead project"? What do you mean?

Very interesting idea, not easy to perform.

Old Beaver

[2009Prius]

Originally Posted by RobertSmalls

...
I'm very sorry to say that this appears to be a "dead project"...

That's too bad!

[RobertSmalls]

Beaver,

Yes, that's the idea.

It's a "dead project" because the guy who was maintaining it (Kubark42) hasn't been heard from in a long time and is presumably no longer pursuing the project. I haven't done any development work here, I'm just enthusiastic about the idea and I'd like to see someone go forward with it.

Ian, if you work on some sort of BSFC gauge, keep us posted, and let me know if I can lend a hand at all.