RDKS/TPMS Grundlagen

In diesem Thread werde ich mir mal das Reifendruckkontrollsystem vornehmen und versuchen seine Geheimnisse aufzudecken.
Dabei geht es in meiner Grundlagenforschung darum wie die dahinterliegende Technik funktioniert, nicht wie man es freischaltet und dergleiche. Darüber gibt es genug Threads. Natürlich hoffe und freue ich auf euren fachlichen Input und Kommentare

Funktionsweise
Grundlegend arbeitet dieses System so, das in den Reifen verbaute Sensoren laufend Meßwerte ermitteln und per Funk an die Fahrzeugelektronik übertragen. Diese werden dann zur Überprüfung des Luftdrucks auf gefährlich niedrige Werte (< 1.8 Bar) überprüft und angezeigt. Jeder Sensor verfügt dabei über eine ab Werk vergebene ID, durch die das Rad identifiziert wird. Über eine Positionszuordnung "wiess" das Fahrzeug dann wo sich welches Rad befindet.

Die Positionsbestimmung funktioniert dabei wie folgt:
Über jedem Rad befindet sich eineNiederfrequenz-Antenne mit geringer Reichweite. Diese sind direkt mit dem BCM verbunden. Im Gegensatz zu den Rädern ist deren Position im Fahrzeug bekannt und unveränderlich. In einer Initialisierungssequenz erzeugt das BCM nun für die erste Antenne, vorn links ein Funksignal auf dem niederfrequenten 125 kHz (LF) Band. Dieses Frequenzband wird u.a. auch für die allseits bekannte RFID- oder auch NFC-Technologie verwand. Aufgrund der geringen Reichweite dieses Signals und dem physikalisch bedingten Abstand der Räder zueinander, erreicht dies nur den unter der jeweiligen Antenne befindlichen Sensor.
Dieser reagiert beim Empfang mit einem Burst an Signalen in denen er seine Identität und aktuellen Parameter mitteilt. Dies macht er ebenfalls per Funk, jedoch auf dem hochfrequenten 433,92 MHz Band. Dieses Signal hat eine verhältnismässig hohe Reichweite und wird vom Empfänger des Funkschlüssels (Keyless bzw. Zentralverriegelung) aufgefangen. Dieser ist ebenfalls mit dem BCM verbunden ist und zufällig dieselbe Sendefrequenz nutzt. So gelangen nur die Daten des angetriggerten Sensors zurück. Das BCM weisst nun intern die empfangene Sensor-ID der Radposition.
Nun folgt der gleiche Vorgangen mit der nächsten Antenne, vorn rechts, anschließend rechts hinten und zum Schluß links hinten.

Welche Daten werden übermittelt und wie oft?
Neben dem erwarteten Reifendruck werden auch noch andere Daten übermittelt wie: Innentemperatur des Reifens, Beschleunigung, Batteriezustand.
Durch die Antriggerung des BCM, aber auch den Fliekraftsensor erkennt der RDKS-Sensor ob sich das Fahrzeug bewegt oder steht. Danach richtet sich die Häufigkeit der Datenübermittlung. Genauere Werte werde ich noch ermitteln.

Was steckt in so einem RDKS-Sensor drin?
Die Energiequelle des Sensors ist eine einfache CR Lithium-Batterie. Laut Herstellerangaben soll diese knapp 15 Jahre halten (Praxiserfahrung habe ich hier noch keine, vermutlich wird es aber weniger sein). Aufgrund dieser endlichen und nicht sehr energiereichen Quelle, ist die Elektronik wie auch das Verhalten des Sensors auf Stromsparen ausgelegt. Darum verwundert es auch nicht, das er die meiste Zeit über passiv. Die Elektronik des Sensors ist in seinem Gehäuse vergossen um bei den hohen Rotationsgeschwindigkeiten und Kräften nicht zerstört zu werden. Es befindet sich ein Spezialchip (Herstellerabhängig) drauf, welcher alle Funktionen steuert und auch die Sensoren enthält. Zudem eine LF- und eine UHF Antenne für die Funkkommunikation.

