My TPMS has recently been showing a "Tire Pressure Monitor System Currently Unavailable" message occasionally. The first time I pulled off a highway and checked all tires, all fine, and the alert had gone away by the time I got back behind the wheel. The last time it happened I was well into a 50 mile trip, and the alert stayed lit for about 10 miles, then went out. Problem is, in between those two times I got an alert to check tire pressure and I ignored it, as I've learned to do with the white-light "soft" alert, which tends to indicate a 2-3 lbs. difference in one tire. Bad move it turned out as it went to red alert, then limp mode (I was doing 85mph). Turned out I had a flat in the rear.

This new intermittent problem: more likely a wheel sensor or the "brain" in the trunk?

 

...about $250 new, under $40 used; would you think it's risky to buy a used one?

 

okay, I bought the $40 used one and it doesn't work; 60 day money-back guarantee made it worth trying, but is it possible that replacing this part requires a Star reset or something??

 

The only coding for the module is to program which wheel sensor is on which tire. They did use at least two different styles of sensors, so it's possible that the donor module is programmed for a different type of senor that what your car has. Does it not get any pressure readings at all? Note that it can takes some miles of driving for the module to register the wheel sensors (i.e. their positions, such as when rotating tires).

 

My original module would work intermittently, so I'm aware that it takes several miles to connect, but the donor module just always displays "Tire Pressure Monitor System Inoperative". Also, my system never identified which tire is low, just that one (or more) is.

 

Oh yeah, I remember now - the CLK doesn't display the pressure, just a warning. Looking at the messages, I think if it were programmed for the incorrect sensors, you'd get a "no sensors" message.

Do you have a scan tool that reads all the car's systems? The TPMS module does have some DTCs that an be pulled.

 

Sounds like batteries getting weak in sensors to me.

 

I have a very cheap code reader. I doubt it will display codes without a CEL.

That's the first I've heard of that. My four sensors are all different ages; you're suggesting all 4 batteries are weak?

I'm gonna ask my tire guy if there's some kind of "reset" he needs to do. If not, I spring for the new $250 part. In general, I tend to avoid a used part if it's electronic, like the IR door lock module. I mean, if the 9 year old part on my car failed, why would I trust someone else's that's at least as old or older?? Like buying a used MAF, lol. Parts like the steering wheel volume/phone buttons or window controls are more "wear and tear" and could have aged better or been better cared for.

 

Only takes one to give the warning message. Agree with getting new parts in this case, not enough saving worth taking the risk on a questionable used part that may or may not fix your issue.

 

I guess that is one of the limitations of the CLK's monitoring system. Since it can't show pressures on individual tires, if one can't be read, all it can do is say "fix me". What is interesting is that the module itself does know which tire's sensor(s) are not reporting or reporting incorrect pressure. it just has nowhere to display this information as MBZ did not reprogram the instrument cluster for that.

Poking around in SDS, I also noticed that this module has SCN coding, meaning that it is programmed to the car's VIN, which is encrypted. That is used by MBZ as a theft-deterrent. The ECU and TCU (for the 722.9) are both SCN coded. This generally requires (1) using a new, virgin part and (2) a live connection to MBZ using a licensed copy of SDS. There are "ways" around this, but none are easy ro cheap. I really can't imagine why a TPMS module would need this level of coding, so maybe it is not required, but just "possible". If it is required, then about your only option is to go to the dealer and have a new part installed. However, I am almost certain I have heard of other members replacing these with used parts.

I go back to suggesting that you get the codes pulled from the module. If you are going to DIY repairs and maintenance on the car, the $250 or less investment in a good scan tool is worth it.

 

Well, go figure!! Grazie, ItalianJoe1 (from Italian eddieo!). My tire guy has an OBD reader that "sees" the sensors in each tire, and neither one on the driver's side is showing up. Maybe my original control module works. I'll find out Monday when he gets a couple of sensors in. I asked him about simply changing batteries but these are both the older, metal type, and I've had them break in my hand so I'm happy to update to newer rubber ones.

I'll have Jimmie's Tires plug his scan tool in on Monday after he replaces to two sensors. He's done that before to "marry" the sensors to the system.

 

SCN is not the same as VIN locked. It means Specified Calibration Number (I think), meaning the module can be specifically programmed for differing vehicle configurations. So when you put that TPMS module in a car with individual sensor display it knows the difference. It's coding, setting options to match the vehicle, not VIN locking it like the theft relevant parts you mentioned. Almost every module in the car has an SCN coding option.

 

Can't change the batteries anyway, they are sealed units, the whole sensor has to be replaced when the batteries die. It's often 7-10 years, which is more than the valve stem should be used for anyway.

 

SCN is in fact Software Calibration Number, which actually is a translation for German that really means "numeric encryption". SCN is the same as VIN encoding via MBZ's encryption algorithm and can only be done on "virgin" parts. Also, it requires either a live connection to MNZ corporate who downloads the encrypted file to SDS while coding the part, or via offline, which is still obtained from MBZ corporate. There are people who can reverse-engineer this and create an offline file, but they charge about as much as a dealer would to program it for you. of course the challenge is in getting that "virgin" part, but also, there are people and tools that can wipe out a used part and make it look virgin. Again, the price for this si not much of a savings over the dealer.

