Beiträge von Go4IT

Zitat von Dermon4

Das Problem ist dass das was geliefert wird und das auf den Fotos des Verkäufers nicht immer dasselbe sind.

Ja, genau so ist es. Leider. Ist eine Lotterie.

Ja, Bilder sind immer gut!

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 => ??

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.

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.

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!

Davon gehen wir hier eigentlich aus, wir wollen ja auch dazulernen

Achso, hier hatte ich eine Reparatur für einen Blinkerhebel im Wiki hinterlegt. Das Prinzip dürfte beim Wischerhebel dasselbe sein:

https://mk4-wiki.denkdose.de/artikel/lenkst…ebel_reparieren

19andre79 hast ne PN

So rein aus dem Bauch und der Erfahrung heraus würde ich auf verschlissene Kontakte im Wischerhebel tippen. Sowas ähnliches hatten wir hier schonmal, musste mal suchen...

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...

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...

Schöne Weihnachten, bis Neujahr liest man sich sicher noch

Ausgehend von der Signatur welche die HW-Funktionen der Firmware mitteilen findet man folgende Funktion an Adresse 0xFFF8_98D5 die diese behandelt:

Schön zu erkennen, selbst ohne jegliche Assembler-Kenntnisse, wie die verschiedenen Signaturen abgeprüft werden. Offensichtlich gibt es diese Varianten:

• 0xDDDD => Diesel BCM mit Xenon, BLIS, TPMS
• 0xEEEE => (vermutlich) Diesel BCM mit Xenon
• 0xCCCC => Diesel BCM mit Xenon, BLIS
• 0x2222 => (vermutlich) Diesel BCM ohne alles

In der Firmware für Benziner BCMs sind natürlich andere Signaturen hinterlegt (z.B. 0x5555 bei einem Benziner ohne alles).

Die oben gezeigte Routine vergleicht die Signatur im Flash mit verschiedenen Werten und liefert dem Aufrufer eine 1 zurück wenn es sich um eine dieser Signaturen handelt, andernfalls eine 0. Da die hier abgefragten Signaturen nur Diesel-BCM Signaturen sind könnte das eine einfache Kondition sein sich bei einem Diesel so und bei einem Benziner anders zu verhalten. Aufgerufen wird sie nur an einer Stelle im Code (0xFFFF8_9982):

Ist das Ergebnis 0, wird der linke Teil ausgeführt ansonsten der rechte.

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

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

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.

Habe jetzt drei Tage rumgerätselt warum ich mit meinen ELM-Adaptern (und ich habe reichlich davon...) keine Multiframe-Messages (ISOTP Fragmentierung) direkt über die Serielle Console empfangen kann, es lag am Clone. Heute habe ich einen OBDLinkEX (Original STN-Chipsatz) erhalten und der funktioniert wie erwartet.

Folgendes habe ich probieren wollen: Abfrage der im BCM gespeicherten VIN direkt mit AT-Befehlen, also ohne Software.

Ich habe folgende Adapter-Typen, allesamt Clones:

Tunnelrats ELM327 (manueller Umschalter)

Tunnelrats TRE27 (automatischer Umschalter, STN-Kompatibel)

ELS27 (autom. Umschalter, STN-Kompatibel):

CM327 von ConversMod (autom. Umschalter)

Alle drei haben bislang mit ELMConfig und ForScan keinerlei Probleme gezeigt.

Wie gut zu erkennen ist haben alle einen Clone-Chip drauf, irgendein PIC. Der Original-ELM ist auch ein PIC, allerdings wurde die Software davon scheinbar nur teilweise kopiert.

Man schnappt sich ein beliebiges Terminalprogramm (ich habe HTerm verwendet), verbindet sich mit dem Adapter und gibt folgendes ein:

AT WS

Da sollte es eine Rückmeldung geben, ähnlich

ELM327 v1.3a

(die Version kann variieren)

Dann den Adapter mit dem Fahrzeug verbinden und folgendes eingeben

AT SP 6
AT SH 726
22 F1 90

Das stellt HS-CAN mit der OBD-ID 726 ein und sendet den UDP-Request "Read Data By Identifier" mit der DID 0xF190 welcher der VIN entspricht.

Erwartet hätte ich eine Multi-Frame Antwort, bekommen habe ich aber immer nur das erste Paket (0: ...):