So weit zu den allgemein bekannten Parametern des Systems und der Sensoren. Nachfolgend werde ich aufzeigen, wie ich an weitere Informationen ran komme um nach und nach die Funkkommunikation der Sensoren zu entschlüssel. Ziel ist es, diese zunächst zu verstehen und dann mit einfachen Mitteln (Arduino und Funkmodule) einen Sensor zu triggern und seine Daten zu empfangen und zu dekodieren. Anschließend möchte ich selbst Daten eines virtuellen Sensors per Funk senden und mal schauen wie mein Fahrzeug darauf reagiert, damit das Hacker-Feeling nicht zu kurz kommt Mal schauen was man damit alles interessantes machen kann.

Aus den ganzen Threads konnte man entnehmen, das Ford u.a. VDO-Sensoren vom Typ "S180084730Z" verwendet.
Also fange ich mit meiner Informationssuche einfach mal da an!

Auf dem Sensor findet man eine menge Informationen:

Was mich besonders interessiert ist die "FCC ID KR5S180020". Das FCC-ID Label erhält jedes für den Funkbetrieb zugelassene Gerät.
Unter dieser URL kann man die Zulassung durch Eingabe der ID einsehen: https://fccid.io/ (bzw. gleich zum Ergebnis: https://fccid.io/KR5S180020)
Da erfahren wir das der Sensor von "Continental Automotive GmbH" hergestellt wird. Im Frequenzband 433,92 MHz arbeitet.

Es gibt dort auch gleich zwei Bilder vom Innenleben eines solchen Sensors. Nicht sehr informativ, aber durchaus interessant:

Damit ist schonmal klar, das hier eine ganz normale Lithium-Batterie zum Einsatz kommt, wie man sie in Uhren und Taschenrechnern (sowas gabs früher mal) verwendet.
Auch erkennt man einen 18 MHz Quarz sowie den Chip mit integriertem Sensor (kreisförmige Öffnung).

Aus dem Dokument "Functional Description" kann man entnehmen wie der Sensor arbeitet:
Tire guard wheel unit type S180 052 020 which includes an integrated pressure, temperature and acceleration sensor and a RF transmitter.
RF receiver unit which includes a RF receiver (not described in this document)
Auf Deutsch: Die Einheit enthält einen Druck-, Temperatur- und Beschleunigungs-Sensor sowie einen Funksender und einen Funkempfänger.

Für den Funksender wird angegeben (weil nur der Sender zulassungspflichtig ist, wird über den Empfänger nichts gesagt):

Carrier frequency: 433.92 MHz
Frequency FSK deviation: +- 40 kHz max
Number of channels: 1
Type of modulation: Frequency Shift Keying (FSK)
Baud rate: 9600bds
Rated Output Power: < 10mW
Antenna: Internal
Voltage supply: 1 Lithium battery 3V (CR2450)
Voltage supply range : 2.1 up to 3.2V

Das bedeutet:
Die Trägerfrequenz ist 433,92 MHz. Es wird nur ein Funkkanal verwendet und die Datenmodulation (sehr wichtig für den Empfang und das Senden der Daten!) wird mit FSK-Modulation (Frequency-Shift-Keying, also Frequenzmodulation) durchgeführt.
Es gibt grundsätzlich zwei Modulationsverfahren, ASK und FSK. Beim ASK wird die Amplidute, also Signalstärke variiert und beim FSK die Frequenz auf dem Trägersignal. Dies bestimmt die Art der zu verwendenden Funkmodule.
Glücklicherweise gibt es für 433,92 MHz und FSK sehr günstige, fertige Sender/Empfänger-Funkmodule (ca. 2-3€ das Stück) auf ebay Die kommen schonmal für den Lauschangriff in Frage.
Die Angabe der Baudrate ist ebenfalls sehr hilfreich und wird mit 9600 Baud (Bit/Sekunde) beziffert.
Die Ausgangsleistung des Funksenders ist maximal 0,01 Watt, also so ein Zehntel eines normalen WLAN-Senders. Schon ganz ordentlich und für einige Meter mehr als ausreichend. Einzig die interne Antenne wird die Reichweite deutlich begrenzen.
Putzig, die Angabe der Energiequelle und Betriebsspannung.

