Reifendruck-Kontrollsystem ("RDKS" bzw. engl. "TPMS") im FL nachrüsten

Zitat von Go4IT

Damit wäre es dann nicht möglich einen Sensor auf dem Labortisch oder in Ruhe zum funken zu bewegen, sondern nur durch G-Kräfte

Zitat von Go4IT

erst einschalten (und damit auf Funk reagieren) wenn sich ein entsprechender Druck aufgebaut hat oder G-Kräfte wirken

Normalerweise ja. Außer mit einem speziellen Testgerät wie es u. a. Reifenfachwerkstätten verwenden. Die können den Sensor immer auslesen, auch wenn er auf dem Tisch liegt.

Zitat von Go4IT

Die Radzuordnung könnte auch so stattfinden das während der Fahrt eine Antenne angeschaltet wird und deren Sendesignal (Botschaft) den Sensor dazu bewegt eine spezielle Antwort zu senden, anstelle der sonst üblichen Sensordaten. Anhand dieses Empfangsmusters wüsste das BCM dann das nur dieser Sensor auf die Antenne reagiert hat und die Position ist klar.

So funktioniert das.

Zitat von Go4IT

Es spricht überhaupt vieles dafür das im Stand praktisch nichts stattfindet, sondern nur während der Fahrt.

Die Sensoren senden auch wenn das Fahrzeug länger steht in regelmäßigem Abstand von einigen Stunden.

Ich würde mal vermuten das Sensoren dann senden,wenn autorisierte Anfrage kommt,wird ja selbe Prinzip sein wie beim Bluetooth LowEnergy 4.0 Geräte die um Batterie zu sparen nichts tun,bevor nicht Autorisierte(Frequenz bedient)Anfrage kommt von BCM, ZV Funk modul oder irgendwas in 433 MHz Bereich.

Ich hab mir TWRP Conversmod Patch vor paar Tage gemacht, und werde es Sensoren in Sommerreifen einbauen.

Also jofel meint das es beim Werks-RDKS keine Menüfunktion in den Einstellungen gibt, also nur dieses Informations-Menü

=> =>

Nicht aber das was man mit dem TPMS-Patch über ConversMod unter den Einstellungen sieht:

=>

Wenn das so ist, dann fehlt dem System ja jegliche Möglichkeit neue Räder anzulernen. Ergo muss es das irgendwie selbst erkennen. Wenn ich meinen Untersuchungsergebnissen trauen kann und der RFA die Sensor-IDs als Empfangsfilter benutzt, dann bleibt eigentlich nur ein Konzept übrig:

Das BCM triggert die Antennen nicht im Stand sondern ganz bewusst nur während der Fahrt und zwar aus einem einfachen Grund: Während man in Bewegung ist, ist es sehr unwahrscheinlich das die Räder ihre Positionen ändern, bzw. andere drauf kommen und ebenso das man Funksignale anderer PKW versehentlich empfängt. Die Triggerung wäre dann automatisch damit verbunden die Eingangsfilter aufzuheben und die eintreffende Sensor-ID der getriggerten Radposition zuzuordnen.

Somit würde sich das System nach einer gewissen Fahrt immer automatisch selbst kalibrieren, ganz egal was man so rumbaut, also auch ein Radwechsel von vorn nach hinten, quer, Sommer/Winter, Ersatzrad, egal.

Das entbehrt nicht einer gewissen Logik.

Bin gerade nochmal zum Auto gegangen, bin bislang noch nie über "Einstellung" sondern immer nur über "Information" zum Reifendruck gegangen. Habe nun tatsächlich auch bei "Einstellung" den Punkt Reifendruck entdeckt. Dort kann ich aber nur zw. beladen und unbeladen auswählen und auf "Prüfen" gehen, dort kommt dann wieder dieselbe Anzeige wie bei "Information". Der langen Rede kurzer Sinn: die menügesteuerte Möglichkeit eine Zuordnung zu resetten bzw. zu erlernen besitzt (braucht) die Werkslösung nicht...

Hab eben auch noch Bestätigung in der Menüstruktur des verbotenen Buches gefunden:

Ein Blick ins Wiki oder PTS (ETIS) hätte gereicht und es wäre uns klar gewesen wie die Sache läuft: https://mk4-wiki.denkdose.de/artikel/rdks/funktion

Fakt 1) Das Erkennungssystem arbeitet nicht im Stand, sondern nur während der Fahrt

Man muss für mind. 15 Minuten mit mind. mit 20 km/h fahren (Fahrzyklus), dann wird die Positionserkennung durchgeführt.

Das wird durch die Beobachtungen von jofel und Endurance bestätigt.

Fakt 2) Es gibt keine separate Anlernfunktion, diese ist automatisch

Dies wird auch in der Funktionsbeschreibung erklärt. Das BCM aktiviert bei in Fakt 1 genanntem "Fahrzyklus" die Antennen nacheinander. Dabei sorgt das Sendesignal dafür das vom Sensor an der Radposition sofort ein Datenpaket ausgesandt wird. Empfängt das BCM dieses gibt es zwei Optionen:

a) die Sensor-ID ist bereits bekannt und der Antennen/Rad-Position zugeordnet => dann passiert einfach nichts weiter

b) die Sensor-ID für die Radposition ist neu bzw. war dort nicht zugeordnet => dann wird die Zuordnung vorgenommen

Das erklärt warum es keine Anlernfunktion gibt und auch wie ein Radwechsel funktioniert. Das BCM erkennt das einfach nach einer gewissen Zeit von ganz allein. Diese Erkennung wird immer durchgeführt, bedarf also keiner speziellen Aktivierung wie beim ConversMod-Patch.

Sehr schön, dann ist das geklärt und bestätigt . Sorgen macht mir, dass das Wiki mittlerweile mehr weiß als Go4IT, aber es ist ja das Jahr des Durchbruchs von KI .

Ja Wiki wüste es schon seit 2020:-)

So mit mk4wiki Papa Oliver auch.

Warum müsst du den Rad neu erfinden Oliver!?:-)

* duck und weg läuft*

Die Welt ist so groß und mein Kopf ist so klein...

Ich hoffe das du es weißt,das es spass war.

Hab grosse Respekt von deine wissen,und Bastelstube.

Ich schreibe zwar nicht viel,aber lesen tuhe ich viel in deine Lebenswerk.

Leider sterben solche Leute wie du, und paar änlichen anderen aus.

Trotz allem Frohe Weinachten.

So, weiter gehts. In der Zwischenzeit habe ich viel getan, untersucht, getestet, gerätselt usw, aber ich komme der Sache immer näher.

Durch Reverse-Engineering der Firmware (an dieser Stelle an großer Dank an "Dieter", meinen "Lehrmeister" und eine großen Hilfe bei meinen Untersuchungen!) ist nun bekannt das es eine Service-Routine im BCM gibt mit der man die RDKS-Antennen einzeln ansteuern kann. Gedacht vermutlich zur Systemüberprüfung, bei Reparaturen oder ggf. auch für den Radwechsel (aber das wäre jetzt reine Spekulation!).

Im UDS-Standard gibt es ein "Input Output Control" mit der SID 0x2F. Dieser ist gedacht um bei ECUs Ein-/Ausgänge per Software direkt ansteuern oder auslesen zu können. Also das was normal die Software unter bestimmten Bedingungen durchführt auf Wunsch selbst zu tun. Damit lassen sich ganz erstaunliche Dinge veranstalten, weil die IO-Control meist nicht von irgendwelchen Randbedingungen oder Sicherheitsvorgaben eingeschränkt wird. Vorausgesetzt natürlich die ECU hat diesen Dienst implementiert. Um das herauszufinden hilft das zuvor schon genannte SID-Scanning, oder aber Reverse-Engineering der Firmware da in dieser natürlich ein UDS-Handler implementiert sein muss. Der zum Service-ID zu nennende DID ist 2 Byte groß, was beim ausprobieren 65.536 Möglichkeiten entspricht.

Im Falle des BCM und der TPMS gibt es in der SID 0x2F den DID 0x2A25 welcher für die IO-Steuerung der Antennen zuständig ist. Der Service erwartet eine Angabe der Antennenposition sowie des einzunehmenden Status.

• Zu beginn erwartet er einen Modus, hier wären die Werte 0x00, 0x02 und 0x03 möglich, wobei 0x03 die Aktivierungssequenz auslöst.
• Der Status besteht aus einer 4-Byte Folge, wobei ein Wert ungleich 0x00 (z.B. 0xFF) die Antenne aktiviert und ein 0x00 Wert deaktiviert.
• Die Antennenposition wird durch einen Wert ungleich 0x00 (z.B. 0xFF) in einer 4-Byte Folge angezeigt.

Die Reihenfolge der Bytes entspricht der internen Antennenanordnung, also das 1. Byte der ersten Antenne vorn ,links. Das 2. Byte der Antenne vorn, rechts. Das 3. Byte hinten rechts und das 4. Byte hinten links.

Ein gültiges Datagramm würde also so aussehen:

• Vorn, links: 2F 2A 25 03 FF 00 00 00 FF 00 00 00
• Vorn, rechts: 2F 2A 25 03 00 FF 00 00 00 FF 00 00
• Hinten, rechts: 2F 2A 25 03 00 00 FF 00 00 00 FF 00
• Hinten, links: 2F 2A 25 03 00 00 00 FF 00 00 00 FF

Das ganze muss in einer "Extended Diagnostic Session" gesendet werden. Also kurz noch ein Exkurs in UDS-Session-Handling...

Nach dem booten, befindet sich die ECU in der sog. "Default Session". In diesem Modus akzeptiert sie nur bestimmte, Betriebsunkritische/ungefährliche SIDs (z.B. auslesen der DTCs). Über spezielle UDS-Session-Befehle kann man aus diesem Zustand in andere Sessions gelangen, sofern die Randbedingungen stimmen. Eine andere Session kann z.B. eine "Programming Session", eine "Safety System Diagnotsic Session" oder eben eine "Extended Diagnostic Session" sein. Es drängt sich förmlich auf das Programmierung und IO-Control nicht während der Fahrt zulässig sein sollten

