ScanGauge II and TPMS interaction

I have a SGII with 4.05 revision plugged in for over a year now and have never had any issue with TPMS. I have looked but have not been able to find any XGauge parameter information for the TPMS signals.

 

No problems here (v 4.05).

 

Nothing on the Prius, but I have had an issue with the old 2002 Camry with SGII, so I have been shy to use the SGII on the Prius.

The SGII would cause the Camry's ECU reset to default and lose all learned parameters every 2 weeks or so, as if the battery had been pull, but the radio and clock would not lose anything so I knew the power was fine. In the Camry it would reset the idle to low, and all the readiness monitors would be reset.

I talked to Linear Logic about it they said it is impossible but it kept happening. So I unplugged the SGII and use it as a code reader only (mostly for friends and family).

Maybe it increases the CAN network traffic too much and caused packet collisions and corrupted some data? I don't know. With the Prius' built in displays I do not find the SGII necessary, certainly did not want to risk it plugging it in again.

 

No problems here but not using any Xgauges. Just reading coolant temp, RPM, 12V system voltage, and l/hr. Oh, and my firmware is a few years old.

 

Have you checked 12v battery? This definitely qualifies as weirdness, as in weirdness cause by failing 12v battery.

 

I've been using my SG II for years, but on a Gen 2. I've never had any any TPMS trouble other than it properly detecting deflated tires.

I was running 3.15 for ages then got upgraded to 4.05 over a year ago. I do use some XGauges but don't remember my polling rate setting. It's either normal or fast.

 

The TPMS is not on the CAN bus - it's on the KWP bus. The Scangauge doesn't understand how to talk to the Prius KWP ecus, such as TPMS. If the Scangauge is set to automatically determine the protocol, it might freeze up some device, but I doubt it could actually change the TPMS setup. The Gen1 problem is quite different, and does not apply to Gen2/Gen3.

My take on this is that it is a long shot that the Scangauge does anything to TPMS. It would be nice if it could talk the Prius KWP protocol. If it could, then you could set up sensor ids, read pressures/temperatures.

 

Truth be told, KWP is for diagnostic purposes only. The ECUs that talk to a scantool via KWP talk among themselves with the BEAN (Gen2) or LIN (Gen3) buses.

At one point, I set up an ELM327 in Monitor All mode, and watched Techstream talk to TPMS. The only traffic the Elm picked up was whatever Techstream was talking to, such as Body or TPMS.

There are gateways between CAN and BEAN/LIN buses. On Gen3, there is a gateway at CAN address 750. The Gen3 Body ECU is addressed as 75040, where 40 just happens to be the Body ECU on Gen2. So it looks like the Gen3 Body ECU is a BEAN/LIN/KWP device, with a gateway providing CAN access to it.

I think I tried accessing the Gen3 TPMS via the 750 gateway. Address 7502A would be the logical way to get to it if the gateway were a general forwarding engine. Didn't work... It might be worth trying again, but my current impression is that gateways are designed to connect specific devices, rather than a general interface between the buses.

 

I wonder if you have tried AT CEA 2A? Page 44 of the ELM document has some examples of using CAN Extended Addresses.

Vincent

 

Sorry to be late to the discussion but the one list of Gen III codes did not seem to include readouts of the ECU error codes . . . or did I miss the memo?

I was happy to see a lot of engineering data in the list but not the codes.

Thanks,
Bob Wilson

 

Interesting clue. What I would have tried was just duplicating the J2534 request that Techstream uses for 75040. Since a slightly different protocol is invoked with extended addressing, I may have missed some option on the request.

It will be a while before I get around to it, but it's worth another look.

 

It would be great if there was a way to read the tire pressure values on the scangauge II. I rented a 2012 Camry this past week and on the "car" menu it did a visual readout of each tires pressures....nothing like that in my c or v.

-M

 

I generally just google a particular code to see the description.

As for how to read them via OBD2, I've got a few sequences that seem to be DTC related.

07 e0 13 b0 Queries DTCs, while the reply of 07 e8 53 01 21 18 says that there is 1 DTC, code P2118.

83 c1 f0 13 00 ff Queries DTCs on KWP device C1. Reply of 83 f0 c1 53 a7 94 says 1 DTC, code B2794.

81 c1 f0 14 Clears DTCs on KWP device C1. Reply of 81 f0 c1 54 acknowledges the clear.

82 2a f0 21 e0 queries DTCs (?), with reply of 86 f0 2a 61 e0 b6 c7 ff fa (dtcs 16c7 & 3ffa?)

82 2a f0 21 e1 queries DTC count, reply of 83 f0 21 61 e1 00 says zero.

So both KWP & CAN devices seem to use 21 e0, 21 e1, 13 00, & 14 codes. There are a number of 13 xx requests, which may be current versus historical queries. Note that these are J2534 recorded sequences - the ELM versions include the frame type & count which are filtered out of the J2534 presentation.

Hardly a full report, but a few tidbits to chew on...

 

did anything ever come of this?