Beiträge von Go4IT

  • Reverse Engineering des Batterie-Sensors

    Es hat jetzt etwas gedauert, auch um div. Auswertungen zu machen, vor allem aber auch um mein Tool zu entwickeln, aber ich denke Spannung und Strom habe ich entschlüsselt.

    Für den Test-Aufbau habe ich den LIN des Batteriesensors vom Fahrzeug getrennt und direkt mit meinem Sniffer-Tool verbunden. Im Tool habe ich eine Funktion "POLL" entwickelt die eine bestimmte ID als Master in einer wählbaren Periode auf den Bus legt. Damit habe ich die ID 0x0D, welche ich in Verdacht hatte Strom und Spannung zu enthalten über fast 2 Stunden mitlaufen lassen, während ich das Fahrzeug nur am Batterieladegerät (CTEK MX5) hatte. Die Spannung habe ich zwischendurch mit einem Fluke Multimeter überprüft und bis auf 0,02V passt sie präzise zur Formel und den Messwerten des Sensors.

    LIN ID 0x0D

    Mein Tool liefert z.B. diesen Frame:

    Code
    (10657.565926) lin0 00D#2520E157 # RX Classic

    Der erste Wert in Klammern ist die Zeit in Mikrosekunden seit dem Start des Sniffers. Die "00D#" zeigt die LIN ID (nicht PID!) an, danach folgend die Bytes in HEX-Paaren. Das "RX Classic" zeigt an das die Prüfsumme des LIN-Frames mit der Classic-Methode berechnet wurde (LIN Standard 1.3). Die Bytes liegen in der Reihenfolge vor wie sie auf den Bus geschickt wurden.

    Strom (1.+2. Byte)

    Der Strom berechnet sich aus dem 1. und 2. Byte im Little-Endian Format. Also muss man aus "2520" ein "2025" machen um einen 16-Bit Wert zu erhalten. Dabei ist der Ruhezustand ("0 A", also kein Stromfluß aus/in die Batterie) mit dem Zahlenwert 0x2000 (8192 dez.) versehen, diesen muss man abziehen um einen relativen Stromfluß zu erhalten. Werte über 0x2000 zeigen also eine Ladung (Strom fließ in die Batterie) und Werte unter 0x2000 eine Entladung (Strom wird aus der Batterie entnommen) an. Die kleinste Einheit sind 10 mA.

    Die Formel lautet: I [mA] = ((b[1] << 8 | b[0]) − 0x2000) × 10

    Damit ist ein Wertebereich von -82A (Entladung) und +573A (Ladung) darstellbar.

    Spannung (3. Byte)

    Die Spannung ergibt sich aus dem 3. Byte geteilt durch 16.

    Die Formel lautet: V = b[2] / 16

    Damit ist ein Wertebereich von 0,0 bis 16,9 Volt mit einer Nachkommastelle darstellbar.

    Zähler (4. Byte)

    Der Wert erhöht sich einfach alle 11 Minuten um eins und läuft nach 0xFF wieder auf 0x00 über. Das wird vom BCM u.U. dafür verwendet die Plausibilität der Sensorwerte zu überprüfen um sicherzugehen das der Sensor nicht abgestürzt ist/hängt.

  • Verkaufe meinen Mondeo

    Ja, irgendwann muss was neue her, das ist klar, auch bei mir. Ich wünsche Dir viel Erfolg beim Verkauf des Mondeo, als Benziner sollte man noch etwas dafür bekommen können, meinen Euro4 Diesel kann ich faktisch nur noch fahren bis er auseinanderfällt oder nach Osteuropa geht, Marktwert hat der keinen mehr (was echt bitter ist, wenn ich sehe was manche für alte Kleinwagen so aufrufen...).

  • Verkaufe meinen Mondeo

    Oha, ich sehe den nächsten entschwinden... so langsam sollten wir uns Gedanken über das Forum machen.

    Rabatte sind toll, aber sind es auch welche? Oder vorher drauf geschlagen? Was zahl der Staat? Und was kostet das am Ende trotz der tollen Rabatte trotzdem noch?

    gobang ich fürchte es ist egal was du aktuell kaufst, wenn das Fahrzeug jünger als 5 Jahre ist machst Du da aktuell eh nicht viel mehr dran als das mechanische (Reifen, Bremsen). Alles elektronische ist inzwischen mit SSL und Verschlüsselung auf CAN so abgesichert, da kommt man als "normalo" eh nicht mehr dran. Davon ab pätzen die Autos doch jeglichen Anpassungsversuch sofort per Internet zum Hersteller/Händler...

  • Reverse Engineering des Batterie-Sensors

    Ich habe meinen Sniffer um eine SCAN-Funktion erweitert, dabei sendet er als LIN-Master die IDs 0x00 - 0x3F auf den Bus. Wenn sich ein Slave angesprochen fühlt sendet er seine Daten zurück. Da der Batteriesensor ja permanent am Strom ist (anders als z.B. der Regensensor oder das BCM) ist auch sein Bus immer aktiv. Also habe ich mal nur den an meinen Sniffer gehangen und somit ist nun klar welche IDs der belegt:

  • Reverse Engineering des Batterie-Sensors

    Ich habe meinen LIN-Sniffer nun um eine Sendefunktion erweitert. Jetzt wird es interessant. Besonders angenehm ist, das LIN nur dann sendet wenn der Master das tut und nach Zündung aus hält das BCM auf dem LIN-Bus die Füße still. Somit kann ich ungehemmt senden. Wenn natürlich das BCM einige Module vom Strom nimmt habe ich schlechte Karten...

    Zumindest beim Batteriesensor ist das nicht möglich, denn der hängt ja direkt an der Batterie, ohne irgendwelche Kill-Switches dazwischen :) Und von dem kann ich schonmal seine Teilenummer abfragen.

    Code
    HEADER 2B
