FIS Textanzeige / Vialle LPG Gasanlage Tankstand über FIS anzeigen
Hi all,
nach langer Entwicklungszeit habe ich endlich mal ein Video über eins meiner Projekte gedreht, um euch das Projekt mal vorzustellen.
Da ich bei mir eine Vialle Gasanlage verbaut habe und diese Anlage nicht mit den übrigen Fahrzeugsystemen integriert ist, braucht man normalerweise ein extra Bedienteil im Innenraum, welches den Tankstand mittels 5 LEDs anzeigt und über einen Taster erlaubt von Benzin- auf Gasbetrieb (bzw. umgekehrt) umzuschalten.
An dem Bedienteil hat mich
a) gestört, dass es als "Fremdkörper" im Innenraum sichtbar ist (z.B. blaue LEDs ...)
b) dass es den Tankstand nur in sehr groben Schritten anzeigt
c) dass es mir nicht angezeigt hat, wenn die Gasanlage unter hoher Motorlast temporär zurück auf Benzinbetrieb schaltet (die Regeln, wann und auf basis welcher Parameter die Lastumschaltung geschieht, kann man in der Anlage programmieren - leider ohne Anzeige am Bedienteil, wann sie greifen)
In meiner naiven Denkweise hatte ich zuerst geplant das Bedienteil durch einen Mikrocontroller abzulösen, welcher mit einem Taster in der Mittelkonsole gesteuert wird, der auch eine LED enthält und darüber den Status anzeigt.
Die Tankanzeige wollte ich eigentlich über durch den Mikrocontroller simulierte Tankgeber zum Kombiinstrument hin realisieren. (bei Benzinbetrieb Anzeige des Benzintankstands / bei Gasbetrieb Anzeige des Gastankstands)
So weit so gut ... also habe ich damit angefangen und musste folgendes feststellen:
1) die Bedieneinheit der Gasanlage wird digital mit Daten versorgt (z.B. auch den Tankstand)
2) das KI erlaubt nur bei einem Stillstand von mehr als 10 Sekunden eine von der normalen Mittelwertsberechnung (die Anzeigeschwankungen während der Fahrt elemeniert) losgelöste Einstellung des neuen Tankstandes
Das Vialle Protokoll hat mich dann erst einmal 2 volle Wochen beschäftigt, bis ich es decodiert hatte und im eigenen Mikrocontroller nachgebaut hatte.
Die Tankstandanzeige hat es dann leider nötig gemacht am ursprünglichen Plan eine Änderung durchzuführen. Ich habe mir dann halt überlegt, dass es ja auch ganz nett wäre, den Tankstand im FIS anzuzeigen :)
Beim 4B wäre das noch sehr einfach gewesen. Leider nicht beim 4F ... aber das konnte ich da ja noch nicht wissen ... ;)
Nächster Schritt war der Bau einer CAN-Bridge mit dem Mikrocontroller. Zwei CAN-Busse, den Mikrocontroller zwischen KI und CAN-GW, wobei der Mikrocontroller alles was auf Bus #1 empfangen wird auf Bus #2 rausschickt und umgekehrt.
Gesagt, getan - eine weitere 1 Wochen später hatte ich das dann auch fertig. Hat eine Woche gedauert, da ich auf dem Weg feststellen musste, dass es mit Zündplus für die Schaltung an der Stelle leider nicht getan ist. da das KI auch ohne Zündung noch kommunizieren können muss, was Dauerplus nötig gemacht hat - leider verbunden mit der Anforderung eines extrem niedrigen Ruhestromverbrauches. (Sleep Modi, auch für die CAN Teiber / den CAN Controller / den Mikrocontroller etc.)
Nächster Schritt das FIS Protokoll ...
Ich dachte eigentlich, dass es mit dem Umschreiben von CAN Messages getan ist, weil diese regelmässig über den Bus - und damit über den Mikrocontroller - geschickt werden und den angezeigten Text enthalten.
Dem ist leider nicht so :(
Die Kommunikation ist an der Stelle schon wirklich sehr gut gelöst. Es wird nichts unnötiges über den Bus geschickt.
Man kann sich die Kommunikation ähnlich wie beim TCP Protokoll im Internet vorstellen - jedenfalls was die Sequenznummern in den FIS Datenpaketen angeht.
Bei einem Protokoll, welches Sequenznummern verwendet, ist es leider nicht möglich einfach zusätzliche Nachrichten einzufügen, ohne die Sequenznummern zu stören. Die Kommunikationspartner stellen sofort fest, dass da irgendetwas in der Kommunikation nicht stimmt, weil die Sequenznummern nicht mehr zu der Anzahl der empfangenen/gesendeten Nachrichten passen.
Das FIS quittiert ein Fehler im Sequenznummernzyklus mit einem Reset ... sehr unschön, da das FIS für eine lange Zeitspanne komplett schwarz wird, bis sich das Protokoll zum MMI wieder vollständig neu aufgebaut hat.
Ok ... weiter im Text ...
Bei einem solchen Protokoll gibt es nur die Möglichkeit eines sogenannten "man in the middle" Angriffs. (falls man hier von einem Angriff sprechen möchte ... ich wollte doch einfach nur meinen Tankstand anzeigen lassen ... *g*)
Glücklicherweise hatte ich das Design ja aber sowieso schon als CAN Bridge mit dem Mikrocontroller in der Mitte ausgelegt :)
Hat mich zwar einige Nerven gekostet, aber mit dem nötigen Zeiteinsatz habe ich das schliesslich dann auch noch alles in den Griff bekommen. (ich gehe hier nicht auf weitere Hürden ein, die zu nehmen sind ...)
Den Mittelkonsolentaster habe ich mit einer RGB-LED versehen. Ist ein blanko-Sonderfunktionstaster, dessen Kappe normalerweise nicht beschriftet ist. Die Kappe habe ich mir gravieren lassen. Man kann keinen Unterschied zu den normalen Mittelkonsolentastern feststellen.
Die Information, ob mein Dicker wirklich auf Gas oder Benzin läuft habe ich mir von jeweils einer Einspritzdüse geholt. Ich denke mal dort kann man 100% sicher sein, auf was gerade gefahren wird ...
So - kommen wir zu dem, was hier wahrscheinlich die Meisten mit sicherheit eh nur interessieren wird ... dem Video, welches die Lösung in Aktion zeigt.
Man könnte nun mit der Lösung auch sehr nette andere Sachen machen:
- Tachoangleichung über den µC
- Anzeige von beliebigen Werten/Texten im FIS (von Daten die über den CAN zum KI fliessen oder über den µC extern geholt werden)
- mit ziemlicher Sicherheit auch weitere Ebenen im Bordcomputer realisieren (wie die Ebenen, die man über die Mode-Taste ansprechen kann)
- Eingaben über den Bordcomputer-Lenkstockschalter realisieren (wenn man die BC Lenkstocktaster länger drückt und wieder loslässt, dann wird kein normaler Event ausgelöst ... dieses lange Drücken könnte der µC auswerten und dann etwas machen)
So viel erst einmal dazu .... hoffe ich bin nicht zu sehr meinem Schreibfluss erlegen und habe euch nicht zu sehr gelangweilt ;)
Kai
Beste Antwort im Thema
Hi all,
nach langer Entwicklungszeit habe ich endlich mal ein Video über eins meiner Projekte gedreht, um euch das Projekt mal vorzustellen.
Da ich bei mir eine Vialle Gasanlage verbaut habe und diese Anlage nicht mit den übrigen Fahrzeugsystemen integriert ist, braucht man normalerweise ein extra Bedienteil im Innenraum, welches den Tankstand mittels 5 LEDs anzeigt und über einen Taster erlaubt von Benzin- auf Gasbetrieb (bzw. umgekehrt) umzuschalten.
An dem Bedienteil hat mich
a) gestört, dass es als "Fremdkörper" im Innenraum sichtbar ist (z.B. blaue LEDs ...)
b) dass es den Tankstand nur in sehr groben Schritten anzeigt
c) dass es mir nicht angezeigt hat, wenn die Gasanlage unter hoher Motorlast temporär zurück auf Benzinbetrieb schaltet (die Regeln, wann und auf basis welcher Parameter die Lastumschaltung geschieht, kann man in der Anlage programmieren - leider ohne Anzeige am Bedienteil, wann sie greifen)
In meiner naiven Denkweise hatte ich zuerst geplant das Bedienteil durch einen Mikrocontroller abzulösen, welcher mit einem Taster in der Mittelkonsole gesteuert wird, der auch eine LED enthält und darüber den Status anzeigt.
Die Tankanzeige wollte ich eigentlich über durch den Mikrocontroller simulierte Tankgeber zum Kombiinstrument hin realisieren. (bei Benzinbetrieb Anzeige des Benzintankstands / bei Gasbetrieb Anzeige des Gastankstands)
So weit so gut ... also habe ich damit angefangen und musste folgendes feststellen:
1) die Bedieneinheit der Gasanlage wird digital mit Daten versorgt (z.B. auch den Tankstand)
2) das KI erlaubt nur bei einem Stillstand von mehr als 10 Sekunden eine von der normalen Mittelwertsberechnung (die Anzeigeschwankungen während der Fahrt elemeniert) losgelöste Einstellung des neuen Tankstandes
Das Vialle Protokoll hat mich dann erst einmal 2 volle Wochen beschäftigt, bis ich es decodiert hatte und im eigenen Mikrocontroller nachgebaut hatte.
Die Tankstandanzeige hat es dann leider nötig gemacht am ursprünglichen Plan eine Änderung durchzuführen. Ich habe mir dann halt überlegt, dass es ja auch ganz nett wäre, den Tankstand im FIS anzuzeigen :)
Beim 4B wäre das noch sehr einfach gewesen. Leider nicht beim 4F ... aber das konnte ich da ja noch nicht wissen ... ;)
Nächster Schritt war der Bau einer CAN-Bridge mit dem Mikrocontroller. Zwei CAN-Busse, den Mikrocontroller zwischen KI und CAN-GW, wobei der Mikrocontroller alles was auf Bus #1 empfangen wird auf Bus #2 rausschickt und umgekehrt.
Gesagt, getan - eine weitere 1 Wochen später hatte ich das dann auch fertig. Hat eine Woche gedauert, da ich auf dem Weg feststellen musste, dass es mit Zündplus für die Schaltung an der Stelle leider nicht getan ist. da das KI auch ohne Zündung noch kommunizieren können muss, was Dauerplus nötig gemacht hat - leider verbunden mit der Anforderung eines extrem niedrigen Ruhestromverbrauches. (Sleep Modi, auch für die CAN Teiber / den CAN Controller / den Mikrocontroller etc.)
Nächster Schritt das FIS Protokoll ...
Ich dachte eigentlich, dass es mit dem Umschreiben von CAN Messages getan ist, weil diese regelmässig über den Bus - und damit über den Mikrocontroller - geschickt werden und den angezeigten Text enthalten.
Dem ist leider nicht so :(
Die Kommunikation ist an der Stelle schon wirklich sehr gut gelöst. Es wird nichts unnötiges über den Bus geschickt.
Man kann sich die Kommunikation ähnlich wie beim TCP Protokoll im Internet vorstellen - jedenfalls was die Sequenznummern in den FIS Datenpaketen angeht.
Bei einem Protokoll, welches Sequenznummern verwendet, ist es leider nicht möglich einfach zusätzliche Nachrichten einzufügen, ohne die Sequenznummern zu stören. Die Kommunikationspartner stellen sofort fest, dass da irgendetwas in der Kommunikation nicht stimmt, weil die Sequenznummern nicht mehr zu der Anzahl der empfangenen/gesendeten Nachrichten passen.
Das FIS quittiert ein Fehler im Sequenznummernzyklus mit einem Reset ... sehr unschön, da das FIS für eine lange Zeitspanne komplett schwarz wird, bis sich das Protokoll zum MMI wieder vollständig neu aufgebaut hat.
Ok ... weiter im Text ...
Bei einem solchen Protokoll gibt es nur die Möglichkeit eines sogenannten "man in the middle" Angriffs. (falls man hier von einem Angriff sprechen möchte ... ich wollte doch einfach nur meinen Tankstand anzeigen lassen ... *g*)
Glücklicherweise hatte ich das Design ja aber sowieso schon als CAN Bridge mit dem Mikrocontroller in der Mitte ausgelegt :)
Hat mich zwar einige Nerven gekostet, aber mit dem nötigen Zeiteinsatz habe ich das schliesslich dann auch noch alles in den Griff bekommen. (ich gehe hier nicht auf weitere Hürden ein, die zu nehmen sind ...)
Den Mittelkonsolentaster habe ich mit einer RGB-LED versehen. Ist ein blanko-Sonderfunktionstaster, dessen Kappe normalerweise nicht beschriftet ist. Die Kappe habe ich mir gravieren lassen. Man kann keinen Unterschied zu den normalen Mittelkonsolentastern feststellen.
Die Information, ob mein Dicker wirklich auf Gas oder Benzin läuft habe ich mir von jeweils einer Einspritzdüse geholt. Ich denke mal dort kann man 100% sicher sein, auf was gerade gefahren wird ...
So - kommen wir zu dem, was hier wahrscheinlich die Meisten mit sicherheit eh nur interessieren wird ... dem Video, welches die Lösung in Aktion zeigt.
Man könnte nun mit der Lösung auch sehr nette andere Sachen machen:
- Tachoangleichung über den µC
- Anzeige von beliebigen Werten/Texten im FIS (von Daten die über den CAN zum KI fliessen oder über den µC extern geholt werden)
- mit ziemlicher Sicherheit auch weitere Ebenen im Bordcomputer realisieren (wie die Ebenen, die man über die Mode-Taste ansprechen kann)
- Eingaben über den Bordcomputer-Lenkstockschalter realisieren (wenn man die BC Lenkstocktaster länger drückt und wieder loslässt, dann wird kein normaler Event ausgelöst ... dieses lange Drücken könnte der µC auswerten und dann etwas machen)
So viel erst einmal dazu .... hoffe ich bin nicht zu sehr meinem Schreibfluss erlegen und habe euch nicht zu sehr gelangweilt ;)
Kai
Ähnliche Themen
111 Antworten
Hallo Kai,
kein Problem Trace stelle ich heute Abend ein. Denn ich möchte ja wissen ob es bei mir mit Sequentierung läuft. Wenn 478 und 479 bei dir für Das Display ist so ist es beim A4 (2 x 8 Zeichen) 261 und 263 vom Radio Navi, 265 und 267 vom Telefon und 6C1 - 6C5 oderso vom Navi für die mittlere Displayfläche. Das was ich als einzigstes sehe was immer um eins hochzählt ist die Sekunde in dem 0x623 Zeit Frame. Das MuFu läuft im A4 über 5C3 und nicht alle der Befehle werden über den Komfort CAN an den Info CAn geroutet. Die Telefontaste erscheint z.B. nicht während die Drehwalzen schon durch gehen.
Ich werde mal einen Baudratenquarz einschrauben und sehen wie die Anzeige dann rast. Beim reinen mitschreiben laufen so ca. 70 und mehr Frames durch CANhacker.
Wenn ich keine Sequenzierung drin habe könnte mein Vorhaben schon klappen
Gruß
Schorsch
Ja. Die Message-IDs kommen mir auch so bekannt vor.
Ich meine, dass ich diese schon mal im Canhacker Forum gesehen habe.
Da stand meine ich auch wie man den Ring Anmeldung durchführt etc.
Sah bei meinem 4F aber leider ein wenig anders aus ;)
Na, dann bin ich mal auf den Trace gespannt. Ich bin mir auch sicher, dass ich daheim auf dem Server noch alte Traces rumliegen habe.
Stelle ich später dann auch mal rein.
Hallo Kai,
so hier im Anhang ein ganz frischer Mitschnitt von heute Abend. Innerhalb des Trace habe ich das Telefon über das BNS sowie das Navi bedient. Alles in allem so um die drei-vier Minuten. in der Regel sind es so um die 60 - 65 Frames pro Sek. Zur Bedienung des Navis waren es mal auch kanpp 90 Frames - liegt wohl an der Darstellung in der Display Mitte.
Nur die ID 213 viel mir auf, da wurde sporadisch das erste Byte hochgezählt allerdinsg nur sehr sporadisch so das es auf dem Trace garnicht mehr erscheint. Alles ander schien mir unauffällig.
Damals als ich angefangen hatte habe ich mal Screenshots gemacht als verschieden Gerätschaften von Strom getrennt waren. Wie CAN ohne Radio/Navi oder auch ohne Telefon oder auch mit eingeschalteten Geräten - alles in der Zip. Einiges ist in den Bildern beschriftet und kein Geheimnis.
In den Bilder findet sich auch zum Teil die ID 213 wieder.
Ja vielleicht kannst du was dazu sagen...............
Gruß
Schorsch
Zitat:
Original geschrieben von kbankett
Du brauchst dafür (Öltemperatur, Ladedruck, Wassertemperatur etc.) keine Diagnose-Session aufzubauen.
Die Werte müssten auf dem Motor-CAN direkt vorbeigeflogen kommen.
Man braucht dort nur die richtigen Message-IDs und Bytes zu finden und schon hat man die Werte.
CAN funktioniert ja auf einem "Broadcast Prinzip".
Es werden regelmäßig Daten verbreitet und der Busteilnehmer, der sie nun gerade braucht kann sie einfach auswerten.
(ist bie Ethernet aber ja genauso)
Höhere Protokolle müssen davon unabhängig auf anderer Schicht realisiert werden. An der grundsätzlichen Funktionsweise eines CAN-Busses ändert das erst einmal nichts.
Der CAN-Bus ist erst einmal die (ISO) Layer 1 (physikalisch) und 2 (logisch) Transportschicht.
Klar, wenn Werte nicht von anderen Steuergeräten benötigt werden, dann sind diese wahrscheinlich auch nicht direkt auf dem Bus verfügbar.
In so einem Fall (Beispiel: Injektorwerte), müsste man dann natürlich an die dementsprechenden Messwerte aus dem Steuergerät kommen und noch mehr an Protokoll implementieren.
Sind aber ja alles ISO Standards ;)
Hi,
ja prinzipiell stehen schon viele Werte auf dem A-CAN zur Verfügung, leider werden die unterschiedlichen CAN-Busse im B8 über das Gateway (So eine Art Router) getrennt. Habe hier die Komplette Liste des B8-Antriebs-CAN's rumliegen und da ist definitiv kein Ladedruck drin, dieser muß (z.B. 1. N75 (Ladedruck-)Sollwert, 2. (gemessener) Istwert) aus dem Motor-STG per Diagnose ausgelesen werden. Diese Werte werden beim B8 nicht ge-broadcast'ed....
ISO Normen bei CAN sind schon klar, nur leider kann man da so wie ich das sehe ziemlich viel "Herstellerspezifisch reininterpretieren"...
Was cool wäre wenn man einen gescheiten Can-Analyzer hätte, der auch die "höheren Schichten" also OSI Layer 2 und darauf folgende analysiert wie z.B. Frames die aus mehreren bestehen zusammenfasst. Es gibt glaube ich Frames die z.B. bis zu 4096 Byte Nutzdaten enthalten können.
Habe aber leider noch kein richtig gutes Buch über Automotive CAN gefunden, vlt. hat ja jemand einen Tip oder eine gute Internetseite ?
Gruß Andi
So, ich bin auch gerade angekommen.
Anbei mal ein Trace, den ich mit dem Mikrocontroller gezogen habe.
Ausserdem habe ich Texte daneben mal von HEX in ASCII übersetzt.
Schau es dir einfach mal an, dann wirst du die Sequenznummern glaube ich ziemlich schnell finden ;)
Es sind beim 4F übrigens die Message-IDs 490 und 491 - da habe ich mit dem Gedächnis knapp daneben gelegen.
Man sieht in dem angehangenen Trace übrigens auch gut ein paar zusätzliche Funktionen. (aus diesem Grund hatte ich diesen speziellen Trace auch gezogen)
Beispiel: Man drückt die Mode-Taste am Lenkrad und daraufhin updated das MMI den FIS Screen mit dem neuen Menü.
Wenn man also zusätzliche Menüs abbilden möchte, dann ist das genau der Weg.
Zusätzliche Ebenen im BC gehen nicht. Wenn, dann geht das nur über die Mode-Taste.
So, nun erstmal in deine Files schauen ... :cool:
Zitat:
Original geschrieben von kbankett
So, ich bin auch gerade angekommen.
Anbei mal ein Trace, den ich mit dem Mikrocontroller gezogen habe.
Ausserdem habe ich Texte daneben mal von HEX in ASCII übersetzt.
Schau es dir einfach mal an, dann wirst du die Sequenznummern glaube ich ziemlich schnell finden ;)
Es sind beim 4F übrigens die Message-IDs 490 und 491 - da habe ich mit dem Gedächnis knapp daneben gelegen.
Man sieht in dem angehangenen Trace übrigens auch gut ein paar zusätzliche Funktionen. (aus diesem Grund hatte ich diesen speziellen Trace auch gezogen)
Beispiel: Man drückt die Mode-Taste am Lenkrad und daraufhin updated das MMI den FIS Screen mit dem neuen Menü.
Wenn man also zusätzliche Menüs abbilden möchte, dann ist das genau der Weg.
Zusätzliche Ebenen im BC gehen nicht. Wenn, dann geht das nur über die Mode-Taste.
So, nun erstmal in deine Files schauen ... :cool:
Hi,
das deckt sich mit meiner Annahme aus dem B8, die eingebauten Seiten (BC1,BC2,Laptimer,Effizienzprogramm) lassen sich zu 99,9% natürlich nicht modifizieren, aber es wird wohl eine Chance bestehen es ala Telefon/Navi einzubinden. Stichwort Ringanmeldung, nur habe ich keine Ahnung wie das gehen soll, das geht bestimmt nicht über die 490/491 er Messages. Welche im Überigen auch beim B8 für die Anzeige im KI verwendet werden.
Gruß Andi
Schau dir den Trace an, dann wirst du sehen, dass es nicht zwingend eine zusätzliche Ringanmeldung braucht. (jedenfalls im 4F nicht)
Man könnte z.B. einfach den Reset-Knopf auswerten und dann einen anderen Screen zum KI schicken.
Das KI stellt diesen dann einfach dar, weil es überhaupt nicht mitbekommt, dass da nicht der Ring schickt ...
Man könnte z.B. Lenkstockbuttons verwenden, die man lange festhält.
Die BC Knöpfe konnte ich im CAN Trace sehen. Wenn man diese lange festhält, passiert im FIS genau garnichts.
Darauf könnte man ohne Probleme reagieren und dann eine andere Aktion ausführen.
(so jedenfalls das was ich mir zu dem Thema überlegt habe)
Hallo,
also den Teil: a1 0f 8a ff 4a ff
msg_1 (490): a1 0f 8a ff 4a ff
MY can_message (490): a1 0f 8a ff 4a ff
finde ich auch in der Komunikation unter 6C5 bei mir wieder und in der Tat wenn ich mir da das erste Byte ansehe wenn das Navi das Display in der Mitte beschreiben will, es wird hoch gezählt. Allerdings nicht ohne Sprünge ...nee nur das untere Nibbel oderso war das......und oft mit 6C4 zusammen.
Wenn das die Schaltung zum Absturz bringt ???? na Wahnsinn.
Wenn aber nur das BNS 5 als Radio läuft erscheint die 6C5 kaum............. sondern mir schein als Statusmeldung mit 6C4 würde ich vermuten.
Man oh man.....................Ich she da noch kein System was ich ableiten könnte.
Also den Resetknopf am LSS auf langes drücken auswerten das ginge schon da ja nur kurzes drücken vom Auto weiter verarbeitet wird. Genauso kann man auch die Tasten vom MuFu die durchkommen mit verarbeiten und wenn der Track vorgespult wird kurz auf Radio-Display und hinterher nach kurzer Zeit wieder auf die Öltemp springen - das sind aber Dinge die noch keine Rolle spielen - erst kommt die Pflicht und dann die Kür.
Aber die Erfahrung die ich gemacht habe das ich schon auf die 428 jenach Codierung (Radio Navi) mit 436 antworten muß, zusätzlich die 661 und 6C0 damit der Status des Radios und des Navis gemeldet wird. So kommt auch kein Fehlereintrag in die Steuergeräte. Die 43A müssen zurück - Status Tel...
Läßt man nur eins weg, bleiben die 2 x 8 Zeichen dunkel. Ich werde mal testen ob auch mit der neuen Schaltung dieser KI Reset zusehen ist und das Teil gelegentlich dunkel bleibt.
Zitat:
Original geschrieben von TDISchorsch
Hallo,
also den Teil: a1 0f 8a ff 4a ff
msg_1 (490): a1 0f 8a ff 4a ff
MY can_message (490): a1 0f 8a ff 4a ff
Die Folge ist anscheinend nur ein Keepalive. (so habe ich es für mich auf jeden Fall einfach gedeutet)
Sobald die grundsätzliche "Aushandelung" mit dem KI abgeschlossen ist, fängt der Countdown an zu laufen.
Immer wenn er bei 0 angekommen ist, gibt es so einen "a1" Request.
In die andere Richtung genauso.
Nach jeder erfolgreichen Quittierung fängt die Uhr wieder erneut an zu ticken.
Das Keepalive wird auch immer gleich von der jeweiligen Gegenstelle (über Kreuz - jedenfalls was die Message-IDs angeht) beantwortet. (Request fängt im 1.Byte oberen Nibble mit "a" an und die Antwort enthält auch ein "a" oberen Nibble des 1. Bytes)
Ich habe sie aus dem Textfile nur nicht rausgelöscht.
Wenn du/ihr diesen Part rauslöscht, dann erhälst du / erhaltet ihr die eigentlichen Protokollnutzdaten.
Zu den IDs, die du postest, kann ich momentan wenig sagen.
Ich bin leider immer noch nicht dazu gekommen mir deine Traces anzuschauen - sorry.
Ich schaue es mir aber noch an, versprochen.
Im Moment habe ich aber ein Projekt, was mich so "erregt", dass ich mich da erst einmal drauf fokussieren muss.
(mehr dazu gibt es dann gleich noch oder morgen in einem anderen Thema ;))
Edit:
Für die interessierten Leser (das hilf.txt ist ja schon ein paarmal runtergeladen worden):
Wenn ihr euch z.B. den Radio Sender Switch anschaut.
Dann dort jeweils das 1. Byte.
Weiter das LSN (gibt es so eine Abkürzung Least Significant Nibble) - also die niederwertigen 4 Bit des 1. Byte.
Ihr seht dann auf Message-ID 490 die Bytefolge zum KI:
2f xx xx xx xx
10 xx xx xx xx
und dann schliesslich die Rückantwort vom KI (auf Message-ID 491):
b1
Die 2 (im oberen (most significant - Neudeutsch hochwertigsten) Nibble) sagt, dass es sich um eine Multipart-Message handelt.
(CAN überträgt pro Nachricht nur maximal 8 Byte Payload (Nutzdaten) ... soll heissen, wenn mehr als 8 Byte übertragen werden sollen (z.B. der Sendername mehr als 3 Zeichen hat (warum nun drei Zeichen ist dann noch einmal was spezielles ...))
Die 1 (im oberen Nibble) sagt, dass es sich um eine Single-Part Message - es folgen keine weiteren Teile - handelt.
Das KI quittiert mit b1.
b - für Quittierung
niederwertiges Nibble = 1, da auf 0 halt die Zahl 1 folgt.
Wie gesagt, die Quittierung ist immer Sequenznummer + 1.
(oder die Sequenzstartnummer der nächsten Sequenz)
Es gibt da aber noch spezielle Adressierungen, wenn bestimmte "Screens" aktiv sind.
(der Navi-Screen ist z.B. so ein Screen)
Hat mich ein wenig Nerven gekostet, bis ich dahinter gestiegen bin ...
Wenn man die Screen Adressierung nämlich nicht beachtet, dann wird nichts mehr upgedated.
Ich habe mich halt gewundert, dass sobald das Navi aktiv ist, die Textzeilen nicht mehr upgedated werden.
Ist aber noch eine weitere Geschichte ...
Achja, jede grobe (z.B. Sequenznummern- / Protokoll-) Missachtung füht zu einem Protokoll-Reset.
Kommt eine passende Quittierung auf eine KI Bytefolge nicht, gibt es auch einen Protokoll-Reset.
Das FIS wird für eine (störende) Zeitspanne komplett dunkel und das Fahrzeug (MMI) und KI handeln erneut ein stabiles Protokoll aus.
Die Initiierungssequenz ist recht komplex, so dass ich sie den Spezialisten überlasse. (dem Fahrzeug und dem KI)
Ich klinke mich erst ab einem stabilen Zustand ein und füge meine Nachrichten ein.
Ich hoffe nun ist es etwas klarer geworden ... noch Fragen?
Wenn ja, dann müssen wir an passender Stelle "tiefer Bohren". ;)
Denkt jetzt immer noch jemand "Ich baue mir da mal eben was"?
@TDISchorsch: Ist natürlich nicht auf dich bezogen ... bekomme da nur häufiger PNs ;)
Hallo,
das es nicht einfach ist hatte ich mir schon von Anfang an gedacht denn nicht umsonst ist der Bereich auch im A4 noch ohne Endergebnisse und meine Ergebnisse spiegeln das letzendlich wieder.
Mal eben geht da garnichts und meine große Baustelle ist "C" selbst und natürlich die verwendeten Protokole die sich Audi da ausgedacht hat.
Die Sequenzierung muß ich mir heute in einer ruhigen Minuten, kann auch mehr sein, mal ansehen und verstehen was da Sache ist.
Eigentlich ganz logisch das Ki und Navi die Komunikation mit zählt und quitiert damit keine Nachricht verloren geht und die z.B. Pfeildarstellungen auch ganz angezeigt werden. Sollte ich da gezwungenermassen tiefer einsteigen müssen kann ich da anhand der Kompassdaten im mittleren Teil, da wird nur Text (Richtung und Straße) angezeigt, bestimmt besser deuten. Noch hoffe ich das ich für die oberen 2 Zeilen das nicht brauche und für das staying alive nur den Teil von 6C0 und ....6C5 brauche.
Wie würde ich sagen, es bleibt spannend.
Gruß
Schorsch
Hallo Kai,
ich hab mir das Protokol mal angesehen und nach anfänglichen Fragezeichen komme ich langsam dahinter, da brauch ich aber noch was Zeit.
Aktuell, nach Anschlußversuch im Auto, plagt mich aber ein anders Problem. Auf dem Labortisch gingen beide CAN Linien mit den 120 Ohm Abschlußwiderständen usw usw perfekt in beide Richtungen.... aber im Auto habe ich da ein Problem. Den CAN Anschluß am Radio habe ich aufgetrennt und da meine Schaltung eingesetzt. (Alles fein säuberlich mit einem extra Quad-Lock Stecker - Kupplung). Die Frames gehen auch von CAN0 (vom Auto) durch die Schaltung zu CAN1 (Radio/Navi) durch. Über die RS232 kann ich genau sehen welche Frames durch laufen. Allerdings gibt das Radio schon nach kurzem keine Antwort mehr. Auch wenn ich einen zusätzlichen 120 Ohm Widersatnd einsetze ändert sich nichts. Liegt das schon an der Sequenzierung oder brauche ich aufgrund der Sterntopologie eine Zusatzbeschaltung (1K gegen +5V und Masse) ????? wie bei dem Audioplayer von Martinsuniverse, anbei Schaltungsausschnitt.
Hast du eine Tipp, oder wie sieht das der Anschluß im A6 aus. ??????
Ich bin da echt ratlos..........
Gruß
Schorsch
Welche CAN Transceiver hast du verwendet?
Hallo Schorsch,
die nummerierten Botschaften betreffen dich nur, wenn du den mittleren Teil des Displays beschreiben willst. Bei den beiden oberen Zeilen gibt es keine Nummerierung, einfach fleißig senden.
VAG-Steuergeräte verwenden auch gern mal 60 Ohm als Abschlusswiderstand. Bei Sternverkabelung ergibt das wohl halbwegs passend wieder die bekannten 120 Ohm.
Viele Grüße,
Sven