>22 F1 90
01B 
0: 62 F1 90 57 46 30 

Technisch gesehen kann eine CAN-Botschaft nur 8 Bytes transportieren, wovon bei UDS eins für das Protokoll draufgeht. Beim ersten Frame noch eins für die Gesamtlänge der Antwort (0x1B = 27 Zeichen). Der ELM (Tester) sendet die Anfrage zur ECU (Server) und diese antwortet mit einer Multiframe-Info im First-Frame. Das müsste der ELM ein Flow Control Frame quittieren und sodann würde das BCM die weiteren Consecutive Frames antworten bis alles übertragen wurde. Mittels eines CAN-Sniffers habe ich gesehen das der ELM kein Flow Control sendet. Dadurch verbleibt es bei dem First Frame.

Mit dem OBDLinkEX läuft das ganze wie erwartet:

>22 F1 90
01B 
0: 62 F1 90 57 46 30 
1: 53 58 58 47 53 41 53 
2: 43 47 58 34 32 37 33 
3: 00 00 00 00 00 00 00 

Vielleicht wollt ihr das mit Euren auch mal testen, wäre interessant?!

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.

Ich wollte diese Serie mal starten um denjenigen die interessiert sind zu zeigen wie man mit einfachen Mitteln, ohne teure Spezial-Hardware/Software auch direkt über den CAN mit Steuergeräten sprechen kann. Hier wird nur ein einfacher ELM-Adapter, ein PC und ein Terminalprogramm vorausgesetzt.

Einige Dinge gleich vorweg...

• Von besagtem ELM-Chip gibt es bekannterweise unzählige Raubkopien (Clones) aus China. Ich verwende auch so einen, mit automatischem HS-CAN/MS-CAN Umschalter weil ich keinen Bock auf das rumgeschalte habe und weil die inzwischen günstig genug sind das sich einer mit manuellem Umschalter nicht mehr lohnt. Aber immer mit Kabel, nicht mit Bluetooth oder WLAN. Dazu gibt es dann auch mitunter irgendwelche Handy/Tablet-Apps oder so. Damit beschäftige ich mich aber nicht.
• Für "intensive" Dinge wie z.B. Firmware-Uploads ist die Methode ungeeignet, es geht hier wirklich nur um Kleinigkeiten bzw. Erkenntnisgewinn. Sowas wie das auslesen von Parameter, patchen von Parametern oder ausführen von Modul-Funktionen ist jedoch möglich.
• Auch entbehrt diese Methode jeglichem Komfort. Man arbeitet hier quasi direkt Low-Level und muss schon wissen was man da sendet oder empfängt. Ein gewisse Kenntnis der Protokolle zur Erzeugung bzw. Interpretation der Botschaften ist unerlässlich. Es gibt also keine Klicki-Bunti Tools mit toller Fehlermeldung, sondern es muss alles Hard-Core gemacht werden. Wem Begriffe die Hexadezimal und CAN nichts sagen, sollte hier erst nachholen.

P.S.: Ein Nachruf auf Elm Electronics die dieses Jahr ihr Geschäft eingestellt haben.

Los gehts!

Grundsätzlich arbeiten alle ELM-Adapter gleich. Auf der einen Seite geht es per OBD-Port zu den CAN-Bussen vom Fahrzeug, auf der anderen per USB-Kabel in den PC. Dort bildet der Adapter über entsprechende Treiber einen virtuellen COM-Port ab. Er verhält sich also wie ein serielles Endgerät. Der original ELM-Chip (ein programmierter PIC) nutzt ein Heyes-Ähnliches Protokoll, wie man es früher bei den Modems kannte (die Älteren unter uns werden sich erinnern...). Man spricht also ein ELM-Protokoll mit dem Chip und der Chip spricht setzt das dann in CAN-Bus Botschaften um, bzw. umgekehrt. Die Befehle sind gut dokumentiert, von ELM selbst und auszugsweise auch im Wiki https://mk4-wiki.denkdose.de/artikel/elm327…protokoll/start

Terminalprogramm einstellen