HEADER sent for ID 0x2B - watch for RX response
(1890.789612) lin0 02B#024147394E000000 # RX Classic
HEADER 2B
HEADER sent for ID 0x2B - watch for RX response
(1891.210934) lin0 02B#0331304336373900 # RX Classic
HEADER 2B
HEADER sent for ID 0x2B - watch for RX response
(1891.610417) lin0 02B#0444450000000000 # RX Classic

    Und nun "pinge" ich einfach mal alle IDs durch... mal schauen

  • Reverse Engineering des Batterie-Sensors

    Nun habe ich mein Sniffer-Tool verfeinert und es liefert mir über WiFi im CANDUMP Log-Format die LIN-Frames welche ich dann mit SavvyCAN laden und auswerten kann.

    Generelles zum Reverse Engineering eines LIN-Busses

    Auf dem LIN gibt es immer nur einen Master und bis zu 64 Slaves. Dabei kann nur der Master eine Kommunikation starten, die Slaves sind passiv und senden nur wenn die vom Master auf den Bus gelegte ID sie anspricht. Dementsprechend kann eine ID immer nur zu einem Slave gehören. Ein Slave kann aber mehrere IDs haben und sowohl Daten vom Master empfangen als auch welche an diesen übermitteln. Das "Wissen" darüber, welche IDs zu welchem Slave gehören, wie viele Bytes dieser auf einer ID erwartet oder sendet, steckt in einer LDF die aber von keinem Fahrzeughersteller öffentlich verfügbar gemacht wird.

    Die LIN-Kommunikationsart bedingt aber das der Master Sensoren periodisch abfragen muss um eine Zustandsänderung zu erkennen, wohingegen Aktoren nur dann angesprochen werden wenn etwas getan werden soll. Zustandsangaben die die LIN-Slaves ggf. benötigen, sowas wie "Zündung an", "Motor läuft", etc. könnten auch wie Sensoren in einem sehr kurzen Takt ausgegeben werden.

    Die Abfragefrequenz richtet sich dabei nach der zu erwartenden Wertänderung eines Sensors. Der Regensensor z.B. wird sicher recht oft abgefragt, da er blitzschnell auf auf die Scheibe auftreffendes Wasser reagieren muss. Wohingegen der Batteriesensor eher nicht so oft gefragt wird, weil sich die Parameter dort relativ langsam ändern (Strom, Spannung, Ladung, Temperatur, ...).

    Man kann also bereits anhand der Frequenz einer ID einschätzen ob es sich dabei um einen Sensor oder Aktor handelt. Hier mal über ein paar Logs die Zuordnung von LIN ID zu dem Zeitlichen Abstand zwischen zwei auftreten in den Logs:

    GruppeLIN-IDFrequenzBemerkung
    10x06~43 Hz
    20x05~21 Hz
    30x20~11 Hz
    40x0E4 Hz
    50x17, 0x19, 0x21, 0x26, 0x27, 0x2A, 0x2B~3 Hz
    60x08, 0x0D, 0x0F, 0x10~1 Hz

    Auch der Zeitpunkt des Auftretens einer ID lässt Rückschlüsse zu. Nehmen wir den Wischermotor. Der bekommt sicher nur dann einen Befehl wenn er sich in Bewegung setzen soll. D.H. wenn ich eine Aufzeichnung mache in der ich z.B. 3x bewusst den Wischer manuell aktiviere und dabei versuche ein gewisses Timing einzuhalten, dann müsste sich das widerspiegeln. z.B.: 3 Sekunden warten, einmal betätigen, wieder 3 Sekunden warten, wieder einmal betätigen, wieder warten, 3x hintereinander betätigen.

    Bei anderen IDs sind es eher die Daten im Payload die eine Änderung anzeigen, d.h. die ID selbst liegt periodisch an, aber ihre Werteänderung nicht. Beispielsweise der Regensensor. Der wird vermutlich eine "Regenmenge" als Wertebereich (von leichtem Niesel bis Wasserfall reichen) und einen Boolean für Regen/Kein Regen haben. Soweit mir bekannt wird über den Regensensor auch die Lichtautomatik gesteuert, d.H. es wird evtl. noch einen Lichtmengenwert geben. Den Regenwert könnte man mit einer Sprühflasche ändern, den Lichtwert mit einer Taschenlampe.

    Was man bei LIN wohl auch gern findet sind sog. "Rolling Counter" um verlorene Pakete zu erkennen. Dabei wird ein Byte bei jedem Frame um +1 erhöht und läuft bei erreichen von 255 -> 0 über und beginnt von vorn.


    Batteriesensor-ID ermitteln

    Der erste, einfachste Test war ein LIN-ID Vergleich mit und ohne angeschlossenen Batteriesensor (den kann ich ja einfach abziehen) durchzuführen. Das zeigte das die LIN ID 0x0D definitiv zum Batteriesensor gehört:

  • Reverse Engineering des Batterie-Sensors

    Mein Sniff war jetzt recht kurz (5 Sekunden) daher fehlen sicher IDs, aber hier schonmal was ich bislang finden konnte:

    IDPIDLENDATAFreq./PeriodMultiframesSENDERMEANING
    0x044FF 89 3A B5
    FF 90 3C BC    		 4BATSENS
    0x05240 02 2
    0x06200 00 2
    0x08-- -Unanswered
    0x0D498 1F C2 1E
    0E 1E BF 1E
    58 1F C0 1E
    00 20 C9 52    		 4BATSENSVermutlich Stromfluss
    0x0E400 B2 0F FF
    00 B2 19 FF    		 4BATSENSVermutlich Spannung
    0x0F49D 7C AE 18
    CD 8D B5 FF    		 4BATSENS
    0x10200 2A
    00 4A
    00 0A    		 2
    0x174B9 C7 E8 C3
    00 C0 00 C0    		 4BATSENS
    0x19-- -Unanswered
    0x20 84 80 00 00
    84 80 01 00
    94 80 01 00
    94 82 03 00
    94 82 02 00    		 4
    0x21-- -Unanswered
    0x22250 00 2BATSENS
    0x26 87 C3 6C C2
    00 C0 00 C0
    01 C0 00 C0    		 4BATSENS
    0x27 FF FF FF FF
    00 F0 FF FF
    01 F0 FF FF    		 4BATSENS
    0x2A-FF FF FF FF FF FF 8BATSENSUnanswered
    0x2B .... 8BATSENSBattery-Sensor, Ford-Part-Number (e.g. "AG9N-10C679-DE")
    0x358... 8RAINSENSRain-Sensor, Ford-Part-Number (e.g. "BV6T-17D547-AD")
    0x3C800 00 00 00 00 00 00 00-1ALL SLAVES"GO-TO-SLEEP" - Wird vom Master gesendet um alle Slaves in den Schlafmodus zu versetzen. Laut Standart ist das erste Byte 0x00 und die restlichen 0xFF, es kommt aber nur auf das erste Byte an.
    Wird vom BCM wenige Sekunden nach Zündung aus gesendet.

    SENDER gibt an, wer die Daten übermittelt, der Master oder der Slave.

    Ich weiß ja welche Module auf diesem LIN-Bus sein können:

    BCMLIN2 (=LIN8)IMSINTERIOR MOTION SENSOR - Innenraum-Bewegungsmelder der Alarmanlage
    BCMLIN8 (=LIN8)WMMSMART WIPER MOTOR MODULE MASTER - Scheibenwischermotor
    BCMLIN8 (=LIN2)RSMRAIN SENSOR MODULE - Regensensor
    BCMLIN8 (=LIN2)BBSSIREN CONTROL MODULE - Sirene der Alarmanlage
    BCMLIN2 (=LIN8)BMSBATTERY MONITOR SENSOR - Batteriesensor

    Wobei in meinem Fahrzeug keine Alarmanlage verbaut ist. Könnte aber gut sein das das BCM trotzdem danach "sucht" und die nicht beantworteten IDs die von den fehlenden Modulen sind. Die, die Antwort geben müssen also BMS, RSM und WMM sein.

    Einige IDs scheinen ihre Werte ohne außen erkennbare Aktion zu ändern, das können typische Sensorwerte sein, von Batterie und Regensensor. Die statischen könnten zum WMM gehören, das werde ich vielleicht erkennen wenn ich den Wischermotor mal gezielt auf unterschiedlichen Stufen laufen lasse.

    Ab hier muss ich dann meinen noch recht simplen Sniffer-Code mit einem Analyse-Tool paaren, ggf. kann ich einen Datenstrom für SavvyCAN erzeugen um dann einzelne IDs zu monitoren.

    Multiframe PIDs besitzen eine interne Statemachine. Die Requests müssen innerhalb von ~400ms geschehen, damit es keinen Timeout gibt und wieder mit dem First-Frame begonnen wird.

  • Reverse Engineering des Batterie-Sensors

    Die ID 0x2B scheint recht sicher dem Batteriesensor zuordenbar zu sein ("AG9N-10C679-DE"):

    Code
    I (6767) LIN_SNIFFER: Valid frame (Classic) - ID: 0x2B, Data len: 8
