MR2 Owners Club Forum banner

41 - 59 of 59 Posts

·
Premium Member
Joined
·
3,511 Posts
sorry, i should have simplified that equation further to where it requires no parentheses:

Injector time in seconds
duty cycle% = injector time * RPM / 1.2

injector time in miliseconds
duty cycle% = injector time * RPM / 1200
 

·
Premium Member
Joined
·
12,678 Posts
I just found something that may be helpful to this process. In Torque Pro, in the "custom PIDs" menu, there is an option to add a predefined list of custom PIDs. The only Toyota models in the list are a couple of different Prius generations, but when you import them you get a HUGE list of (mostly mode 21) PIDs that someone has apparently decoded.

A couple of interesting things I noticed:
1. The variables that are being used go WAY above D. Some of the equations are calling variables all the way up to AB in fact.
2. They are packing WAY more than 2 data values into a single PID. For example, 0x2101 has 26 values associated with it, including MAF, RPM, throttle position, load, coolant temp, intake air temp, and vehicle speed. Getting all of those out of a single PID would massively speed up logging.
3. They are reporting VVT "aim angle", "change angle" and "OCV Duty" on 0x2144, with equations for each. Is the Prius a single VVT motor? I don't see separate values for intake and exhaust. Still, the equations (assuming they are correct) might be a good start at decoding our VVT, and it's entirely possible that the other cams are other variables on the same PID, likely with the same equation.

Hopefully I'm not getting worked up over nothing here, I haven't tested any of these PIDs. Maybe they are all Prius specific and don't cross over to anything else? Hopefully not.

Also, worth noting that Torque lets you export these as a CSV file, so you can look at the list in excel rather than in Torque. I think you can also import PIDs into torque in the same manner, so if we end up with a nice list of extra PIDs it would be easy to make a shareable file to easily import them.
 

·
Premium Member
Joined
·
3,511 Posts
if #2 is right that is amazing, but there's only 6 bytes of data in a PID so i don't see how you fit all that in there. Can you post what the decoding math is?

it's very likely the same math is used across all the models so those equations would be useful.
 

·
Premium Member
Joined
·
12,678 Posts
Attached is the exported list out of Torque.

I just found this a google search for Toyota Mode 21 PID List, suggesting that 0x2181 actually returns 18 bytes of data.

 

Attachments

·
Registered
Joined
·
1,270 Posts
Discussion Starter #45 (Edited)
if #2 is right that is amazing, but there's only 6 bytes of data in a PID so i don't see how you fit all that in there. Can you post what the decoding math is?

it's very likely the same math is used across all the models so those equations would be useful.
I'm not finished with decoding this entirely but since you've asked here is what I have. I was going to get to this soon. There is an "extended response" service that can return any number of bytes, specified by the ECU. I've showed it previously without explanation in some of the previous screenshots.

Here it is for VVT (see in green):



And for Automatic Transmission Temperature (also in green - this one I've decoded and will present the details later):



I don't know whether to refer to this as a special "service" or "mode 10." It's used in the response to some PID's. It starts with

10 A 61 B M N O P

where A is the number of bytes to expect and B is the PID that was requested and MNOP are data bytes.

The query device gives an acknowledgement,

30 00 01 00 00 00 00 00

which is then followed by the continuation of the multiline response from the ECU

21 A B C D E F G
22 A B C D E F G
et cetera.

The total number of bytes refers to the number of bytes in the first response line (the line that starts with 10) plus the bytes in the lines 21, 22, 23 et cetera.

I don't see a priori where there would be a limit on the number of lines other than FF maybe.

PS. Also at some point when time allows I am planning to put these discovered PID's into Torque Pro as user-defined variables and log the query and response on the CANbus to see how they behave in a non-Toyota query device.
 

·
Premium Member
Joined
·
3,511 Posts
Hmm, i was not aware that OBDII allowed responses over 6 bytes long. Many other CAN protocols have a "transport protocol" where they allow large messages than the architecture allows. I'll have to run that query to get that response and see if the format looks familiar. I bet it's a broadcast format so there should be no handshaking necessary.

the ability to get a PID that reports RPM and MAF at the same sample is *HUGE* if we could get ignition timing at the same time it would be even better but that may be a bit greedy :)