Anschließend folgt in "DUTY CYCLE CALCULATION" auch gleich Klarheit darüber, wann und wie oft der Sensor in Betrieb geht und damit die durchschnittliche Arbeitszeit (Dutyclycle):
PARKING: 1 burst transmission every 13H + 1 WUP transmission
FIRST BLOCK: During 2 minutes after vehicle start, burst emission every 16.8s (8 burst emission)
INTERIM FIRST BLOCK: none transmission
DRIVING: 1 burst emission every 67.2s during the rest of the hour (54 burst emission)
INTERIM: none transmission
=> During 1 hour, the Wheel Unit transmits 63 bursts + 1 WUP.
1 burst = 30.29806ms MAX
1 WUP length max = 42.1ms MAX
=> total transmission during 1 hour = 63 x 30.29806ms + 42.1ms = 1.96s
DUTY CYCLE = (1.96 / 3600) x 100% = 0.06%

Ein "Burst" ist dabei eine Übertragunseinheit aller Parameter, also ein "Datensatz". Im Stand erfolgt eine unangeforderte Aussendung alle 13 Stunden.
Nach dem Fahrzeugstart (erkennt er durch den Beschleunigungssensor) erfolgt in den ersten 2 Minuten eine Übertragung alle 16,8 Sekunden (8 übermittelte Datensätze) und während der anschließenden Fahrt für die erste Stunde alle 67,2 Sekunden eine Übermittlung (54 Datensätze pro Stunde). Macht insgesamt 63 Datensätze in der ersten Fahrtstunde.
Zwischen diesen Aussendungen ist der Sensor passiv und weitgehend intern stromlos. Eine Aussendung dauert ca. 0,03 Sekunden und so kommt man auf eine Betriebszeit von 0,06% pro Stunde. Daraus wird dann der Stromverbrauch abgeleitet.
Erste Erkenntnis: Wer häufig Kurzstrecken fährt, bei dem halten die Batterien nicht so lange.

Was ein "WUP" ist, weiß ich noch nicht. Könnte "Wakeup" mit gemeint sein. Wenn ja, dann ist es der LF-Sender und der würde hiernach auf FSK als Modulation verwenden und besteht aus 10 Blocks, wobei jeder Block auf 5 '00'-Bytes besteht.
Hier verrät und die Doku auch gleich die Kodierung. "Manchester". Eine sehr wertvolle Info! Der Manchaster-Code ist die wohl häufigste Kodierungsform im Funkbereich. Sie definiert wie eine logische "1" und eine logische "0" elektrisch, bzw. als Funkwellen "aussehen". Im dieser Kodierung ist auch gleich der Takt enthalten, sodass sich ein Empfänger darauf einstellen kann, ohne hochgenaue Quarzbasis oder zusätzlichem Taktsignal.

Wow! Schon eine Menge Info die das FCC-Datenblatt hergibt. Eine wertvolle Quelle!

Als nächstes werde ich mal was über den Chip recherchieren. Da gibt es sicher auch einige interessante Dinge zu erfahren. Desweiteren baue ich mir einen Funkempfänger auf und werde den in der Nähe meiner Sommerreifen im Keller platzieren. Mal sehen ob der was aufschnappt. Ich habe früher schonmal damit den Code meiner Funksteckdosen geknackt und konnte mit einem Arduino alle fernsteuern. Achja, Garagentoröffner arbeiten auch auf dieser Frequenz und die älteren nutzen keine weitere Verschlüsselung... mein Nachbar kann ein Lied davon singen evilgrin

Sensor Betriebsmodi

