Drivetrain measurements

[dcb]

I can also choose to question your faith in the ECU readings, no? I'm not sure you fully comprehended my previous message at this point.

[dcb]

I don't know where the disconnect is here, but let me take it one issue at a time I guess, and ask that you accept this as constructive with the goal of ensuring accuracy in interpretations and conclusions regarding "transaxle efficiency" and have some faith that I have reasonably in-depth understanding and experience in these things in general. Being open to constructive criticism can only strengthen your position.

Lets address the lack of mg1 sensors a second (hopefully you already understand some of the concerns in converting current to a real torque value, which is what the ECU seems like it is doing).

A few sites seem to infer mg1 parameters from mg2, i.e. in
Request help on decodes for MG1 / MG2 rpm - PriusChat Forums

* MG2 rpm =~road speed in mph x 57
* MG1 rpm =(3.6 x engine rpm) -(2.6 x MG2 rpm)

There is nothing unusual in automobile ECUs about inferring what is going on based on indirect readings, my saturn is a prime example where they saved a few cents by programming the gear ratios into the transmission instead of adding a clutch switch, or were able to eliminate the cam position sensor entirely by looking at other parameters. It happens all the time, the prius, or "aftermarket" tools are no exception.

But in regards to your stated goals, "measuring transaxle efficiency", where this figure will be publicly available, I need to point something out.

So if, like I was questioning in the other thread, we try to "measure" the efficiency of the circuit between MG1 and MG2 when the battery is inactive, and the MG1 parameters are derived from MG2 in the ECU black box (and not really guaranteed accurate without further research), then we are not necessarily looking at a real measure of MG1->MG2 efficiency, we are simply reverse engineering the MG1 power reporting code.

Can you let me know if that much make sense?

[bwilson4web]

I reworked my 'normalize' routine so it is now data independent. Graham miniscanner data is one record per observation with a time-stamp which makes analysis difficult. The 'normalize' routine collects all of the samples until it is about to repeat. It then writes them as a CSV record with the average of the time-stamps also giving a 3x reduction in file space. Even if the number of observations per cycle changes, in this case 4 vs 6, the missing data can be handled by a straight-line approximation in the spreadsheet.

I've attached the new format, and Friday data to this note:

• MG1 Nm
• MG2 Nm
• MG1 rpm
• MG2 rpm
• Battery Volts
• Battery amps

The new data is for the same route I used in the first post:


START ACCELERATION

This time I was parked where I could monitor on-coming traffic and wait until there was a pause:

Here you can clearly see the "EV" in the first minute when the car tries to keep the engine in a low-power mode, maximum EV, to warm-up the engine. During this time, I can accelerate the car drawing a deep discharge from the traction battery and high MPG. The acceleration energy comes from the traction battery, not fuel burn from a cold engine. BTW, the later NHW20 and ZVW30 models have expanded this EV mode nearly three times.

Where this comes into play is if you park near the exit where you can see on-coming traffic, you have the option of reaching cruise speed using traction battery energy and very high MPG. Once the car transitions to cruise mode, the recharge is handled by taking a fraction of the engine power from a warmed-up, efficient engine.

Speculation, it may be possible to install enough solar cells to put a 'peak charge' on the traction battery when it is parked. The advantage is it may handle the initial acceleration energy costs with no subsequent fuel burn impact.

CRUISE

Pretty much as before, the data is much smoother:

The surprise was how long the traction battery continued to draw a 5kW charging load. I've not seen this before and bears investigation.

STOPPING

Again, as before, here you can clearly see the ICE stop at 42 mph indicated:

Nothing new here other than once again seeing regenerative braking.

Vehicle Overhead

Looking at cases where there was no appreciable MG1/MG2 power, we can plot the traction battery load and find:

The NHW11 comes with day-light running lights which make a contribution but so too does the electric power steering and possibly other unmapped electrical loads. Here is another place to save energy.

MG1/MG2 Electrical Efficiency

There is not enough data and unexpected, the fast polling rate did not happen. I may need to do another configuration save to make a fast polling rate sticks. The other alternative is to take longer drives in steady state conditions and we've had a break in the hot weather.

