E6x CAN-BUS Analyse // DBC Datenbank

    @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 :)


    Zitat von freakmaster

    Mittelpositionen der Gauges im Bild sind x=41,y=68 und x=278,y=68


    Ok, nur mal so zum Verständnis für den Anfang: Ich habe mal ein Bild mit den Positionen erstellt.
    Sind die Positionen von oben oder von unten anzusehen?


    Ich nehme an dass es sich bei den beiden Punkten um die Mitte der beiden Anzeigen handelt.
    Wenn ja, sind aber irgendwie deplaziert ;)


    Technische Frage zur Durchführbarkeit: Müssen die beiden Anzeigen rund sein? (Wenn man auf dem kleinen Platz zwei Anzeigen in rund gestaltet, leidet die Ablesbarkeit. Sie sind einfach zu klein)
    Ich nehme an, das dieses Display für den linken Lüftungsschacht gedacht ist?

    Und nochwas: Ist es möglich die Zeiger, falls es später welche werden sollten, so anzupassen, das sie tagsüber weiß sind, und wenn man das Licht anschaltet in Amber dargestellt werden?
    So kann man das Display originaler erscheinen lassen ;)

    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.

    Ok, gut, damit kann ich was anfangen :)


    Nach der Schriftart, die der Originalschriftart am nächsten kommt, suche ich noch.


    Und die Symbole kann ich auch anpassen.


    Es wäre nur schön im Vorfeld alle Symbole die gebraucht werden zu wissen.
    In dem Beispielbild sind beiden Symbole 40px breit, aber die Öltemperatur wirkt kleiner.
    Also muss das einiges angepasst werden, damit es optisch harmoniert.
    Deswegen wäre es schön, wenn anfangs alles Symbole feststehen, dann kann ich die simultan nebeneinander bearbeiten :)

    Dann geb ich auch noch mein Wissen als Ergänzung dazu, da nur minimale Abweichungen :trinken:


    Der CAN im Automobilbereich (dafür wurde er erfunden) kennt die genannten Filtereinstellungen. Hierüber kann der FZG Hersteller die Rechenlast der Busteilnehmer reduzieren oder Geräte ausschließen. Daher verwaltet der FZG Hersteller in der Datenbank auch die notwendigen Empfänger. Je nach Vorgaben können oder müssen die Empfänger die Filter entsprechend konfigurieren. Es können nur Busteilnehmer, die diese Filter nicht nutzen auch alle Nachrichten mithören.


    Es werden die Flags in der Antwort gesetzt, nicht in der Botschaft -> "keine Antwort" führt zu einem Busfehler. Anders als beim LIN ist ein Antwort nicht Teil der Nachricht sondern ein Teil der Kommunikation.
    Fehler am CAN werden vom Transceiver an den CAN Controller und so den Mikrocontroller weitergegeben -> sehr wichtiges Feature, denn ein Steuergerät setzt sich selbst in den BusOff, nicht ein anderes.


    Die Mikrocontroller im Automotive-Umfeld haben die CAN-Controller integriert. Nur sehr selten wird auf externe CAN-Controller zurückgegriffen. Auch bei "Einplatinencomputern" gibt es entsprechende Versionen oder Typen. Ein BeagleBone Black hat z.B. 2 CAN-Controller integriert, ein Raspberry Pi muss diese über SPI anbinden. Die Anbindung über SPI ist überholt, eine Anbindung des CAN-Transceivers ohne CAN-Controller ist tatsächlich Murks.


    Die Interpretation der Daten ist frei definierbar. In CAN-Datenbanken wird diese Freiheit eingeschränkt, um die Interpretierung Toolgestüzt zu ermöglichen und im Steuergerät zu vereinheitlichen. Daraus folgt, dass man für jedes Signal die Position und Länge in der Nachricht angibt und dann wählen kann, ob eine einfache Umrechnung erfolgt. Falls ja, werden Bytereihenfolge (Intel/Mot.), Wertetyp (z.B. Float), Faktor und Offset angegeben. Andernfalls gibt es die Wertetabelle.


    BTW mit welchem Tool erstellst du die CAN DB? Mein Tool kann sie nicht lesen: syntax error in line 115 ?(

    Zitat von saft6luck

    BTW mit welchem Tool erstellst du die CAN DB? Mein Tool kann sie nicht lesen: syntax error in line 115 ?(

    Sorry, war tatsächlich einer drin...
    Ist mit SavvyCan erstellt. Der Hundling lässt einen speichern aber das File dann nicht mehr laden...
    War ein Fragezeichen drin, das wohl nicht zulässig ist.

    Nochmal Fragen zu den Datenpaketen.


    Beispiel: 0AA#BBC32CFECC14B48C


    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.



    Ich habe nun gefunden mit ^1 und ^2 und ^3 und *16.




    Wie wird nun gerechnet?


    Das ist ja nur aus der ASCII Tabelle richtig.
    ==>> Hex 00 = Dez 0 = Standgas
    HEX 9E = Dez 158 = ~62% Gas
    Hex FE = Dez 254 = Vollgas



    Vielen lieben dank schon mal
    Liebe Grüße Marcel


    Ok habs 0AA8 =


    8*16^0 8*1
    10*16^1 10*16
    10*16^2 10*256
    0x16^3 0*4096



    = 8+160+2560 = 2728

    ich schon wieder.
    Anbei habe ich mal alles zusammen getragen was ich so habe.


    @freakmaster deins fehlt noch und muss noch von mir ergänzt werden.


    Wenn ich Zeit finde werde ich es über einen S Verweis noch vergleichen ob es schon identische gibt.


    E65 E60 E84.


    Sind nicht von mir ermittelt nur zusammen getragen.


    Gruß Marcel


    Can Bus Codes total.zip

    @MarcelA

    Zitat von 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:


    Zitat von Freakmaster

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

    Zitat von Paladin

    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!

    @freakmaster danke für die Infos, damit kann ich was anfangen :)


    Noch zwei Fragen, und dann kann ich anfangen meine Ideen im Hintergrund mal zu Spielereien und dann "sichtbar" zu machen.


    Anbei ein Bild einer Menüführung inkl. einer permanenten Anzeige.
    Die permanente Anzeige finde ich interessant, da man diese Informationen immer sehen kann und nicht extra aufrufen braucht.
    Dort findet man wichtige Detail wie Wasser- und Öltemperatur sowie die Spannungsanzeige.
    Evtl. kann man später noch eine Ladeanzeige in Ampere mit hinzufügen, mal schauen ...


    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?


    (Das Bild ist nur symbolisch und noch nicht "optisch" ausgelegt)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden