Scangauge or Torque App?

What do you use for the software with this? Seems like a great deal since the Mini VCI connectors appear to be super cheap. I had the 'standard' TIS subscription but couldn't find it before my two days expired. Thanks.

 

I use the official Mongoose and Techstream.

Most Mini VCI sellers include an unofficial "cracked" copy of the official Techstream with the cable. (not legal but they don't care)

I've played around with Mini VCI from Ebay and it pretty much does the same things a Mongoose/Techstream. (Techstream is the official Toyota dealer diagnostic software)

If you are home tinkerer and are not concerned about using "stolen" software the Mini VCI package is a very good deal and will pay for itself the first time you use it.

 

Thank you!

 

So, is there a final version with all the correct PIDs avaliable now? I'm using the PLX Kiwi Bluetooth adapter with my Android phone. I tried using MG1 and MG2 RPM but MG1's readings were off the wall. Also with HV battery current, and State of Charge. Is there a HP reading for MG2 by the way? Thanks!

 

Did the PIDs you're using come from the NHW11 vehicle database converted with the Torque
exporter (see the bottom of this page)? I gave some more details on how to do that back here.

In a nutshell, the way the exporter stands right now, it's just a file you have to download, and you can run it on your computer from the command line. The comments at the top of the exporter file give an example of how to run it. Your computer probably already has Java installed, and you can follow the link in my earlier post to download the free-forever version of Saxon, which it also needs. You don't need to download the NHW11 database itself as a separate step; you can just give the exporter the network URL for the database file, and it will read the current database and make your up-to-date CSV file.

One problem that can arise when people just mail around their copies of CSV files is you never who's got which one up to date with what. If you work straight from the database on sourceforge and you know of anything missing or erroneous, please let me know, or, we can set you up with an id to make corrections directly.

The CSV exporter is kind of a stopgap measure. Really the best way to integrate with Torque would be to write a plugin for it that accepts the XML database file directly, and would let you select items to display and in what measurement units right in the app. Just haven't got the time right now.

I know the database has MG1 and MG2 rpms and torques. If you find the scaling is wrong (do you have another scanner or other way to check it?), we should make sure that gets corrected in the database.

I don't think the ECUs will give you MG horsepower numbers directly. That's an example of something I think you can do in Torque itself by creating a synthetic PID that multiplies rpm and torque, with the right scale factor.

-Chap

 

I'm not sure that we ever solved successfully for the signed variables, which include MG rpm and torque, and one of the two HV current measures. See the earlier extended discussion in this thread. This field has worked for me for HV Current:

HV Battery Current (-99.9A to 999A only)

There are also two available S0C fields, and this one works for me

State-of-Charge soC 01C9 (A)*(200)/(51) 0 1000 %{SoC} 8416F1

 

Hey Guys,

Great thread, I used the information in your discussion and wrote a small tool for PC that can read all the Prius Gen 1 PID in one screen, I used Labview to do so, and a$1 bluetooth dongle that can connect to a cheap $14 ELM 327 Ebay OBD plug.

I tested it, and the battery voltages results are in the attached pictures, I see almost 0.2v between max and min voltage, any reason for concern?

Please let me know if you have more ideas on what to add to this tool, so that maybe us prius gen 1 owners will have some PC diagnostic tool in addition to the android option, and we can save some money, I injured my back very bad lately, so I have some spare time to play with it a little when it doesn't hurt to sit for more than a few minutes.

Thanks and keep up the good work.

 

That's cool! Will you be sharing the source for your tool?

I've not used Labview before. If you develop something with Labview, does it end up being something you can distribute and other people can run it without buying Labview themselves? Or is it only usable where people already have Labview installed?

-Chap

 

Very cool.

WRT the voltage delta, my experience is that because of the slow communication time and the volatility of the voltage when underway it's hard to get a really good handle on the high-low delta. The voltage of all cells could have changed by more than 0.2v in the time it takes to cycle through the measurement across all the cells. I suppose that sitting at a stop with the ICE off would allow a consistent measure, but I think that is also the circumstance in which a marginal battery probably looks fine.

When I watch the high and low values (and I've been watching this pretty intently for the past 6 months!) when underway I see a delta of .15-.40v. I was somewhat alarmed with the higher spreads at first, but they occur during high charge/discharge states, so I'm rosily attributing that to the timing differences. And as Bob Wilson and others have pointed out, having one or two blocks that are consistently low against the others is probably of more concern than the actual spread. In my case while the high voltage is almost always block 1 or 19, the low varies across ~5 other blocks, which gives some comfort. In any case I haven't ever had an error code, and the behaviour has been consistent across >25,000 km.

Hope this helps.

 

ps. looking more closely at your images I see errors returned for some of the codes - this looks like what I was getting before resolving the ECU addressing, when all the ECUs sent a response to the unqualified query. If that's the case you might want to resolve that. You probably have the ability to parse out the response you want, but there is discussion above on how you might address the specific ECU, which is a better approach if you can do it.

 

I can create an exe version with the environment that will allow it to run without having Labview on the PC, I believe it will be 100-200MB file, and it will be located in the "program files" folder, with a desktop and start menu links.
BTW I originally wrote this tool so that I'll have the Prius fuel consumption bars(that shows consumption every 5 min) in my Yaris, or any other car, I used some loops that take the air flow sensor, and speed, and use it in a formula to calculate the momentary fuel consumption, I actually tested it on the prius and the results are amazing, the prius bars and my bars are exactly the same, so does the MPG main result.

BTW#2 ,I didn't try it, but I believe that it can run with an ELM that is connected via usb cable as well, since it only has to show as COM port on windows, and my tool does the rest.

Thanks, I also think it's a slow communication issue, I had to give 1000 ms delay between write and read to the COM port, it's only that slow in the 2002 prius, other cars I've tested can return the string in about 100ms.

Thanks for the response about it, at first I found it very strange to receive so many hexadecimal numbers, because I originally wrote the first screen so that I'll have the Prius fuel consumption bars(that shows consumption every 5 min) in my Yaris, or any other car(it's SUPER COOL to have the Prius bars on other cars), but when I saw multiple responds from the ELM on the prius 2002, I just bypassed the "problem" , for instance:

This is an example to a string response after sending " 01A6"to the ELM,
01A6
41 A6 00 00 32 FF
41 A6 00 00 00 00 00 <DATA ERROR
41 A6 06 66 06 71

>
I've made some experiments, and found that the last line is what I need, in order to get A,B,C,D for the blocks voltages formula, so I wrote a code that finds the last "41 A6" combination, and read the hexa code right after it, in order to get the A,B,C,D and perform my calculations.
I did the same for the HV block resistances.
To be honest, I don't know how to address the 'header" as you've mentioned on this thread, I send the PID to the port and run my search algorithm on the results to get what I want, I think it will be nice to know how to do it, but anyway, since this Gen1 prius is probably the only creature that will have this kind of ECU setup, and since I'm writing everything manually on Labview, I think it's ok to work with it as is for now, unless someone knows how to address the other ECU(?), just by sending string with the PID to ELM?

I attached pictures of the ELM327 that I have, and the bluetooth dongle.

Thanks!

 

Hey Jeff, one more thought, I believe that the first line that I'm getting is the results for the 16F1 header and that the second result line is the D5F1 header, I know that we have at least 3 PID that are used for both ECU, such as: 01CE, 01CD, 01D1, and I wonder if that's why I get 2 or 3 results, and whether I should look for the second row for the Battery ECU, and the first row for the main ECU, I believe that when <DATA ERROR is received, the PID simply does not exist in the ECU that is receiving it.

Example:
The PID 01CE is for Battery blocks 17,18,19 resistance, but it's also the MG1 and MG2 temperature PID, the string that I receive from the ELM is:
01CE
41 CE 52 4E
41 CE 15 15 15


>
Means that the 52 4E is for MG1/2 temperatures, and 15 15 15 is for battery blocks resistance?

If so , I only need to write those 3 PIDs so that the ones that refer to the 16F1 header will look at the first line, to get the correct value, and then I'm pretty much done with all PIDs( that I know that exist from this thread).
In other cars it's so simple, you only have 1 line
Thanks.

 

If you don't set any header, the ELM will use functional addressing; i.e. any ECUs that has data will response. If an ECU is busy, other ECUs that are not will response first. So, the 1st response is not necessary from 16 and the 2nd may not necessary from D5. You can turn on the header in the response by this command so you can see which ECU responded:

> AT H1

If you specify the header in your query, you are using physical addressing; i.e. only the target ECU will response, the rest will not. e.g.

> AT SH 82 16 F1

Every query issue after this will only get response from the HV ECU. If you need to get response from other ECU, you need to set the header again. e.g.

> AT SH 82 D5 F1

You can refer to the ELM327 data sheet for more information.

Vincent

 

Hi Vincent, that is great information, I remember looking at the ELM data sheet almost 2 years ago when I wrote the tool for the Yaris, I was too lazy to look again , Thanks, I will run this line and will test the results and report if it worked .

Thanks !

 

My experience is that a header value of 82 doesn't work, but 84 does. I don't have an explanation for this. Getting functional addressing working is a much better solution than trying to isolate the response you're interested in, particularly given the communication bottleneck.

 

This thread needs to be a sticky because it contains the original work known about:

• Gen I customizations
• Torque App
• Android

These brilliant pioneers figured out the answers but some have moved on to other rides and interests.

A couple of weeks ago, Good Prius Friend SageBrush loaned me an Android and bluetooth OBD adapter. Within a short period of time, I created a vehicle profile "03_Prius" and connected to the car. The default, engine ECU PIDs are working just fine. The next step is to load the known PIDs and test, hopefully without compromising existing customizations for the NHW20. The question becomes how to add value?

All I might offer is mapping how Android/Torque fits with:

• Graham miniscanner - NHW11 day-driver and primary for engineering studies
• miniVCI - NHW11 and ZVW30 debugger and diagnostic tool (*)
• Scangauge II - ZVW30 day-driver and limited diagnostic tool, also NHW11

So I'm interested in what might be needed.

Bob Wilson

* - I used to have Autoenginuity but a 'hijacker' killed that virtual PC image. At $500, I've never bothered to refresh it because it did not offer any technical advantage over miniVCI.

 

I reworked the nhw11.csv for better usage.
Tested with Torque 1.8
Can be downloaded from github repository here:
github com
search for "nhw11"

Main modifications:

Sensor naming prefixed with ECU name (where the data from).
(HV, EN, Bat)

Changing equation on negative value capable sensors

Changing unusual metric like dV cV deciVolt CentiVolt
(may be because of scangauge's limited display capability)

Explanation of some special PIDs:

Fuel Injection time for cyl #1: This value remains not 0 when engine is stopped. Must be combined with "Drive Situation ID" if Drive Situation ID is 0 => fuel injection is 0 This can be used for instant fuel consumption measurement.

Shift Sensor 2: P : approx. 0.5 V R : approx. 2.8 V N : approx. 3.4 V D : approx. 4.0 V B : approx. 4.5 V

Shift Sensor 1: P : 1 R : 2 N : 4 D : 8 B : 16

Fuel system status #1: 1 : Open loop due to insufficient engine temperature 2 : Closed loop, using oxygen sensor feedback to determine fuel mix 4 : Open loop due to engine load OR fuel cut due to deacceleration 8 : Open loop due to system failure 16: Closed loop, using at least one oxygen sensor but there is a fault in the feedback system

Drive Situation ID: 0 : Engine stopped 1 : Engine about to be stopped 2 : Engine about to be started 3 : Engine operated or operating 4 : Generating power or load driving 6 : Revving up in P position

 

This should be made into a sticky post

 

Just wanted to say thanks to everyone who contributed!

 

How do you change the HV battery temp sensors to display Fahrenheit?
Have it selected in units in settings but guess I need to edit PID...
Anyone get the state of charge working?