Der Wechsel der Session ist verhältnismäßig einfach, hierfür hat UDS den SID 0x10 vorgesehen. Diesem folgt ein Byte (DID) mit dem Session-Typ:

• 0x01 => Default Session
• 0x02 => Programming Session
• 0x03 => Extended Diagnostic Session
• 0x04 => Safety System Diagnostic Session

Man sendet also einfach

10 03

um in die Extended Session zu gelangen. Gelingt dies, antwortet die ECU mit einem PRC (Positive Response Code), also der angefragten SID + 0x40 sowie dem DID und einer 4 Byte langen Session-ID:

50 03 00 32 01 F4

(hier wäre die Session-ID 0xF4013200)

Nun ist man in der Extended Session und kann entsprechende weitere Befehle senden, wie beispielsweise den Code zum ansteuern der Antenne vorn links:

2F 2A 25 03 FF 00 00 00 FF 00 00 00

Alle nicht Default-Sessions haben einen Timeout. Die ECU wird die Session ihrerseits beenden sobald dieser überschritten ist. Die Timeout-Werte sind irgendwo in den ISO-Dokumenten zu UDS verbuddelt, es sind aber nur wenige Sekunden. Timeout bedeutet dabei die Zeit der Inaktivität der Kommunikation zwischen Tester und ECU. Um eine Session aufrecht zu erhalten sendet ein Tester daher meist regelmäßig eine "Tester Present" UDS-Nachricht (0x3E) um den Timeout zu verhindern. An dieser Stelle sei gesagt das der Original ELM bzw. STN eine Funktion hat um selbstständig, zyklisch solche Nachrichten zu senden.

Für einfache, manuelle Tests muss man das nicht, da reicht es beide oben genannten Bytefolgen zügig hintereinander abzusenden.

Zum testen habe ich eine Original-Antenne an den TPMS1 angehangen und das Signal mit einem DSO abgegriffen, was dann so aussieht:

Man sieht schön das die Antenne anfangs für einige Millisekunden statisch angesteuert wird bevor die Taktung beginnt. In dieser ersten Phase wird der Selbsttest durchgeführt. Die Elektronik im BCM erkennt damit ob eine Antenne angeschlossen ist oder eine Störung (Leitungsunterbrechung, Kurzschluß) vorliegt. Wäre das der Fall, bleibt es danach ruhig (Flatline). In dem Fall aber wird das Ausgangssignal mit 125 kHz moduliert, was mehr sehr schön in der Vergrößerung des Signals erkennen kann:

Die Firmware sendet über die Antennen also kein LF-Datenbank zum Sensor, so wie von mir anfänglich vermutet, sondern einfach nur ein statisches Trägersignal. Das machen einige andere Hersteller ganz genauso, weil es eben viel einfacher und störunanfälliger ist als eine LF-Datenmodulation per OOK (On-Off-Keying).

Allerdings findet das nur während der Fahrt statt, wenn also der Sensor im Rad bereits durch die G-Kräfte entsprechend aktiviert wurde und selbst sendet. Meine Vermutung ist das die angegebenen 20 km/h Mindestgeschwindigkeit in Wirklichkeit eine gewisse G-Kraft ausdrücken sollen bei der sich der Sensor aktiviert. Um das im Labor zu testen müsste ich also einen Sensor auf einer kleinen Scheibe mit einen Akkuschrauber montieren und drehen lassen, sonst wird auch die Triggerung mit LF nichts bewirken.

Sicherheitshalber habe ich einen Versuchsaufbau gemacht und eines meiner Sommerräder an die sendende Antenne gehalten und dabei das 433 MHz-Band mit einem AirSpy SDR# überwacht. Da kam absolut nichts, kein Signal vom Rad. Das bestätig meine These. Da ich grad keinen externen Sensor da hab und ich ein 20kg schweres Alu-Rad nirgendwo drehgelagert einspannen und bewegen kann, muss ich mir wohl erst einen solchen Sensor zulegen um das herauszufinden.

Der Sensor wird erstmal ohne jegliches Zutun senden, sobald eine gewisse Rotationsgeschwindigkeit erreicht ist. Dann sendet er anfangs ja alle 15 Sekunden. Wenn ich in diesem Zustand das LF-Signal erzeuge würde ich erwarten das er sofort und ggf. mehrfach hintereinander sendet. Möglicherweise sendet er sogar ein anderes Datagramm.

Um das zu überprüfen muss ich an den Funkempfänger (RXRF) ran, welcher oben im Dachhimmel sitzt und für ZV und TPM zuständig ist. Der ist per LIN-Bus direkt am BCM angeschlossen:

Interessant dabei ist, das bei Fahrzeugen mit Keyless derselbe LIN auch ans KVM verzweigt. Wo also die ZV und Schlüsseldaten verarbeitet werden hängt dann von der Einstellung in der CCC ab. Die TPMS-Daten werden jedoch immer vom BCM verarbeitet.

LIN ist ein einfaches serielles Datenprotokoll, das kann man mit einem Logicanalyzer mitschneiden und anschauen.

Der LIN-Bus (Ein-Draht-Serial-Bus) des RXRF ist an Pin 8 vom Stecker-Dachhimmel des BCM angeschlossen. Von dort verläuft er zum LIN-Transceiver (TLE2759) an Pin 6 (BUS). Der Transceiver splittet das Signal in TxD und RxD Signalzweige auf. Der TxD (Pin 4), also die Leitung die vom µC kommend Daten zum RXRF sendet verläuft direkt zum Pin 75 "P4_2 / RXD3 /IO1_2" des R32C. Dieser Pin ist Teil des UART3:

• 0x0000DD Transmit ICR
• 0x0000FD Receive ICR
• 0x0001E0 Transmit/Receive Mode
• 0x0001E1 Bit Rate
• 0x0001E2-3 Transmit Buffer Register
• 0x0001E4 Transmit/Receive Control Register 0
• 0x0001E5 Transmit/Receive Control Register 1
• 0x0001E6 Receive Buffer Register
• 0x0001F0 Transmit/Receive Control Register 2

kann aber auch als einfacher IO-Pin bedient werden:

• 0x0400C4

Ich bin jetzt kein RDKS freak, kann ich mir nicht Originale leisten, hab nur Chinese Nachbau mit Android Mirordashcam, die haben ihre Dienst getan in letzte 4 Jahre für 50€

Was ich weiss, das es bei BMW X5 von 2012 von meine Frau,idioten sicher geht.

Hintere Bereifung inkl.Felgen umgeschmissen auf Vorderachse, wegen reifen verschleiss.

Software hat es nach 10-20 km fahrt von selbst erkannt,und die anzeige Werte angepasst.

Ford wird da änlich machen.

Des wegen bin ich irritiert, das es hier von neu Anlehrnen rede ist, und RDKS Sensor ID mit bestimmten Buchstaben/Ziffern sein müss.

Reifen Händler müssten da 1000 fehlbestellungen haben, Gewährleistung usw.Damit verdient doch keiner Geld, wenn es ein Ratespiel ist,mit Bestellung.

Zitat von veni40

Hintere Bereifung inkl.Felgen umgeschmissen auf Vorderachse, wegen reifen verschleiss.

Software hat es nach 10-20 km fahrt von selbst erkannt,und die anzeige Werte angepasst.

Ford wird da änlich machen.

Ist auch so. Normalerweise geht das beim Mondeo ohne Probleme, egal welches Rad sich an welcher Pos. befindet. Normalerweise. Aber eben das ist es ja nicht immer.

Zitat von veni40

Des wegen bin ich irritiert, das es hier von neu Anlehrnen rede ist,

Auch hier gilt: Normalerweise. Aber... Da muss ... nix angelernt werden.

Zitat von veni40

und RDKS Sensor ID mit bestimmten Buchstaben/Ziffern sein müss.

Ist leider so, wie mehrere Fälle hier beweisen. Aber Go4IT ist der Sache ja auf der Spur. 🙂

Zitat von veni40

Reifen Händler müssten da 1000 fehlbestellungen haben, Gewährleistung usw.Damit verdient doch keiner Geld, wenn es ein Ratespiel ist,mit Bestellung.

Da müsste man mal die eine oder andere Werkstatt fragen. Gegeben hats das da mit Sicherheit auch schon. Bei zigtausenden Werkstätten allein in D ist die Wahrscheinlichkeit dafür bestimmt relativ hoch.

Jetzt wollte ich mir die Kommunikation zwischen RXRF (IRX) Empfänger und BCM mal näher ansehen. Es ist ja so das dieser, neben den Informationen der ZV auch die RDKS-Sensordaten empfängt und dann per LIN ans BCM weitergibt. Also habe ich mir einen LIN-Sniffer gebaut (sehr einfach, mittels L9637 Transceiver und einem USB-UART) und den Pin 8 des Dachhimmelkabelbaum-Steckers angezapft. In meinem Versuchsaufbau auf dem Labortisch erkenne ich auch den Versuch einer Kommunikation, welcher aber mangels fehlender Umgebungsbedingungen des BCM nach ein paar Versuchen endet.

Im Auto aufgebaut hatte ich mehr erwartet, wurde aber erstmal bitter enttäuscht, es kam genau NICHTS auf der LIN-Leitung. Selbst mit einem DSO habe ich nur eine 12V Flatline. Zum Test habe ich den Pin 8 mal ausgepinnt und trotzdem kann ich das Fahrzeug per ZV öffnen/verriegeln und auch die Zündung aktivieren. Nehme ich Pin 20 raus (12V Stromversorgung des Empfängers) kann ich das nicht mehr. Also hat der Empfänger schon die besagte Funktion, aber scheinbar ist das LIN-Signal nicht am BCM angeschlossen? Laut Schaltplan müsste es das aber sein.

