Scanner survey

I'd like to suggest recording the charging heat-pump:

• record battery temperature and current
• force charge: hold brake and floor accelerator until engine stops

The resulting graph will show the exothermic action of charging the battery. This is what happens every time the car descends a tall hill. Then imagine driving through hill country with every descent heating the battery and not seeing a corresponding decrease on the next hill assent. This is heat-pumping the battery.

The only mitigation I know of is to use "B" on hill descents to minimize over charging the traction battery. It is not perfect but rather less bad.

Bob Wilson

 

Does it generate a single .csv file with all data in the one file?

The Graham scanner uses a TAB delimited output with each data field offset by the number of TABs needed for alignment. I use a Perl program to normalize the data for loading into excel. Sounds like I'll have to do the same with this data. It would be nice if the .csv file has any naming convention to identify what data it contains or when it was captured.

One thing I don't like about the Graham data is there are no data identifiers in the data file. You have to manually add them when you create the excel spreadsheet.

I wonder if we can change the sampling interval per data type? For example, temperature values tend to change slowly compared to traction battery current or MG1 torque.

According to the tracking data, my Autoenginuity left Montgomery on Friday so I should get it Monday. You've certainly stroked my enthusiasm for this tool. I can hardly wait to see what it can pick up from our ZVW30.

Bob Wilson

 

Autoenginuity arrived this afternoon. Boy will I be happy to go home tonight!

I took it out with my wife's ZVW30 and recorded an 8 mile loop. It treats the 2010 Prius as a generic OBD-II vehicle but the data recording and standard options look to be very useful for some of my energy studies:


Now to start mapping out the NHW11 functions and inducing some well defined errors. This will be fun.

Bob Wilson

 

Hi Tom,

I started with the 2003 today and even submitted my first trouble report and got this reply:

I pointed out the Graham miniscanner did but this doesn't seem to be a big impediment to what I want to see. All in all, this is a great tool.

We are going to have a lot of fun!!

Bob Wilson

 

Here is the screen showing the list of ECUs that this scanner found:

I was surprised to find the ABS and EMPS codes. I haven't cleared them but will be going back to see what sort of date or timestamp might be available. This really is a nice, vehicle wide tool ... still looking and learning.

Bob Wilson

 

I haven't looked at those code, yet. I'm keeping them in reserve as there is one more scanner I want to test ... the OBD connector and two switches.

The maintenance manual shows a simple OBD jumper is supposed to cause the codes to 'flash'. It is also claimed that we can clear the codes too. If so, this could be a very affordable, >$10, code reader technique. We won't get quantitative values but rather just flashing the codes. That may be enough for many DIY.

Bob Wilson

 

Interesting. Is there a table of what those code are?

I first stumbled across this approach a couple of weeks ago when I was looking up one of the diagnostic techniques. Regardless, I plan to test it with my NHW11 once the connector arrives. We'll see what can be found. <grins>

I'll be inducing a number of faults in my NHW11 by jumpering the temperature thermistor lines to a low resistance. This will give a false "over temperature" condition. Then I'll be able to compare the codes from:

• connector and push buttons
• Graham miniscanner
• Auto Enginuity

Bob Wilson

 

Ahhh, I see it now! Thank you!

So what we have are:

• operator displays and symptoms - the usual posting we see here and other forums.
• OBD connector and two switches - read out two-digit codes flashed on operator display lights. Some assembly required and a table of codes.
• retail OBD scanners - typically just the vehicle or engine ECU codes and engine related live data points.
• Graham scanner - covers HV, engine and battery ECU codes as well as 50+ live data points.
• Auto Enginuity - covers all ECUs except the CCS, for the primary codes (haven't checked subcodes, yet) and live data points (some questions here.)
• Toyota scanner - everything but not commercially available

About the Auto Enginuity scanner, I'm still learning how to configure it. It looks like the 'auto detect' function of the OBD interface can induce codes and false failure indications. Also, some of the live HV ECU values don't look right, MG1 and MG2 torque. This doesn't surprise me but I just need to document the problems and turn it over to the vendor. But the battery information is awesome.

I ran a forced charge last night and saw the five temperature probes climb from 95F to 100F in a couple of minutes. This is the 'heat pump' effect I'd seen before.

Bob Wilson

 

I 'rediscovered' this and solved it by disabling "autoconnect." This lets me check the discovery process before enabling it. I also suspect this may have falsely set codes on the ABS but this needs more investigation.

Bob Wilson

 

I'm getting a handle on the data record functions:


This is my typical commute profile with our 2003 Prius:

• ~2-5 minutes - initial warm-up when the goal is to minimize fuel burn until the car can go into S4, full hybrid mode.
• ~10-15 minutes - normal commuting, trying to keep either 38 mph range or cruise at 55+ mph.
• ~2-3 minutes - final cruise to the house using as much EV mode as possible to use the stored traction battery energy to reach home.

I'm finding the reported MG1 torque does not look right suggesting there may be a data conversion problem. However, there is a "Generator Current W (A)" value not seen before that reports a number that appears to correlate with ICE power. This may provide a short-cut for ICE BSFC charting.

By design, Auto Enginuity (AE) tries to report data values by ECU. However, this makes it difficult to get the fuel consumption needed for a proper BSFC chart. But ICE rpm is reported for all controllers and this may provide the correlation function needed to make a usable BSFC chart.

Like the Graham miniscanner, the data capture rate is probably limited by the slow-speed OBD bus. However, by limiting capture to just the values of interest, we can sample more rapidly and hopefully, resolve some of the race-condition, sampling error challenges.

There are a series of "Info 1-5" data fields that are not well described. We know from the Graham scanner that sometimes more than one data field can be reports in a single query, mitigating some of the time delay problems from sampling separate fields.

For those interested, I don't see a way to read out the actual OBD Tx and Rx frames and from the package. Regardless, I'm still learning 'where the knobs are' and trying to make it run in a more predictable manner. For example, one menu option seems to cause the package to crash but I haven't turned it in, yet.

Bob Wilson