Beiträge von freakmaster

    Versucht er denn zu zünden oder tut sich gaaaaar nix?
    Wenn ers versucht sollte es sich anders anhören ("angestrengter") bzw. Rauch ausm Auspuff kommen.
    Wenn er sich "unangestrengt" anhört, wird kein Sprit eingespritzt => Kann die Synchronisation zwischen "Wegfahrsperre" (CAS) und Motorsteuergerät (DDE) sein.


    Auf alle Fälle jemanden mit den entsprechenden Tools den Fehlerspeicher auslesen lassen!
    Bitte keine generischen Programme verwenden, sondern originale! Da sieht man einfach mehr Daten...


    Überbrücken kannst du am
    Massepin => Fahrtrichtung links, am Dom. Schaut aus wie eine Sechskantschraube mit Kuhle oben und verlängertem Zylinder nach unten
    Plus-Anschluss => Fahrtrichtung links, rote Kappe mit großem + Zeichen

    Sorry für die späte Rückmeldung. War erst auf Geschäftsreise und dann mit Sabine beschäftigt...



    Frage 1: Wieviele Menüpunkte und Informationen kann/soll man später abrufen?
    Frage 2: Ist das Display "nur" druckempfänglich, oder kann man auf dem Display auch wischen wie auf einem Handy?

    Zu Frage 1:
    Schwer zu sagen...
    Kommt immer darauf an, was einen interessiert.
    Vorteil: Wenn mal die Grundlagen geschaffen sind, kann das theoretisch jedermann selbst mit dem Nextion Editor selbst erweitern (Der Controller ist da aufwändiger).
    Daher würde ich einen "weiter" bzw. "zurück" Button ("<" oder ">") vorsehen, um die entsprechenden Seiten durchschalten zu können.


    Zu Frage 2:
    Das Display ist leider nur Druckempfindlich (Resistiv). Wischen ginge nur vernünftig mit einem Kapazitiven Display.


    Steuerung über den Controller (ZBE) wäre theoretisch schon möglich aber um eine parallele Wirkung auf das Navi + Display zu verhindern, müsste man einen dual-CAN-Controller einsetzen und zwischen Fahrzeug und ZBE einschleifen. Zusätzlich stellt sich dann die Frage, wie man zwischen Display und Navi umschaltet...
    Alles in allem meiner Meinung nach nicht "smooth" machbar.

    Was genau meinst Du mit Befehlsset?

    Das Display ist bis zu einem gewissen Maß "intelligent".
    Man kann ihm mit einer gewissen Anzahl an definierten Befehlen sagen, was es machen soll: instruction-set


    Was z.B. geht ist: "Zeichne einen Strich vom Koordinate xy bis Koordinate xy in der Farbe z".
    Der Vorteil daran: Ich muss mich nicht um die Berechnung der Koordinaten zwischen den beiden Punkten kümmern und dem Display sagen, dass es da auch noch Farbige Punkte setzen soll
    => Spart Rechenleistung und ich kann mich weiterhin um den CAN kümmern.


    Was nicht geht ist der Befehl: "Zeichne einen 20 px breiten, geschwungenen Pfeil mit einem Farbverlauf von grün nach lila von links unten nach rechts oben".
    Hier müsste ich die einzelnen Pixel selbst berechnen, was zwar möglich aber einfach scheixxe ist ;)
    Lösung => Ein jpg mit dem Pfeil vorbereiten und das dann als Bild anzeigen lassen.


    Das müsste man z.B. auch mit den Buttons machen, wenn die die Farbe von weiß auf orange ändern sollen!

    @MarcelA

    Nochmal Fragen zu den Datenpaketen.
    0AA ist die Can ID , Dann sollte doch die länge kommen oder (#) ? oder steht # für 8
    Woher weiß man als nächstes für was z.b BB C3 2C FE oder CC oder 14 steht,
    und könnte mir dann jemand die rechnung der Hex zeigen.


    zu der Frage wegen der Länge hatte ich hier schon was geschrieben:


    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.

    Die Daten aus dem Trace kann man einfach manuell aufsplitten.
    Zeile im Trace:
    0AA#EABD099EB80A9483<LF>
    =>
    0AA # EA BD 09 9E B8 0A 94 83
    =>
    ID: 0AA
    # <= Trennzeichen // ab hier kommen Daten
    EA BD 09 9E B8 0A 94 83 => immer 2 Zahlen/Buchstaben ergeben einen "Block" bzw. ein Byte
    <LF> => Zeilenende und damit auch Datenblockende


    Zum Umrechnen nutze ich immer entsprechende Rechner. Z.B. den hier: klick
    Was meinst du denn damit?


    Zitat von MarcelA

    Das ist ja nur aus der ASCII Tabelle richtig

    Die ASCII Tabelle ist eine Tabelle, welche einen "Zahlenwert" zu einem Buchstaben umwandelt und hat mit dem Beispiel nichts zu tun.
    Fassen wir nochmal kurz zusammen:


    Es gibt (mindestens) drei Möglichkeiten, "Daten" über den Bus zu transportieren.
    - Binär => z.B. Türstatus
    - als Zahlenwerte => 0AA - Beispiel mit dem Gaspedal hier ausm Thread
    - als Zeichenwerte => 0x380


    Da wir ja erstmal nicht wissen, um welche Daten es sich auf dem Bus handelt, müssen wir uns das System immer genau anschauen und herumtesten.
    Je nach verwendetem Tool werden nebeneinander HEX sowie DEZ-Daten angezeigt, womit sich die Fgst-Nr. z.B. recht einfach finden lässt, sofern sie nicht irgendwie verschlüsselt wurde.



    @Ivy_E60:
    Auf auf, wieder ran an den Speck! ;)
    Ich bin leider die Woche auf Geschäftsreise und kann von hier aus nicht auf dein Excel zugreifen aber ich glaube, ich kenne es und habe auch daraus schon ordentlich gelernt!
    Wenn du lust hast, schnapp dir mal die DBC und schau drüber.
    Hattest du schonmal mit den cantools gearbeitet? Das .h und .c-Files mit denen erstellen klappt bisher leider auf meinem Linux nicht...



    @Paladin:
    Die Icons sind schonmal cool!
    Hättest du einen geschickteren Vorschlag für die Anzeigen? Ich bin grafisch wie gesagt ne 0-Nummer, also lass dich darauf nicht festlegen!
    Das einzige, was uns einschränkt ist das Befehlsset des Displays, was sich aber unter Umständen wieder mit Images aushebeln lässt...

    Das Anpassen der Skalen ist nicht schwer - da ist das Auslöten vom EEPROM aufwändiger.
    Dafür gibt es mittlerweile eine Software, welche ziemlich einfach zu benutzen ist. Such mal nach "perfekt toolbox".
    Alternativ kannst du das ganze mit HEX-Werten selber ausrechnen aber das willst du nicht ;)

    Bei dem Display ist links oben x0,y0
    Rechts unten dann x400,y240


    Mittelposition war natürlich falsch, sorry. Da gehört jeweils die Hälfte der Control-Höhe/-Breite dazu gerechnet, welche bei 80x80 liegt
    Die Mittelpunkte sollten damit auf: x80,y108 und x320,y108 liegen (Zahlen "begradigt").


    Die Farbe der Zeiger kann man problemlos im Betrieb anpassen.
    Ist nur ein bisschen Code notwendig.

    @Paladin: Langsam tippen ist nach "zwei mal so einen Text ausm Kopf raus tippen" zu viel verlangt :kap::D



    Displaygröße sind 400*240 Pixel.
    Die beiden Gauges sind derzeit mit dem Generator hier Unter Nutzung der folgenden Daten erstellt (Spoiler -> Codeblock). Mittelpositionen der Gauges im Bild sind x=41,y=68 und x=278,y=68


    Die Icons der Buttons haben derzeit eine Größe von 30x30 (Tanken), 40x40 (< >) oder 50x50 (Settings & Home) Pixel wobei nur die Pfeile einen Rahmen außen rum bekommen haben.
    Skalieren lassen sie sich ja im Normalfall ganz gut.
    Format der Bilder geht JPG und PNG out of the box - der Rest wird hald umkonvertiert.
    Hintergrund immer #000, Hauptfarbe im Regelfall #fff - bei der kleinen Tempanzeige die BMW-M-Farben:


    rgba(69,153,254,.70)


    rgba(3, 30, 73)
    rgba(238,4,5,.70)


    Ansonsten sei deiner Kreativität keine Grenze gesetzt :)


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

    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

    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

    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:

    Code
    int FrameHandlerClass::getEngineRPM(byte* buff)
    {
    	return (((buff[5] << 8) + buff[4]) / 4);
    }

    Soweit mal zu der Ausführung - mehr gibts später...

    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

    Früher war es bei BMW üblich, dass nur ein "Ersatztacho" verbaut werden konnte der entweder den gleichen oder höheren Kilometerstand hatte ansonsten hat das Kombi gemeckert und der Manipulationspunkt ging an. Was passiert jetzt wohl wenn man sein Kombiinstrument ausbaut, meinetwegen 20tkm. mit dem neuen Digitalen rumfährt und dann sein altes originales wieder einbaut?


    Knapp daneben aber trotzdem fast vorbei ;)


    1. Manipulationspunkt: Der kommt nur, wenn die VIN aus dem Kombi nicht zur VIN vom Fahrzeug passt. Abgeglichen wird mindestens mit dem CAS soweit ich herausfinden konnte. Ob andere STGs beteiligt sind, weiß ich nicht.


    2. Km-Stand: Es wird bei Einbau eines anderen Kombiinstrumentes zwischen "Fahrzeug" und "Kombi" abgeglichen. Der jeweils höhere Km-Stand wird bei dem jeweiligen Partner abgespeichert.
    Hat das Kombi weniger und wird ins Fahrzeug eingebaut, wird der Km-Stand vom Fahrzeug im Kombi gespeichert - !!EGAL, OB DIE VIN KORREKT IST!! Also nicht mit dem Kombi von nem Kumpel quertauschen ;)
    Hat das Fahrzeug weniger und das Kombi mit dem höheren Km-Stand wird eingebaut, speichern alle STG den höheren Wert ab. Ich weiß derzeit nur von CAS und den Schlüsseln.


    Der Kilometerstand im Kombi wird in einem EEProm gespeichert. Je nach Baujahr wird eines der folgenden (oder kompatiblen) EEProms verwendet:
    M35080
    M35080-3
    M35080-6
    M35080VP
    M35080V6
    080D0WQ


    Möchte man also ein anderes Kombi aus einem anderen Fahrzeug einbauen, muss man so oder so die VIN im EEProm ändern, sofern man den Manipulationspunkt los werden möchte.
    In diesem Zuge setzt man den Km-Stand also einfach gleich mit auf 0 und die Sache ist erledigt. Damit lässt sich das Kombiinstrument dann problemlos mit den üblichen Tools codieren.
    Wer das mal brauchen sollte, einfach melden. Kann ich gern erledigen... Wird z.B. auch beim Umbau auf einen M5-Tacho benötigt.


    Wenn man das hier angesprochene Display für xx Km eingebaut hatte, einfach das originale Kombi wieder einbauen.
    Der höhere Km-Stand wird automatisch im Kombi gespeichert und gut ists.


    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): BMW_E6x_30_01_2020_11_31.zip

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