Gibt es keine Stelle, wo man an Stelle eines vorhandenen Stopfens einen Fühler einbauen kann?

gruss kai

also anscheinend gibts diese Pt100-Sensoren auch mit Schraubgewinde:

https://www.reichelt.de/?ARTICLE=151264 ... Gwod44MJsQ

Wenn man so ein Ding als M16 irgendwo findet, könnte man direkt das Gewinde von der Ölablass-Schraube nehmen um einen Öltemperatur-Fühler zu platzieren...

Adapter M8 auf M12x1,5 drauf und statt der vorhandenen Sensoren verbauen.

Gibt wohl Pt1000-Sensoren mit M12-Gewinde:

http://www.motorsensor.de/html/temperaturfuhler.html


Man könnte natürlich auch diese Sensoren anstatt der werksseitigen Öl- und Wassertemperatur-Sensoren reinschrauben. Damit misst man dann mit dem Mikrocontroller die genaue Temperatur, und simuliert auf der anderen Seite per PWM Spannungs- und Widerstandswerte für Motorsteuergerät und Öltemp-Anzeige die denen der werksseitigen Sensoren entsprechen.

Risiko dabei ist nur, was macht man wenn der Bordcomputer ne Fehlfunktion hat. Bei der Öltemperatur ist das ja bei MEMS1.9 nicht tragisch, weil der Öltemp-Sensor eh nur an die Temperaturanzeige und die Öltemp-Warnleuchte angeschlossen ist. Aber hat das Steuergerät einen Notlauf-Modus für den Fall dass der Kühlwassersensor kein Signal liefert?

So rein vom Design-Konzept her soll der Bordcomputer eigentlich komplett nicht-invasiv ausgelegt sein. Das heißt, dass er die Motorelektronik in keiner Weise beeinflusst, und dass ein Problem im Bordcomputer keine weiterführenden Probleme am Auto verursacht.

Wir haben doch zwei Sensoren für die Kühlmitteltemperatur, Anzeige und ECU sind getrennt. Nimmst natürlich den von der Anzeige.

so wie das jetzt klingt wird es immer wilder und sicher nichts was mal jemand anders einfach so bei sich reinbauen kann...

Klappt wunderbar, hab dort meinen Sensor von raid drin .

Nun, wir sind hier bislang immer noch in der Forschungs- und Entwicklungsphase. Da ist es normal, dass Teil-Lösungen für bestimmte Probleme diskutiert, verfeinert und mitunter auch wieder verworfen werden. Nicht ohne Grund hab ich das als ein "Langzeit-Projekt" tituliert. Es fließt eine Menge Arbeit in das Projekt genau deswegen, damit am Ende alles relativ einfach zu bauen und anzuschließen ist. Und dabei noch einigermaßen genaue Werte liefert.

Was jetzt konkret die Frage der Öl- und Kühlwasser-Sensoren angeht: auch hier muss man sich halt Gedanken machen, wie man es so hinbekommt dass die Genauigkeit der Messungen auch einigermaßen hinhaut. Wenn dieser Teil des Projekts fertig ist, dann wird es so oder so darauf hinauslaufen, dass man einfach ein paar Strippen richtig verkabeln muss. Und das wirst du ja noch können


Hier hat übrigens schon mal wer eine MC-Schaltung mit nem Pt1000 gebaut... das könnte man direkt so übernehmen:

https://openenergymonitor.org/emon/buil ... re-sensing

> Hier hat übrigens schon mal wer eine MC-Schaltung mit nem Pt1000 gebaut... das könnte man direkt so übernehmen

Der wird bei 3D-Druckern durchaus benutzt, und unter anderem im Marlin Projekt dann auch ausgewertet. Da sind auch Werte Tafeln zu finden. Aber leider ist jeder Sensor anders....

Evtl. ist solch ein Arduino für das Projekt hier ganz gut geeignet. Zum einem einfach zu programmieren (kein Flasher notwendig), PWM, digital und analog IO, als 3D board nicht teuer aber bereits mit Spannungsstabilisator, 24V Verträglichkeit, MOS-FETs, Displays etc. bestückt.

gruss kai

Ja, ich benutze für das Projekt bereits die Arduino-Platform.

Ich habe zwei Arduino Uno R3-Boards, mit denen ich das meiste an Programmierung mache. Dazu noch ein zwei Serial-Programmer-Module die ich ebenfalls mit Arduino betreibe.

Die Mikrocontroller werden am Ende aber als Standalones auf Lochrasterplatinen verlötet. Dadurch lassen sich die Schaltungen die ich vorhabe besser und platzsparender realisieren. Man kann dann alles einfach in kleine Modulgehäuse mit D-SUB-Anschluss bauen (bin allerdings im Moment auf der Suche nach einem Anbieter dieser neueren HD-Stecker mit Bügelverschluss, die z.B. auch bei Audi und VW verbaut werden. Wenn da wer näheres weiß wo man sowas kriegt, dann wär das mal ganz interessant). Jedenfalls, auf den Lochrasterplatinen wird dann z.B. auch ein Spannungsregler verbaut, ich nehme dafür in der Regel Recom R78E5.0-Regler. Transienten und Überspannungen, besonders wichtig im Auto, werden abgefangen mit Induktivitäten und TVS-Dioden.

Das schöne an Arduino ist halt, dass es dafür jede Menge Ressourcen und kostenlose fertige Libraries gibt. Und programmiert wird in einem vereinfachten, aber sehr flexiblen C++ Dialekt in der Arduino-IDE.

Falls von euch wer sich auch mal mit physical computing beschäftigen möchte, dann ist das echt zu empfehlen... macht ne Menge Spass... man kan mit Arduino einfach nur LEDs blinken lassen, aber man kann auch sehr viel komplexere Projekte verwirklichen, wie halt zum Beispiel einen Bordcomputer

Extrem cool, was Du da zauberst, Gerrit !

Sachma, wieviele Temperatursensoren kann man denn implementieren ?

1. will ich schon generell auch einen haben

2. waers ganz gut zu wissen, mit welchen Temperaturen man bei mir im Motorraum an signifikanten Stellen rechnen darf ...

Bevor die Bude mir wegschmilzt ...

äh, also wieviele Temperatursensoren kann man da implementieren... hm... da hab ich irgendwie noch nicht drüber nachgedacht...

Bei meinem Projekt sind vier geplant. Öl, Kühlwasser, Innenraum- und Außentemperatur. Motorraum-Temperatur könnte man machen, aber bei einem nicht-modifizierten MGF wird die Wahrscheinlichkeit eher sehr gering sein, dass im Motorraum gefährlich hohe Temperaturen herrschen. Immerhin fahren wir alle nen MGF und keinen Audi R8...

Aber solange wie du noch nicht weißt ob die Kühlung für deinen Turbo ausreichen wird, würde ich vielleicht in der Tat einen Temperatursensor verbauen... nur so zur Sicherheit. Wenn du einen Abgasturbolader richtig trittst, dann kann er je nachdem Temperaturen von über 800 bis 900 °C erreichen. Denk also in jedem Fall an gute Belüftung im Motorraum. Bei dir kommt durch den Heckmotor auch noch dazu, dass der Turbolader schwieriger durch Fahrtwind kühlbar ist, zumal besonders beim MGF die seitlichen Lufteinlässe so gut wie nix vom Fahrtwind tatsächlich in den Motorraum leiten. Beim TF hat man das ein wenig besser hinbekommen, nachdem was man so hört.

Ich würde ausserdem mal darüber nachdenken, vielleicht ein paar Luftleitbleche zu bauen, die zusätzlich Fahrtwind von der Unterseite des Autos an den Turbolader leiten.

Mit so einem Temperatursensor könntest du jedenfalls zumindest schlimmeres verhindern... möglicherweise auch, dass dein Motorraum hinten in Flammen aufgeht... Andererseits, es könnte ne Weile dauern, bis irgendwas um den Turbolader herum derart Feuer fängt dass die Temperatur auf 1000°C oder so steigt.

Aber Spass beiseite, erinner mich mal dran im Sommer, wenn ich bei meinem Projekt hier hoffentlich aus dem gröbsten raus bin... wenn man "nur" eine Turbolader-Temperaturanzeige haben will, dann ist das an ein paar Wochenenden fertig entwickelt und zusammengelötet. Da könnte man dann ein kleines Display ins Armaturenbrett machen das die Lader-Temperatur anzeigt.

Hm... eigentlich könnte man dann auch gleichzeitig ne Ladedruck-Anzeige implementieren... wenn man dahinten am Lader schon mal Kabel verlegt...

Evtl. solltest Du die Temperatursensoren nicht einzeln anschliessen, sondern einen i2c / 1-wire bus nutzen. Dann ist es egal, ob Du 2 oder 20 Sensoren hast (ach ja, Außenluft wäre schoen, wg. frost{gefahr|schutz}).

i2c z.Bs. DS1631:
Messbereich -55°C to +125°C
Genauigkeit +-0,5°C