As for the TPMS coding, I'm doing this in "simulation" mode, so I can't guarantee that it's the same in real-time, but it is SCN coding:

 

Maybe on old cars, but on newer cars the SCN coding can be done over and over again on many components. The initial startup and teach in of DAS components is when the VIN is locked and cannot be done again once it's set. It may be called "release transport protection" on many parts, like the ESL/EIS, VGS, M/E, that i'm aware of. Probably terminology differences between DAS and Xentry, but I know for sure I can SCN code parts on my 215 and it isn't just to VIN lock them.

 

My "official" knowledge of SCN coding ended with MY2005, so things may have changed. My understanding is that any time you get the screen asking for a VIN, followed by the screen I posted above for online/offline coding, that is SCN coding. SCN coding transfers encrypted data that is generated by MBZ corporate based on the VIN. I compare this to "activating" Microsoft software products. You key in that long license number, then go online and they verify it and transfer an encrypted key to authorize the software. MBZ is doing something similar with the VIN. My understanding is also that SCN coding can only be performed once on a virgin part. After that, there may be some adaptations that can be changed, but the part can't be SCN coded again and thus cannot be moved to a different car. Some parts I know that work this way: ECUs, 722.9 TCUs, the ESM (gearshift) in some models, NTG 2.5 COMAND units, and the rear SAM in the W164 (why?!?!).

I do know that there is also some security involved in DAS (drive authorization) that is not SCN coded. For example, the EIS does not require SCN coding nor does the instrument cluster, but they get "married" by programming them to the VIN. This is because the odometer reading is stored in both and it must match, or they will lock-out the reading. This coding does not require communicating with MBZ corporate to encrypt anything, but it is a one-time-only operation on a virgin part.

Of course there are "ways" around some of this. For example, if you have a used part that can normally not be re-coded, its EEPROM can be erased and thus it will appear as "virgin" to SDS. I have done this with an instrument cluster. The challenge in SCN coding is with the encryption algorithm. I have heard that someone has successfully reverse-engineered that and can provide a file based on your VIN to be used with DIY SDS systems.

Like I said, that is all my understanding of this, and I know things have changed some over the years. I have no idea why the TPMS module would require SCN coding, just as the rear SAM in the W164. I discovered that the rear SAM in the W164 when helping a forum member wanted to add the factory tow hitch. The WIS docs say to replace the rear SAM, but it's the same part number. The reason why is it requires SCN coding, and official SDS can't change any adaptations except during SCN coding. Luckily, the "developer mode" version of SDS has the ability to change them without re-coding. I can't find it right now, but I am pretty sure I have heard of W164 owners who replaced their rear SAMs with used parts, and even though they require SCN coding, the used part worked just fine with no other coding. It makes me wonder if the only reason for that module requiring SCN coding was to prevent adding the trailer hitch.

 

SCN coding isn't VIN programming of the part, but of the options for the vehicle based on what it has according to the VIN/Vedoc. I'm a dealer tech, I do this all day every day. SCN coding can be done over and over again, VIN paring not so much. You can re-code a 164 rear SAM when adding the trailer hitch, but you have to update the Vedoc with the option code for a tow package so when you do the SCN, it programs it properly for the trailer detection functionality. I've had to fix this exact issue before, where a hitch was added but Vedoc wasn't updated, two techs before me missed it, replace the sam again, all kinds of things. All we had to do was add the proper option code, then re-SCN code the existing rear SAM, and boom, working trailer lights.

 

Interesting. WIS states that the W164 SAM must be replaced due to the need for new SCN coding. Like I said, my experience on some of these things is a bit dated, so maybe it has changed. Another thing that I hacve run across that you might have some input for...the 722.9 conductor plate requires SCN coding. My understanding is that it can only be coded once as a virgin part. Is that true? I hear a lot of people trying to replace them with used parts, and no one has figured out how to SCN code them without erasing the EEPROM. They have, however, figure out how to "create" the code without the need for offline coding.

 

722.9 conductor plates have transport protection and are VIN locked, so the initial startup process marries them to the other DAS components and they cannot be re-programmed for another vehicle after that. The option in Xentry for SCN coding is not the same as this, I think that's why we keep going back and forth on this. I can go into the adaptation menu and select software update or SCN coding multiple times on a 722.9 VGS with no issues. But the initial startup for a new plate that locks it to the car can only be done once, and once the VIN is written and transport protection detached, that VGS belongs to that car unless you somehow can erase the EEPROM as you say, which currently is only done via aftermarket hacks.

 

OK, I understand what you are saying now.

 

The mystery continues! As ItalianJoe1 guessed, 2 of my sensors were not transmitting. Today only one was out, so I had it replaced and codes cleared; got about 2 miles and TPMS Inoperative again. Went back and had the other changed and codes cleared again, same thing: about 2 miles and inoperative again. Going back tomorrow.

 

....and yet another update: the system came back to life with the the "donor" module! when I was unknowingly driving around with 1 or 2 bad sensors, I kept swapping the modules back and forth, remembering that my original module would at least work intermittently. Once we got all the sensors transmitting, I made the illogical assumption that there was nothing wrong with my module but lo and behold: the donor one (a 2006, I believe!) works! So both Plutoe and ItalianJoe1 were correct, it seems!