Torque Log Analyzer - Improve Your Hybrid Driving

[Lesolee]

I collected another log with the same set of PIDs on my car with "synchronous logging" enabled

log entries are still 1 sec apart

I would be surprised if they were exactly 1 second apart. If you look at my recent logs they are about 0.6 to 0.8 seconds per result (as seen in the “device time” column. Alternatively you can see repeated seconds in the “GPS time”. To see a read period of just over a second you could spot the missing second in the sequence of GPS times, or use the tenth second resolution on the device time column.

Synchronous logging is clearly a recommended (actually more like a mandatory) action for our purposes.

[Lesolee]

This snip is from a Prius Gen II log and the car is showing fault codes P3015 and P3020. Using the document Toyota Diagnostic Trouble Code Retrieval , Prius Hybrid NHW11 1.5 NZ-FXE (I hope this is the right model) the codes mean High Voltage Battery module fault for banks 5 and 10.

The log has been set up badly so there is not a steady progression from bank 1 to 14. This is not just a matter of me being a bit obsessive-compulsive. Firstly you can more readily see that all banks are included if they are in numerical order. Secondly the order of PIDs is also (hopefully) related to when they are read in time. The time ordering is important since they are not sampled at exactly the same time. The Battery block PIDs should also be in their own little block, with nothing between them. (It is unfortunate that Torque Pro doesn’t have a simple config file for the PIDs to be logged so one could easily switch between data sets to be logged, and they could be re-ordered very simply and quickly.)

“delta” is a column I added which is highest – lowest Battery block. You can’t see the battery current column but it is not excessive. Look at the grey cells, especially the 17.46V reading. This does not occur anywhere else in the log. If there were 50A transients occurring this might be reasonable due to the non-simultaneous sampling. But during this period the current is low (<4A) so there is no excuse for the reading to be wrong by 0.7V!

I could easily imagine the electronics being faulty and giving spurious readings, but how it manages to read the values, compute the max and min values, and get that wrong, is hard to understand.

[Alessandro71]

I collected another log with the same set of PIDs on my car with "synchronous logging" enabled

log entries are still 1 sec apart

I would be surprised if they were exactly 1 second apart. If you look at my recent logs they are about 0.6 to 0.8 seconds per result (as seen in the “device time” column. Alternatively you can see repeated seconds in the “GPS time”. To see a read period of just over a second you could spot the missing second in the sequence of GPS times, or use the tenth second resolution on the device time column.

Synchronous logging is clearly a recommended (actually more like a mandatory) action for our purposes.

GPS Time Device Time

Mon Jul 06 08:14:58 CEST 2015 06-lug-2015 08:14:57.650

Mon Jul 06 08:14:59 CEST 2015 06-lug-2015 08:14:58.652

Mon Jul 06 08:15:00 CEST 2015 06-lug-2015 08:14:59.651

Mon Jul 06 08:15:01 CEST 2015 06-lug-2015 08:15:00.656

Mon Jul 06 08:15:02 CEST 2015 06-lug-2015 08:15:01.645

Mon Jul 06 08:15:03 CEST 2015 06-lug-2015 08:15:02.642

for 48 PIDs I was expecting a consistent slowdown, not such a precise cadence

[Lesolee]

I tried this Battery discharge test on my Auris

http://artsautomotive.com/publications/7-hybrid/140-predictive-battery-failure-analysis-for-the-prius-hybrid/

and couldn't get it to do anything much. Admittedly I did it from memory so didn't exactly follow their setup. Specifically I always start the hybrid system and immediately press EV so the ICE never runs until I let it. But with Torque Pro running the Battery current never got above 4A, even pressing the accelerator quite hard. I did it with the handbrake off first, holding it on the footbrake whilst trying to accelerate in reverse. Then I held it on the handbrake whilst trying to reverse. That gave the higher 4A current, the footbrake holding being limited to more like 2A.

Has anyone tried this on an Auris/Yaris?

[Lesolee]

I am trying to (Torque Pro) log fuel consumption on my Auris. None of the PIDs in the GenIII Prius PID set seem relevant. The built-in ones

• Fuel flow rate/hour
• Fuel flow rate/minute
• Fuel rate (direct from ECU)
• Miles per gallon (instant)
• Miles per gallon (long term average)

all give a “-“ sign, suggesting they are not being read. I have also logged these to a file over tens of minutes whilst driving and they just give the minus sign rather than a reading. Has anyone successfully got a reading from these on a hybrid?

[Alessandro71]

As for mileage pid check FAQ here

http://torqueloganalyzer.blogspot.it/p/q.html

[Lesolee]

I am trying to (Torque Pro) log fuel consumption on my Auris. None of the PIDs in the GenIII Prius PID set seem relevant. The built-in ones

• Fuel flow rate/hour
• Fuel flow rate/minute
• Fuel rate (direct from ECU)
• Miles per gallon (instant)
• Miles per gallon (long term average)

all give a “-“ sign, suggesting they are not being read. I have also logged these to a file over tens of minutes whilst driving and they just give the minus sign rather than a reading. Has anyone successfully got a reading from these on a hybrid?

This is from Alessandro's Torque Log Analyser FAQ section, just to reduce the number of mouse clicks ...

-----------------------------------------------------------------------------------------------

Why fuel and mileage PIDs are always zero?

There are 3 switches to enable fuel logging:

• settings / data logging / log trip fuel consumed
• settings / obd2 adapter / don't calculate fuel (don't check it)
• settings / obd2 adapter / enhanced mpg calc

------------------------------------------------------------------------------------------------

3 of the 5 readings now appear one the live screens

Now all I have to do is figure out how I have managed to break the logging today so that it doesn't log anymore, even though it thinks it is logging (menu allows you to stop logging and then changes to start logging and yet still no log

[Lesolee]

I finally got a result! Torque was apparently “upset” by my changing the PID file and not changing the PIDs being logged. So I deleted the additional PIDs list, restarted Torque, cleared the list of PIDs being logged, re-instated the additional PIDs file, re-entered the PIDs to log and it is happy again. Error trapping is evidently not a strong point in Torque Pro.

The idea behind this test is to get around the problems with non simultaneous sampling of current and voltage readings and to get a good indication of Battery bank imbalances. The test is to coast along at around 50mph with the accelerator pressed enough to keep the charge current near zero for several seconds. Then press the brake just hard enough to give full regenerative braking. The measurements between the two states (zero current and about 100A) are only a few seconds apart. And during the time of the test the Battery does not have a chance to recharge very much so most of the voltage difference is caused by the series resistance of the Battery bank.

Brake1.jpg shows the problem very nicely. When -99A first appears in the log the banks are definitely being affected as the voltage has changed by over a volt. But Blocks 11 and 12 are higher than the rest. The current is probably ramping up quickly so the exact time of sampling changes the voltage measured. But that has nothing to do with imbalance in the banks, it is purely a function of the measurement process.

In this analysis I take a block of current readings that are mostly the same, and ignore the first and last rows of data (as the current was possibly not constant on that row. I then take “before” and “during” readings of the voltage, calculate the voltage change on a bank by bank basis. Using this method the differences between the banks are seen to be pretty small (on a good battery).

Just using a random driving log is not up to the job of getting a robust battery health measurement.

I expect this series resistance measurement to give a substantially larger answer when the battery is at 0°C, but that measurement will have to be delayed until the winter time!

[Lesolee]

For today’s logging I thought I would go up to the M40. (Yesterday I went down to the M4, but they had closed the Eastbound junction and the Westbound has had 50mph roadworks for ages). Just my luck, the M40 had 50mph “roadworks” (although these roadworks were nowhere to be seen). The idea was to drive at one of three constant speeds of 50mph, 60mph and 70mph to get averaged fuel consumption figures under real world conditions.

Having imported the Torque log into Excel, the method was to put conditional formatting on the speed column to show

47-53mph = grey background

57-63mph = tan background

66-74mph = light blue background

It is then easy to see the blocks of constant speed, and to ignore small blocks.

Each of the blocks was averaged into its respective speed result (which is done using a formula such as

=AVERAGE(AP2:AP68,AP101:AP136,AP153:AP181,AP217:AP288)

Note the commas between the groups. All you have to do is left mouse click and drag on the coloured area, type a comma, and repeat for the next coloured area (of the same colour).

Having averaged the speed, I then averaged the fuel flow rate in litres/hour, by simply copying the average result cell into a new column.

The mpg is

Average speed (mph) / [ average fuel (litres/hour) * 0.219969 ]

The other important point was to copy the Altitude column closer to the speed column, make a Difference in Altitude column between adjacent readings, and average those for the same intervals as the other readings. (Again, just copy the average result cell to the required column and that happens automatically).

A negative average means a downhill slope on average. The 60mph block has an average of -0.23m change for a logging interval of about 1 second. This means its value is over-optimistic (high) because it is running downhill. The 70mph figure is overly pessimistic because it is averaged going uphill. Although 0.23m/s (vertically) doesn’t sound like much, it equates to something like 4.5kW, a not insignificant amount of power.

A linear regression line through all the available data points for today’s run gives the 60mph as too high and the 70mph as too low, in accordance with the known average slope correction required.

[Lesolee]

How did you spend your Sunday night? Well I needed to get more data so I was driving back and forth in a nearby industrial estate logging at various constant speeds! I can’t believe how many other cars there were cluttering up my testing.

So, here’s the maths ...

The power output from MG2 is the torque times its angular speed. You get the angular speed by taking RPM and multiplying by 0.104719755 (this is the conversion factor from RPM to rad/sec).

The result is power measured in Watts.

Do the same for MG1 and the engine, sum them, and you get the total mechanical power supplied to the wheels, assuming the power combiner in the transaxle is lossless. You can then plot mechanical power output versus speed.

When it is just running on electric you have a mechanical power and an electrical power and the ratio gives the efficiency of the MG2 driver and MG2. The result is in the region of 82% efficiency. I have used that value to re-use some older electrical-only measurement data to give me the 10mph result. I didn’t bother averaging the upslope and downslope power requirements. The regression line just fits between the points anyway and you can see the spread of values due to the measurement.

[Alessandro71]

How do you consider negative rpm from mg? Do you take only absolute values?

[Lesolee]

How do you consider negative rpm from mg? Do you take only absolute values?

Negative rpm and positive torque is negative power.

Negative torque and positive rpm is negative power.

Negative torque and negative rpm is positive power.

All you need to do is multiply the given values of rpm and torque for each power source and the signs sort themselves out.

[Alessandro71]

Have a look at this thread.

A faulty Battery where the error code of the ECU doesn't match the evidence from log

http://www.hybrid-synergy.eu/showthread.php?tid=56185&page=3

[Lesolee]

Google translate is having a bit of trouble with that site, and the translation is a bit off, but I get the sense of what is happening. The brake-reverse test is very nice, so nice that I am cross-posting a trimmed version of it.

It is not clear from the colours which cell is the droopy one. However that one is quite bad compared to the rest, Using a ruler on the screen the droop of most of them is 35mm and the bad one is 50mm. Could I request the raw log file please.

I would recommend NOT pulling the car apart until we do some more experiments -- unless the car is doing something bad (other than throwing warning messages).

I would like to see the log for the cruise to full regenerative braking test, from a cruise at 50-60mph (accelerator pressed to give zero current for about 5 seconds, then maximum regenerative braking).

After the above test I would like to see the car run up at speed until the Battery is charged to at least 6 bars then full regenerative braking from 70mph. Repeat 2 or 3 times to really pump the Battery full of charge and see if that can rebalance the cells. The Battery is about to be changed anyway so there is nothing to lose other than a bit of time and petrol. Obviously some down hill driving and regenerating would greatly help the quest for maximum bars on the battery display.

[Lesolee]

Thanks to Alessandro for sending me the data from the previous image (originally provided by MadP from the Italian forum). The complaint was that the Prius was throwing codes for faulty Banks 5 and 10, but these were not showing up in Alessandro’s analysis report.

I have done the same analysis I did previously, namely look for a large current transient, where it is stable at one value for (at least) several seconds then immediately changes to another value for (at least) several seconds. Ignore the row containing the changed current value as that will be read badly by the hardware. Average the “before” and “after” individual block voltages, take the difference, and divide by the current change. The answer is the DC series resistance of the Battery blocks.

I am very pleased to report that banks 5 and 10 have 50% higher series resistance than the other banks. Note that this “old worn out battery” is no such thing. All the rest of the banks look as good as my new one!

Note again that the series resistance readout PIDs don’t spot this problem and are therefore of dubious merit as diagnostic tools. Also note that block 7 is quite droopy, but has a low loss as measured by the series resistance test.

Given the age of the vehicle and the cost of replacing the Battery I would not be in a hurry to pull it apart to fix the reported problem unless it had some actual measurable badness associated with it like the mpg dropping by 30% or the car failing to drive properly.

[Lesolee]

Tips for Useful Logging (using Torque Pro)

1) Don’t include a whole lot of irrelevant PIDs

2) Don’t log calculable terms such as max block voltage, min block voltage, number of block with max voltage, number of block with min voltage, difference between max and min block voltages, etc. Just log individual block voltages.

3) Make sure the block voltages are read out in strict numerical order.

