E6x CAN-BUS Analyse // DBC Datenbank

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • E6x CAN-BUS Analyse // DBC Datenbank

    Servus zusammen,

    nachdem ich bis heute noch keine DBC-Datenbankdatei für die CAN BUS Analyse vom E6x gefunden habe, hab ich angefangen, eine zu erstellen.

    WICHTIG:
    Die meißten der bisher enthaltenen Daten sind nicht auf meinen Mist gewachsen, sondern wurden von Trevor Cook in einem E84 analysiert und dokumentiert!
    Ich bin derzeit dran, die Daten mit meinem E61 abzugleichen, anzupassen und in der DBC-Datenbank zusammenzufassen:

    Stand 30.01.2020: klick


    Allzu groß ist das File leider noch nicht, soll (und wird *hoffentlich* ;) ) jedoch in den nächsten Tagen massiv erweitert werden.

    Zum Sniffen verwende ich teilweise SavvyCan in Verbindung mit meinem eigenen Datendisplay (GVRET-Protokoll per WiFi) - wobei ich hier noch Stabilitätsprobleme mit dem AP vom ESP32 habe (connection wird von einem Teilnehmer zurückgesetzt - warum auch immer...).

    Alternativ habe ich ein Korlan USB2CAN Interface von 8devices, das ich mit den Linux CAN-utils kombiniere. Zur besseren Lesbarkeit beim Sniffen gibt es dann noch die cantools, die sich mit der DBC-Datenbank ideal kombinieren lassen.

    Zur Erstellung der Datenbank nutze ich dann auch SavvyCan.
    Das kann übrigens auch wunderbar die Logfiles vom candump öffnen...

    Wäre cool, wenn sich ein paar Leute finden, die noch Daten für die DB beitragen möchten, oder auch gerne anhand der DB anfangen, sich in das CAN-Thema einzuarbeiten.


    lg

    Flo

    ps. Die einfachste Stelle, den KCAN anzuzapfen ist übrigens hinter dem Kombiinstrument ;)
    pps. Bitte ein Interface ohne Abschlusswiderstand verwenden, sonst wird des nix mit Daten lesen...

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von freakmaster ()

  • Hi,

    ich habe großes Interesse mich da rein zu arbeiten.
    Ich lese aktuell etwas auf Techtinker und habe da das sniffing tool her aber weiter noch nichts gemacht.
    Datenbanken habe ich die vom e84 auch gefunden und noch eine weitere.
    Aber nicht für den e6x.


    Gruß Marcel
  • Servus Marcel,

    na dann auf auf, ran an den Speck! :)
    So schwer ist es gar nicht, die ersten Daten zu bekommen und anhand der Datenbank bzw. Beschreibungen zu verstehen - zumindest, wenn man ein fertiges Interface benutzt.

    Für mich persönlich war es das schwerste, mein Datendisplay-Interface dazu zu bekommen, die Daten per WiFi zu übertragen und eine entsprechende (!fertige!) Clientsoftware zu finden, um sie auszuwerten.
    Bis ich endlich das GVRET Protokoll und eine Beispielimplementierung gefunden habe...

    Jetzt fehlt nur noch die Erfahrung beim Analysieren der Daten selbst.
    Hab gestern nur auf die schnelle die Gänge / Drivemodis gesucht und gefunden - das ging tatsächlich innerhalb von 5 Minuten.
    Fehlt noch die Logikanalyse, welche Daten das Kombiinstrument tatsächlich benutzt (sind zwei getrennte IDs mit teilweise identischen Daten) und der Vergleich zu einer originalen Getriebesoftware (hab meines auf Stage 3 stehen und damit die Ganganzeige im Kombi auf D/S).

    Sofern sich Zeit und ehrlich gesagt auch Lust findet, werde ich mal den Codeanteil des Sniffers für den Arduino (ESP32) extrahieren und auf GitHub stellen.
    Das Datendisplay liegt da auch schon, ist aber derzeit noch nicht sichtbar, da es nicht sauber lief. Ist auch für die nächste Zeit angedacht...
  • Also ich hätte auch Interesse, aber in anderer Form als zur Mithilfe :D
    Für mich sind das alles Hieroglyphen, wenn ich mir die Tabelle der Dokumentation anschau.

    Aber schade finde ich, wenn das Wissen und KnowHow vorhanden ist, aber dann keine schöne Umsetzung, wie z.B. auf dem Display im angefügten Bild.

    Es braucht niemand ein zusätzliches BMW-Emblem auf dem Monitor, wenn man sich schon in einem befindet. Das auf dem Lenkrad sollte genügen.
    Die Bedienelemente könnte man auch denen nachempfinden, die sich im Auto befinden, und die Schriftart auch gleich mit.
    Und eine Schriftart mit Serifen geht gar nicht :P

    Also wenn da mal was benötigt wird, da würde ich gerne mithelfen ;)
    Bilder
    • dash.jpg

      87,78 kB, 700×389, 18 mal angesehen
  • Paladin schrieb:


    Es braucht niemand ein zusätzliches BMW-Emblem auf dem Monitor, wenn man sich schon in einem befindet.
    Ach komm. Manchmal braucht man hald noch ne zusätzliche Erinnerung :D ;)
    Ich darf da nicht meckern, da ich was ähnliches in meinem Display drin habe... (Bilder gerade nicht möglich weil @Work...)
    Jedoch hat das eine Funktion.

    Hier mal noch der aktuelle Stand der Datenbank (massiv erweitert): Stand 30.01.2020 11:31 Uhr
  • jepp und direkt z.b an der rs32 Schnittstelle z.b Tdx und Rdx Leitung ablesen. Oder an den Adern z.b von USB.
    Ich meine kann man nicht direkt die Signale am K Can ablesen oder Pt Can?
    So ein interface ist doch eigentlich schon so das es die Daten verständlich macht für die Pc Schnittstelle.

    Gruß Marcel
  • MarcelA schrieb:

    Ich meine kann man nicht direkt die Signale am K Can ablesen oder Pt Can?
    So ein interface ist doch eigentlich schon so das es die Daten verständlich macht für die Pc Schnittstelle.
    Nicht böse nehmen, aber ich glaube da müssen wir etwas weiter bei den basics anfangen - ist glaube ich für alle gut :)

    1. die beiden von mir verwendeten Interfaces lesen direkt die Daten vom K-Can aus.
    Wenn ich sie an den PT-CAN hängen würde, wäre das auch durchaus möglich - sind nur unterschiedliche Geschwindigkeiten unter Verwendung der gleichen Protokolle.

    2. Thema Protokolle:
    Die "Elektrische Kommunikation" passiert immer über ein definiertes "Protokoll".
    Das ist im Prinzip nichts anderes als eine Definition, welches Signal (HIGH vs. LOW // z.B. 12V vs. 0V) in welcher Zeit und welcher Abfolge welche Bedeutung hat.
    Auf Basis dieser Protokolle werden Daten ausgetauscht.
    Beim K-/PT-/F-/...CAN passiert das ganze mit einer Art Telegramm.
    Das Telegramm ist grundsätzlich aus folgenden Elementen aufgebaut (Extended-Frames und den Control-Overhead wie CRC etc. lassen wir mal außer acht!):

    - ID: dreistellige Identifikationsnummer des Telegrammes.
    - Länge: Information, wie lange das Datenpaket ist. (0-8 Bit)
    - Datenpaket: Hier sind 0 bis 8 "Paketfelder" zulässig, wobei ich eine Information in einem oder mehreren Feldern verpacken darf.

    Steuergeräte senden grundsätzlich einfach immer ihre "Standard"-Daten auf den BUS, welche von den Entwicklern als "dauerhaft wichtig" empfunden wurden.
    Bei kritischen Daten (z.B. Drehzahl, "Gaspedalstellung", Crashsensordaten etc.) passiert das in definierten Zeitintervallen (z.B. 200ms, 2s etc.)
    Bei weniger kritischen Daten aufgrund eines Ereignisses (z.B. Knopf für die Innenbeleuchtung wurde gedrückt).

    Andere Daten wie z.B. der Ladedruck werden nicht automatisch auf den BUS gelegt, weil sie von anderen Steuergeräten normalerweise nicht benötigt werden!
    Den Ladedruck braucht im e6x z.B. nur das Motorsteuergerät, welches den Sensor selbst auswertet - also warum dann wertvolle und begrenzte Bandbreite auf dem Bus belegen und die Daten senden, wenn eh keiner zuhört?

    Hier kommen wir dann zum Thema Diagnose/-schnittstelle.
    Gewisse Daten können per Diagnosesoftware bei den Steuergeräten "angefragt" werden, welche dann als Antwort die gewünschten Daten auf den BUS legen.
    Hierbei kommen dann im Normalfall mehrere, unterschiedliche Protokolle zum Einsatz.

    Gehen wir z.B. von einem Interface einer freien Werkstatt (!! NICHT BMW !!) aus, das per WLAN mit dem PC Verbunden ist.

    1. PC <=> Interface // Protokoll, das genutzt wird, um Daten auszutauschen: TCP

    Das Interface übersetzt jetzt die per TCP erhaltenen Daten und es geht weiter:
    2. Interface <=> OBD Diagnoseschnittstelle // Protokoll: unterschiedlich.

    Warum "unterschiedlich"?
    Weil jeder Hersteller sein eigenes Süppchen bezüglich der Diagnoseschnittstellen kocht und zudem noch vom Gesetzgeber gezwungen wurde, gewisse Standards zu unterstützen.
    Heißt also, dass das Interface und das Steuergerät, an dem die Diagnoseschnittstelle angeschlossen ist, sich unterhalten und dann auf ein Protokoll einigen.

    3. "OBD-Steuergerät" <=> "Ziel-Steuergerät" // Protokoll: CAN

    Hinten raus läuft die Kommunikation also dann effektiv wieder über den CAN.
    Natürlich könnte man jetzt auf der Netzwerkschnittstelle am PC mitsniffen und die Daten auswerten, wobei hier jedoch wieder properitäre Protokolle auf Basis von TCP verwendet werden, welche man erst analysieren müsste aber warum?
    Wir sniffen ja bereits auf dem CAN mit, welcher ja doch relativ einfach gestrickt ist...

    Um beim Beispiel von oben zu bleiben:
    Wenn wir also den Ladedruck haben wollen, müssen wir "nur" auf dem CAN mitsniffen, über die Diagnosetools den Ladedruck anfordern und schauen, welche Telegramme auf dem BUS hin und her gesendet werden.
    Das ist der Teil, den ich selbst leider noch nicht durchgeführt habe. Der steht jedoch auf meinem Plan, sobald mal etwas Zeit da ist...

    Ich hoffe, die Erklärung ist halbwegs verständlich und löst so manchen Denkknoten :)

    ps. Wenn Profis mitlesen: Bessere sowie ausführlichere Erklärungen als meine sind erwünscht - ich lern gern dazu! :top:
    pps. Die OSI-Schichten hab ich auch mal gemütlich ignoriert ;D
  • freakmaster schrieb:

    MarcelA schrieb:

    Ich meine kann man nicht direkt die Signale am K Can ablesen oder Pt Can?
    So ein interface ist doch eigentlich schon so das es die Daten verständlich macht für die Pc Schnittstelle.
    Nicht böse nehmen, aber ich glaube da müssen wir etwas weiter bei den basics anfangen - ist glaube ich für alle gut :)
    Nein da gibt's nix böse zu nehmen. Das ist super.
    Ich habe noch keine Ahnung von dem ganzen und habe mich bis jetzt mehr dem mechanischen gewidmet
    Ich möchte aber gerne das ganze verstehen und mehr darüber wissen.
    Da ist das erstklassig solche Infos zu bekommen.

    Also passt das doch ziemlich.
    Wenn ich jetzt ein Bmw spezielles Interface habe ist da doch bestimmt der selbe can Reciver wie im datendisplay von Saft6luck drin und wandelt die Daten vom Can H und L aus übergibt sie der Tdx Rdx.

    Entschuldige wenns totaler Quatsch ist ist nur Ne Frage die mir im Kopf rum Schwirt.

    Die Werte in den Tabellen habe ich gesehen und mit den stellen ist mir verständlich. ich war vor 15 jahren mal auf einem Lehrgang für Mercedes und Canbus. So ist das bei Benz auch in etwa. Es kommt bei Mercedes noch Dringlichkeit dazu was an welcher Stelle ist müsste ich auch erst raus kruschteln.

    Das nicht alles auf dem Bus liegt macht Sinn wenn man das so liest.
    Danke für die klasse Informationen.
    Wie gesagt arbeite mich da erst rein.


    Liebe Grüße Marcel
  • MarcelA schrieb:

    Wenn ich jetzt ein Bmw spezielles Interface habe ist da doch bestimmt der selbe can Reciver wie im datendisplay von Saft6luck drin und wandelt die Daten vom Can H und L aus übergibt sie der Tdx Rdx.
    Jein ;D

    Hier kommen wir schön langsam zum OSI-Modell...

    Transceiver-ICs gibt es natürlich von verschiedenen Herstellern mit unterschiedlichen Spezifikationen. Manche können z.B. die höheren BUS-Geschwindigkeiten nicht, andere brauchen dafür aber mehr Coding (Software) etc.
    Alle unterstützen sie jedoch die gleiche "elektrische" Spezifikation (Layer 1). Sonst würden sie einfach geschmeidig in Rauch aufgehen ;D

    Das "übergeben" an Tx / Rx stellst du dir aktuell noch etwas zu leicht vor.
    Die Große Frage ist z.B.: Wer genau übergibt die Daten woher an wen?
    Tx/Rx sind nur Bezeichnungen für Sende-/Empfangsleitungen ohne jegliche Spezifikation, welches Protokoll genutzt wird.
    USB hat z.B. diese Leitungen, RS232 jedoch auch! Ein CAN-Transceiver hat die beiden aber ebenfalls...
    Alle drei Protokolle haben aber ganz unterschiedliche Spezifikationen, "was wie wann" über welche der beiden Leitungen zu senden ist.

    CAN-Transceiver <=> Microcontroller (z.B. Arduino) nutzt "TxD"/"RxD", um miteinander zu kommunizieren. z.B. PDF Seite 5
    Nur ist das kein RS232 Protokoll ;)

    Wenn ich die Daten dann erst einmal im Microcontroller habe, kann ich sie dann entsprechend weiter Verarbeiten (z.B. Anzeige der Daten auf einem Display) oder weiterschicken (Speichern auf einer SD-Karte, per RS232 Protokoll an den PC oder ein serielles Display, per Wlan an eine PC uvm.)

    Mit dem Treiber, den ich auf meinem Arduino benutze, bekomme ich effektiv die drei notwendigen Daten zur Weiterverarbeitung.
    Hier mal ein Beispiel, wie die Daten eines CAN-"Telegramms" ausschauen:

    ID: 0AA
    Länge: 8
    Daten: C6 DA F3 00 00 00 84 C8

    In diesem Datenpaket verstecken sich nach meinem aktuellen Wissensstand drei Informationen.
    1. Drehzahl
    2. Drehmoment
    3. Gaspedalstellung

    Die Drehzahl lässt sich dann z.B. mit folgender Methode auslesen:

    Quellcode

    1. int FrameHandlerClass::getEngineRPM(byte* buff)
    2. {
    3. return (((buff[5] << 8) + buff[4]) / 4);
    4. }
    Soweit mal zu der Ausführung - mehr gibts später...
  • freakmaster schrieb:

    Transceiver-ICs gibt es natürlich von verschiedenen Herstellern mit unterschiedlichen Spezifikationen. Manche können z.B. die höheren BUS-Geschwindigkeiten nicht, andere brauchen dafür aber mehr Coding (Software) etc.
    Alle unterstützen sie jedoch die gleiche "elektrische" Spezifikation (Layer 1). Sonst würden sie einfach geschmeidig in Rauch aufgehen ;D

    Bei CAN gibt es erstmal grundsätzlich drei Standards:
    • CAN HighSpeed (wird vor allem im Powertrain verwendet)
    • CAN LowSpeed (Innenraum CAN, bei den E6x Fahrzeugen ist es dann K_CAN)
    • CAN FD (Flexible Datarate, baut auf CAN HS auf, aber der Datenblock wird schneller übertragen als Header)
    Wichtig ist noch, dass HighSpeed (bis 1MBit) und LowSpeed (bis 125kBit) nicht nur was über die Übertragungsrate aussagen, sondern auch über die Physik. Beide (und auch FD) sind differenzielle Signale, aber die Pegel sind unterschiedlich UND LowSpeed ist fehlertolerant, das heißt, wenn eine der CAN-Leitungen bricht oder Kurzschluss hat, läuft der Bus weiter im sog. "single wire mode".

    freakmaster schrieb:

    Die Große Frage ist z.B.: Wer genau übergibt die Daten woher an wen?
    Das ist völlig irrelevant. Warum? Ganz einfach, es gibt keinen "Empfänger" in dem Sinne. CAN ist ein ereignisgesteuertes Bussystem. Sprich, es tritt ein Ereignis auf, Schlüssel wird eingesteckt, CAS verschickt daraufhin eine Botschaft mit der ID 0x130 (ignition status, alle 100ms). Jedes Steuergerät, welches diese Botschaft interessiert, nimmt sie an, sonst wird sie verworfen. Empfangen wird die Botschaft aber von ALLEN Steuergeräten im Netzwerk, dabei muss irgendein Steuergerät, bzw. dessen CAN-Controller, die Flags in der Botschaft setzen.

    Die Kette im Steuergerät sieht so aus: Transceiver --> CAN-Controller -> CPU. Der CAN-Controller übernimmt die lowlevel Aufgaben, zum Beispiel überprüfen der CAN-Botschaft auf Korrektheit, Flags in der CAN-Botschaft setzen, einen anderen CAN-Knoten in BusOff schicken, wenn er den Bus zumüllt und und und. Wichtig ist dabei, die CPU kriegt davon nichts mit, denn das interessiert sie auch nicht. Desweiteren beinhaltet der CAN-Controller auch den sog. Akzeptanzfilter. Der ist dazu da, damit die CPU nur die Botschaften bekommt, die sie auch interessieren. So frai nach dem Motto, was mich nicht interessiert, muss ich nicht verarbeiten. Im CAN-Controller wird auch die Geschwindkeit eingestellt und der Sample-Punkt.

    freakmaster schrieb:

    CAN-Transceiver <=> Microcontroller (z.B. Arduino) nutzt "TxD"/"RxD", um miteinander zu kommunizieren. z.B. PDF Seite 5
    Wie gesagt, zwischen CAN-Transceiver und den Mikrocontroller gehört ein CAN-Controller, wie ein MCP2515 (mit SPI) von Microchip oder der gute alte SJA1000 (8-bit parallel) von NXP.

    Es geht zwar auch ohne, aber das ist Kategorie Murks und sollte NUR zum Lesen verwendet werden, wenn überhaupt.

    freakmaster schrieb:

    Mit dem Treiber, den ich auf meinem Arduino benutze, bekomme ich effektiv die drei notwendigen Daten zur Weiterverarbeitung.
    Hier mal ein Beispiel, wie die Daten eines CAN-"Telegramms" ausschauen:

    ID: 0AA
    Länge: 8
    Daten: C6 DA F3 00 00 00 84 C8
    Stimmt so nicht ganz. Du bekommst erstmal eine Abfolge von Bytes, wo Du weißt, dass die ersten drei Bytes die CAN-ID ist, dann ein Byte lange DLC und dann ein 8 Byte langes Datenfeld, weil DLC in diesem Fall 8 ist.

    Die Daten im Datenfeld können nach Intel oder Motorola Standard kodiert werden (sprich LSB oder MSB) und sind fast immer über Faktor und Offset kodiert. Zum Beispiel eine CAN-Botschaft 2CA 2 40 FF bedeutet Aussentemperatur und zwar genau -8°C. Die Formel wäre (byte[1] - 80)/2, also 0x40 = 64 und dann (64-80)/2 = -8.
  • Servus Hemi,

    danke dir für die Ausführungen!!
    War mir fast alles bekannt aber du hast es definitiv besser auf den Punkt gebracht, als ich X/ :trinken:

    Mit "Die Große Frage ist z.B.: Wer genau übergibt die Daten woher an wen?" war in diesem speziellen Falle die Frage vom Marcel bezüglich RX/TX gemeint.
    Dass beim CAN mit "Fire&forgett" gearbeitet wird, hatte ich ja schon beschrieben.

    Bei der Kette habe ich den Controller außer acht gelassen, da der von mir verwendete ESP32 bereits einen CAN-Controller eingebaut hat. My fault :/

    Mir ist in der Arbeit leider die Zeit ausgegangen, daher konnte ich die vorbereiteten Beispiele nicht mehr abschicken und muss sie neu schreiben -.-
    Ich bleibe mal beim Beispiel mit der ID 0x0AA und überspringe die Zerlegung der Daten vom CAN-Controller in die drei aufgeführten Bestandteile, da das wie gesagt der Treiber von Thomas Barth für mich erledigt...


    Hier ein paar Pakete aus einem Trace im Format vom candump aus den CAN-Tools, die ich mitgeschnitten habe, um die 0x0AA zu bestätigen.
    Wer die Daten unten mit dem Beispiel vom Hemi vergleicht, wird feststellen, dass in dem Trace keine Angabe zur Länge des Datenblocks enthalten sind.
    Das ist im Falle des Traces auch irrelevant, da die Datei Zeilenweise eingelesen wird und damit das Ende der Zeile (LF / LineFeed) das Ende des Datenblocks markiert.

    Timestamp Interface <CanID>#<Daten>
    (1580407425.319989) can0 0AA#F493FF00A80A8083
    (1580407425.419913) can0 0AA#EABD099EB80A9483
    (1580407425.519990) can0 0AA#39B828FE640FB486 <= das schauen wir uns mal an

    (1580407425.619937) can0 0AA#BBC32CFECC14B48C

    39 B8 28 FE 64 0F B4 86
    unbekannt

    Drehzahl
    Drehmoment
    Gaspedal


    Bei der Gaspedalstellung ist es aus meiner Sicht relativ einfach, da kein Offset und kein Faktor notwendig (ACHTUNG: Wer mit den Infos vom Trevor Cook vergleicht, wird einen Unterschied merken. => Wer findets? ;) ).

    Hex 00 = Dez 0 = Standgas

    HEX 9E = Dez 158 = ~62% Gas

    Hex FE = Dez 254 = Vollgas


    Die Drehzahl konnte hier aus meiner Sicht ebenfalls bestätigt werden.
    Grundsätzlich können wir davon ausgehen, dass sich die Information der Drehzahl in zwei Byte verstecken muss.
    Warum?
    Ein Byte = acht Bit = Werte von 0 bis 256
    zwei Byte = sechzehn Bit = Werte von 0 bis 65.535
    Unsere Drehzahl geht beim Diesel bis ~4500 (gerade Zahl, um es einfacher zu machen), bedeutet also, dass wir die Zahl nicht ohne Offset und Faktor in ein Byte (max 256) rein quetschen können.

    Wie vom Hemi ausgeführt, gibt es zwei Arten, die Daten zu codieren. Alle Daten, die ich bisher bei meinem e61 bestätigen konnte, waren LSB codiert.
    Bedeutet also, dass wir die Werte der zwei Byte "64" und "0F" erst einmal "zusammenhängen" müssen - und zwar erst das im Array befindliche "höhere" Byte[5] und dann das "niedrigere" Byte[4] => "0F64"

    Umgerechnet in einen Dezimalwert wären das dann 3940 - würde erstmal plausibel klingen (bedenkt das Vollgas) AAAABER schauen wir uns eines der kurz darauf folgenden Datenpakete an (DA D3 30 FE 88 3F B4 B0), wäre - noch immer bei Vollgas - der Wert 3F88 umgerechnet: 16264

    16 k Umdrehungen? Bei einem Diesel? Niemals ;D
    Hier muss also mindestens ein Faktor ins Spiel kommen...
    Zum Glück sind Entwickler nicht immer Sadisten (Sorry Hemi ;) Ich gehe mal davon aus, dass du einer bist - und zwar einer, der die Ausnahmen der Regel bestätigt :saint: ) und rechnen nicht oft mit krummen Zahlen.
    Also tasten wir uns mal langsam ran:

    16264 / 2 = 8132 (immer noch zu hoch)
    16264 / 3 = 5421,33 (neeeeeee, passt nicht)
    16264 / 4 = 4066 => BINGO Das passt doch recht gut

    Gegencheck auf unser Paket bei Standgas: A8 0A => 0AA8 => 2728 / 4 => 682 => Passt.
    Wenden wir den Faktor also auf die 3940 aus unserem Beispielpaket an, kommt eine Drehzahl von 985 U/Min heraus.

    Schauen wir jetzt auf die Zeitstempel, so lässt sich relativ einfach die Zeit herausrechnen, wie lange es gedauert hat, um von Standgasdrehzahl auf Vollgasdrehzahl (bei stehendem Fahrzeug) zu kommen:
    (1580407426.620043) can0 0AA#E00D31FE543FB4B0

    Vom Zeitstempel schneiden wir mal den identischen Teil weg (158040742...). Dann bleibt übrig:
    Zeitstempel bei Standgas: 5.319989
    Zeitstempel bei knapp Vollgasdrehzahl: 6.620043

    6.620043 - 5.319989 = 1,300054 Sekunden
    Wie kommt jetzt so eine glatte Sekundenanzahl zustande? Denkt an den Zeitintervall, in dem die Pakete teilweise geschickt werden...
    In diesem Falle 100 ms = 0,1 Sekunden

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von freakmaster ()

  • Nicht alle Datenpakete beinhalten jedoch eine Dezimalzahl.
    Informationen können auch "bitweise" übertragen werden.

    Hier am Beispiel der Datenpakete mit der ID 2FC => Status der Türen:
    2FC#81 00 00 FF FF FF FF
    2FC#81 55 05 FF FF FF FF

    Schauen wir uns die beiden markierten Bytes an (denkt an die Umstellung aufgrund der LSB Codierung).

    HEX 0000 = DEZ 0 = BIT 00000000 00000000
    HEX 0555 = DEZ 1365 = BIT 00000101 01010101

    Fahrertüre = erstes Bit (von rechts nach links!)
    Beifahrertüre = drittes Bit
    Türe hinten links = fünftes Bit
    Türe hinten rechts = siebtes Bit
    Motorhaube (unbestätigt) = neuntes Bit
    Kofferraum = elftes Bit

    Wobei das Bit 0 bedeutet, dass die Türe geschlossen ist.
    Wurde sie geöffnet, geht das entsprechende Bit auf 1.
    Die beiden Beispiele zeigen also die "Extreme" - alle Türen auf und alle Türen zu.

    Wäre z.B. nur die Fahrertüre offen, wäre das Datenpaket folgendermaßen:
    2FC#81 01 00 FF FF FF FF

    Wäre zusätzlich noch der Kofferraum offen:
    2FC#81 01 02 FF FF FF FF
  • alias10 schrieb:

    Sehr interessantes Thema, aber ich verstehe den Sinn dahinter nicht. Was habt ihr vor mit den Daten?
    Z.B. das hier :)




    Datendisplay ähnlich dem vom saft6luck

    Die Technologie (=CAN) dahinter, um die Daten vom Fahrzeug zu bekommen ist die gleiche, jedoch nutze ich z.B. einen anderen Controller (ESP32).

    @Paladin: Wenn dir mal langweilig ist - Die Anzeigen im Sportmodus finde ich persönlich nicht so pralle, bin aber in der Bildbearbeitung bzw. Erstellung nicht bewandert genug, um selber welche zu basteln...
    Icons für Öltemperatur, Wassertemp und Gaspedal bräuchte ich auch noch ;D

    @Marcel: Welche Hardware zum Sniffen gebraucht wird schreibe ich gerne die Tage zusammen.
    Ich würde aber gerne vorher noch das Problem der Verbindungsabbrüche im WLAN-Modus beheben - das macht das Arbeiten doch recht unangenehm...

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von freakmaster ()

  • @freakmaster wenn Du jemanden "direkt" ansprechen möchtest, dann tippe das @ und fange dann direkt hinter dem @ langsam an die Buchstaben hintereinander zu tippen, dann erscheint eine Liste mit den Usernicks ;)
    Dann kannst Du den User direkt anwählen, dann wird er auch benachrichtigt :)

    Ich habe eben meinen Namen zufällig entdeckt :)

    Zu den Symbolen: Ok, welche Größe, welches Dichte, welches Format, welche Farbtiefe?
    Welches Format und welche Größe hat das Originaldisplay auf dem Foto?
    Ist es ein Touchdisplay, brauchst Du "Marker" außenrum?
    Sind die "Marker" kreisrund, oder eckig?