Der Sensor kennt verschiedene Betriebsmodi. Im Normalfall befindet er sich in einem Schlafmodus. Hier verbraucht er praktisch keine Energie.
Aus diesem Modus wird er bei bestimmten externen oder internen Ereignissen "erweckt". Das interne Ereignis ist ein Timer, welche je nach vorherigem Betriebsmodus unterschiedlich eingestellt wird. Externe Ereignisse wären die Triggerung durch das Wakeup-Signal eines 125 khz Senders, ein signifikanter Druck- oder Temperaturunterschied oder auftretende G-Kräfte durch Rotation.

Der Sensor misst den Luftdruck alle 60 Sekunden. Liegt dieser unter 1.5 Bar, sendet er jedoch keine Daten und legt sich per Timer gleich wieder schlafen. Er befindet er sich im sog. "Storage mode" (Lagermodus). Dadurch können RDKS-Sensoren auch längere Zeit gelagert werden, ohne das dies auf die Lebensdauer der Batterie geht. In einem Reifen herrscht auf jeden Fall ein höherer Druck, ausser der Reifen verliert Luft und ist irgendwann Platt, dann würde nach einer Zeit auch hier in den Storage-Mode eingetreten. Gleiches gilt natürlich wenn der Sensor vom Rad entfernt wird. Auch für den Versand von Sensor ist das wichtig, das diese nicht zum funken anfangen.

Der Sensor misst und übergibt den Reifendruck in der Einheit kPa (Kilopascal). Ein Druck von 100 kPa entspricht dabei 1 Bar. Der Meßbereich ist laut Datenblatt von 100 kPa bis 1300 kPa, also 1-13 Bar.

Wird ein Luftdruck über 1.5 Bar gemessen, oder wurde der Sensor durch ein LF-Signal "eingeschaltet" (Power-on command), befindet er sich im "Initial mode" (Initialisierungsmodus). In diesem Zustand mißt und sendet er alle 0,85 Sekunden seine Sensorwerte. Insgesamt macht er das 256 mal hintereinander, also über einen Zeitraum von fast 4 Minuten . Diese Sequenz dient u.a. zur Funktionskontrolle und zum anlernen eines Sensors am Fahrzeug. Anschließend wechselt er in den "Normal mode".

Im "Normal mode" (Normalmodus) wird der Reifendruck alle 3,4 Sekunden gemessen und alle 60 Sekunden gesendet.

Weicht der alle 3,4 Sekunden gemessene Luftdruck um 200 mBar (20 kPa) vom vorherigen ab (positiv wie negativ), tritt der Sensor in den "Pressure alter mode" (Druckalarmmodus) ein. In diesem Zustand arbeitet der Sensor wie im "Inital mode", also mit rascher Messung und häufigen Übertragungen. Dies soll einen schnellen Druckabfall signalisieren und der Fahrzeugsteuerung einen rechtzeitigen Warnhinweis oder sogar Eingriff (ESP, ABS-Eingriff oder Temporeduktion) geben.

Ein spezieller "High temp alert mode" (Übertemperaturmodus) wird ab einer Umgebungstemperatur von 120° aktiviert. Auch hier verhält sich der Sensor wie im "Initial mode". Diese Temperaturen könnten durch eine Beschädigung am Reifen, Bremsen oder Radlager entstehen.

Was lernen wir daraus?

Bei Fahrzeugen ohne TPMS ab Werk, also die mit dem ConversMod TPMS-Patch, fehlen die entsprechenden "Trigger-Antennen" in den Radkästen. Dadurch können die Sensorpositionen nicht automatisch ermittelt werden.

Zudem können die RDKS-Sensoren nicht zur Datenübermittlung im Stand getriggert werden. Hierzu bedarf es einer signifikanten Druckveränderung (füllen/ablassen von Luft im Reifen) oder der Rotationskräfte. Dadurch werden beim Reifenwechsel die neuen Sensoren und Druckwerte erstmal nicht erkannt. Man muss schon viel Glück haben, das gerade zu diesem Zeitpunkt der 13-stündige Schönheitsschlaf der Sensoren zuende war und sich die Sensoren von selbst gemeldet hatten.

Beim ändern des Drucks hat man ca. 4 Minuten zeit, den Druck abzulesen bzw. quasi mit "Live" Ansicht zu ändern. Sehr hilfreich ist hier einer der aussen ums Auto läuft und einer der innen die Druckanzeige überwacht.

Vielleicht sollte man auch darauf achten, beim Reifendruckeinstellen an der Tanke nicht ausgerechnet neben einem anderen Ford zu stehen, sonst hat man womöglich dessen Sensoren angelernt

Vielleicht hat ja jemand eine Antwort darauf, warum der für unsere Mondeos passende Sensor die Typenbezeichnung "S180084730Z" hat, auf dem Sensorgehäuse selbst aber "S180052020K" steht?

Zitat von Norbert

Über den Empfänger im Sensor ist evtl. nichts dokumentiert weil man diesen als Einfalltor für Hacking am Fahrzeug nutzen konnte.
Im TV wurde mal darüber berichtet dass man moderne Autos auf diesem Weg auch beeinflussen kann.

Kann man sich, in einem gewissen Rahmen durchaus vorstellen. Es gibt auch einige Abhandlungen über Trackingmöglichkeiten mittels RDSK-Sensoren. Der Aufwand ist jedoch immens und der Nutzen eher klein. Die Kombination geringe Sende/Empfangsreichweite, Fahrzeuggeschwindigkeit und geringe Signalwiederholrate/Bandbreite ist es schon recht sicher. Was man aber beim "Sozial hacking" damit alles erreichen könnte bleibt der Fantasie überlassen. Natürlich könnte man dem Fahrzeug vorgaukeln das einer oder alle Reifen platt oder überhitzt sind. Sicher machen andere Hersteller inzwischen mehr aus diesen Daten als nur ein "Dingdong" im Display.

Das die Dokumente nichts über die LF-Sender sagen hat einfach den Grund, das man die teuren Analyse und Programmiergeräte verkaufen will und weil man das für eine FCC-Zulassung nicht dokumentieren muss. Was der Sensor EMPFÄNGT ist dort nicht von Belang, sonder nur was er SENDET.

So ganz nebenbei habe ich dann auch die CAN-ID für die RDSK-Sensordaten gefunden. Es ist die 079. Der Aufbau ist wie folgt: ID1 ID2 ID3 ID4 DA1 DA2 DA3 DA4.
Wobei ID1 bis ID4 die 32-Bit Sensor-ID ist (z.B. "0EDEC92F"), so wie auf dem Sensor aufgedruckt.
DA1 bis DA4 habe ich noch nicht entschlüsseln können. Von der Sache her muss es sich dabei aber um Druck, Temperatur, Batteriestatus und Betriebsmodus handeln.

Temperaturdaten werden üblicherweise als 1-Byte Wert mit einem Offset von 40 übermittelt. Wobei der Wert 40 dann 0° C entspricht und 00 eben -40° C. Die Skala geht dann, bedingt durch die maximale Größe eines Byte: 255-40= 215° C. Bei den aktuellen Temperaturen würde ich einen Wert von 40-50 (in Hex wären das 0x28 bis 0x32) erwarten. Solche Werte sehe ich aber nicht im Datenstrom (siehe unten). Oder man verwendet Bit 7 als Vorzeichen. In dem Fall müsste man 128 (Hex 80) vom Wert abziehen um positive Werte zu erhalten. Auch das passt nicht.
Auf jeden Fall sollte sich die Temperatur im Stand fast garnicht ändern, bei der Fahrt aber langsam ansteigen und dann im Stand wieder abkühlen.

Beim Druck ist mit der Übermittlung in kPa zu rechnen, welches in Bar umgerechnet werden muss. 100 kPa entsprächen 1 Bar. Demnach könnte man mit einem Byte nur max. 2,55 Bar abbilden. Das kann nicht sein. Es gibt auch Hinweise das man den kPa-Wert mal 2,5 nehmen muss. Das würde denn Messbereich bei einem Byte auf 6,375 Bar erhöhen, was schon ordentlich wär. Bei einem mittleren Druck von 2,4 Bar im Reifen wäre das ein Wert um die 100 (Hex 64). Das könnte man, mit viel gutem Willen beim ersten Datenbyte "DA1" erkennen. Jedoch ist hier auch der Wert schonmal Hex C7 oder Hex 07, was überhaupt nicht passt.