4) Put the Battery current either immediately before or immediately after the block voltage readouts.

5) Don’t bother logging “series resistance” of more than one block.

6) Rename the useful PIDs in the hybrid csv file by prefixing them with a decimal point.

7) Don’t edit the PID csv file using MS Excel

Explanations

1) Double the number of PIDs read and the read-speed is halved. Fast update is useful.

2) Several logs have conclusively demonstrated that these derived terms can be entirely unrepresentative of the actual results read from the block voltages. In any case they can be calculated when the log is being processed without wasting read-speed.

3) The sequence of PIDs in the log defines the read sequence. Reading the Battery blocks in sequence gives a more useful result. It also makes it a lot easier to see if all blocks have been logged.

4) The Battery current changes the block voltages. Making the PIDs next to each other reduces the sampling time error.

5) The series resistance readout is demonstrably not useful for battery diagnosis (as seen in this thread).

6) The decimal point in front of the name makes these PIDs appear at the front of the list. You therefore save ages in generating the log file because you don’t have to scroll through the whole list to add the next PID. It will be there ready for you, and as you add say block B10, that will be removed from the list and block B11 will be offered up to you next. (Remember to remove these decimal points from the headings in the log file before uploading to the Torque Log Analyser website as the changed names will mess with the program!

7) MS Excel reads the output csv log files just fine. The PID files on the other hand include Hex fields which MS Excel gets confused by since 7E2, for example, means something very different in hex compared to a decimal with exponent.

[Alessandro71]

Good advices, I will update my site including them.