1. Attachments are working again! Check out this thread for more details and to report any other bugs.

ScanGauge II and TPMS interaction

Discussion in 'Gen 3 Prius Technical Discussion' started by HTMLSpinnr, Sep 13, 2012.

  1. HTMLSpinnr

    HTMLSpinnr Super Moderator
    Staff Member

    Joined:
    Dec 8, 2003
    5,339
    917
    251
    Location:
    Surprise, AZ (Phoenix)
    Vehicle:
    2018 Tesla Model 3
    Model:
    N/A
    TLDR: Can ScanGauge II inadvertently alter the TPMS sensor registration in the TPMS ECU?

    Full story:

    I've observed a potentially interesting interaction/problem regarding SG-II and TPMS. I've had a ScanGauge-II plugged into my 2010 Prius since Aug 2010.

    Initially, my TPMS light would only come on for extended trips (post tire replacement), however on my last Prius Expert trip to SoCal, the light came on and stayed on. I did remove my ScanGauge to place into other Prius vehicles during that trip (Prius v, specifically).

    I took the car in last week to have the light addressed. Initially, the Toyota tech at my dealer identified that one of my 4 sensors was damaged during my last tire install and replaced it, which we thought corrected the condition. The light stayed off for about 25 miles, then reappeared. I hadn't changed any XGauges during the entire time. I took it in a 2nd time where they kept the car most of the day. The tech took another look and found that the last few characters of the TMPS sensor IDs had been modified in the ECU, so they re-initialized the system again, inputting the correct numbers. All was well until they plugged in my ScanGauge II again. As soon as they did, the TPMS light came back on. They plugged their TechStream in, and observed 2 of the 4 wheel IDs had the last few digits modified again. Still having the old numbers on the screen, they corrected the last few numbers. They asked me to keep the ScanGauge off for at least 72 hours. I intend to give it a few weeks to see if the numbers drift again (which could point to a failing ECU instead of the SG-II).

    At the time of the test, I had the following Xgauges setup for display:
    • Engine RPM (Passive TXD 01CC)
    • Friction Brake Sensor (TXD 07B02107)
    • HV Battery SoC (TXD 07E2015B)
    • HV Battery Amp draw (TXD 07E2218A)
    My ScanGauge was set for fast polling (vs normal or slow).

    In the past when this light came on, I've also had other XGauges displayed - including AC draw, Fuel GPH, HV battery temp and Engine coolant temp, along with some other braking stats displayed. The SG-II had firmware 3.17mb, though I sent it off yesterday to Linear Logic for a firmware upgrade (before I was able to talk to the Toyota tech today for "root cause").

    Interestingly enough, he claims that he's seen this on 1-2 other cars as well.

    I'm curious - has anyone else seen this? Are the TPMS initialization "codes" known or obtainable? Are they anywhere "near" the TXDs we use?

    I'm grateful that I wasn't charged for this effort (extended warranty), but concerned about plugging the unit back in to trigger the condition again w/o understanding if specific TXDs may be inadvertently triggering this, or if I should be concerned that my unit (or the cable) is failing and/or sending bad data. I'll probably end up calling Linear Logic on this as well to see if they have any thoughts on it, but wanted to poll the folks here in case this was something already observed.
     
    seckwielen likes this.
  2. jdcollins5

    jdcollins5 Senior Member

    Joined:
    Aug 30, 2009
    5,131
    1,338
    0
    Location:
    Wilmington, NC
    Vehicle:
    2010 Prius
    Model:
    III
    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.
     
  3. spiderman

    spiderman wretched

    Joined:
    Jul 5, 2009
    7,543
    1,558
    0
    Location:
    Alaska
    Vehicle:
    2010 Prius
    Model:
    II
    No problems here (v 4.05).
     
  4. Jonny Zero

    Jonny Zero Giggidy

    Joined:
    Jun 22, 2012
    1,388
    351
    0
    Location:
    Austin, TX
    Vehicle:
    2012 Prius
    Model:
    Five
    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.
     
  5. HTMLSpinnr

    HTMLSpinnr Super Moderator
    Staff Member

    Joined:
    Dec 8, 2003
    5,339
    917
    251
    Location:
    Surprise, AZ (Phoenix)
    Vehicle:
    2018 Tesla Model 3
    Model:
    N/A
    This is something along the lines of what I was thinking, but don't have a good understanding of the CAN protocol in general, nor any good means of sniffing or analyzing the packets to be sure. I could certainly revert from Fast to Normal polling intervals, but I don't want to get into a position where I need to visit the dealer to reinit my TPMS system again. Having a Tachometer and other data is "useful", but not if it compromises a safety system.
     
  6. David Beale

    David Beale Senior Member

    Joined:
    Jul 24, 2006
    5,963
    1,979
    0
    Location:
    Edmonton Alberta
    Vehicle:
    2012 Prius
    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.
     
  7. Chazz8

    Chazz8 Gadget Lover

    Joined:
    Sep 19, 2008
    744
    234
    61
    Location:
    Central New York
    Vehicle:
    2012 Prius v wagon
    Model:
    Five
    Have you checked 12v battery? This definitely qualifies as weirdness, as in weirdness cause by failing 12v battery.
     
  8. HTMLSpinnr

    HTMLSpinnr Super Moderator
    Staff Member

    Joined:
    Dec 8, 2003
    5,339
    917
    251
    Location:
    Surprise, AZ (Phoenix)
    Vehicle:
    2018 Tesla Model 3
    Model:
    N/A
    No, but I will. Car is over 3 years old (~40 months). I've had no other 12V-failure like symptoms though.

    SG II is already on it's way back from it's firmware upgrade (talk about QUICK turn-around, I just mailed it off yesterday). Helps that they're only on the other end of the "valley" from me ;-)
     
  9. cwerdna

    cwerdna Senior Member

    Joined:
    Sep 4, 2005
    12,544
    2,122
    1
    Location:
    SF Bay Area, CA
    Vehicle:
    2006 Prius
    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.
     
  10. HTMLSpinnr

    HTMLSpinnr Super Moderator
    Staff Member

    Joined:
    Dec 8, 2003
    5,339
    917
    251
    Location:
    Surprise, AZ (Phoenix)
    Vehicle:
    2018 Tesla Model 3
    Model:
    N/A
    Received my 4.06 upgraded ScanGauge Friday (pretty quick considering I sent it Wednesday). Put "most" of my XGauges back in, and so far, so good.

    Behaviorally the gauge doesn't quite function the same - the passive RPM gauge now freezes as the other xgauges are polled rather than being a continuously updated (40fps) display. So annoying that I switched to the built-in polled RPM display instead.

    Good news is, "so far", the TPMS light hasn't returned.
     
  11. RobH

    RobH Senior Member

    Joined:
    Sep 18, 2006
    2,369
    978
    70
    Location:
    Sunnyvale, California
    Vehicle:
    2006 Prius
    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.
     
  12. HTMLSpinnr

    HTMLSpinnr Super Moderator
    Staff Member

    Joined:
    Dec 8, 2003
    5,339
    917
    251
    Location:
    Surprise, AZ (Phoenix)
    Vehicle:
    2018 Tesla Model 3
    Model:
    N/A
    That's what I discovered too after further digging. I'm not sure if they didn't save values before unplugging the first time. Either way, it's all supposition w/o something in between to sniff the bus. It's likely easier to observe cause and effect and point the finger to something not Toyota specific or provided.

    Is there not a gateway between the two? Thinking about the HyCam where pressures can be displayed on the MFD - no idea how that's happening though.
     
  13. RobH

    RobH Senior Member

    Joined:
    Sep 18, 2006
    2,369
    978
    70
    Location:
    Sunnyvale, California
    Vehicle:
    2006 Prius
    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.
     
  14. vincent1449p

    vincent1449p Active Member

    Joined:
    May 24, 2004
    894
    331
    0
    Location:
    Singapore
    Vehicle:
    2012 Prius c
    I wonder if you have tried AT CEA 2A? Page 44 of the ELM document has some examples of using CAN Extended Addresses.

    Vincent
     
    seckwielen and RobH like this.
  15. bwilson4web

    bwilson4web BMW i3 and Model 3

    Joined:
    Nov 25, 2005
    27,067
    15,372
    0
    Location:
    Huntsville AL
    Vehicle:
    2017 Prius Prime
    Model:
    Prime Plus
    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
     
  16. RobH

    RobH Senior Member

    Joined:
    Sep 18, 2006
    2,369
    978
    70
    Location:
    Sunnyvale, California
    Vehicle:
    2006 Prius
    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.
     
  17. managerman

    managerman Prius v Nerd

    Joined:
    Mar 12, 2012
    228
    110
    0
    Location:
    Columbus, OH
    Vehicle:
    2012 Prius v wagon
    Model:
    Three
    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
     
  18. RobH

    RobH Senior Member

    Joined:
    Sep 18, 2006
    2,369
    978
    70
    Location:
    Sunnyvale, California
    Vehicle:
    2006 Prius
    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...
     
    seckwielen likes this.
  19. lensovet

    lensovet former BP Brigade 207

    Joined:
    May 23, 2009
    2,614
    495
    0
    Location:
    Burlington, NJ
    Vehicle:
    2018 Tesla Model 3
    Model:
    N/A
    did anything ever come of this? :)
     
  20. HTMLSpinnr

    HTMLSpinnr Super Moderator
    Staff Member

    Joined:
    Dec 8, 2003
    5,339
    917
    251
    Location:
    Surprise, AZ (Phoenix)
    Vehicle:
    2018 Tesla Model 3
    Model:
    N/A
    I have not had a recurrence of the problem. I suspect there may have been a failure to complete the process correctly, but w/o some sort of sniffer in place, there's little way to provide empirical evidence either way.