Column 1 Column 2 Column 3 Column 4 Column 5 Column 6 Column 7 Column 8 Column 9 Column 10 0 Time (mm:ss) 38:59 39:21 39:43 40:05 40:27 40:49 41:10 41:32 41:54 1 IB Main Battery (A) 1.39 1.35 1.60 1.07 33.87 25.11 -11.13 33.5 -4.75 2 Battery Block Max Voltage (V) 15.43 15.41 15.37 15.36 14.52 15.53 16.46 16.37 16.43 3 Maximum Battery Block No (#) 15 1 19 19 1 19 19 19 1 4 Battery Block Min Voltage (V) 15.25 15.24 15.20 15.16 14.65 15.76 16.28 16.18 16.33 5 Minimum Battery Block No (#) 3 3 4 7 7 7 12 7 7 6 Battery Block Voltage 1 (V) 15.40 15.41 15.33 15.31 14.68 15.59 16.41 15.34 16.77 7 Inside Resist 1 (Ohm) 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 8 Battery Block Voltage 2 (V) 15.33 15.31 15.27 15.27 14.48 14.92 16.38 15.18 16.63 9 Inside Resist 2 (Ohm) 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 10 Battery Block Voltage 3 (V) 15.27 15.25 15.21 15.19 14.62 15.96 16.18 15.74 16.69 11 Inside Resist 3 (Ohm) 0.023 0.023 0.023 0.023 0.023 0.023 0.023 0.023 0.023 12 Battery Block Voltage 4 (V) 15.27 15.26 15.21 15.21 14.76 15.63 16.35 15.81 16.73 13 Inside Resist 4 (Ohm) 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 14 Battery Block Voltage 5 (V) 15.27 15.25 15.22 15.20 14.98 16.43 16.18 16.62 16.61 15 Inside Resist 5 (Ohm) 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 16 Battery Block Voltage 6 (V) 15.33 15.34 15.31 15.26 14.97 16.14 16.33 16.58 16.70 17 Inside Resist 6 (Ohm) 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 18 Battery Block Voltage 7 (V) 15.27 15.24 15.17 15.20 15.70 15.90 16.17 16.41 16.51 19 Inside Resist 7 (Ohm) 0.021 0.021 0.021 0.021 0.021 0.021 0.021 0.021 0.021 20 Battery Block Voltage 8 (V) 15.28 15.27 15.22 15.22 15.21 16.25 16.21 16.84 16.55 21 Inside Resist 8 (Ohm) 0.023 0.023 0.023 0.023 0.023 0.023 0.023 0.023 0.023 22 Battery Block Voltage 9 (V) 15.29 15.27 15.23 15.22 15.80 15.84 16.23 16.34 16.56 23 Inside Resist 9 (Ohm) 0.023 0.023 0.023 0.023 0.023 0.023 0.023 0.023 0.023 24 Battery Block Voltage 10 (V) 15.30 15.27 15.23 15.23 16.23 15.92 16.25 16.34 16.49 25 Inside Resist 10 (Ohm) 0.023 0.023 0.023 0.023 0.023 0.023 0.023 0.023 0.023 26 Battery Block Voltage 11 (V) 15.32 15.28 15.27 15.07 15.39 16.08 16.47 16.55 16.28 27 Inside Resist 11 (Ohm) 0.024 0.024 0.024 0.024 0.024 0.024 0.024 0.024 0.024 28 Battery Block Voltage 12 (V) 15.29 15.28 15.23 15.06 15.59 16.74 16.40 16.35 16.22 29 Inside Resist 12 (Ohm) 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 30 Battery Block Voltage 13 (V) 15.31 15.28 15.25 15.15 15.41 15.85 16.40 16.94 16.21 31 Inside Resist 13 (Ohm) 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 32 Battery Block Voltage 14 (V) 15.30 15.29 15.25 15.08 15.40 15.86 16.38 16.65 16.29 33 Inside Resist 14 (Ohm) 0.023 0.023 0.023 0.023 0.023 0.023 0.023 0.023 0.023 34 Battery Block Voltage 15 (V) 15.41 15.41 15.33 15.25 15.47 15.76 16.39 16.60 16.38 35 Inside Resist 15 (Ohm) 0.023 0.023 0.023 0.023 0.023 0.023 0.023 0.023 0.023 36 Battery Block Voltage 16 (V) 15.30 15.33 15.29 15.16 15.43 15.85 16.28 16.73 16.26 37 Inside Resist 16 (Ohm) 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 38 Battery Block Voltage 17 (V) 15.32 15.29 15.27 15.21 15.26 15.58 16.44 16.49 16.39 39 Inside Resist 17 (Ohm) 0.021 0.021 0.021 0.021 0.021 0.021 0.021 0.021 0.021 40 Battery Block Voltage 18 (V) 15.39 15.38 15.33 15.27 15.42 15.85 16.48 16.55 16.37 41 Inside Resist 18 (Ohm) 0.021 0.021 0.021 0.021 0.021 0.021 0.021 0.021 0.021 42 Battery Block Voltage 19 (V) 15.43 15.41 15.37 15.33 15.53 15.87 16.45 16.41 16.55 43 Inside Resist 19 (Ohm) 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 0.022 44 Battery Inside Air Temperature (C) 23 22 22 22 22 22 22 22 22 45 Battery Temperature 1 (C) 27 27 27 27 27 27 27 27 27 46 Battery Temperature 2 (C) 30 30 30 30 30 30 30 30 30 47 Battery Temperature 3 (C) 31 31 31 31 31 31 31 31 31 48 Battery Temperature 4 (C) 26 26 26 26 26 27 27 27 27 49 CCTL (Bit) 1 1 1 1 1 1 1 1 1 50 Cooling Fan HI (Bit) 0 0 0 0 0 0 0 0 0 51 Cooling Fan LO (Bit) 0 0 0 0 0 0 0 0 0 52 Cooling Fan MID (Bit) 0 0 0 0 0 0 0 0 0 53 Delta SOC (%) 20 20 20 20 20 20 20 20 20 54 ECU Code (ASCII) 255 255 255 255 255 255 255 255 255 55 EQC0 Front Relay (Bit) 0 0 0 0 0 0 0 0 0 56 EQTR Charge Start Signal (Bit) 0 0 0 0 0 0 0 0 0 57 Normal Status (Bit) 1 1 1 1 1 1 1 1 1 58 Onboard Charge Status (Bit) 0 0 0 0 0 0 0 0 0 59 Outer Charge Status (Bit) 0 0 0 0 0 0 0 0 0 60 Pre Onboard Charge Status (Bit) 0 0 0 0 0 0 0 0 0 61 SBLW Fan Stop Request (Bit) 0 0 0 0 0 0 0 0 0 62 The Number Of Stored DTCs (#) 0 0 0 0 0 0 0 0 0 63 VMF Fan Voltage (V) 0 0 0 0 0 0 0 0 0 64 WIN (Kw) -20 -20 -20 -20 -20 -20 -20 -20 -20 Removed range text; ordered so battery modules are paired; formatted for trailing zeros. I've highlighted the same values reported by the Graham miniscanner. The Graham scanner also reports the highest battery temperature but this may be calculated from the four values. The miniscanner can also read up to three, stored DTC and clear them as needed. Bob Wilson
Hi Bob, Look at the fifth and sixth data samples. The maximum voltage shown in those two samples is lower than the minimum voltage. Since battery module pair #7 shows up most frequently as lowest voltage, does that mean a module within that pair is most likely to fail? Also compare the voltage shown for pair #7 with the voltage shown as minimum. For example, look at the last column of data. Module pair 7 has the minimum voltage in that column. However minimum voltage is reported as 16.33. Meanwhile, voltage for module pair #7 is reported as 16.51. Wouldn't you expect the values should be the same? In that same column, maximum voltage is reported as 16.43, for pair #1. However this is contradicted by pair #1 voltage being reported at 16.77. I wonder if there's some timing lapse that would account for this weirdness in the data.
Exactly! Each data value is polled from the ECU by Auto Enginuity and reflects the value found when polled. In actuality, there is a time-stamp for each field but I left only the first time-stamp for each set of data. BTW, I've been experimenting with how to display the data in a way that maximizes understanding. I'm done with changing table formats for now. But you are absolutely correct that there are race conditions between the different values. Bob Wilson
I also notice a distinct glitch in the running data over time. Below is a 45 minute drive in the 03 in which I recorded all block voltages via Battery ECU, Now some of the deltas shown in this plot show around a 5V delta between hi and low block! This I would think should cause DTC's from both the HV ECU and the Battery ECU. In reality it shows a sample rate irregularity probably caused by the OBD port rate combined with the AE interface. But you still can see the general trend of charge level, (most middle blocks are here) and when it was discharging from accels, and when it was charging from coasting and/or regen-braking. But the outliers are the end cells so that makes me wonder if it's real. This car is 8 years old with 30Kmi. and the original hv battery. It was driven mainly by the wife aprox. 5/10 mi/day. I know it's not enough to appreciate the benefit of the hybrid system, but it still saves gas at the pump bigtime! Anyway, this is recorded from live data capture, I have not yet induced any DTC's yet to see if it can detect them correctly, this car has no stored dtc;s. I think by pulling the service plug we can induce a HV supply error and see what it picks up. Has anyone tried this yet and what was the outcome?
Incidentally, I also noticed that you cannot actually record the "cold" block voltages since you must first start the car in order to connect to the system. By this time it is already charging- so the voltages will be normal to high once you get the software and interface going. The car does hold a charge (display always full in morning) but never left more than three days without driving. I wanted to touch on the above statement that there is a big difference in data recorded over time versus realtime data (frame data and dtc capture). With recorded over time data it is sensitive to any system bottlenecks and glitches (this case OBDII port rate and the hardware/software being used. Also any irregularities in the system being read as well. Freeze frame and dtc data is captured as it happens so as long as it captures dtc's correctly all this recorded data is really just a mute point anyway, only meant to be used as another troubleshooting tool. I have found so far that recorded data is much more accurate if you only record for a short time interval- like 1 or 10 mins, not 45mins. or an hour. The longer it records the more chance of picking up irregularities in data through many reasons. But in Bob's posted data in above post, it would need a few more samples to filter out irregularities.
It's possible that some of the data was simply copied down incorrectly. Not necessarily. Even new battery packs can have one or two blocks that spend a lot of time at a slightly lower voltage than the others.
Yes, it would. The OBD system is not part of the problem. Deselect all parameters except Battery Block Minimum Voltage and Battery Block Maximum Voltage, and retest.
Sounds like a good one to plot . So you think by having too many parameters to collect per cycle, the software/hardware can't keep up so by sampling only two it should get much more updated readings? -will try soon.
I had the same problem with the Graham scanner. The polling interval is about 120 ms. but stuff happens a lot faster. So I adopted the practice of only using data where two points are within 10% of each other. Otherwise you get too many outliers and they'll drive the data nuts. That is on my list but Saturday, I got my solder, OBD connector. I'm going to add a couple of cheap, push buttons and using that connector, verify we can read out the two-code flashes (Thanks Patrick.) The one thing that has me scratchin' my head is MG1 torque is nearly random. I suspect they have a data conversion error so I'm starting to look at it much closer. I still don't feel good about how to get it synced with the car correctly. I've had occasions where it just stopped polling too. I would not call AE a solid piece of work. So far: ISO9141-2 - vehicle type interface OBD-II compliant - initialization type, but I still get spiked codes on the ABS. The other initialization types didn't throw the codes but they also were less reliable in data recording. I had tried KWP2000 but it was unreliable. At least it didn't throw false codes on the ECUs. I'm finding the best approach: Plug in the OBD interface Plug in the laptop and get it fired up and the application Turn the car to IGN (no need to start or READY) After the first sync Pull down "Vehicle" and "disconnect" Pause while it does it Pull down "Vehicle" and "connect" It seems going from "disconnect" to "connect" lets the software properly initialize the OBD module and sync the software. Then it seems to be a whole lot more reliable. In recording the data, less is more. You'll still have race conditions and have to throw out data that is not part of stable operation. GOOD LUCK! Bob Wilson
I was looking at the battery voltages this weekend and SOC. I noticed that doing a forced charge leads to some peculiar data. The AE SOC values per module were above 80% but didn't quite follow the voltages. It almost looked like the dV drop of NiMH batteries but the drop was excessive. Later, I noticed the SOC display was higher than the actual SOC based upon voltage in the modules. It was very strange. So last night, I put the car in "R" with the rear wheels against a curb. I was able to bring the module voltages to more normal levels and the operator SOC and battery levels seemed more 'normal.' I'm planning to do more stuff in this area in the future. All in all, the Graham Miniscanner is a more solid, plug-and-play, product. The AE is still a little too flaky for me to feel confident. It has more data points but . . . Bob Wilson
Hi jk450, I don't think Bob copied it by hand, it should be captured by AE. I think the problem is that Bob left out the time-stamp for each field. The table shows only one time-stamp for all 64 samples which we know are not correct since the data are serial not parallel. The sampling rate seems to be about 22 seconds and many changes in values can happen it those 22 seconds.
Exactly! I still have the original CSV file but it is nearly useless for practical analysis: first row titles - columns 1, 3, 5 . . . have "Time" text; columns 2, 4, 6 . . . have data element text. This title text line is great and a significant improvement over the Graham Miniscannner second row - blank line subsequent rows - columns 1, 3, 5 ... have time values and columns 2, 4, 6 . . . have data values So the first step is to transpose the data so the first column holds the title text in each row. Since I only need one time-stamp for each group of data, I removed all but the first. This leaves a spreadsheet that looks like the data table posted. But the order is as originally recorded. So I sort and group the data so the module-pair voltages and internal resistence are together and a couple of other order changes to help make sense of the data. This is not how the data elements were originally read but it makes practical analysis possible. Bob Wilson
Here is a plot of only the raw hi and Lo block voltage from the 03 Prius Batt ECU during cold start to driving.. As can be seen there are three dropouts in only the Lo data that goes clear to 0V, one right after the ICE started. But this can be filtered out since there are many more good data points.. Will show in next shot.
Here is the filtered version of the last shot. There are many more good data points to keep the trend accurate. When one goes to "0" just fill in the last value. The value around 640 seconds (an accel) is real at 14V, so I left it.
Here is a zoomed in shot of the cold start voltages and then starting the ice. You can see the voltage sag from startup, then it immediately goes to charge.
And a shot of the 03 Prius Batt ECU Hi / Lo block voltages filtered, and zoomed in on some accels and regens from coasting and braking. Of course regen braking has the highest charge voltage. The drop at time 637 secs. of low block is real at 14V. This point shows a 1.2V difference - a sign this 8yr old hv battery is almost chucking a code.
Here's one last shot of the cold start, initial charge and then starting to drive. You can see the charge right after ICE start, from 138 to 148 was reverse then the first few accels and regens of the drive.
Great charts! I too have noticed intermittent data dropouts in some of my studies. I'll be starting a thread on MG1 shortly. What is disappointing is the vendor doesn't seem to have a clue about Prius values and seems distinctly uninterested in addressing my documented concerns. I notice they provided a programming document for the ProLine and I'm thinking a Java based, Prius specific alternative might make a lot of sense. Java to be operating system independent but 'reverse engineer' the OBD protocol(s). This might give us some relief. Bob Wilson
Hi Bob, Yes there are drop outs in data however the general trends are there, so you can just fill them in. Since the data requests are time stamped, if the system interface does not have a value ready at some point, it just posts 0. This all of course was using their built in plotting utility. I'm sure some other program that polls for a value then if not received yet by the time stamp, use the last value and go on so as not to miss the next one coming along. That would need the addition of an "if/then" statement in the code.
