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
Ja, ich meine mich auch zu erinnern, dass Clk/2 das maximum sind.
Die CAN Controller habe ich alle mit eigenen Quarzen versehen, so wie auch den ATMega.
8Mhz sollten es an der Stelle bei mir sein.
Wie gesagt, bei mir hören auch die Uhrzeitsignale ab einem bestimmten Punkt (nehme an wenn das KI in den Ruhezustand geht) auf.
Auf jeden Fall hat das mit dem Lauschen auf Messages funktioniert und der Controller geht in den Schlafzustand. (wie beschrieben)
Zum Einschalten könnt ihr doch das Zündungssignal (Klemme 15) nehmen, oder? Schneller als das Kombi fährt eure Schaltung allemal hoch.
Ausschalten wollt bzw. dürft ihr vermutlich nicht mit Kl15, richtig? Dann könntet ihr doch die Versorgungsspannung auf der Platine selbst abschalten. Grundprinzip: Ein Transistor/Relais gibt parallel zum normalen Anschluss an Klemme 15 auch Klemme 30 frei. Diesen Transistor schaltet ihr mit dem Controller ein und sollte Klemme 15 abgeschaltet werden, dann versorgt euch der alternative Weg weiter mit Spannung. Kommen dann keine Botschaften mehr, dann entzieht ihr euch einfach selbst den Saft.
Klemme 15 funktioniert definitiv nicht.
Das KI (jedenfalls im 4F) wacht schon mit der Betätigung der Funkfernbedienung für die Entriegelung auf.
(auch andere Systeme im Wagen)
Bis dann endlich mal der Zündschlüssel rumgedreht wird, ist die Kommunikation schon gestorben und kommt nicht mehr neu zustande.
Nene ... wenn, dann nur über CAN. Alles andere wäre in meinen Augen Pfusch.
Ach stimmt, ihr trennt ja den Bus auf. Klar, dann müsst ihr vor allen anderen wach sein. Wenn euer Baustein wake-up über CAN unterstützt, dann könnt ihr den Mikrocontroller schlafen legen. Aber das wisst ihr bestimmt selbst ;)
Hallo Kai, hallo Sven,
auch der A4 hat ohne Zündschlüssel ein Eigenleben. Selbst wenn er ohne Schlüssel da steht und nach ca. 2 Min in den Schlaf fällt reicht schon das Öffnen einer Tür oder Heckklappe, natürlich aus das Aufschließen per Funk....... Ich kämpfe noch mit mir ob ich die elegante Slepp Mode Variante oder die Relaisüberbrückung wählen soll - entschieden habe ich mich noch nicht. Obwohl die Relaisbrücke wahrscheinlich die einfachere Alternative ist da ich ja nur bei der Eigennutzung der 2 x 8 Zeichen die CAN-Brücke brauchen würde - mal sehen.
Ich denke ich werde morgen mal die Probe durchführen und für die Abschaltung testen und dann wird mir der CAN USB Adapter schon sagen wo der Auslöser ist - ich hoffe ich erkenne es auch.
Wenn die alle gleichzeitig aus dem Sleep Mode erwachen reicht das druch aus, denn einen Fehler im Stg gibt es erst wenn nicht nur ein Frame ausbleibt.
Achja ich habe die CAN Controller mit je 16MHz und den ATMega im Moment mit 19,6608 MHz bestückt.
Aber zugunsten des schnellen SPI könnte durchaus der ATMegatakt noch auf 16MHz schrumpfen - denn die Uart braucht im Betrieb eh keiner mehr.
So jetzt ist es schon wieder spät und ich muß morgen Sonntag arbeiten.......gute Nacht.
Gruß
Schorsch
Relais würde ich wenn icht verwenden.
FET(s) dürfte(n) deutlich schneller und Langzeitstabiler sein.
Ich hatte auch die ganze Zeit schonmal vor zusätzlich noch eine "Überbrückung" einzubauen.
Für eine komerzielle Lösung würde ich da auf jeden Fall was machen.
Für mich ist es auch so ok. Im Notfall weiss ich was zu tun ist ;)
Hallo Kai,
würde das mit FETs den überhaupt funktionieren können ?????? ich keine die sonst nur von empfindlichen Vorverstärkern. In diesem CAN BUS Fall müßten die ja einfach nur komplett durchschalten. Dann würdest du die Transceiver bestimmt auch von der Versorgung (+5V) trennen oder ??????
Die Relaislösung kam aus dem Audioplayer von Martinsuniverse und da scheint es keine Probleme zugeben, zumindest ließt man nichts davon.
Man kann sicher darüber philosopieren ob die Schaltung nötig wäre, denn wenn ich immer alle Frames durchschleuse obwohl nichts ausser den Daten des Radios angezeigt wird - wäre die Brücke eine Rückfallebene die bei einem Fehler der eigenen Schaltung diese vom CAN nimmt und quasi überbrückt.
Oder die Überbrückung ist immer dann offen wenn ich selbst was anzeigen will und wird bei einem Fehler oder Nichtgebrauch wieder passiv und damit geschlossen. Ist sicher auch davon abhängig ob und wie der Sleep Modus umzusetzen ist.
Bei deiner Tankanzeige kann ich mir durchaus vorstellen das man die wie die Benzintankuhr immer im Blick haben möchte quasi als Startbildschirm und sich dann für anderes machbares (Öltempe ect...)entscheidet. Ich möchte zur Zeit nur die Öltemp und im nächsten Schritt den Ladedruck anzeigen. Könnte zwar auch bedeuten das die 2 x 8 Zeichen nur noch das anzeigen und so quasi auch auf 100 Prozent Einschaltdauer kommen. Aber wenn die Überbrückung immer drin ist wenn das Auto abgeschaltet ist kann auch das Auto selbst die Sleep Phase bestimmen und arbeitet mit allen Teilnehmern des Normalbetriebes (Auslieferungszustand) also ohne Zusatzschaltung.
Also eine Einzellösung die der Schaltungsnutzung und Anwendungsdauer entsprechen sollte.
Zweiter Ansatz mit Relais wäre das auch noch ohne Ruhestrom zu realisieren. Wie würdest du die FETs einsetzen ???? DS Strecke in den CAN einschleifen ?????
Gruß
Schorsch
Ich weiß zwar nicht wie das beim A4 ist aber beim A6 gibt es zwischen dem Gateway Pin13 und dem Tacho Pin28 eine Wakeup Leitung, mit der könntest du dann deinen Bus Starten.
Ansonsten würde ich zum Trennen einen CD4066 nehmen, der kann Frequenzen bis 65MHz durchschalten
Ja, der CD4066 beinhaltet schaltungstechnisch genau so etwas, wie mir vorgeschwebt hat.
Noch besser, wenn es sowas schon gleich fertig gibt ;)
Danke, Sigi!
Hallo
das ist doch mal ein gutes Bauteil .........ich denke die 5 Ohm zwischen den Schaltkontakten sollte nicht zuviel sein allerdings braucht man dann bis zu 15V VDD.
Zitat:
Switch On-State Resistance Matched to
Within 5 ? Over 15-V Signal-Input Range
Bei 5V wie sie der µC ausgeben kann sind es schon 15 Ohm an den Kontakten und das kann für die CAN Strecke schon wieder zuviel sein. Natürlich kann man den Baustein auch per Transistor der an 12 - 13,5V (im Auto) liegt ansteueren der wiederrum durch den µC gesteuert wird. Das wären dann trotzdem ein paar Bauteile, denn einen Pulldown möchte der Baustein an den Eingängen auch haben um wieder sauber zutrennen. Aber für 32 Cent bei Reichelt ists ein Versuch wert -oder ???? und man hat keine Klick Geräusche von einem Relais.
Gruß
Schorsch
Hallo,
ich möchte noch mal kurz die Problematik mit den CAN-Pegeln und der Terminierung von TDISchorsch aufgreifen. Ich lasse mich ja gern eines besseren belehren, aber ich behaupte jetzt, dass Schorsch die falschen CAN-Transceiver benutzt und ich kann mir vorstellen, dass die Probleme auch daher rühren (auch wenn sie jetzt scheinbar nicht mehr auftreten).
Das Ding ist halt, dass der Infotainment-CAN ein Low-Speed-CAN ist (auch Fault Tolerant CAN genannt). Und dabei geht es nicht nur um die Transferraten, es geht auch um die Bus-Pegel, die sich unterscheiden (einfach mal googeln oder etwa im Selbststudienprogramm 269 von Audi nachsehen). Und der eingesetzte Transceiver MCP2551 ist nun mal ein High-Speed-Transceiver. Ein TJA1055T wäre eigentlich der richtige Baustein dafür.
Kai in seinem A6 hat das "Problem" nicht, da er ja auf dem "Kombi-CAN" zwischen FIS und Gateway arbeitet, den es zum einen im A4 (B6 und B7) gar nicht gibt und der zum anderen auch ein richtiger High-Speed-CAN mit 500k ist.
Just my 2 cents.
Grüße
Jens
Hallo,
könnte sein................................ehr nicht. Leider ist der Pegel auch so an den Klemmen des BNS 5 zumessen wenn nur das angesteckt ist. Der MCP kann alle Modi deshalb auch der unterschiedlich zuberechnede RS Widerstand.
Ich hab das Abbrechen der Kommunikation mit dem BNS 5 nur den Pegel zugeschoben, aber durch die Prints im der Software war nur der Datentransfer zu langsam und das BNS 5 hatte nur die Kommunikation eingestellt.
bei läuft es rund ........................
Gruß
Schorsch
Erstmal riesen Respekt an den TE und das sehr tiefgreifende Thema!!!
Ist schon enorm was alles moeglich ist..
Reicht da ein Elektrotechnik-Studium aus um erstmal mitreden und dann spaeter einsteigen zu koennen?
Ihr habt mich da sehr neugierig gemacht :)
Ich finde es total toll, dass heutzutage wieder mehr und mehr Leute sich mit Elektronik beschäftigen.
Das ganze wird aktuell ja auch wieder deutlich einfacher, da es so etwas wie einen Raspberry Pi gibt.
Wenn ich heute so etwas aufbauen wollte, dann würde ich definiiv keinen Atmel AtMega mehr verwenden, sondern einfach einen Raspberry Pi.
Diesen dann mit 2 CAN Bussen ausstatten und schon hat man eine extrem leistungsfähige Plattform.
Ok, bzgl. Stromsparen muss man sich noch etwas einfallen lassen.
Generell ist so ein Raspberry aber schon echt eine extrem nette Sache.
- Leistung satt
- Günstig in der Anschaffung (nicht ganz so günstig wie ein Atmel AtMega, aber am Ende nur unwesentlich teurer und dafür 100mal leistungsfähiger)
- Ein komplettes Multitasking-Betriebssystem
- Man steckt einen WLAN Stick rein und kann bequem über WLAN arbeiten/debuggen/entwickeln
Insbesondere der letzte Punkt ist eine extreme Arbeitserleichterung.
Dadurch, dass ein komplettes Linux drauf läuft, kann man viele Dinge gleichzeitig abdecken.
Studieren muss man dafür nicht.
Im Zeitalter des Internets kann man doch innerhalb kürzester Zeit so ziemlich alles lernen/machen.
Das ist die nächste wirklich absolut faszinierende Sache.
Klar, Zeit muss man aber natürlich immer investieren. Zugeflogen kommt nichts - auch wenn das manchmal so aussehen mag.
Hinter allem steckt Arbeit...
Wenn ich irgendwann eine LPG-Anlage fuer meinen Direkteinspritzer bekomme dann werde ich mich auch mit diesen Thema beschaeftigen :)
Ich haette ja gern die Vialle LPdi oder die Liquimax von Prins.. Nur leider kriege ich von allen Seiten eingefloest es geht nicht und irgendwie kann ich das nicht glauben :)
Wenns beim 3,2FSI geht muss es auch beim 5,2 FSI gehen sei es mit 2 Parallelsystemen fuer beide Baenke separat:)
Der FSI ist ja bekannt fuer seine Anfaelligkeiten im Kolbenbereich.. Aber wenn er hochgehen sollte dann tut er das auch im Benzinbetrieb..
Ich wuerde das Risiko auf jeden Fall eingehen weil ich diese Antriebsart als sehr zukunftsweisend ansehe im Gegensatz zum reinen Elektroantrieb und damit auch noch 50% billiger bis vielleicht 2018 fahren kann..