1-wire z.Bs. DS18B20:
Silikonkabel

oder LK-Temp2

Das ist zwar deutlich teurer als ein Pt1000, aber es braucht kein lookup mehr und auch keine Probemessung.

Dazu geht es dann auch als bus.

BTW, was ist denn mit CAN-Bus?

Ich mein' im Auto gibt es echt fiese Störsignale, da sollten CAN-Bus Bauteile bereits gegen gefeit sein. Und evtl. kann man einfach etwas vom Golf oder so nehmen, das sollte dann bezahlbar und KfZ-tauglich sein.

gruss kai

Also die DS18B20-Sensoren die ich für Innen- und Außentemperatur nehmen wollte, die sind per OneWire-Bus angeschlossen. Das klappt mit zwei Sensoren ganz gut hier bei meinem Prototyp.

Für Innenraum und außen dürften die DS18B20 ausreichend sein von der Genauigkeit. Kümmert ja keinen, ob man nun real vierzehn oder fünfzehn Grad Celsius hat... außerdem hab ich schon fünf Stück davon hier liegen die ich aus China bestellt hab, also werd ich die auch verwenden



Der Bordcomputer wird ja modular aufgebaut sein, und übertragen werden die Signale per I2C. Die I2C-Leitungen werden mit 4,7-Kiloohm-Pullup-Widerständen auf 5 Volt stabilisiert. Allein das sollte schon ein wenig Ruhe reinbringen, und sollte genug sein um Kabelstrecken von fünf Metern und mehr zu ermöglichen. Die 5 Volt werden außerdem konstant gehalten von Recom R78E5-Spannungsreglern, von denen jedes Modul seinen eigenen hat. Die sollen eigentlich einigermaßen gut mit Spannungsschwankungen im Bordnetz umgehen können.

I2C und CAN sind ja im Grunde beides serielle Protokolle. Ob man nun mit I2C oder CAN ein paar Bytes hin und her schiebt ist für diesen Zweck hier eigentlich nicht so wichtig. Wir haben ja ein Bordcomputer-Hauptmodul als Master, und eine Handvoll Module die als Slaves arbeiten. Der Master requestet nur Daten von den Slaves (nach momentanem Stand insgesamt 27 Bytes), die dann im Hauptmodul für alle möglichen Berechnungen und Service-Meldungen genutzt werden. Dafür reicht I2C aus. I2C wird zudem direkt von den Atmel-Mikrocontrollern unterstützt die ich verwende. Für CAN bräuchte man einiges an zusätzlicher Hardware. Das macht es komplizierter und teurer.

I2C ist tatsächlich etwas störungsanfälliger, vor allem weil halt alles davon abhängt dass die Module auf eine Systemuhr ("system clock") synchronisiert sind. Diese system clock ist ein Rechtecksignal, das auf allen beteiligten Masters und Slaves synchron laufen muss. Aber so weit ich weiß, macht es auch nix, wenn zwischendurch mal eines der Module "aus dem Tritt kommt" durch Störsignale, weil es sich dann sofort wieder selbsttätig mit der system clock der anderen Module synchronisiert.

Ich dachte eher an Spannungspitzen, die aus dem Bordnetz kommen. Also schön viele Ableiterdioden einbauen....

Ich habe da schon böse Erfahrungen gemacht, aber da ging es immer nur um ein paar Euros, nicht um solch ein komplexes Projekt.

gruss kai

ach so, ja... Ja, da hab ich versucht ein bisschen dran zu denken.

Hier mal ein Ausschnitt aus einer meiner Schaltskizzen:



Der Spannungsregler wird von sich aus schon die Spannung einigermaßen konstant auf 5V halten und kann bis zu 28V vertragen. Trotzdem wird halt durch ne Drossel in Verbindung mit ner TVS-Diode und ner 1.5A-Sicherung gewährleistet, dass Spannungsspitzen rausgefiltert und dauerhafte Überspannungen abgefangen werden. Denn so richtig gesund ist das für den Spannungsregler ja auf Dauer auch nicht. Die Sperrdiode soll zusätzlich vor inversen Spannungen schützen.

Nachdem dieses Projekt ja schon längere Zeit "auf Eis" lag (ich hatte einfach zuviel anderes um die Ohren), werde ich nun die begonnene warme Jahreszeit nutzen um wieder etwas intensiver an der Sache zu arbeiten.


