Ecke der IBus-Hacker

  • Außerhalb der Wagens sieht das ja ganz nett aus. Aber eingebaut?
    Gleichzeitig mit dem IKE funken könnte ins Auge gehen...




    M.f.G.



    Ich

  • Meinst Du jetzt mich oder Tobias?


    Wenn mich:


    1. IKE vom 850er hat keine IBus-Anbindung.
    2. Das Navi wird völlig getrennt vom Fahrzeugbus verbaut. Der einzige Berührungspunkt ist das GateWay. Siehe Bild:



    Im unteren Teil ist der 850er, oben ist das Navibus.


    Es gibt nur wenige Sachen, die aus dem Navibus zum Fahrzeug geschickt werden:


    -> Uhrzeit, wird bei jedem "Zündung an" gesetzt
    -> das Resetten der Verbrauchswerte


    Anders ist es in die Richtung 850er -> Navibus:
    -> BC-Werte
    -> Datum
    -> Uhrzeit (die Uhrzeit wird vom EKM "hochgezählt")
    -> CheckControll


    Grüsse
    Hemi

    Grüße
    Heinrich


    Alle von mir gezeigten Bilder gehören mir, sind von meinen Autos/Tieren/Gegenständen und gemacht mit meiner Kamera/Handy... bei Abweichungen wird es gesondert vermerkt...

    Besitzer von https://www.motorkontrolle.de, Forum für freiprogrammierbare Motorsteuerungen.

  • Naja, dann ist ja klar. Beim 8er ist ja die IKE noch nicht am I-Bus. Beim E39 wird das so aber nicht funzen, denke ich...




    M.f.G.



    Ich

  • Nenn mir nur einen Grund wieso das im E39 nicht gehen soll???


    Dem IKE ist es doch völlig Banane wer mit seiner Kennung die Nachrichten rumschickt. Die Nachrichten sind ja nicht an ihn adressiert, also kein Problem.


    Grüsse
    Hemi

    Grüße
    Heinrich


    Alle von mir gezeigten Bilder gehören mir, sind von meinen Autos/Tieren/Gegenständen und gemacht mit meiner Kamera/Handy... bei Abweichungen wird es gesondert vermerkt...

    Besitzer von https://www.motorkontrolle.de, Forum für freiprogrammierbare Motorsteuerungen.

  • Zitat

    Original von Hemi
    Dem IKE ist es doch völlig Banane wer mit seiner Kennung die Nachrichten rumschickt. Die Nachrichten sind ja nicht an ihn adressiert, also kein Problem.


    Dem IKE schon. Nur, daß du evtl. die originalen Nachrichten vom IKE plattmachst mit dem "Piratensender". Das wäre dann sagen wir mal "suboptimal".




    M.f.G.



    Ich

  • Welche Nachrichten denn bitte?????? Und wie kann man die plattmachen?


    Die BC-Werte sendet IKE an das OBD (Textzeile im IKE). Kein IKE-High -> Keine Textzeile -> keine BC-Daten auf dem BordMonitor.


    Wenn Du Kollisionserkennung auf dem Bus meinst, dann sei unbesorgt, dafür ist gesorgt, dass es nicht auftritt.


    Grüsse
    Hemi

    Grüße
    Heinrich


    Alle von mir gezeigten Bilder gehören mir, sind von meinen Autos/Tieren/Gegenständen und gemacht mit meiner Kamera/Handy... bei Abweichungen wird es gesondert vermerkt...

    Besitzer von https://www.motorkontrolle.de, Forum für freiprogrammierbare Motorsteuerungen.

  • 123_BMW bzw. du:



    Die Befürchtung, daß man irgendwelche Nachrichten auf dem IBus plattmachen kann, ist absolut berechtigt und sollte auch dringend berücksichtigt werden. Die BimmerBox z.B. sendet wild Sachen aus ohne sich zu vergewissern, ob da schon jemand am senden ist Und so fällt ab und zu das BimmerBöxchen halt aus. Das muss ich bei Gelegenheit auch mal fixen.


    Um das Problem der Kollision zu lösen, gibt es zwei Sicheheitsmechanismen, die implementiert wurden (zumindest in meiner Hardware)


    1. Es muss vor dem Senden auf den Bus eine gewisse Zeit (2-10ms, je nach Priorität der Meldung) Ruhe herrschen, bevor man was sendet.


    2. Wärend der Übertragung muss geprüft werden, ob nicht jemand anderes dazwischen funkt und die Nachricht zerstört. Falls das passiert, eine zufällige Zeit innerhalb eines Zeit-Rahmens warten und nochmal versuchen zu senden.


    3. Es gibt auf dem IBus eine Adress-Arbitrierung, heisst: Da die Quelladresse in IBus Nachricht zu erst übertragen wird, setzt sich die höhere Adresse durch. (Hier könnte man noch etwas ins Detail gehen, das lass sich aber erstmal)



    Dieses Bus Zugriffsverfahren heisst CSMA, Carrier Sense Multiple Access. Bei Ethernet wird das fast genauso gemacht, nur dort gibt es die Adress-Arbitrierung nicht.


    Soviel zu Theorieteil.


    In der Praxis:


    Ich fahre nun schon seit ein paar Tagen mit einem "zweiten IKE" herum. Funktioniert prima. Da es bei mir ja zwei Einheiten mit der selben Adresse gibt, sendet mein Controller die pseudo IKE Nachrichten etwas später als das original IKE aus, bzw. prüft länger und gibt so allen anderen Geräten mit Priorität 1 Vortritt.



    Ich hab nun also meine GPS-genaue Uhr mit Datum im Menü unten und im TV. Zudem hab ich einen virtuellen Bordcomputer (ist noch nicht ganz fertig) Dieser setzt die BC Werte auf dem Bordmonitor etwas "anders".


    Reichweite ist: Wassertemperatur: +70° z.B.
    A-Temp ist Aussentemperatur
    Verbrauch 1: Durschn. verbrauchte Liter pro Tag seit letzter Inspektion, oder seit Reset.
    Verbrauch 2: Bordspannung in Volt
    Geschw: Geschwindigkeit
    Distance: Drehzahl in RPM
    Limit: Tage seit letzter Inspektion
    Timer: Stoppuhr


    Funktioniert noch nicht alles so wie es soll, aber wenns mal fertig ist, gibts Bilder :D


    Gruß
    tobi

  • Tobias,


    zu Deinem Punkt 2, wegen dazwischen funken:


    Heisst es, dass Du während des Sendens die Nachricht auch empfängst und schaust, ob das, was Du gesendet hast auch dem entspricht, was Du empfangen hast?


    Grüssle
    Hemi

    Grüße
    Heinrich


    Alle von mir gezeigten Bilder gehören mir, sind von meinen Autos/Tieren/Gegenständen und gemacht mit meiner Kamera/Handy... bei Abweichungen wird es gesondert vermerkt...

    Besitzer von https://www.motorkontrolle.de, Forum für freiprogrammierbare Motorsteuerungen.

  • Heinrich:


    Genau. Ich unterscheide zischen zwei Varianten, wobei ich momentan die erste verwende.


    Late Collision:


    Es wird immer die ganze Nachricht rausgeschickt und gleichzeitig empfangen. Stimmt das nicht überein, wurde mein Paket zerstört und wird etwas später nochmal gesendet.


    Wie es perfekt sein sollte:


    Early Collision:


    Jedes Bit wird sofort geprüft. Stimmt eines nicht, wird sofort angehalten und es später nochmal versucht. Hier besteht die theor. Chance, daß der dazwischenfunkende sein Paket noch gültig wegbekommt. Dazu müsste ich in meinem Fall aber ein SW Uart TX-seitig implementieren, was dann wieder ein Nachteil ist.



    Durch die leichte Verzögerung meiner Nachrichten gegenüber dem IKE tritt von meiner Seite jetzt keine Kollision mehr auf. (mit dem Oszi kontrolliert)


    Gruß
    Tobias

  • Ah, okay, ich verstehe.



    Aber Du könntest ja die "Late Collision" dahingehend aufbohren, dass Du nicht die ganze Nachricht nach dem Senden vergleichst, sondern byteweise. Sprich, Du sendest ein Byte und empfängst es auch, dann vergleichst Du ob das, was Du geschickt hast auch dem was Du empfangen hast entspricht, wenn ja -> weitermachen, wenn nicht -> abbrechen und später versuchen.


    Grüsse
    Hemi

    Grüße
    Heinrich


    Alle von mir gezeigten Bilder gehören mir, sind von meinen Autos/Tieren/Gegenständen und gemacht mit meiner Kamera/Handy... bei Abweichungen wird es gesondert vermerkt...

    Besitzer von https://www.motorkontrolle.de, Forum für freiprogrammierbare Motorsteuerungen.

  • Heinrich, ja gute Idee. Ich hatte mir sowas auch schonmal überlegt. Dadurch wird zwar die Nachricht des anderen nicht geschützt, aber die Busbelegungszeit wird reduziert.

  • Wie soll das denn gehen? CAN-Messages werden doch immer als Block gesendet. Es besteht standardmäßig keine Implementierung, die eine Fragmentierung der Pakete vorsieht.
    Und genau die Arbitrierung meinte ich mit plattmachen: wenn 2 Sender die gleiche ID haben und diese bitweise auf den Bus legen, gewinnen beide. Und dann senden beide - leider gehen dabei beide Datensegmente über den Jordan.
    Klingt erst mal nicht schlimm. Nur wird bei kaputten Paketen der Errorcounter des Senders um 8 Bit inkrementiert. Bei 128 wird der Sender durch alle Busteilnehmer als "babbling idiot" markiert.
    Damit ist er dann nicht mehr aktiver Teilnehmer des Busses. Schlecht fürs IKE...
    Und für 16 Kollisionen braucht man im "Idealfall" wenige Sekunden.


    Ich hatte ja zunächst angenommen, daß der neue "Teilnehmer" an der Arbitrierung teilnehmen soll. Aber einfach so dazwischenfeuern ist schon recht sportlich... ;)




    M.f.G.



    Ich

  • 123_bmw.


    IBus ist nicht CAN, sondern LIN. Die Übertragung kann jederzeit unterbrochen werden. Es wird dann nach einer Zeit >2ms die KOMPLETTE Nachricht noch einmal geschickt. Es gibt auch in LIN keine Fragmentierung.


    Es gewinnen nur dann beide, wenn Sie zur gleichen Zeit mit der Sendung beginnen. Da das IKE bzw Prio 1 Nachrichten immer innerhalb einer festen Zeit nach einer Ruhepause an den Start gehen und "mein" IKE deutlich länger wartet, kommt es zu keiner Kollision. Die Kollision könnte nur auftreten wenn das IKE tatsächli mal in genau derselben Mikrosekunde los senden würde.


    Wenn mein Gerät eine eigene einzigartige ID hätte, könnte es auch an einer Adress-Arbitrierung teilnehmen, da es aber ebenfalls IKE als Absender ist, muss es dem Original durch dieses "Zwischenfeuern" Vorrang lassen. Es ist auch kein dazwischenfeuern, da zwischen einer Frage an das IKE und einer Antwort vom IKE Funkstille meinerseits ist. Meine Nachrichten kommen erst danach.


    Gruß
    Tobi

  • Auf dem IBus können keine zwei Teilnehmer gleichzeitig senden, es geht nicht.


    Wenn der Bus auf high ist, halten alle die Schnauze. Wenn der Bus von high auf low wechselt (und das passiert, wenn die Nachricht gesendet wurde), wird nach einer definierten Pause gesendet. Diese Pause bei Prio 1 Nachrichten beträgt 1,7 ms.


    Fragmentierung kann IBus/LIN nicht.


    Grüsse
    Hemi

    Grüße
    Heinrich


    Alle von mir gezeigten Bilder gehören mir, sind von meinen Autos/Tieren/Gegenständen und gemacht mit meiner Kamera/Handy... bei Abweichungen wird es gesondert vermerkt...

    Besitzer von https://www.motorkontrolle.de, Forum für freiprogrammierbare Motorsteuerungen.

    Einmal editiert, zuletzt von Hemi ()

  • Hemi:


    Naja "können" schon, und wenn beide die gleiche Quelladresse haben, würde das auch am Anfang garnicht auffallen. Vorrausgesetzt beide starten zu exakt genau der gleichen Zeit. Der Trick bei der Busarbitrierung ist, das das Gerät mit der niedrigeren Adresse den Bus vor einer höheren runterziehen (also auf Masse) kann und so die höherwertige das merkt und sofort stoppen kann. Dadurch kan das Gerät mit der niederwertigen Adresse ohne Halt weitersenden, ohne das was kaputt gegangen ist.


    Diese Art der Adress-Arbitrierung ist speziell von BMW. Im LIN 2.0 Dokument wird immer nur von 1 Master x Clients geredet. Da sendet keiner bevor der Master es nicht angeordnet hat (duch einen Request)

  • 123_bmw:


    Es ist nicht 100% LIN. LIN ist eigenmtlich nicht Mulitmasterfähig, das wurde halt von BMW erweitert.


    CAN ist immer mit zwei Kabeln und differentiellen Signalen. LIN verwendet nur ein Kabel. Im Motoraum ist CAN, im Fahrgastraum LIN (D-Bus, I-Bus, K-Bus)

  • Daher meine Verwirrung. CAN kann sehr wohl auch einadrig sein (zweiter Kanal auf Masse, keine Redundanz). Und die Struktur des Datenpaketes, die Hemi beschreiben hat, ist die von CAN. LIN sieht doch ganz anders aus!? :kratz:




    M.f.G.



    Ich

  • Ja stimmt, da war was, hast absolut Recht: CAN kann man auch mit nur einem Draht verwenden. CAN und LIN sind ähnlich. Also ich kenn LIN so: je ein byte: Quelle, Länge, Ziel, Command, Daten und am Schluss ein Byte Checksumme.


    CAN hat 11Bit Adressen (Identifier Feld) sowie div. andere Spezial-Bits. LIN ist rein auf Bytes (8 Bit) aufgebaut. CAN Frames werden noch während des Sendes durch das Bestätigungs-Bit bestätigt, wobei bei LIN auf Frame Ebene nichts bestätigt werden muss.

  • Wenn du etwas Online-Literatur über den LIN-Bus im E39 hast, immer her damit! Inzwischen juckt es mich doch, vielleicht doch was am E39 zu proggen (wenn ich irgendwann mal wieder Zeit habe. :boese: ). Aber erst mal einlesen. ;)




    M.f.G.



    Ich