That 0x2101 in the sheet you uploaded is likely to not be valid for the 2GR since it includes prius specific things. but there's likely a big message with lots of data available on the 2GR also. This will massively increase our sample rate ability.
 

·
Premium Member
Joined
·
3,511 Posts
good call on that transport. That's unfortunate that it looks to only support one transport packet at a time though. that means we can't just blast the ECU with requests at that point.
 

·
Premium Member
Joined
·
12,678 Posts
That 0x2101 in the sheet you uploaded is likely to not be valid for the 2GR since it includes prius specific things. but there's likely a big message with lots of data available on the 2GR also. This will massively increase our sample rate ability.
Maybe. But I only see one item on 0x2101 that appears hybrid specific (state of charge), and that uses variable V, which happens to be the last variable used on that PID. So, perhaps they took a generic 0x2101 list and added on to the end of it?

However, there are a couple of items I am seeing that give me cause for concern:

[PRIUS]Throttle Position - 0x2101 - L * 20 / 51
and
[PRIUS]Vehicle Speed_7E0 - 0x2101 - L * 15625 / 25146

also

[PRIUS]Coolant Temperature_7E0 - 0x2101 - I * 9 / 5 - 40
and
[PRIUS]Vehicle Speed_7E2 - 0x2101 - I * 15625 / 25146

Surely these cannot both be correct right? There's no way the same variable multiplied by some constant can equal both throttle position and vehicle speed, or coolant temperature and vehicle speed. But I don't know what the 7E0 code refers to, and that (and other similar codes) appear on a number of the PIDs in this list.
 

·
Premium Member
Joined
·
3,511 Posts
Those have to be for different software version. I could see the same byte listed twice as temp in one unit versus another. it would be odd but i could see it. but in this case there's no way those are on the same ECU.
 

·
Registered
Joined
·
1,270 Posts
Discussion Starter #50
Those have to be for different software version. I could see the same byte listed twice as temp in one unit versus another. it would be odd but i could see it. but in this case there's no way those are on the same ECU.
There's something you need to know. The PID definitions all changed in 2010. 2005-2009 is different from 2010+
 

·
Premium Member
Joined
·
3,511 Posts
I'm really not surprised to hear that. From the tune and hardware side i see so many changes in 2010 also. That's why right now i only support pre 2010 ECUs except where i had no choice with the 2012 scion tC ECU.
 

·
Registered
Joined
·
1,270 Posts
Discussion Starter #52
Also, I think but I'm not sure that the extended response ID may have something to do with 29-bit CAN ID's as opposed to the 11-bit ID's that are used for most things.
 

·
Premium Member
Joined
·
12,678 Posts
That makes sense, torque has a separate last for 2004-2009 gen2 Prius and another for 2010+. I don't remember what the list I posted was, might have been the combo of both. There is a lot of overlap between them though.
 

·
Registered
Joined
·
1,270 Posts
Discussion Starter #54
I've looked at the Prius lists before and to me they seemed to be of limited usefulness because of the focus on battery ECU PIDs and such.

I'm going to continue doing what I'm doing taking things one step at a time and making sure that for each step I have proper validation, contextualization, and verification. There's a lot more to get to this is like studying moon rocks - can't do them all all at once.

I don't know whether the knock and fuel PIDs have been covered anywhere else. These are real gold when it comes to tuning, and to my knowledge you seen it here first.
 

·
Premium Member
Joined
·
12,678 Posts
I've looked at the Prius lists before and to me they seemed to be of limited usefulness because of the focus on battery ECU PIDs and such.