Bob Wilson

ps. As I pointed out before, we can worry about calibration after getting the instrumentation working. There is a GPS receiver on the way and I'll be visiting a number of local benchmark routes. Plus I have high-resolution, accelerometers. Capturing and reporting the data may give insights on how to measure the six, ECU variables. Calibration can happen anytime. For example, acceleration versus power.

There is an acceleration event dominated by traction battery and MG2 power along with a small amount of ICE power. Do the math using the NHW11 curb weight, add 10% for driver, fuel, full-size spare, tools and jack.

[dcb]

Just checking, you realize every other row is missing a battery measurement?

[bwilson4web]

Originally Posted by dcb

Just checking, you realize every other row is missing a battery measurement?

Yes, it is how the Graham miniscanner is reporting the data. I've attached the source and 'normalized' data.

The Graham miniscanner starts by sending a set of "..." as a timing clue for downloading a software update. Then it writes the first data timestamp and data:

2.840<TAB>0.0<CR><LF>
2.840<TAB><TAB><TAB>0<CR><LF>

The first and third data requested are MG1 torque and MG1 rpm. Since these come from a single response packet, the Graham miniscanner reports both values from the first packet which is why the first two data records have the same time stamp. Then comes:

3.357<TAB><TAB>0.0<CR><LF>
3.357<TAB><TAB><TAB><TAB>0<CR><LF>

The second and fourth data requested are MG2 torque and MG2 rpm. Again, they came from the same response packet so we get two, identical time stamp records from one data request.

So the third and fourth data requested are MG1 rpm and MG2 rpm and again, the Graham miniscanner is reporting the first and second items that come from the same response packets:
3.873<TAB>0.0<CR><LF>
3.873<TAB><TAB><TAB>0<CR><LF>
4.389<TAB><TAB>0.0<CR><LF>
4.389<TAB><TAB><TAB><TAB>0<CR><LF>

The fifth and sixth data elements are traction battery voltage and current:
4.907<TAB><TAB><TAB><TAB><TAB>0<CR><LF>
5.396<TAB><TAB><TAB><TAB><TAB><TAB>0.0<CR><LF>

These are separate requests and response packets so the time stamps change. But to minimize sampling errors, we use these two in the spreadsheet to calculate the traction battery power drain or charge.

So what happens when we normalize the data is:

A) MG1 torque, MG2 torque, MG1 spin, MG2 spin
B) MG1 torque, MG2 torque, MG1 spin, MG2 spin, Batt Volt, Batt Amp

It looks like the traction battery data is only every other record but it is easy to miss that there are two separate MG1/MG2 records. All of the data is there and clustered so the most time-adjacent data is in a single record.

Bob Wilson

[bwilson4web]

Hi,

Yesterday I was doing more testing by recording my normal, morning commute route. Most of the data looks noisy as the Prius rapidly passes power between the ICE, MG1, MG2, and traction battery. But there is one segment where I got up to 55 mph (indicted) on a fairly flat section:

During this segment, the car actually achieved something that looked like a steady-state.

In this case, MG2 is working as a generator and passing power to MG1 which is working against the ICE to get it to run slower. That power then takes the mechanical path back towards MG2. So I took the data and calculated electrical path efficiency, MG1/MG2:

• ~70% - raw, not counting the vehicle overhead, ~500W, 44-78%
• ~82% - adding the vehicle overhead, ~500W, as an electrical path load with a range from 65-94%.

One lesson learned is the car has to be on a fairly flat section, otherwise altitude changes add and subtract to the load and makes steady-state measurements unusable. I am waiting on a GPS receiver but this may not be the best way to measure the small altitude changes that trigger rapid state changes in the Prius. So I may have to add vertical acceleration data to get an accurate, altitude change metric.

You'll also notice the ratio of power taking the electrical versus mechanical path changed substantially. It looks like the electrical path is favored as the engine power decreases. MG1 driving against the ICE is making it turn slower and like over-drive, into a potentially more efficient point on the operating line.

Bob Wilson

