Statt einer "Deckel Auf" Warnung würde ich eine "Sprit fast Leer" Warnung für Sinnvoller halten .
Ob das Dach auf oder zu ist sieht man und ob`s verriegelt ist dafür braucht doch keiner ein Lämpchen . Aber wenn der Sprit zur Neige geht , dafür gibts nichts .Ausser der recht grob geschnitzte Zeiger .

Ne Sprit-Warnung ist ja tatsächlich schon geplant. Laut meiner Skizze zum Motordaten-Modul wird ja der Tankgeber mit ausgelesen (bei OBDII hätte man den Tank-Füllstand sogar direkt über K-Leitung), und das soll zum einen dazu dienen eine Rest-Reichweite mit der gegebenen Tankfüllung zu kalkulieren, und zum anderen dazu, bei niedrigem Sprit ne Warnmeldung rauszugeben.

Problem ist halt, dass der Tank beim F/TF nicht gerade die ideale Form hat für sowas. Und dass deshalb der Tankgeber-Stand stark schwankt bei halbvollem Tank und darunter. Aber das muss man halt einfach hinnehmen.

Hab jetzt die Verdeck-Kontrolle mal in ein eigenes Modul ausgelagert... hat den Vorteil, dass man sie wirklich "optional" machen kann, und außerdem werden hinten im Wagen eh schon Datenbus-Kabel liegen (für das Motordatenmodul vom MkI und die hintere Lampenkontrolle), also soll man die auch ruhig benutzen, anstatt dass man extra Strippen nach vorn zum Komfortmodul zieht.

Das könnte dann in etwa so aussehen:



Und hier mal zwei Übersichts-Bilder, wie ich mir die einzelnen Teile des Bordcomputers vorstelle beim MkI und beim MkII/TF:

MGF MkI:




MGF MkII / TF:



Durch diesen streng modularen Aufbau wo die einzelnen Module über Datenbus miteinander verbunden sind, wäre es im übrigen auch denkbar, dass man am Ende nicht alles nachrüstet. Vielleicht weil man wirklich nur die OBDII-Daten haben will, oder halt eben keinen Wert auf die Verdeckkontrolle legt.

wofür braucht man bei einem MGF eine Innen und Außentemperatur ?
bei mir ist die immer gleich

Außentemperatur kann echt hilfreich sein wenn's draußen anfängt zu frösteln. Gerade bei der etwas zickigen Straßenlage des MGF/TF auf glattem Untergrund.

Den Temperaturgeber werd ich in den Kühlergrill machen. Somit weiß ich immer in etwa, wie die Temperatur in Bodennähe ist. Die meisten moderneren Autos haben die Außentemperatur-Sensoren auch vorn unten im Kühlergrill.

Und ich finds davon abgesehen einfach ganz komfortabel, zu wissen wieviel Grad draußen sind

Naja Innentemperatur... sagen wir mal so: diese DS18B20 Temperatursensoren gibt's billiger wenn ich fünf Stück kaufe, also warum soll man die nicht überall hinpappen...

Und ich hab Klimaanlage bei meinem MGF, also kanns durchaus nachts kälter als draußen sein

Das ganze heißt ja Komfortmodul. Das sind Komfort-Funktionen, von denen man die meisten nicht wirklich braucht, aber ich finds einfach neckisch sie zu haben. Zumal die technische Umsetzung gerade bei diesen digitalen Temperatursensoren super einfach ist, sie geben direkt eine Temperatur in °C an den Mikrocontroller weiter, die ich dann einfach nur noch auf dem TFT-Bildschirm ausgeben muss.

Hoffentlich erbarmt sich bald jemand und macht das Ding endlich zu,
man kann dieses Hickhack über den Elektronikscheiß nicht mehr lesen,
zu einem englischen Roadster passt das einfach nicht .
Ich liebe meinen F so wie er ist, basta!

Und wer zwingt Dich das ganze dann zu lesen?

Ich kann da auch nicht viel mit anfangen, aber ich hab durchaus Respekt vor dem Enthusiasmus mit dem der Kollege hier zu Werke geht!
Und da finde ich solche Worte dann doch sehr respektlos und überflüssig.

@MG 850:

You are not being very British at all, old chap

da kannst ja lieber einen in den Motorraum machen und den Lüfter über deine Schaltung statt über den Sensor im Motorraum steuern...

Dann schau dir doch mal die Modifikationen an, die manche Leute vor allem in England (und nicht nur dort!) an ihren MGFs machen. Da ist alles dabei, von Hello Kitty-Look bis hin zu stock car-Racer. Willst du dich bei denen auch hinstellen und sagen, was ihr Engländer da an euren MGs macht passt nicht zu einem englischen Roadster?

*kopfschüttel*

Also ich würde die Sitzflächentemperatur messen


Sorry, aber das musste gerade sein Ist nicht bös oder herabwürdigend gemeint.

Hab mich am Wochenende mal ein wenig näher in das Thema "OBDII" eingelesen...

Es besteht vielleicht doch Hoffnung, dass man auch beim MGF MkI Daten über K-Line vom OBD-Diagnosestecker bekommen kann. Bin da noch nicht ganz sicher.

Ich werde wohl jetzt demnächst erstmal ein OBDII-Motordaten-Modul bauen (für den MGf MkII von Thorsten werden wir das eh brauchen), und dann mal schauen ob ich damit auch Daten aus meinem Wagen anzapfen kann.

Der Aufbau eines solchen OBDII-Moduls ist wirklich sehr einfach:



Und für den Atmega-Controller in dem Modul gibts halt wie gesagt eine fertige OBDII-Software-Library, mit der man - zumindest bei OBDII - die Daten ruckzuck ausgelesen bekommt.

Sollte das auch beim MkI klappen, dann könnte sich der Entwiclungsaufwand für ein Motordaten-Modul drastisch reduzieren. Dann würde man insbesondere nicht das Einspritzsignal und den Kurbelwellensensor am Motorsteuergerät anzapfen müssen.

Den elektronischen Geschwindigkeits-Geber den ich verbaut hab werde ich aber vermutlich trotzdem versuchen zum laufen zu bringen. Denn dadurch erhöht sich die Genauigkeit irgendwelcher Verbrauchs-Berechnungen deutlich.

Ich hab mal ein bisschen gesucht und zwei wirklich interessante Seiten zum Thema MEMS Protokoll gefunden:
http://alum.wpi.edu/~colinb/rover-mems- ... tocol.html
http://memsdiag.blogspot.de/
https://github.com/colinbourassa/memsgauge

Anscheinend ist da einiges schon erfolgreich analysiert worden.

peter

das ist natürlich klasse... danke...

Laut der "Electrical Library" von MG (vor MJ 2001) verwendet der Diagnoseanschluss eine K-Leitung nach dem Protokoll-Standard ISO9141. Das ist schon mal sehr gut, denn ISO9141 deutet eigentlich auf OBDII hin:




Was ich im Moment sehe, ist dass es Probleme geben könnte bei den PIDs. PID heißt Parameter Identifier, und diese PIDs haben ein hexadezimales Format. Diagnose unter OBDII funktioniert normalerweise so, dass das Diagnose-Gerät über die K-Leitung Daten anfordert indem es eine OBDII-spezifische PID sendet für die ein Wert erbeten wird. Diese PIDs sind bei jedem Auto mit OBDII gleich. Das sind zum Beispiel 0x05 für die Kühlwassertemperatur und 0x0c für die Motordrehzahl. Und dann wird dasjenige angeschlossene Gerät innerhalb des K-Leitungs-Bus das für diese PID zuständig ist den wert zurückschicken, den diese PID gerade hat. Meinetwegen PID 0x05 = 80 oder 0x0c = 2354.

Bei OBDI, zumindest bei MEMS1.6, scheint es so zu sein dass diese PIDs anders belegt sind. Kühlwasser ist auf der PID 0x03, und die Motordrehzahl auf 0x01.

Sollte das bei MEMS1.9 nicht mehr der Fall sein und die PIDs sind so wie bei OBDII, dann sind die Chancen besser, dass man was brauchbares beim MGF MkI auslesen kann.

Ich werde für das OBDII-Modul diese Arduino-Library verwenden:

https://github.com/stanleyhuangyc/Ardui ... raries/OBD

Und laut der Datei OBD.h in dem Ordner sind folgende PIDs damit abfragbar:



Die unterstützten Protokolle sind:



Jetzt ist halt die Frage, ob ISO9141 und ISO9141-2 zueinander kompatibel sind.

Aber der nächste Schritt wird erstmal sein, ein OBDII-Modul zu bauen. Hab heute die Teile bestellt, werd mich wohl am Wochenende dran machen.

Hallo MGF74,

endlich finde ich Zeit auch mal zu posten.

Tolles Projekt, was mir persönlich gefällt,ist die Lampenkontrolle von Audi.

zum OBD-Gedöns:
schon lange her als ich ein Testbook an meinem TF dran hatte.
Das Testbook verwendet verschiedene Adapterstücke zwischen dem dicken und langen Kabel und der OBD-Buchse, diese haben verschiedene Belegungen, je nach am Testbook aufgerufener Funktion, wird man aufgefordert das blaue, gelbe, grüne ... Adapterkabel zu verwenden.
vielleicht hilft der Hinweis in irgendeiner Form.
Hier mal 2 von x der Adapterkabel zur Darstellung, Bilder sind zwar unscharf, aber dafür ist Hintergrund scharf.

Interessant... sieht irgendwie so aus als wäre Pin 7 da garnicht drauf belegt, auf den Adapterkabeln... nachdem was ich bisher rausgefunden hab, müsste auf Pin 7 eigentlich die K-Leitung sein... *grübel*

Hab grad nochmal das hier durchgelesen:

https://www.obd-2.de/obd-2-faq/53-welch ... okoll.html

Zeit zum Editieren ist abgelaufen, dann als seperates Posting.

ebenso halte ich den Frostwarner für sinnvoll.

...und vielleicht etwas zu weit gegriffen:
Fehlermeldung als Sprachausgabe. Müsste vermutlich über Audio-Speicher-Modul realisierbar sein,
z.B. http://www.elv.de/mp3-sound-modul-msm-2 ... AhiH8P8HAQ
gabs auch mal vom Conrad, finde ich gerade nicht.
Ohne jetzt nachzuschauen wieviele D-Ausgänge die Bausteine haben, über einfache MUX-Schaltungen würde man sich bei mehreren Meldungen einige digitale Ausgänge sparen.
Warum ich auf die Idee kam: fuhr die letzten Monate oft Audi A3 8P und Passat 3C5, überall nur Gepiepse für irgendetwas, und man musste während der Fahrt dann in den Displays suchen, was die Kiste einem eigentlich "sagen" will, z.B. "Lampe defekt", "Kühlwasserstand", "Wassertemperatur". So nebenbei: früher war das einfacher, das gabs einfach eine Glühbirne an der Tank- oder Temperaturanzeige...

... und noch weiterer ausgeholt, und somit eigentlich schon off-topic:
da ja schon Temperatursensoren angesprochen wurden.
Jeden Winter, jeden Morgen, Umluft an, Klima an. Die Klima scheidet ja Feuchtigkeit ab ( und verteilt sie unter dem Beifahrerteppich ), so sind die Fenster schneller beschlagfrei. Wäre dann die Abfrage: draußen kalt, drinnen kalt -> Umluft und Klima an.

zurück zur Realität:
da ja die Heatresistors so ab und zu das Zeitliche segnen, vielleicht hat schon jemand mal eine PWM-Steuerung realisiert. Wäre auch eine sinnvolle "Erweiterung", bzw. würde dem Ausspruch "der Besitzer muss das Auto vollends fertig bauen" nahe kommen.

Nachtrag:
gerade Dein posting bzgl. PIN 7 gesehen.
Hier noch Bilder der anderen Adapter, ich weiß aber nicht ob ich damals die kompette Adapter-Auswahl fotografiert habe, ich denke aber ja.

Also es gibt ein MP3-Modul für Arduino, das man verwenden könnte:

http://www.ebay.de/itm/Micro-SD-TF-U-Di ... SwEetWASZ1

Damit könnte man in der Tat auch Sprachmeldungen als MP3-Dateien verwenden. Aber das ist erstmal nicht "Entwicklungsziel"... wenn der Bordcomputer so langsam fertig ist, kann man sich immer noch Gedanken machen ob man statt Pieptönen lieber Sprachmeldungen hat. Oder vielleicht ja einfach nen "Gong" oder so.

Ich hab in meinem Audi A4 B5 das "große FIS" drin, was auch jede Menge Pieptöne von sich geben kann für alles mögliche von Warnmeldungen. Mich störts aber nicht. Es piept ja tatsächlich nur wenn was nicht in Ordnung ist

Momentan ist erstmal nur geplant, für akustische Signale ganz einfach einen 15 Millimeter Mini-Lautsprecher auf der Platine des Head Unit-Moduls zu verbauen:

https://www.conrad.de/de/miniaturlautsp ... 10277.html

Für Pieptöne sind die Dinger völlig ausreichend, hab so einen schon in nem anderen Projekt verbaut. Und sie können direkt über den Microcontroller angesteuert werden mit ner ganz einfachen Transistor-Schaltung.

Was die ganzen Temperaturen angeht - man könnte dafür eine eigene Menüseite machen im Head Unit-Modul... so wie ich's neulich schon mal ein wenig "gebastelt" habe für die Sprit-Daten:



Wobei ich nicht glaube, dass die Motorraum-Temperatur einen wirklichen Nutzen darstellt. Zumal sie ja vom Motorraum-Lüfter für gewöhnlich immer in einem akzeptablen Bereich gehalten wird.

Anderes Thema - Wegen OBDII und so muss ich halt einfach abwarten, ob ich mit meinem selbst gebauten OBDII-Modul in die Diagnose reinkomme bei meinem Wagen. Und welche Daten ich damit bekomme. Ich werd ja nur erstmal provisorisch einzelne Pins verbinden, und da muss ich halt einfach vorher auf der Rückseite der OBD-Buchse schauen, an welchem Pin das rosa Kabel angeschlossen ist. Unabhängig von der Pin-Belegung scheint das rosa Kabel immer K-Line zu sein.

EDIT: Hab jetzt ENDLICH den Atmega1284P-PU Controller zum laufen bekommen. Der wird das "Herzstück" der Head Unit sein, und er wird sowohl die Daten von den umliegenden Modulen abrufen als auch sie auf dem TFT-Display ausgeben.



War etwas knifflig...

Was weitere "technische Spielereien" angeht... wenn der Bordcomputer erst einmal komplett fertig ist... und auch ERST DANN... dann könnte man überlegen, ob man neben den ganzen Mess-Daten die man für das TFT-Display errechnet auch die ganzen OBDII-PIDs per Bluetooth an ein angeschlossenes Smartphone sendet, auf dem dann mit einer App alle Daten schön anschaulich dargestellt werden. Es gibt für die Arduino-Entwicklungsumgebung mit der ich arbeite Bluetooth-Libraries und spezielle Bluetooth-Sendemodule, mit denen man sowas realisieren könnte.

Klar gibt es für sowas schon Bluetooth-Steckeradapter für die OBDII-Buchse zu kaufen, die man mit seinem Smartphone und ner dazugehörigen App verbinden kann. Aber so ein System wie meins hätte dann den Vorteil, dass man direkt ohne was einstöpseln zu müssen die Daten hätte.

Und man könnte das in ein komplett eigenes Modul auslagern, sodass es einfach nur an die im Auto bereits verbaute Bordcomputer-Elektronik über den I2C-Datenbus angeschlossen wird.

Das ist aber absolute Zukunftsmusik. Das würde schätzungsweise nochmal ein weiteres Vierteljahr Entwicklungsarbeit bedeuten, noch obendrauf auf die Deadline von nächstem Frühjahr/Sommer, die ich mir ohnehin jetzt schon gesetzt hab.

Nichtsdestotrotz - wäre mal interessant ob von euch wer Erfahrung hat mit der Programmierung von Android-Apps... hab da nämlich (bislang) keine Ahnung von... wie schwierig ist es, per Bluetooth empfangene Daten in einer App aufzubereiten und mit ein paar grafischen Symbolen und Animationen anzuhübschen?

Sollte nicht allzu schwierig sein. Über einen entsprechenden Socket kann man den InputStream lesen. Wobei "schwierig" schwierig zu definieren ist :-)

Hier mal ein Developer Link zum Blauzahn:

https://developer.android.com/guide/top ... tooth.html