Der Batteriestatus kennt vermutlich nur "Normal" oder "Low", wäre also mit einem Bit abbildbar. Das kann überall stecken. Vermutlich ist es zusammen mit dem Betriebsmodus (Normal, Initialisierung, Alarm, etc.) in einem Byte kodiert. Mit 2 Bit lassen sich alle vier Betriebsmodi darstellen.

Zuletzt muss das noch der Beschleunigungswert drin stecken. Da würde ich erwarten das sich im Stand überhaupt nichts tut, während der Fahrt aber schon.

Hier ein Beispiel für die empfangenen Werte eines Sensors über eine Fahrstrecke von einigen KM in ca. 15 Minuten. Überwiegend Stadtverkehr. Die erste Zahl mit dem Komma ist zwar ein Zeitwert, enthält vor dem Komma aber nur die Minute, also bitte nicht nach gehen. Die ganzen Null-Werte habe ich weggelassen, es sind also nur die wirklichen Übertragungen enthalten:

Sensor 0E E0 CB 88
-------------------------
34,575 079 8 0E E0 CB 88 67 9F 3E 14
51,926 079 8 0E E0 CB 88 67 9F 3E 23
09,227 079 8 0E E0 CB 88 67 9F 3E 51
26,577 079 8 0E E0 CB 88 67 9F 3E 58
43,878 079 8 0E E0 CB 88 67 A0 3E 7D
01,228 079 8 0E E0 CB 88 67 A0 3E 87
18,530 079 8 0E E0 CB 88 67 A1 3E 49
35,830 079 8 0E E0 CB 88 67 A1 3E 44
53,229 079 8 0E E0 CB 88 67 A2 3E 2A
10,530 079 8 0E E0 CB 88 67 A1 3E 45
27,830 079 8 0E E0 CB 88 67 A2 3E 42
45,081 079 8 0E E0 CB 88 67 A2 3E 3F
02,383 079 8 0E E0 CB 88 67 A2 3F 43
18,933 079 8 0E E0 CB 88 C7 A2 3F 20
35,283 079 8 0E E0 CB 88 C7 A2 3E 2D
51,633 079 8 0E E0 CB 88 C7 A2 3F 1F
07,984 079 8 0E E0 CB 88 67 A2 3F 0C
24,288 079 8 0E E0 CB 88 67 A2 3F 18
40,586 079 8 0E E0 CB 88 67 A2 3F 17
56,885 079 8 0E E0 CB 88 67 A2 3F 18
13,236 079 8 0E E0 CB 88 67 A3 3F 19
29,586 079 8 0E E0 CB 88 67 A3 3F 15
45,890 079 8 0E E0 CB 88 67 A3 3F 17
02,187 079 8 0E E0 CB 88 65 A3 3F 16
18,490 079 8 0E E0 CB 88 67 A2 3F 17
34,839 079 8 0E E0 CB 88 67 A3 40 15
51,139 079 8 0E E0 CB 88 67 A3 40 16
07,492 079 8 0E E0 CB 88 67 A3 40 16
39,840 079 8 0E E0 CB 88 67 A3 40 3C
57,191 079 8 0E E0 CB 88 67 A3 40 40
29,492 079 8 0E E0 CB 88 07 A3 40 42
49,745 079 8 0E E0 CB 88 07 A3 40 3A
54,096 079 8 0E E0 CB 88 07 A3 40 40
58,399 079 8 0E E0 CB 88 07 A4 41 08

Der Empfang der RDKS-Daten geschieht ja über das Empfangsmodul für die Zentralverriegelung/Keyless-Go. Dieses sieht irgendwo im Dachhimmel. Weiss jemand genau wo und wie das aussieht?
Vom Anschluß her müsste das Stecker C4, Pin 8 am BCM sein, ist mit "LIN (RF RECEIVER)" im Schaltplan bezeichnet. Das Signal wird also per LIN ans BCM übertragen.