Leider gaben einige meiner Schaltpläne hier falsche Infos aus, vermutlich stimmte das Modelljahr nicht. Aber in einem anderen habe ich dann das gefunden:

Es geht also bei Keyless nicht auf Pin 8, obwohl die Leitung im Stecker endet, sondern auf Pin 6 und dann quasi 1:1 durch aufs KVM. Das Irre dabei ist, das Pin 6 bei meinem Dachhimmel-Stecker garnicht bestückt ist...

In einem anderen Schaltplan, mehr zu meinem Fahrzeug passend anstelle allgemein, finde ich das Schema:

Dort geht der LIN vom Empfänger sowohl auf das BCM als auch auf das KVM. Der Split geschieht an dem Kompaktstecker C22-AB im Beifahrerfußraum.

Dieser verläuft zusammen mit dem Dachkonsolen-Stecker aus dem Dachhimmel-Kabelbaum. Wenn die Verbindung auch zum BCM geht um z.B. nur auf RDKS Daten zu reagieren (würde Sinn ergeben), dann müsste ich aber trotzdem dort alle Signale messen können die auch das KVM erhält.

Das würde ein Stück weit erklären warum die ZV und Zündung auch bei abgezogener Verbindung am BCM weiter funktioniert. Nicht aber warum ich dort nichts messe.

Ich vermute das der mittlere Zweig von C22-AB Pin 16 garnicht belegt ist. Ich werde mal an C22-AB 15 (GY-BN) mein Glück versuchen...

Ok, es gibt Neuigkeiten. In der Tat ist es so das der Dachhimmel-Kabelstrang nicht direkt ans BCM geht, sondern an den C22-AB. Von dort gehen dann die Leitungen u.a. weiter ins BCM an C4. Der "IRX_DATA" Pin des RFRX (433 MHz Empfänger) kommt wie im Schaltplan zu sehen auf C22-AB Pin 15 an. Auf der abgehenden Seite des C22-AB (in Richtung BCM Kabelbaum) gibt es auch einen bestückten Pin 16, ebenfalls mit GY-BN (Grau/Braun) bestückt. Dieser geht auch dann an Pin 8 vom BCM. Aber wie bereits spekuliert haben beide Pins keinen Kontakt zueinander, d.h. die im Schaltplan eingezeichnete Brücke zwischen Pin 15 und Pin 16 existiert nicht!

Möglicherweise habe ich das auch einfach nur falsch gelesen, denn bei jeder Verbindung ist immer noch ein Ausstattungsmerkmal hinterlegt. Steht da "MAIN" betrifft das alle Varianten. Im Fall der Brücke steht "IGN_SW" drunter und das steht dann meiner Vermutung nach für Fahrzeuge mit klassischem Zündschlüssel und so muss man sich diese Verbindung, zumindest die Brücke, dann bei einem Keyless Fahrzeug wegdenken. Macht alles nur so bedingt sinn, denn der Schaltplan den ich zeige ist ausdrücklich nur für Keyless Fahrzeuge. So, oder so, die Brücke gibt es nicht und somit ist klar das ich dort nichts messen konnte.

Das habe ich aber nun getan und das hat, zusammen mit einigen vorherigen Versuchen auf dem Labortisch doch ein paar Erkenntnisse mit sich gebracht.

1.) Das Protokoll zwischen RFRX-Empfänger und BCM ist KEIN LIN

Ich habe zuerst per DSO das Signal zwischen RFRX-Empfänger und BCM untersucht. Elektrisch verläuft dieses über einen TJA1020, einen klassischen LIN-Transceiver. Im BCM geht es an die UART3 Pins des R32C, welcher auch LIN könnte. Aufgrund des Baujahres dürfte es sich wenn um LIN 2.0 handeln. Dieses nutzt klassischerweise eine Baudrate von 9.600 Bit/s und eine gerade Parität. Der Ruhepegel ist hoch (logisch 1). Mit dem DSO hat ich die kürzeste Bit-Zeit ermittelt, was mir die Baudrate bestätigte (9.615 kHz ~ 9.600 Baud):

Da mein DSO neben Async serial auch LIN decodieren kann, habe ich das mal aktiviert, aber feststellen müssen das hier keine LIN-Daten rauskamen:

Es fehlen auch typische Merkmale einer LIN-Kommunikation wie der BREAK (lange Pause, auch Slow-Init genannt) und der SYNC (Burst von mind. 14 Bits zum einschwingen der Empfängerbausteine). Es kommen einfach nur klassische UART bits rüber, 8 Daten-Bits, 1 Stop-Bit, 1 Parity-Pit. Das Parity auf EVEN gestellt konnte mein DSO dann die Serial-Daten erkennen. Aber es handelt sich nicht um ein LIN-Protokoll.