Um nun direkt mit dem ELM-Adapter sprechen zu können braucht man noch ein Terminalprogramm. Ich verwende dazu HTerm (https://www.der-hammer.info/pages/terminal.html) aber es gibt natürlich unzählige andere die genauso ihren Dienst tun werden. Der Script Communicator (https://sourceforge.net/projects/scriptcommunicator/) ist richtig gut und hat viele nützliche Zusatzfeatures, hat aber auch eine andere Lernkurve die HTerm.

Nach dem Start von HTerm stellt man die COM-Parameter ein (1). Der COM-Port des Adapters sollte bekannt sein. Einfache Möglichkeit den rauszufinden ist, den Adapter erstmal nicht anzustecken und die Liste der Ports aufzuklappen. Danach dann anstecken, kurz warten, den "R"-Button drücken und nochmal nachsehen, dann man sollte den neuen erkennen.

Die Parameter für die serielle Kommunikation (1) stellt man am besten erstmal auf die Default-Parameter des ELM-Chips ein: 38.400 Baud, 8 Daten-Bits, 1 Stopp-Bit, keine Parität (8N1) und klickt "Connect".

(!) Der ELS27 oder TRE27, bzw. andere ELM-Adapter mit automatischer HS/MS CAN Umschaltung verwenden ggf. andere Baudraten. Mein TRE27 z.B. arbeitet nach dem anstecken mit 2 MBaut (2.000.000 Baud).

Das Terminal wirkt wie eine Kommandozeile. Jedes eingegebene Kommando muss mit einem Zeilenende-Zeichen abgeschickt werden. Hat man nichts anderes eingestellt ist dies einfach das Return-Zeichen (als "CR" oder auch "\r" dargestellt). Das stellt man sowohl beim Empfang als auch beim Senden ein (2).

Weil die Schnittstelle zum ELM rein auf ASCII-Zeichen basiert (auch Daten werden als ASCII-Zeichen kodiert angegeben), stellen wir den Typ auch entsprechend ein (3).

Erste Kommunikation und CAN-Parameter einstellen

Bevor man irgendwas anderes tut sollte man die Kommunikation überprüfen und ob man mit dem richtigen COM verbunden ist. Das geht am einfachsten mit dem "AT WS" Kommando, welches die Version des ELM-Chips (Firmware) zurückliefern sollte:

AT WS
> ELM327 v1.5

Das ">" ist nicht Bestandteil der Botschaft, es wird vom Terminalprogramm hinzugefügt

Nun sollte man die Schnittstelle einstellen:

AT L0
> OK
AT E0
> OK

AT L0 => Sende kein zusätzliches LF-Zeichen am Zeilenende (Default: L0). Diese Einstellung muss mit der in HTerm korrespondieren.

AT E0 => Erwarte die gesendeten Befehle nicht als Echo zurück (Default: E1). Fortan gibt es also nur noch "OK", Nutzdaten oder eine Fehlermeldung in dem "Received Data" Fenster.

CAN-Schnittstelle konfigurieren

Nun müssen wir den Adapter für den Bus vorbereiten mit dem wir kommunizieren wollen. Das wird über das "SP" Kommando (Set Protocol) erledigt. Dieses gibt sowohl den Typ als auch die Geschwindigkeit des Busses an. Der CAN im Mondeo ist ausnahmslos mit 11 Bit IDs (Standard ID) und es gibt nur zwei Geschwindigkeiten, 500 kbaud und 125 kbaud. Somit kommen nur zwei Modi in Frage:

• "AT SP 6" => HS-CAN
• "AT SP B" => MS-CAN / MM-CAN

Als Beispiel nehme ich mal das BCM. Dieses kommuniziert ausschließlich auf dem HS-CAN mit einem Tester. Also

AT SP 6
> OK

Um nun ein reines CAN-Paket zu senden (also ohne die eigentlichen Stärken des ELM das Protokoll zu kennen auszunutzen) geben wir zunächst die CAN-ID der zu sendenden Botschaft an:

AT SH 726
> OK

In diesem Fall senden wir mit CAN-ID 0x726, darauf reagiert das BCM.

Da der ELM-Chip für OBD entwickelt wurde und es dort nur Botschaften mit max. 7 Datenbytes gibt, wir aber 8 haben wollen für volle Flexibilität, müssten wir das noch umstellen. Der Befehl hierfür lautet "AL" (Allow Long Messages):

AT AL
> OK

Es gibt noch mehr Automatismen abzustellen um reine CAN-Botschaften zu verschicken:

AT CAF 0
> OK
AT ST FF
> OK

Der "CAF0" sorgt dafür das ELM nicht versucht die Antworten zu formatieren.

Das "ST40" setzt einen höheren Timeout für die Antworten. Der Default is "32" was 200 ms entspricht. Das ist für manche Anfrage zu kurz und ELM sendet dann "NO DATA" auf die Konsole. Daher setzen wir ihn etwas höher... Sollte das BCM im Schlafmodus sein, reicht auch diese Zeit nicht aus, dann macht es Sinn vorher eine andere CAN-Botschaft zum aufwachen zu senden.

Damit wir eine Antwort besser zuordnen können aktivieren wir die Anzeige der Header-Informationen

AT H1
> OK

Nun können wir die ersten Daten senden!

Ab dann reicht es aus die Rohdaten zu senden:

03 22 2A 00 00 00 00 00
> OK
...
> 72E 07 62 2A 00 BD CE 6C 8

Hiermit habe ich die TPMS-Sensor-ID (VR) abgefragt. Die Antwort vom BCM (CAN-ID 0x72E) lautete: "BDCE6C08".

Ja, es ist für die Wissenschaft fast schon tragisch das Du nun über ein funktionierendes BCM verfügst, so bleiben einige Tests zweifelhaft

Das werden wir also erst im Frühling wissen wenn Du die Sensoren in den Rädern hast und montierst. Ich würde dir bis dato trotzdem empfehlen erstmal nur ein Rad zu machen...

Du weisst ja nicht ob die Sensoren in den Rädern nun 0er sind oder Ber. Die Idee von Endurance hatte ich auch schon das Du einfach ein Rad durch eines ohne Winterreifen ersetzt und den Sensor in die Nähe legst. Das könnte aber einfach daran scheitern das die Sensoren im Tiefschlaf sind und erst einschalten (und damit auf Funk reagieren) wenn sich ein entsprechender Druck aufgebaut hat oder G-Kräfte wirken. Beides wäre bei diesem Test-Setup nicht der Fall.

Auch spricht bislang einiges dafür das die Raderkennung nicht wie anfänglich gedacht beim einschalten der Zündung erfolgt, sondern später während der Fahrt. 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. Einmal aktiviert sendet er auch wenn er wieder im Ruhezustand ist, nur halt sehr selten. Das soll sicherstellen das man nicht unbemerkt mit einem Plattfuß losfährt.

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.

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

Die Frage mit "0" oder nicht kann auch vom Empfänger (RFA) abhängen. Untersuchungen haben gezeigt das das dieser vom BCM mit den zu empfangenen IDs programmiert wird und fortan dann auch nur noch auf diese IDs hört und sich so allem anderen Funkschmutz schützt. Das gleiche gilt für die ZV die ja auch darüber läuft. Dazu ist einmalig das Henne/Ei Problem zu lösen. Bei der ZV ist das der Anlernvorgang. Bei den TPMS-Sensoren wäre das ein Radwechsel und aufrufen der Funktion "Sensoren zuordnen" im IPC. Darüber müsste auch was im Handbuch stehen? In diesem Fall könnte der Filter kurz aufgehoben werden und alles empfangen was reinkommt. Sobald die Software dann vier verschiedene Werte gelernt hat macht diese den Broadcast-Empfang wieder dicht. Die Radzuordnung passiert dann später wieder wie gehabt automatisch.

Das BCM kann man mittels UDS-Nachrichten über den HS-CAN ansprechen. Das erste was man so tut wenn man ein noch unbekanntes Modul (ECU) untersucht ist die UDS-Adresse des Moduls zu ermitteln. Für das BCM ist diese wohlbekannt: 0x726

Eine Nachricht auf diese CAN-ID wird vom BCM auf dem HS-CAN erkannt und behandelt. Sollte dabei etwas sinnvolles herauskommen antwortet das BCM mit einer Nachricht auf der CAN-ID 0x72E, das legt das Protokoll so fest (Empfangs-ID + 8).

UDS definiert zahlreiche Services, ein immer sehr dankbarer ist der "Read Data By Identifier" mit der "Service-ID" (SID) 0x22. Er erhält als einzigen Parameter eine 2 Byte langen "Data Identitifier" (DID). Dieser referenziert einen Datenwert den die ECU liefern kann.

Die Antwort der ECU enthält dann entweder einen negativen Ergebniscode oder einen positiven. Im letzteren Fall folgen dann die Daten des angeforderten Identifiers. Entweder direkt in der Nachricht, wenn diese kurz genug um in einen Frame zu passen (SF=Single Frame), oder eben Fragmentiert mit einer Folge von nachfolgenden Frames (FF=First Frame und entsprechende CF=Consecutive Frames).

Ein Teil der DIDs ist genormt und wird z.B. bei der OBD-Fahrzeugdiagnose verwendet, z.B. die Seriennummer, Firmware-Version, Hardware-Version, usw. Der große Rest kann Herstellerspezifisch belegt werden. Ein schön Test ist es einfach alle Werte durchzuprobieren, bei 2 Bytes sind das maximal 65.535 Varianten (inkl. den genormten). Das dauert garnicht lange und man hat zumindest eine Reihe von DIDs auf die das ECU reagiert. Damit kann man dann z.B. Routinen im Firmware-Code suchen oder einfach versuchen aus den gelieferten Daten einen Sinn zu beziehen. Da kommt natürlich nicht immer Klartext (ASCII) rüber.

Im Fall des BCM ergab ein solchen "Scan" das auf den DIDs 0x2A00 bis 0x2A04 die im E2 Data Flash gespeicherten RDKS-Sensor-IDs geliefert werden. Schickt man das UDS-Datenwort

726 8 03 22 2A 00 00 00 00 00

aus den HS-CAN, erhält man als Antwort z.B.

72E 8 07 62 2A 00 0D CE 6C 8E

(Wie UDS funktioniert und wie der Frame-Aufbau ist werde ich hier jetzt nicht erklären, das steht alles im Wiki oder im Internet)

Die mit Read Data gelesenen Werte kann man grundsätzlich auch mit "Write Data By Identifier" (DID 0x2E) beschreiben. Das TPMS-Tool hat zwar in der GUI einen "Write" Button, aber der wird nie anklickbar. Wer .NET Decodieren kann kann sich ja mal mit JetBrains dotPeek o.ä. darin umsehen ob das nur nie fertig programmiert wurde oder unter welchen Bedingungen es evtl. doch geht?

Egal, jedenfalls kann man das einfach mal probieren. Nicht jeder mit Read lesbare Wert ist auch beschreibbar, das sieht man dann am Rückgabewert der Antwort.

Also sende ich einfach mal:

726 8 07 2E 2A 00 BD CE 6C 8E

und es kommt

72E 8 03 7F 2E 78 00 00 00 00
72E 8 03 6E 2A 00 00 00 00 00

Die 0x7F in der ersten Antwortet bedeutet "Service Not Supported In Active Session". Zum beschreiben muss man also eine andere als die Default-Session eröffnen, vermutlich eine Extended Session. Das ist nicht unüblich. Würde das BCM meine Anfrage generell ablehnen, hätten wir eine 0x11 bekommen.

Interessant ist aber auch die zweite Antwort, denn 0x6E ist die angefragte SID + 0x40 (0x2E + 0x40 = 0x6E) was eine positive Antwort bedeutet.

Hm, erst Nein, dann Ja? Die Antwort liegt im Protokoll und im NRC-Code, das letzte Byte der ersten Antwort. Die 0x78 bedeutet in diesem Kontext nämlich nicht nein, sondern "Request Correctly Received-Response Pending". Das BCM sendet also rasch eine Antwort mit dem Hinweis "Ich bearbeite Deine Anfrage, ruf mich nicht an ich rufe Dich an!". Diese Funktion kann sich nur ein Beamter ausgedacht haben Sie soll wohl verhindern das eine Ausführung die intern einfach was länger dauern kann (wie z.B. das beschreiben einer EEPROM Speicherstelle) zu einem Timeout beim Tester führt weil der nicht so lange auf die Antwort warten wird. So weis der Tester nach der ersten Antwort das eine zweite folgt.

In der zweiten Antwort erhalten wir dann die positive Rückmeldung, die neue ID ist gespeichert. Und ja, lesen wir diese nun wieder zurück bekommen wir:

72E 8 07 62 2A 00 BD CE 6C 8E

Das bestätigt auch das TPMS-Tool

Es ist also grundsätzlich möglich eine beliebige ID ins BCM einzukodieren. Die Frage wäre nun ob diese dann auch verwendet wird? Sollte das der Fall sein wäre es nicht unwahrscheinlich das man auch mit Nicht-0 Sensor-IDs arbeiten kann.

Das herauszufinden liegt nun an uns.