Das Funkprotokoll eines RDKS-Sensors entschlüsseln

Wie bereits in den anderen Artikeln zum Thema erläutert sendet der Sensor ein Funksignal auf dem 433 MHz Band. Ziel dieses Artikels ist es aufzuzeigen wie man das Signal empfangen und dekodieren kann. Darin enthalten sind neben dem Reifendruck auch noch andere Daten wie die Innentemperatur des Reifens, die aktuelle Beschleunigung (G-Kraft) sowie der Batteriezustand des Sensors.

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.

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.

Wird die Fahrgeschwindigkeit von 20 km/h mehr als 15 Minuten lang unterschritten, geht das Reifendrucküberwachungs-System in den Parkmodus über. Im Parkmodus übermitteln die Reifendruck-Sensoren alle 13 Stunden ein codiertes Signal an die CJB. Fällt der Reifendruck innerhalb der 13 Stunden um mehr als 0,06 bar ab, erfolgt bei einem Reifendruckverlust die Signalübertragung durch den Sensor häufiger.

Mein Ziel ist dieser Sensor.

Die wohl wichtigste Vorarbeit, denn sie spart viel rumprobieren.

• 32-Bit Sensor ID 0C3AAA56 (hex) = 00001100 00111010 10101010 01010110 (binär)
• Message-Frame: ID + Pressure + Temperatue + Battery + Control-Bits + CRC

Bei der Informationsbeschaffung haben wir einen unfreiwilligen Helfer, die FCC. Hier müssen alle sendenden Geräte registriert sein um eine Betriebserlaubnis zu erhalten. Dabei wir die jeweilige Sendeeinrichtung von den Ingenieuren der FCC genau unter die Lupe genommen. Erst dann erhält der Hersteller die begehrte Lizenz und eine ID dazu. Der Hersteller muss zudem zahlreiche Unterlagen einsenden. Einige davon sind über die FCC ID sogar frei zugänglich. Die beschaffen wir uns als erstes!

Hier nutze ich den Web-Dienst https://fccid.io/ und gebe dort die ID vom Sensor ein KR5S180020 und gelange hier hin https://fccid.io/KR5S180020. Aus den Dokumenten entnehme ich wertvolle Betriebsparameter und werde im folgenden darauf verweisen.

Aus dem Dokument „Functional Description“ kann man entnehmen welche Werte der Sensor liefert: Tire guard wheel unit type S180052020 which includes an integrated pressure, temperature and acceleration sensor and a RF transmitter.

• Sensoren: Druck-, Temperatur- und Beschleunigungs-Sensor

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.

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 auch FSK als Modulation verwenden und besteht aus 10 Blocks, wobei jeder Block aus 5 '00'-Bytes besteht.

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

Der Sensor kennt verschiedene Betriebsmodi. Im Normalfall befindet er sich in einem Schlafmodus. Hier verbraucht er praktisch keine Energie. Aus diesem Modus wird er durch bestimmten externe oder interne Ereignisse „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 im Rad.

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. 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 der Storage-Mode wirken. Gleiches gilt natürlich wenn der Sensor aus dem Rad entfernt wird.

Wird ein Luftdruck über 1.5 Bar gemessen oder wurde der Sensor durch ein LF-Signal „eingeschaltet“ (Power-on command) tritt er in diesen Betriebsmodus ein. 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“.

Hier wird der Reifendruck alle 3,4 Sekunden gemessen und alle 60 Sekunden gesendet.

Weicht der 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 bei einem schnellen Druckabfall der Fahrzeugsteuerung einen rechtzeitigen Warnhinweis oder sogar Ziet zum Eingriff (ESP, ABS oder Temporeduktion) geben.

Er wird ab einer Umgebungstemperatur von >=120° aktiviert. Auch hier verhält sich der Sensor wie im „Initial-Mode“. Diese Temperaturen könnten z.B. durch eine Beschädigung am Reifen, Bremsen oder Radlager entstehen.

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. Aber selbstverständlich ist auch ein DVB-T Stick, bzw. ein richtiger SDR Empfänger (SDRplay, HackRF, LimeSDR, usw.) bestens für unsere Zwecke geeignet.

Die Ausgangsleistung des Funksenders im Sensor liegt laut FCC Datenblatt maximal 10 mW (0,01 Watt) und entspricht in etwa einem Zehntel eines normalen WLAN-Senders. Das schon ganz ordentlich und für einige Meter mehr als ausreichend. Einzig die interne Antenne des Sensors wird die Reichweite wohl deutlich begrenzen.