P.S.: Ich konnte mit meinem 433 MHz Empfänger bereits mal was aufschnappen. Da ist aber extrem viel anderes Zeug in der Luft unterwegs. Was gut geht, ist das empfangen der Öffnen/Schließen Botschaften vom ZV-Schlüssel Ich warte noch auf einen passenden LF-Sender um die Sensoren beliebig triggern zu können. Das aber nur am Rande, weil ein Sekundärziel von mir ja ist, selbst Funkdaten eines virtuellen Sensors senden zu können.

P.P.S.: An diesem Stecker gibt es noch weitere LIN-Busse, die mit "IMS" und "RSM". Vielleicht hat ja jemand ne Idee was das sein könnte?

Ich danke Euch! Werde das alles in die Wikibeschreibung des ZV-Systems aufnehmen. Zu dem Thema mache ich aber nochmal einen gesonderten Thread, denn da gibts noch ne Menge zu klären

Für diesen ist erstmal wichtig den Signalweg der RDKS-Sensoren lückenlos zu ermitteln. Habe mir dazu gleich mal so einen Empfängerbaustein in ebay geschossen. Für 12€ inkl. Versand durchaus vertretbar Den kann ich dann mit meinem "BCM im Glas" verbinden und müsste so sogar schon Original-RDKS-Daten empfangen können. Die LIN-Botschaften kann ich dann, zur Verifikation auch inhaltlich mit den Funkbotschaften die ich über meinen eigenen Empfänger erhalte abgleichen.

Zur Frage mit den Antennen habe ich mir mal die Pins auf dem BCM angeschaut. Laut Steckerbelegungen befinden sich die Antennen an folgenden Anschlüssen:

Stecker C1 (Grün, Motorraum)
Pin 19+20 (19 ist das Signal) => Antenne, vorn rechts
Pin 35+36 (36 ist das Signal) => Antenne, vorn links

Stecker C2 (Braun, Innenraum)
Pin 19+20 (19 ist das Signal) => Antenne, hinten rechts
Pin 35+36 (36 ist das Signal) => Antenne, hinten links

An den gelb unkringelten Stellen fehlen ganz offensichtlich Bauteile auf der Platine. Vom Abstand, Anzahl und Größe der Pads können das nur Widerstände/Kondensatoren/Dioden sein.
Der entsprechende IO-Port am Chip des BCM ist somit "unbeschaltet" und daher die Fehlermeldung.
Jetzt müsste mal jemand ein BCM aus einem mit werkseitig verbautem TPMS öffnen und Fotos von der Platine machen. Besonders Detailfotos der besagten Stellen.
Evtl. kann man das ganze nachrüsten. Die BCM-Platine selbst hat aber durchaus noch weitere Stellen mit fehlenden Bauteilen. Gut möglich das hier noch mehr fehlt. Denn hundertprozentig geht die Antennenspule nicht direkt auf einen uC-Port. Da sind noch Treiberbausteine im Spiel.

Schon. Denn einerseits passen die Pins am Board des BCM. Andererseits stimmen die Angaben in meinen Unterlagen zum BCM Pinbelegungsplan.
Evtl. gibt es hier wieder Unterschiede bei vFL und FL?!

Ich habe hier, zum Vergleich, mal den gleichen Ausschnitt, nur von einem 2011er Plan:

Nur um nochmal zu zeigen was wir schon wissen, Pinbelegung am BCM ist unterschiedlich zwischen vFL und FL. Aber nicht nur das, auch die Anordnung der Stecker ist gänzlich anders. Beim vFL sind die großen Stecker seitlich beim FL oben.
Und obwohl mein "BCM im Glas" ein FL Modell ist, steht auf der Platine was mit "Rev 2008". Also frei nach dem Motto "Alter Wein in neuen Schläuchen"

Hat von Euch zufällig jemand eine original RDKS Antenne ("Fliegenklatsche") über?
In ebay werden die um die 20€ angeboten, aber bevor ich mir sowas zulege, dachte ich, ich frag mal nach.
Brauche nur eine, zum testen.