Also habe ich mir einen kleinen LIN-Transceiver auf einem Steckbrett montiert, meinen FDTI USB-UART Adapter angeschlossen und mittels Terminalprogram auf 9.600 Baud 8E1 gelauscht was da kommt und das sah so aus:

12 02 00 10
12 02 40 50

Eindeutig eine Kommunikationsanforderung.

2.) Der RFRX-Eingang am BCM nur bei Fahrzeugen mit klassischer Zündung verwendet (nicht Keyless)

Versuchsweise habe ich dann die CCC von "With Keyless-Go" auf "Without Keyless-Go" geändert und siehe da, dann kommt deutlich mehr:

12 02 00 10
12 02 40 50
21 02 00 23
21 07 70 10 BD CE 6C 8E D7
21 07 70 10 BD CE 6C 8E D7
12 08 70 01 10 BD CE 6C 8E EA
21 07 70 11 0D 35 41 1D 23
12 08 70 01 11 0D 35 41 1D 1E
21 07 70 12 0D CF 88 B6 B8
12 08 70 01 12 0D CF 88 B6 85
21 07 70 13 0D CE 6A 5E B2
12 08 70 01 13 0D CE 6A 5E 8F
21 07 70 14 0D CF 88 BA B2
12 08 70 01 14 0D CF 88 BA 8F
21 0A 10 38 00 00 03 00 03 00 00 03
12 0B 10 01 38 00 00 03 00 03 00 00 30

Das Protokoll lässt gut erkennen das das erste Byte die Kommunikationspartner angibt. Im oberen Halbbyte der Sender, im unteren der Empfänger. ID-1 ist sehr wahrscheinlich das BCM, ID-2 der RFRX-Empfänger.

Als nächstes folgt ein Byte mit der Anzahl der nachfolgenden Bytes im Frame (LEN), was etwas an ISO-TP erinnert.

Dem LEN-Byte folgt dann ein Command-Byte (oben im Beispiel ist das 00 oder 40 oder 70 oder 10).

Dann folgen ggf. noch Datenbytes, also Parameter des Kommandos. Als letztes kommt ein Prüfsummenbyte (CRC). Dieses ist einfach ein XOR über den gesamten Frame, also vom ersten Byte bis zum letzten Datenbyte (ohne das Prüfsummenbyte selbst, versteht sich).

Was die einzelnen Kommandos und Parameter bedeuten muss man nun nach und nach rausfinden. Auch werden sich die Daten die ich hier im Laborbetrieb messe von denen im Feld (Auto) unterscheiden. Ich rechne im Labor damit das etliches fehlt, weil ich ja kein betriebsbereites Fahrzeug habe, sondern praktisch nur das Hirn auf dem Labortisch liegt.

Bei Fahrzeugen mit Keyless-Go geht der IRX_DATA Pin des Empfängers direkt zum KVM. Somit landen auch die RDKS-Daten erstmal beim KVM und werden von diesem dann entweder auf den HS-CAN als auch den MS-CAN Bus gelegt (das KVM ist an beiden angeschlossen, wird es aber vermutlich nur auf HS-CAN senden). Das BCM nimmt die Daten dann in Empfang und verarbeitet sie um sie ggf. selbst an einen anderen Bus (z.B. MS-CAN) zu schicken damit das IPC diese darstellen kann. Weiterhin wertet es auch die Drücke usw. aus um ggf. Warnmeldungen zu produzieren.

3.) Der RFRX-Empfänger wird auf die Sensor-ID programmiert (jede beliebige)

Was ich aber sofort gefunden habe sind die Sensor-IDs. Dieser Teil programmiert vom BCM die im BCM gespeicherten Sensor-IDs in den Empfänger:

21 07 70 10 BD CE 6C 8E D7
12 08 70 01 10 BD CE 6C 8E EA

21 07 70 11 0D 35 41 1D 23
12 08 70 01 11 0D 35 41 1D 1E

21 07 70 12 0D CF 88 B6 B8
12 08 70 01 12 0D CF 88 B6 85

21 07 70 13 0D CE 6A 5E B2
12 08 70 01 13 0D CE 6A 5E 8F

21 07 70 14 0D CF 88 BA B2
12 08 70 01 14 0D CF 88 BA 8F

Wie ja schonmal erwähnt gibt es beim Mondeo 5 Radpositionen und ich vermute das es sich beim letzten um das Ersatzrad handeln kann, sofern eines im Fahrzeug ist und kein Notfall-Kit weil Subwoofer.

Schön zu erkennen wie das BCM das Kommando 0x70 an den Empfänger schickt und dieser es in seiner Antwort quittiert.

Dem Kommando folgt dann als erster Parameter die Radposition, oder Speicherstelle. Hier sind es 0x10 bis 0x14.

Dieser folgen dann die 4-Byte der Sensor-ID und am Ende wieder das CRC.

Diese ID hatte ich mittels oben genannter UDS-Prozedur mal bewusst "falsch" programmiert, da sie nicht mit einer "0" beginnt:

BD CE 6C 8E