I'm going to continue doing what I'm doing taking things one step at a time and making sure that for each step I have proper validation, contextualization, and verification. There's a lot more to get to this is like studying moon rocks - can't do them all all at once.

I don't know whether the knock and fuel PIDs have been covered anywhere else. These are real gold when it comes to tuning, and to my knowledge you seen it here first.
Very true, those are the real advances, and it seems unlikely we will get them any way other than decoding them by your method.

But if we can get more of the basic data that we already have with fewer PID requests and therefore speed up the logging rate, that is very beneficial as well. And if we can get that knowledge by piggybacking on information that is already out there rather than decoding each one manually, why not?

For what it's worth, I did try some of the Prius PIDs yesterday, and I was getting data from some of them. Need to do a little more looking to figure out if any of them are worth while. Also I am getting data from the two knock PIDs you discovered, although I have not driven the car yet to see how they actually behave in use.
 

·
Registered
Joined
·
1,270 Posts
Discussion Starter #56
This section is for the Automatic Transmission Temperature PID. At first, this might not seem useful. But there are some reasons for covering it.

1. This was one of the first PID's to "leak out" into the wild. From my research, it was shared with US owners by Russian hackers around 2012-2013. Probably the reason for the interest in this PID is the totally fragile and unreliable nature of Tundra and Tacoma transmissions. Anyway with this PID being known already, it gives a reference point to check that the PIDs and equations that are coming out of this work match up with what's already out there.

2. It gives a good illustration of the "extended response" service.

3. It could potentially have useful applications in our vehicles.

To collect data for this PID I drove my Rav4 up a hill. This generated a Techstream log and a CANbus log.

Techstream:



CANbus:



In order to match these up, I decoded the RPM portion of the CANbus log. This is the chart for PID 0C for RPM, derived from the CANbus log:



The points in this RPM chart based on the CANbus log can be matched up one-to-one with the RPM points in the Techstream log, and this lets us sync up the Techstream log temperatures with the CANbus log response values.

So then examining the variation of the reported temps in Techstream and comparing them to the lines in the CANbus log, it becomes apparent that something VERY STRANGE is going on. First off the PID code for the transmission temp query is easy to spot it has a standard PID query "02 21 D9 00 00 00 00 00 00" and the PID code is D9 - which agrees with the PID code reported elsewhere (Russia, if you are reading this, thank you!). This is not the strange part. Here is what's strange: the variation of the log data matching the temperature variation is in a line of the log that does not appear to fit the simple definition of a PID response. See the lines circled in red. These lines circled in red are the lines that contain the data variation that matches the variation in temperature in the Techstream log. They do not look like a PID response. And furthermore, in the place where we do expect a PID response, immediately after the PID query, we see something that that does not seem fit the definition of a PID response either. See the lines circled in blue. Instead of "0n 61 PID A B C D E" we see instead "10 XX 61 PID A B C D." Here's the log, with the relevant portions highlighted:



Let's set all this puzzling stuff aside for a minute and just focus on what we can solve. By scanning through the log, we get the following datapoints:

21 6B 80 00 00 00 00 00 ↔ 67.5
21 6C 20 00 00 00 00 00 ↔ 68.1
21 6C C0 00 00 00 00 00 ↔ 68.7
21 6D 60 00 00 00 00 00 ↔ 69.3
21 6E 00 00 00 00 00 00 ↔ 70
21 6E A0 00 00 00 00 00 ↔ 70.6
21 6F 40 00 00 00 00 00 ↔ 71.2
21 6F E0 00 00 00 00 00 ↔ 71.8
21 70 80 00 00 00 00 00 ↔ 72.5

And from this we decode that

A/T Oil Temperature 1 (C) = E - 40 + F / 256,

where E and F refer to the first and second value after the "21" code. This agrees with the equation reported elsewhere by sources that can be deemed reliable, like this one for example:
https://www.toyota-4runner.org/1760494-post22.html