Aus dem FCC-Papier erhalten wir bereits die wichtigen Parameter der Funkübertragung um aus dem Funksignal einen Binären Datenstrom zu dekodieren:

• Trägerfrequenz: 433,92 MHz (69.089 cm Band) Periodenzeit 2,3046 ns
• Frequency FSK deviation: +- 40 kHz max
• Sendekanäle: 1
• Modulationsart: FSK (Frequency-Shift-Keying)
• Baudrate: 9600 Baud
• Sendeleistung: < 10 mW
• Datenkodierung: Manchester

Der Manchaster-Code ist die wohl häufigste Kodierungsform im Funkbereich. Sie definiert wie eine logische „1“ und eine logische „0“ als Funksignal übertragen werden soll. Bei dieser Kodierung ist auch gleich der Sendetakt mit dem Nutzdatensignal enthalten, sodass sich ein Empfänger darauf synchronisieren kann ohne selbst über eine hochgenaue Quarzbasis oder einem zusätzlichem Taktsignal zu verfügen. Zudem erlaubt es vor allem dem Sender hier etwas unpräzise zu sein.

Sind diese Fragen geklärt und hat man einen Weg gefunden den Sensor zum senden zu bringen, kann man in den empfangenen Daten nach der Sensor-ID suchen.

Hierzu ändert man die Temperatur am Sensor, z.B. durch erwärmen mit einem Fön und sucht in den Empfangsdaten nach sich verändernden Bytes.

Der CRC-Typ kann durch Brute-Force ermittelt werden.

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.

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.

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.

Meine Annahme bisher: Das müsste eine „isochore Zustandsänderung“ sein, da das Volumen (V), also die Gasmenge (was auch immer drin ist) des Reifens ja konstant bleibt. Der Sensor sendet einen IST-Wert von Druck (p2) und Temperatur (T2). Der Angezeigte, temperaturkompensierte Druck (p1) im Display ist immer bei 20°C (T1, „Normtemperatur“). Damit müsste die umgestellte Formel wie folgt lauten: p2 = T2 * (p1/T1) Bei der Berechnung müssen die Basiseinheiten verwendet werden. Also die Temperatur in Kelvin und der Druck in Pascal. 20° Celsius entsprechen 293,15° Kelvin. 100.000 Pascal (100 kPa) entsprechen 1,0 Bar.

Zitat von VDO: „Das Steuergerät wertet die Datentelegramme aus, erkennt den Absender und entscheidet, ob der Fahrer informiert werden muss. Überwacht wird jedes Rad separat. Dabei wird der Luftdruck durch einen Temperaturfaktor auf den Normdruck umgerechnet. Beim „Drücke speichern“ werden die Reifenfülldrücke ebenfalls auf 20 °C normiert. Um Fehleinstellungen zu vermeiden, ist deshalb besonders darauf zu achten, daß die Reifenfülldrücke bei „kalten Reifen“ kontrolliert bzw. korrigiert und gespeichert werden.“

Die Reifeninnenlufttemperatur geht spielend von „Außentemperatur“ bis auf 50-60°. Der Luftdruck ist proportional abhängig von der Lufttemperatur. Damit der Druck in Winter und Sommer, Stand und Autobahnraserei halbwegs stimmt und überwachbar bleibt, werden die vom Sensor gesendeten Druckwerte um die Temperaturdifferenz kompensiert. Das heißt das man von einem Drucknormalwert bei 20° C ausgehet (Reifendruckfüllung). Fällt die Temperatur darunter, wird der gesendete Druckwert entsprechend hochgerechnet. Ebenso bei steigendem Druck abgezogen. Ansonsten hättest Du da ganz andere Werte im Display! Die Werte für Temperatur und Beschleunigung habe ich inzwischen geknackt. Den Temperaturwert kenne ich zwar, aber die Umrechnung ist mir noch nicht ganz klar. Ich werde dann hier mal die „rohen“ Daten posten, damit man mal sieht was so im Reifen abgeht

Irgendwie muss ein Bytewert von 0xA9 letztenendes einem berechneten Luftdruck von 2,32037 Bar entsprechen. Zur Gegenprobe noch die anderen Werte: 0xAE = 2,38902 Bar / 0xB3 = 2,45767 Bar / 0xB7 = 2,51259 Bar.

https://mondeo-mk4.de/forum/thread/20310-rdks-tpms-grundlagen/?pageNo=2.