I (6773) LIN_SNIFFER: 02 41 47 39 4E 00 00 00                         | .AG9N...
...
I (7251) LIN_SNIFFER: Valid frame (Classic) - ID: 0x2B, Data len: 8
I (7257) LIN_SNIFFER: 03 31 30 43 36 37 39 00                         | .10C679.
...
I (7689) LIN_SNIFFER: Valid frame (Classic) - ID: 0x2B, Data len: 8
I (7695) LIN_SNIFFER: 04 44 45 00 00 00 00 00                         | .DE.....

    Wobei die ID 0x35 ganz sicher dem Regensensor gehört ("BV6T-17D547-AD"):

    Code
    I (6914) LIN_SNIFFER: Valid frame (Classic) - ID: 0x35, Data len: 8
I (6920) LIN_SNIFFER: 02 42 56 36 54 00 00 00                         | .BV6T...
...
I (7357) LIN_SNIFFER: Valid frame (Classic) - ID: 0x35, Data len: 8
I (7363) LIN_SNIFFER: 03 31 37 44 35 34 37 00                         | .17D547.
...
I (7796) LIN_SNIFFER: Valid frame (Classic) - ID: 0x35, Data len: 8
I (7802) LIN_SNIFFER: 04 41 44 00 00 00 00 00                         | .AD.....

    Die erste Ziffer gibt also den Index an, so wie bei CAN TP (Segmentierte Nachricht, eben eine die nicht in eine Payload passt, also größer als 8 Byte ist) mit "FF - First Frame" und "CF - Consecutive Frames". Wo aber ist wohl das First-Frame welches den Index 0x01 hat?

  • Reverse Engineering des Batterie-Sensors

    Sodale, mein LIN Sniffer Code nimmt langsam Form an. Nachdem ich ein paar Bugs finden und beheben konnte scheine ich nun beliebige LIN Frames, beantwortete und unbeantwortete, sniffen zu können. Das bishere Ergebnis (mit noch ein paar Debug-Logs) sieht so aus:

  • Reverse Engineering des Batterie-Sensors

    Da ich aktuell noch nicht weis wie und wo sich die Daten des Batteriesensors im CAN tummeln, wäre das noch zu früh. Ich muss erstmal den Sensor auf dem LIN eindeutig identifizieren und seine Kommunikationen mitlesen. Dann kenne ich seine Daten und kann danach auf dem CAN suchen um der Sache näher zu kommen.

  • Reverse Engineering des Batterie-Sensors

    Nachdem das nun mal geklärt ist muss ich natürlich etwas anders an die Interpretation der Daten auf dem Bus herangehen. Es ist definitiv so, das erst nach einschalten der Zündung Daten auf dem LIN2/LIN8 laufen, vorher ist da Totenstille. Nach ausschalten der Zündung laufen noch eine kurze Zeitlang Daten, bis der "Battery-Safer" zuschlägt, wie üblich.

    Da ich keine LDF-Dateien habe (und Ford die sicher auch nicht rausrückt) muss man die einzelnen IDs selbst identifizieren. Bei LIN ist es so das nur der Master eine Kommunikation initiiert, die ganzen o.g. LIN-Slaves verhalten sich passiv und antworten nur wenn sie gefragt werden. Ein Slave kann durchaus mehrere IDs besitzen, aber eine ID kann nur einem Slave zugeordnet sein. Hat ein Slave mehrere IDs, dann dient das unterschiedlichen Funktionen, z.B. grundlegend der Schreibrichtung vom Master zum Slave oder umgekehrt und verschiedenen Nachrichtentypen/Längen. All das würde in einer LDF (LIN Definition File) stehen.

    Die ID entscheidet also WER angesprochen ist und WIE. Am Bytestream selbst kann man ohne LDF nicht wissen ob die Bytes nun vom Master zum Slave oder vom Slave zum Master übertragen wurden, man kann also Programmierung und auslesen nicht differenzieren. Elektrisch könnte man das durch einlegen eines Widerstandes zwischen LIN-Master-Ausgang und LIN-Bus-Anschluß realisieren. Dann gäbe es einen Pegelunterschied beim rezessiven Bit zwischen Master und Slaves und man wüsste wer die 0en sendet. So macht man das üblicherweise beim Rev-Eng von Eindraht-Bussen. Aber ich glaube ich komme auch ohne diesen Eingriff in die Bordelektrik aus durch bloße Analyse der Daten und wie sich diese verändern.

    Problem dabei könnte sein das LIN nicht wie CAN ständig Botschaften sendet, sondern nur dann wenn der LIN-Master (hier ist es unser BCM) etwas wissen oder programmieren will. Es kann also sein das bestimmte Botschaften nur sehr selten oder nur bei bestimmten Aktionen (z.B. Batteriesensor zurücksetzen) auf dem Bus liegen. Das macht das Rev-Eng etwas aufwändiger und zeitintensiver...

    Ein Kern-Problem bei der Entwicklung des Sniffers ist, die Länge der Nutzdatenbyte aus einer Nachricht zu identifizieren, bzw. Nachrichten auf die kein Slave antwortet. Da tüftele ich gerade noch, denn es gibt im LIN Protokoll kein Längenbyte wie beim CAN. Ich teste gerade mit unterschiedlichen, teils heuristischen Algorithmen, welche stabil laufen und welche nicht. Das klingt total trivial, ist es in der Praxis aber leider nicht.

  • Reverse Engineering des Batterie-Sensors

    Evtl. nur bei den Euro5 Diesel wurde ja schon spekuliert, aber egal. Also muss der Sensor auch eine Funktion ohne Start/Stopp haben, auch für normale (also nicht EPB) Batterien und evtl. haben beide Systeme auch nichts miteinander zu tun.

    Ich habe inzwischen mein LIN-Sniffer Projekt etwas vorangetrieben, nicht trivial, davon werde ich mal später berichten wenn alles läuft, aber bereits eine Erkenntnis gewonnen: Beim rumspielen mit dem LIN-Bus hatte ich mal eine Situation das beim Anschließen meines Sniffers an Betriebsspannung der Scheibenwischer immer einmal auslöste! Bis dato dachte ich der Batteriesensor wäre einzeln an einem eigenen LIN-Bus. Als mein Projekt soweit war das ich den LIN als Bytestrom sniffen konnte habe ich den Klassiker beim Rev-Eng gemacht, mir diesen nicht nur als HEX sondern auch als ASCII ausgeben zu lassen. Und was finde ich da?

    Code
    02 42 56 36 54 00 00 00  → ASCII: "BV6T"
