Hi Rob, thanks for your answer. When connect with Techstream, the car answer with the type of car, and then the user must try the year of fabrication to tell the program what units have this model concrete. The data 83 F0 2A C1 D9 8F must be the request, no? and the reply can be the type of car? I would get to communicate with the ECU with an arduino. Know you about a similar project with toyotas? TK
You would have to identify a LIN wire or connector from the wiring diagram. Nobody seems to have done any research about the protocols that Toyota uses on the LIN bus.
I had some luck with an ELM compatible device on my gen 2 Prius (2009): CANBUS PIDs | Page 3 | PriusChat It would be interesting to see if it also works with gen 3 Prius the same way.
Hi there, thanks for this information, Does anyone how can this information can be retrieved from the CAN BUS of the Prius III? I'd like to log the total fuel consumption, and last few lines of the provided doc seems to point to that, but where do I find this on the CAN bus? (Msg ID, start bit, length, etc...). That would be really nice! Thanks Olmo
Bump on a super old thread. First thank you so much Rob, your info has helped me tremendously in trying to get TPMS data. I have a TPMS ecu on the bench with an OBD y cable splitter. One side I run Techstream reading TPMS data with a knockoff mongoose cable. The other side is a ELM327 adapter printing to serial monitor. Just like you said, starting the ELM at Fast INT 10.4k baud, then changing the baud to 9,600 followed by opening the MA monitor all let’s me “spy” or see the Techstream data. My 2007 Tundra is asking for the data using 82 2A F0 21 26 as opposed to identifier 15 you mentioned for Prius. The response is all 00 because the ecu is on the bench with no sensors around. My question to you is can you explain more of the Toyota Fast INT procedure? I am learning KWP-2000 as I go. Do you have to send an initialization command every time before you send a request or do you initialize once and the bus stays active while you ask for data. I don’t fully understand the concept of the timing and initialization. I know if not done properly I can not send request. I tried turning the Techstream monitor off and sending commands via the ELM monitor and always got a BUS INT ERROR. You mentioned ELM chips can’t properly initialize to Toyota. I noticed as Techstream first connects to the vehicle it sends 81 13 F0 81 but I didn’t see a response. When connecting directly to the TPMS ecu the first message is 81 2A F0 81 with response 83 F0 2A C1 E9 D6. I believe this is the fast INT initialize command you mention. If I can figure out the initialization process I hope to write arduino code to initialize the bus and then request TPMS data every x seconds to send/update a display. Thanks Jeff
A few days working on this steady and I have figured it out. Posting in case someone reads this one day. I got my logic analyzer out and watched the serial commands sent to my bench top TPMS ecu from Techstream. I then went to my OBD2 serial monitor and tried to recreate the signal via ELM 327 chip. No matter what I did I could not get the ELM to initialize with the bus so that I could send a data request. As stated above the TPMS ECU is KWP-2000 Fast Int protocol but at 9600 Baud instead of 10400. The initialization message is 81 2A F0 81 1C The message header 81 2A F0......... 81 means 1 data byte 2A is address of TPMS Ecu F0 is the interface address 81 is the message command 1C is the check sum Using the scope I realized and was able to see that the Fast Int process is a 50Ms pulse followed by sending the above mentioned initialization message. The issue is in the 50Ms pulse that starts this sequence. The ELM 327 default is 25Ms Low and 25Ms High for the pulse then sends the data. Techstream however sends (and the TPMS Ecu) is looking for 35Ms Low and 15Ms high. If you do not change this timing in the ELM 327 it will never properly initialize to the bus. This image shows the OBD on top and Techstream on bottom. You can see the differences in the timing on the break (low part of the pulse) I had to read the ELM 327 datasheet extensively but found in the Program Parameters (ATPPS prints the table) that Parameters 1A and 1B control the timing of this pulse. Default is 25Ms for each. These commands to the ELM327 should change the timing to make the 35Ms Low and 15Ms high. After doing this I was able to initialize the TPMS bus with my ELM327 adapter and send/receive messages. AT PP 1A SV 0E (Sets Low to 35Ms) AT PP 1B SV 06 (Sets High to 15Ms) AT PP 1A ON (Turns Setting ON) AT PP 1B ON (Turns Setting ON) Run ATPPS again to make sure the values changed and are on in the table. This was the fix for me and I now have a fully functioning connection/bus
Thanks Jeff for solving a 13 year old mystery. Having the right tool (logic analyzer) and knowing how to use it obviously helps a lot.