[dcb]

Do you have the raw data for that segment? Would like to know what mg1 and ICE RPM are doing and be able to count area under the curves.


And can you expand on "~82% - adding the vehicle overhead"? Vehicle overhead is not intuitive to me in this context.


Also FYI, a GPS isn't the "no brainer" one might hope:
http://ecomodder.com/forum/showthrea...tml#post235722

Arduino Forum - TinyGPS

[bwilson4web]

Originally Posted by dcb

Do you have the raw data for that segment? Would like to know what mg1 and ICE RPM are doing and be able to count area under the curves.

And can you expand on "~82% - adding the vehicle overhead"? Vehicle overhead is not intuitive to me in this context.

I'll post the data later this evening. The raw data file is about 88K which is not so bad. But when it goes into the spreadsheet, it grows due to the formula needed to derive ICE rpm, torque, watts, MG1 and MG2 watts, and traction battery watts. The smallest spreadsheets are now over 300K and this one is much larger. Regardless, I'll include the time-range in seconds and you should be able to replicate the math.

The vehicle overhead needs to kept separate from the energy transfer between MG1 and MG2. The NHW11 Prius is running roughly 500W for the control computers, displays, inverter coolant pump and day-light running lights. This is drawn from the traction battery bus by a DC-to-DC converter to run the 12V bus. We see this when the car is sitting with the engine off and not moving sustained by the traction battery draw. If our interest is in the electrical path, power losses, we have to account for this vehicle overhead along with the traction battery charge/discharge load.

What I did is adjust the traction battery load by adding 500 W, the vehicle overhead. Then the adjust traction battery load was added to MG1 and divided by MG2 to calculate the electrical path, power efficiency.

Bob Wilson

[bwilson4web]

Promised files.

Sorry, the 'csv' file exceeds the forum limits. Yet curiously, the 0.5M spreadsheet uploaded fine. <sigh>

Bob Wilson

[bwilson4web]

Last night, everything came together and I was able to capture my commute home route at 4:00 AM (no other traffic) and get the fastest polling data from the Graham Miniscanner. This chart shows observed transaxle, electrical efficiency:

Conditions:

• Using cruise control to just past crest of overpass and shift into "N" for ballistics glide to flat: 1st is "useless overpass", 2nd is "Airport Road", and 3d is "Golf Road."
• 2003 Prius, NHW11 - modified with largest possible drive tires LRR Sumitomo T4s at 50 psi, low viscosity transaxle lubricant.
• temperature 77F, no wind, dry
• Start: 34.703460 -86.587693 598 ft., driving South
• Indicated 38 mph -> 40 mph true (GPS)

During the cruise segments on the flat, the engine is running and MG2 is generating the electrical power that passes back to MG1. Toyota calls this "energy recirculate" mode. In this mode, the electrical path efficiency (MG1 output, traction battery charge, and ~445W vehicle load is created by the MG2 electrical generation load.) This may seem low but the ICE rpm is retarded as it is working like an overdrive. Also, the electrical path is passing a fraction of the ICE power that reaches the wheels.

When reaching the upgrade of the overpass, the cruise control commands more power and this in turn switches MG1 to the generator and MG2 as the output load. Now the electrical path efficiency clusters around 70-90%. You can hear the engine spin-up to generate the climbing power needed.

At seconds 1,040, a traffic light turned red at 34.665647 -86.572284 612ft "Byrd Springs Road." When the light turned green, I accelerated and the electrical path efficiency clustered around 75-82%. Also notice that the ratio of ICE power taking the electrical path rapidly fell off as the car approached the target speed.

Clearly, there are two electrical power flow modes, normal and energy recirculate. Energy recirculate is less efficient but it is driving the engine to turn slower, effectively an overdrive. From the acceleration data, we can see the ratio of how much power takes on or the other path varies by speed and load.

Prius transaxle efficiency is not a simple, steady-state device and more studies are warranted. BTW, in this benchmark run, the vehicle indicated over 64 MPG (~68 MPG) not bad considering it seats five with a good sized trunk.

Bob Wilson