Zumindest schickt das BCM diese ID anstandslos an den Empfänger. Ob der was damit macht wäre noch zu klären, aber zumindest in dieser Richtung gibt es scheinbar keine Filterung oder ID-Anpassung.

Während der Fahrt kommen die Sensorwerte dann regelmäßig, aber natürlich etwas "durcheinander" angeflogen. Hier ein Auszug:

12 02 00 10
12 0A 07 0F 07 61 42 66 AC 3F 29 E8
12 0A 07 0F 07 61 39 67 B3 3D 29 8F

12 02 00 10
12 0A 07 0F 07 61 23 67 AD 3F 19 B9

12 02 00 10
12 0A 07 0F 07 61 05 67 B1 3D 0B 93

12 02 00 10
12 0A 07 0F 07 61 42 66 AE 3F 06 C5

Das Kommando 0x07 liefert also die Werte der Sensoren. Nach dem Kommandobyte folgt die 4 Byte Sensor-ID (blau), danach der Sensor-Status (grün), der Druck (rosa), die Temperatur (orange) und die G-Kraft (türkis).

Das "12 02 00 10" ist sowas wie ein BREAK bei LIN, es leitet die Kommunikation ein und gibt dem Empfänger die Zeit sich ggf. aus einem Ruhemodus heraus zu bewegen. Es kommt immer vor einer Kommunikation, ist also ein schönes Trennzeichen.

Somit ist dann auch klar das der Empfänger nur die IDs durchlässt die er kennt, gelernt hat. Beim neu anlernen, also wenn das BCM die Anlernprozedur während der Fahrt ausführt, wird es hier was anderes geben was den Empfänger veranlasst alle IDs erstmal zu akzeptieren die er in der Luft so findet. Das muss noch ermittelt werden.

Alles in allem aber schon sehr viele Erkenntnisse, wie ich finde!

Auf/Zusperren der ZV per Funkschlüssel

Beim Druck auf die "Öffnen" Taste der Funkfernbedienung sieht man z.B sowas am IRX_DATA:

12 02 00 10
12 0C 01 5C 63 F8 47 35 15 1B 41 00 C7 22
12 0C 01 5C 63 F8 47 35 15 1B 41 00 C1 24
12 0C 01 5C 63 F8 47 35 15 1B 41 00 AE 4B
12 0C 01 5C 63 F8 47 15 15 1B 21 00 AF 0A
12 0C 01 5C 63 F8 47 15 15 1B 21 00 AD 08
12 0C 01 5C 63 F8 47 15 15 1B 21 00 A9 0C

Die FFB sendet auch bei einmalig kurzer Betätigung des Tasters immer 6 Signalfolgen in Reihe. Jede hat natürlich andere Daten, da rollierende Verschlüsselung. Ähnlich sieht es beim drücken der "Abschließen" Taste aus:

12 02 00 10
12 0C 01 48 77 EC 53 11 01 25 33 00 AC 35
12 0C 01 48 77 EC 53 11 01 25 33 00 9F 06
12 0C 01 48 77 EC 53 11 01 25 33 00 9E 07
12 0C 01 6D 52 C9 76 24 25 24 23 00 9B 02
12 0C 01 6D 52 C9 76 24 25 24 23 00 A4 3D
12 0C 01 6D 52 C9 76 24 25 24 23 00 A1 38

Da das Kommando in allen Fällen "01" ist, vermute ich das die gedrückte Taste/Funktion verschlüsselt im Code enthalten ist.

Programmierung des RFRX-Empfängers auf die im Fahrzeug hinterlegten Schlüssel

Ebenso interessant wie aufschlussreich, die Programmierung des Empfängers auf die im BCM hinterlegten Schlüsselcodes:

21 07 70 00 49 76 ED 52 D6
12 08 70 01 00 49 76 ED 52 EB
21 07 70 01 49 05 D0 84 4F
12 08 70 01 01 49 05 D0 84 72
21 07 70 02 00 00 00 00 54
12 08 70 01 02 00 00 00 00 69
21 07 70 03 00 00 00 00 55
12 08 70 01 03 00 00 00 00 68
21 07 70 04 00 00 00 00 52
12 08 70 01 04 00 00 00 00 6F
21 07 70 05 00 00 00 00 53
12 08 70 01 05 00 00 00 00 6E
21 07 70 06 00 00 00 00 50
12 08 70 01 06 00 00 00 00 6D
21 07 70 07 00 00 00 00 51
12 08 70 01 07 00 00 00 00 6C

Auch hier kommt dieselbe Programmierung wie bei den RDKS-Sensoren zum Einsatz, Kommando 0x70. Das nachfolgende Slot-Byte ist jedoch ein anderes und gut zu erkennen das es in Summe 8 Plätze sind, weil es max. 8 Schlüssel geben kann. Auch gut zu erkennen das ich wohl nur 2 Programmiert habe. Und das, obwohl ich hätte schwören können das ich mal drei hinterlegt hatte... hm. Egal.