03 31 37 44 35 34 37 00  → ASCII: "17D547"
04 41 44 00 00 00 00 00  → ASCII: "AD"
=> "BV6T-17D547-AD"

    Das ist Teilenummer des Regensensors (BV6T, weil ich den beim Frontscheibenwechsel mal ausgetauscht hatte). Das hat meine Neugierde geweckt und ich habe mir die Schaltpläne nochmal ganz genau angesehen und musste feststellen das es faktisch nur drei getrennte LIN-Busse im BCM gibt, LIN0, LIN1 und LIN2:

    Der hier im Plan angegebene "LIN8" des Batteriesensors, welcher seltsamerweise im Schaltplan nirgendwo an die "internal HW" führt:

    scheint in Wirklichkeit also auch einfach nur ein "LIN2" zu sein. Auch daran angeschlossen ist der Scheibenwischermotor:

    Schaut man bei den anderen LIN2 Membern wird dort auch lustig LIN2 und LIN8 durcheinander gewürfelt:

    Also wieder mal ein kleines Geheimnis aufgedeckt das in keiner Dokumentation steht :)

    LIN-Busse des Mondeo MK4

    1. LIN0
    2. LIN1
    3. LIN2 (aka "LIN8")

    Ich habe das im Wiki https://mk4-wiki.denkdose.de/artikel/lin-bus/start entsprechend ergänzt.

    Hier noch der LIN vom PCM zum Generator, der mit dem BCM freilich nichts zu tun hat:

  • Reverse Engineering des Batterie-Sensors

    Ich habe jetzt dem Signal erstmal zur Bestimmung der Baudrate mittels einem Logic-Analyzer auf den Zahn gefühlt. Hier habe ich nach dem LIN-Transceiver (ich habe einen TJA1020 verwendet, den "Klassiker"):

    Mit 2M/s aufgezeichnet ergibt sich eine Bit-Zeit von 104,5 µs, was nach der Formel Baudrate = 1 / Bit-Zeit in s eine Baudrate von 9.600 ergibt. Das ist schon etwas ungewöhnlich, da LIN standardmäßig 19.200 Baud benutzt, gut das ich nachgemessen habe! LIN nutzt 8N1, also 8 Daten-Bits (das LSB zuerst), kein Parity-Bit und 1 Stopp-Bit. Nie mit angegeben aber immer enthalten ist auch ein Start-Bit. Ein LIN-Frame, die kleinste Informationseinheit also, besteht aus insgesamt 10 Bits.

    So habe ich den Protocol-Interpreter vom Logic-Analyzer eingestellt und sehe damit dann auch diese Frame-Daten in Form von Bytes.

    Wie schon erwähnt gibt es auf einem LIN-Bus einen Master und mehrere (bis zu 63) Slaves. Auf unserem Batteriesensor-Bus zum glück nur diesen einen Slave. Die senden nur wenn sie vom Master dazu aufgefordert werden. Die Kommunikation läuft immer so ab das der Master einen Request (Header) auf den Bus legt. Dieser besteht aus einem BREAK, einem SYNC und einem PID.

    Das BREAK ist (mind.) 13 Bits lang und besteht als 0-Bits (Leitung wird auf LOW gezogen). Im gemessenen Signal ist es 1,352 ms lang (13 * 104 µs):

    Das BREAK gibt den Slaves auf dem Bus Zeit aufzuwachen, falls diese sich im Tiefschlaf befinden. Dann folgt das SYNC, welches aus einer Folge von 0 und 1 im Wechsel besteht (daraus resultiert der Hex Bytewert 0x55). Dies verwenden die Slaves um sich auf die Baudrate und Phase des Masters einstellen zu können.

    Als letztes überträgt der Master das PID, quasi die Adresse des Slaves der angesprochen wird. Die eigentliche ID ist dabei 6 Bit lang, wodurch sich eine maximale Anzahl von 63 Nodes ergibt. Weil die ID wichtig ist wird sie mit zwei Paritäts-Bits gesichert (die höchstwertigen Bits). Der Wert des Partitäts-Bits P0 ergibt sich aus einem XOR von ID0 ^ ID1, sowie einem ID2 ^ ID4 und einem XOR beider Ergebnisse. Das Parity Bit P1 verwendet ID1, ID3, ID4 und ID5 zur Berechnung. Im obigen Datagramm ist 0x20 die LIN-Bus Adresse. Bei dieser Adresse sind beide Paritäts-Bits "0" wodurch sich keine Werteänderung ergibt. Die Adresse ist auch gleichzeitig sowas wie ein Befehl. Ein LIN-Slave kann auf mehreren Adressen reagieren um damit unterschiedliche Daten zu senden.

    Im Anschluß an dieses Anforderungs-Signal vom Master sendet der sich angesprochene Slave dann seine Daten. Das ist aus dem obigen Beispiel:

    0x84 0x80 0x00 0x00

    Wieviele Bytes das sind, bestimmt allein der Slave, es dürfen aber maximal 8 sein. Dem folgt dann ein CHECKSUM Byte (ob im Beispiel 0xFA).

    So sieht dann eine solche Datensalve aus:

    Als nächstes versuche ich dann mittels meines Selbstbau LIN-Sniffers, bestehend aus dem TJA1020 und einem ESP32 die reinen Nutzdaten zu extrahieren und daraus schlau zu werden.

  • 327Elmconfig

    Also du kannst ELMConfig starten und mit der Auswahl des COM und "Mondeo MK IV" verbinden, ja? Dann stimmen Treiber und Einstellungen erstmal.

    Dann gehst Du auf "BCM" und dort unter "Procedures" wählst Du "Read CCC from BCM", genau so wie hier beschrieben https://mk4-wiki.denkdose.de/artikel/elmcon…_oder_ipc_laden

    Und dann kommt dieser Fehler? Die geforderte Datei ist in der Tat der Standard SBL (Secondary Bootloader). Das ist ein kleines Stück Software welches über CAN in das RAM des BCM geladen und ausgeführt wird um die Kontrolle zu übernehmen. Diese Datei müsste eigentlich im Unterordner "data" von ELMConfig vorhanden sein. Schau mal unter C:\Programme\ELMConfig\data

    Evtl. hast Du nicht richtig installiert und der Ordner fehlt oder ist leer?

  • Reverse Engineering des Batterie-Sensors

    Nachdem ich nun auch einen Batteriesensor im Fahrzeug habe, gebe ich mich mal ans Decoding der Nachrichten die dieser mit dem BCM so austauscht. Mein erster Test war einfach mal ein Oszi dran hängen (kleiner Tipp: mit einem "Ossi" klappt es leider nicht!) und siehe da: nach dem einschalten der Zündung habe ich dort heftigen Grenzverkehr ;)

    Dann werde ich mir jetzt mal einen kleinen LIN-Bus Sniffer zusammenbauen und mal schauen was ich dort so finde. LIN ist ja im Grunde nichts anderes als ein Serieller-Port mit ein paar Spezialitäten (BREAK). Ich wollte mir immer mal einen LIN-Bus Adapter für PC kaufen, stattdessen habe ich mir immer was zusammengelötet... naja.