So now let's turn back to the response format. By comparing logs for other variables taken separately (like for example, VVT), we arrive at the conclusion that there is an extended response format that is used to pack multiple variables into a single response. See the response circled in green (ignore red and blue):



Decoding this query and response,

000007E0: 02 21 D9 00 00 00 00 00
000007E8: 10 08 61 D9 21 31 00 04
000007E0: 30 00 01 00 00 00 00 00
000007E8: 21 6B 80 00 00 00 00 00

The query "02 21 D9" receives a response from the ECU that starts with "10 08" which means "expect 8 parameters" and it sends the first four "21 31 00 04" on the first line (they are A B C D) and then the next four "6B 80 00 00" are sent on the line that starts with 21, they are E F G H. How do we know there is an G and an H? In the link to Toyota-4Runner.org there is a reference to G and H. They give the output of the second transmission temperature sensor, that is available on other vehicles, but not on the RAV4. So the RAV4 just sends "00 00" for G and H.

This same format of extended response is used elsewhere for other PID's (like for example VVT) and its general form is:

000007E0: 02 21 PID 00 00 00 00 00
000007E8: 10 XX 61 PID A B C D
000007E0: 30 00 01 00 00 00 00 00
000007E8: 21 E F G H I J K
000007E8: 22 L M N O P Q R
000007E8: 23 S T U V W X Y
and so on depending on how many parameters are being returned.

So going back to the beginning of this post, we've covered points 1 and 2, meaning that (1) we've confirmed that we're doing is consistent with what others have done before and (2) we've decoded an extended response format that is not documented in the standard OBD2 description. This leaves the third point, which is potential use of this info in our vehicles.

Our vehicles do not have an automatic transmission so this leaves two unused pins on the ECU for the transmission temperature sensor. They are THO1 (B30-126) and ETHO (B30-124). I've marked these in red on the ECU connector diagram.



So in theory all we have to do is hook up a temperature sensor to these two pins and we'll get a temperature displayed along with our other OBD2 variables queried from the ECU.

What about the sensor calibration? Two ways to approach this.

One is to find a sensor that matches the calibration of the OEM transmission temperature sensor, which I believe to be this (pending additional confirmation):



Or, we hunt through the ECU binary file for the sensor calibration map and edit it to match the calibration of whatever sensor we choose.

Either way we can get an OBD2 display of one more temperature in addition to the IAT and the ECT, which could be useful in some situations.
 

·
Premium Member
Joined
·
12,678 Posts
Very cool.

Or, we hunt through the ECU binary file for the sensor calibration map and edit it to match the calibration of whatever sensor we choose.

Either way we can get an OBD2 display of one more temperature in addition to the IAT and the ECT, which could be useful in some situations.
Or, option 3, you use whatever sensor you want and adjust the PID equation until you get the proper readings.
 

·
Registered
Joined
·
1,270 Posts
Discussion Starter #58
Very cool.



Or, option 3, you use whatever sensor you want and adjust the PID equation until you get the proper readings.
There's another potential use that could be interesting. We hook up a resistor to the two terminals in order to lie to the ECU about the transmission temperature - on the chance that without a transmission temperature that ECU limits the power delivery.
 

·
Premium Member
Joined
·
12,678 Posts
There's another potential use that could be interesting. We hook up a resistor to the two terminals in order to lie to the ECU about the transmission temperature - on the chance that without a transmission temperature that ECU limits the power delivery.
Perhaps, but that seems very unlikely to me at this point. Two reasons. 1: If they were going to limit power, they would do so at some level below normal OEM power, not ~80hp above. 2: If you were going to limit power and you have access to an electronic throttle body, why would you bother with any method other than closing the throttle (which they aren't doing).

In other news, the Prius PIDs have so far been a total bust. Many of them appear to be valid PIDs, in that they do report data, but it's either wildly wrong compared to the expected value, or doesn't vary in the expected way, or both. Oh well, at least I learned how to import custom PIDs from an excel file.
 
41 - 59 of 59 Posts
Top