Bei genauerer Betrachtung der Empfangsdaten beim bedienen der FFB fällt auf, das die Nutzdatenbytes 2-5 eine XOR-Verschlüsselung des o.g. Schlüsselcodes enthalten und das im 7. Nutzdatenbyte freundlicherweise auch gleich der Dekodierschlüssel mitgeliefert wird.

Hier ein paar Beispieldaten aus meinem Sniff:

12 0C 01 5C 63 F8 47 35 15 1B 41 00 C7 22 => 49 76 ED 52

12 0C 01 49 76 ED 52 20 00 24 42 00 BC 65 => 49 76 ED 52

12 0C 01 48 77 EC 53 11 01 25 33 00 9E 07 => 49 76 ED 52

12 0C 01 6D 52 C9 76 24 25 24 23 00 9B 02 => 48 77 EC 53

12 0C 01 6F 50 CB 74 36 26 26 34 00 A6 3B => 49 76 ED 52

Nur einmal hat es nicht gestimmt, möglicherweise ein Übertragungsfehler und ein Grund dafür das nicht nur ein Datenpaket beim drücken einer Taste geschickt wird, sondern immer 6 in Folge.

Somit ergibt sich schonmal eine Reihe entschlüsselter Kommandos vom/zum BCM:

0x00 => Ping/Wakeup (aka BREAK)
0x01 => Taste auf ZV-Schlüssel gedrückt
0x02 => ??
0x03 => ??
0x05 => ??
0x07 => Übermittlung der RDKS-Sensordaten (ID + Status + Druck + Temperatur + G-Kraft)
0x10 => ??
0x30 => ??
0x70 => Schlüsselcode/Sensor-ID Filter im Empfänger programmieren.
0x80 => ??

bin heute wieder ein Stück schlauer geworden - und neue Rätsel tun sich auf:
nochmal zur Erinnerung für uns alle: ich hatte ja - ohne auf die führende "0" bei der Sensor-ID zu achten, 8 Stück VDO-Sensoren (Typ S180084730Z) gekauft. 4 Stück der Sensoren liegen noch unverbaut bei mir herum und haben allesamt lt. Aufdruck eine Sensor-ID beginnend mit "B". Die vier bereits verbauten Sensoren erlauben eine problemlosen Betrieb. Auch wenn das "TPMS-Tool", siehe meinen Comment #116, für die verbauten Sensoren IDs jeweils beginnend mit "0" ausgeworfen hat, so war ich bislang der Meinung, dass dies evtl. ein Fehler ist. Es müsste ja ein ziemlich großer Zufall sein, dass ich von 8 bestellten Sensoren 4 mit einer 0-er ID bekomme und genau diese - ohne darauf zu achten - alle in die WR verbauen lasse...

...bin heute unter diesen Voraussetzungen zu ÖAMTC gepilgert, die haben so ein Auslesegerät, dass Sensor IDs direkt an der Quelle (also direkt am Rad) ausliest. Seht selbst: alle ausgelesenen IDs beginnen mit "0" (!)

Auch wenn ich es immer noch nicht glauben kann, die Beweislage ist wohl erdrückend... Und eigentlich ist es ja mega-cool: ich habe ein funktionierendes RDKS mit den richtigen Sensoren! Und es ergibt sich daraus auch Erkenntnisgewinn:

• das TPMS-Tool zeigt genau die Sensorwerte an, die auch direkt am Sensor anliegen. D.h. es ist diesbezüglich vertrauenswürdig (wie damit wohl auch das BCM)
• es gibt Mondeo-seitig kein Firmeware-Update o.ä, das heimlich eine führende "0" in die Sensor ID reinschummelt

Für mich bleiben noch zwei Fragen:

1. ist die zwingend notwendige "0" in der ID Ursache oder Symptom? Damit meine ich, haben alle Sensoren mit einer 0-er ID eine Eigenschaft, die bei der ID beginnend mit "0" keine Probleme macht oder ist es tatsächlich so, dass der Mondeo eine ID mit "0" am Anfang erwartet und somit einfach "schlecht" programmiert wurde? Ich frage mich das auch deshalb, weil in diversen UK-Foren die Sensor ID "0" nicht häufig als Issue vorkommt. Dort wird öfters berichtet, dass nur Sensoren funktionieren, die "FoMoCo" als Hersteller-Aufdruck haben, welche wo "Ford" drauf steht würden nicht gehen. Aber vielleicht ist das eh dasselbe wie die "0" in der Sensor-ID...
2. hat evtl. VDO beim Sensor Typ S180084730Z die IDs im nachhinein upgedated? Das könnte der Fall sein, wenn es gehäuft bei den Mondeos zu Reklamationen kam und dieser Typ vorwiegend im Mondeo im Einsatz ist. Das ist jetzt zwar eine steile These von mir, aber ich mag immer noch nicht so recht daran glauben, dass mir der Zufall so in die Hände gespielt hat. Ich werde daher mal guggen, ob ich einen der noch unverbauten Sensoren auslesen lassen kann, dann weiss ich mehr. Das wird aber definitiv erst im Lauf des Jahres 2024 der Fall sein