Der nächste Schritt wird sein, kleinere Mikrocontroller in den peripheren Messmodulen. Im Motordaten-Messmodul und dem Komfortmodul sind bisher je ein Atmega328P-PU mit 28 Pins vorgesehen. Damit haben wir aber in beiden Modulen einiges an Pins über, die nicht gebraucht werden. Außerdem ist der Code in diesen Modulen eher überschaubar, da sie wenig mehr tun als Dinge zu messen und die Messdaten an das Hauptmodul weiterzugeben. Dazu braucht man keine 32 KB Speicher. Als Alternative kommt der Atmel Attiny 84 in Betracht. Nur 14 Pins, damit halb so groß wie der Atmega328 (was auch bedeutet, dass ein fertig gebautes Modul kleiner wäre). Und wird die Aufgaben mit 8 KB Speicher genauso bewältigen können. Auf ein externes Quartz, mit welchem man die Taktfrequenz auf bis zu 20 MHz steigern könnte, kann man eigentlich auch verzichten. Auch dadurch spart man halt wieder zwei Pins ein. Einiges an den Messdaten die erhoben werden ist zwar "zeitkritisch", aber dann auch wieder nicht so sehr, dass man mit 8 MHz interner Taktfrequenz nicht hinhauen würde.

Noch nicht ganz sicher bin ich mir aber bei dem sehr schnellen Kurbelwellen-Signal, welches ja ohnehin schon von einem eigenen kleinen Mikrocontroller gemessen wird, der nix anderes tut (ein Atmel Attiny 45)... diese Atmel-Mikrocontroller brauchen zwar nur ein bis zwei Takte pro Befehl, was theoretisch zu einer Auflösung von bis zu 0,125 Mikrosekunden bei 8 MHz führt. Aber praktisch gesehen könnten sich leichte Mess-Ungenauigkeiten ergeben, wenn man eine einigermaßen genaue Motordrehzahl ermitteln will.

Hier mal ein Bild vom Kurbelwellen-Signal beim MGF 1.8i bei 3000/min:



Wie man sieht, ist ein Puls der Kurbelwelle bei 3000/min ca. 0,2 Millisekunden, d.h. 200 Mikrosekunden lang. Und dann halt 100 Mikrosekunden bei 6000/min. Da könnte man mit 8 MHz Taktfrequenz schon an Grenzen stoßen, wenn es darum geht, konstant einen genauen Messwert zu ermitteln, bei dem es dann um die Frage gehen könnte, war der Puls jetzt 187 oder 212 Mikrosekunden lang. Zumal der Chip ja auch noch die ganzen anderen Befehle nebenher abarbeiten muss die im Quellcode stehen. Mit einer Taktfrequenz von 20 MHz über ein externes Quartz hätte man immerhin um den Faktor 2,5 etwas mehr "Luft". Zumal ja auch noch ständig der Mikrocontroller des Haupt-Moduls per Datenleitung "anklopft" und fragt "Was sind deine neuesten Drehzahl-Daten?".

Da ansonsten die Baupläne für die Module mehr oder weniger feststehen, werde ich dann bald tatsächlich mal einen Prototyp des Motordaten-Messmoduls auf einer Lochrasterplatine zusammen löten und im Wagen anschließen. Aber bis dahin werd ich noch ein wenig an ein paar Details feilen müssen.

Hat der tiny keinen Frequenzeingang? Ansonsten Frequenz nach Spannung und Spannung messen, dafür gibt es fertige Bauteile.

gruss kai

Hab mich dazu heute abend nochmal ein wenig schlau gemacht.

Man kann die Frequenz eines Input-Signals beim Attiny über den eingebauten Timer messen, ja. Ist möglicherweise sogar schneller als mein bisheriger Code, in dem ich das über pin change interrupts mache (Stichwort Latenzzeiten).

Wenn meine Oszi-Messungen stimmen, dann hat das Kurbelwellen-Signal bei 7000 U/min eine Frequenz von um die 5,3 MHz. Der eingebaute Timer des Attiny kommt allerdings nur mit Input-Signalen klar, die die Hälfte der Mikrocontroller-Taktfrequenz betragen. Also komme ich so oder so nicht mit den 8 MHz hin, auf denen der Attiny maximal ohne externes Quartz laufen kann. Ein externes 16 MHz-Quartz wird dann wahrscheinlich reichen.

EDIT: Hupps, hab mich um drei Stellen vertan... das Signal hat 5,3 KILOhertz... nicht Megahertz... ...also reicht 8 MHz Taktfrequenz wohl doch aus. Wenn die Latenzzeiten kurz genug sind bei der Messung über den Timer.