Mein Projekt soll sein, die Temperatur über einen speziellen Sensor in einen PIC (8 bit) einzulesen, und das Ergebnis auf einer dreistelligen LED-Anzeige auszugeben. Temp-Bereich wäre von 0°C bis 120°C, nur ganze Zahlen (keine Dez-Stellen). Die Genauigkeit ist weniger wichtig, 2 % wären schon gut, die Geschwindigkeit der Ausgabe auch nicht: Alle 10 sek reicht völlig aus. Der NTC-Sensor hat eine logarithmische Kennlinie, an diesem einen speziellen Typen geht kein Weg dran vorbei (nichts anderes möglich). Zu ihm habe ich das off. Firmendatenblatt, in welchem in einer Tabelle die Temp-Werte in 5°C-Schritten gelistet sind und die dazugehörigen Widerstandswerte. Es gibt aber keine Formel, auch keine Koeffizienten über Material o.Ä.. Das Prog soll in C erstellt werden. Ich bin da zwar noch Anfänger, möchte das Projekt aber schon vorbereiten. Selbst habe ich hier im Forum unter „Formeln“ gesucht, jedoch nichts gefunden, was mir wirklich hilft. Ein angeblich leicht zu bedienendes Formelprogramm namens „Kleine-Programme-der-Mathematik“ erweist sich als undurchschaubar. Es soll möglich sein, mit einem Office-Programm eine Formel zu erstellen. Habe das heute in OpenOfficeCalc versucht, es aber zu keinem Ergebnis gebracht (Das blöde Calc akzeptiert die neu installierte Java-Runtime nicht). Wer kann mir einen Weg aufzeigen, aus den Wertepaaren eine Formel zu erstellen, die eine 8-bit-MPU zur Umrechnung gebrauchen kann? Grüße, wilhelmT
:
Bearbeitet durch User
Be Ti schrieb: > Zu > ihm habe ich das off. Firmendatenblatt, in welchem in einer Tabelle die > Temp-Werte in 5°C-Schritten gelistet sind und die dazugehörigen > Widerstandswerte. Es gibt aber keine Formel, auch keine Koeffizienten > über Material o.Ä.. Wenn die Genauigkeit nicht so wichtig ist, kannst du doch einfach die Tabelle in den PIC klopfen und jeweils zwischen zwei Einträgen per Dreisatz interpolieren. > Habe das heute in OpenOfficeCalc versucht, es aber zu keinem Ergebnis > gebracht (Das blöde Calc findet die neu installierte Java-Runtime > nicht). Dann mußt du ihm vielleicht mal beibringen, wo die liegt ;-)
Hallo Wilhelm, Es geht auch mit einer Tabelle. http://sebulli.com/ntc/index.php?lang=de&points=32&unit=1&resolution=8+Bit&circuit=pulldown&resistor=10000&r25=10000&beta=3480&tmin=0&tmax=120
Als C-Anfänger kann ich weder das Eine - Formel selbst erstellen - , noch das Andere - eine Tabelle erstellen. Ich bin aber willens, beides zu lernen und werde es auch lernen. Zunächst möchte ich aber wirklich den Weg über eine Formel versuchen, das muss ja irgendwie gehen. Dem "Calc" habe ich den exakten Pfad zur frisch installierten Java-Runtime-Umgebung gegeben. Das doofe Calc behauptet frech, nichts zu finden. Vielleicht reicht die "Umgebung" nicht, und es muss eine "vollere" Version sein. @SuseLinux: Jubel, welch' ein tolles Programm, das wäre der Bringer........wäre! Wenn die Ansteuerung des Sensors wie in dem Formeleditor beschrieben via Vorwiderstand ginge. Geht aber nicht. Mein Sensor muss dringend aus einer Konstantstromquelle seinen Saft beziehen, sonst driftet die Genauigkeit in wirklich nicht mehr sinnvolle Dimensionen ab, alleine schon wegen des irren Logarythmusses. Gruß, wilhemT
:
Bearbeitet durch User
>Mein Sensor muss dringend aus >einer Konstantstromquelle seinen Saft beziehen, sonst driftet die >Genauigkeit in wirklich nicht mehr sinnvolle Dimensionen ab. Das glaube ich nicht ganz. Denn ein Widerstand hat die Toleranz X. Eine Konstantstromquelle aus mindestens einem Widerstand mit der gleichen Toleranz X und zig weiteren Bauteilen mit zusätzlicher Toleranz hat mehr Fehler.
Mit Excel kann man Annäherungsformeln für Kurven aus Tabellen erstellen. Vielleicht kannst du ja mal deine Werte hier schreiben, dann kann dir jemand die Formel nennen. Dreisatz zwischen den Stützpunkten wäre allerdings auch sinnvoll.
Schaue dir das hier bitte einmal an, insbesondere den ersten Teil mit der Formel: http://de.wikibooks.org/wiki/Linearisierung_von_resistiven_Sensoren/_Heissleiter Den Teil mit den OPV-Schaltungen kannst du auch überfliegen, den brauchst du ja nicht unbedingt. Die Mathematik dahinter könnte aber die Lösung für dein Problem sein.
Be Ti schrieb: > Der NTC-Sensor hat eine logarithmische Kennlinie, an diesem einen > speziellen Typen geht kein Weg dran vorbei (nichts anderes möglich). Zu > ihm habe ich das off. Firmendatenblatt, in welchem in einer Tabelle die > Temp-Werte in 5°C-Schritten gelistet sind und die dazugehörigen > Widerstandswerte. Es gibt aber keine Formel, auch keine Koeffizienten > über Material o.Ä.. Der zweite Google-Treffer zu "ntc kennlinie". Es gibt Formeln. Durch probieren könnte man auch auf die Parameter kommen. http://www.controllersandpcs.de/lehrarchiv/pdfs/elektronik/pass01_03x.pdf Aber in Deinem Fall ist eine Werteliste und der Dreisatz effektiver. mfg klaus
Ja, wie beschrieben, aus bautechnischen Gründen gibt es nur einen einzigen Typen. Der oder keiner. Das Prob mit dem Vorwiderstand muss nicht unbedingt eines sein. Habe mir gerade überlegt, dass eigentlich nichts dagegen sprechen würde, "unter" die Konstantstromquelle und vor den Sensor noch einen zusätzlichen Widerstand einzufügen. So im Bereich von 400 Ohm müßte das noch passen. Deswegen sind wir aber nicht aus dem Schneider, was deine tolle Formel angeht, "Suse". Die verlangt die Eingabe irgendeiner Konstanten, und da gibt - wie gesagt - das Datenblatt nichts her. Den Hersteller des Sensors hatte ich schon mal angeschrieben. Die Reaktion war die Zusendung dieses Datenblattes und die Weigerung, irgendwas anderes noch zu unternehmen oder raus zu rücken. Der Sensor heißt übrigens: Z- S 088 . Gruß, wilhelmT
Be Ti schrieb: > Wer kann mir einen Weg aufzeigen Du legst einfach alle Tabellenwerte in ein Array und vergleichst sie. Ist der Tabellenwert < Meßwert, machst Du mit dem nächsten eine Geradeninterpolation. Bzw. wenn Du es ganz genau willst: http://de.wikipedia.org/wiki/Spline-Interpolation Be Ti schrieb: > die eine 8-bit-MPU zur Umrechnung gebrauchen kann? Die Bitbreite spielt keine Rolle. Ein C-Compiler kann Code für mindestens 32Bit-float erzeugen, das reicht dicke.
Be Ti schrieb: > Mein Sensor muss dringend aus > einer Konstantstromquelle seinen Saft beziehen Wozu das denn? Man nimmt besser einen Widerstand zur Referenz des ADC, die kürzt sich dann einfach raus.
Marek Walther schrieb: > Schaue dir das hier bitte einmal an, insbesondere den ersten Teil mit > der Formel: > http://de.wikibooks.org/wiki/Linearisierung_von_resistiven_Sensoren/_Heissleiter > > Den Teil mit den OPV-Schaltungen kannst du auch überfliegen, den > brauchst du ja nicht unbedingt. Die Mathematik dahinter könnte aber die > Lösung für dein Problem sein. Sorry, zu früh gedrückt und bearbeiten ging nicht mehr. Die obige Formel sollte auch für deinen NTC gelten, nur die Parameter sind etwas anders. Dazu könnte dann folgendes weiter auflösen: http://www.sprut.de/electronic/temeratur/temp.htm#ntc Die Konstanten musst Du in deinem Datenblatt finden, wenn nicht, hast du das falsche Datenblatt.
Angehängte Dateien:
-
ohne_Parallel-R.jpg
100 KB -
mit_Parallel-R.jpg
180 KB
Probiers mal mit einem Parallel-Widerstand zum NTC. Ich mach mir da immer ne Excel-Tabelle, Spannung, Strom, Kurve zeichnen und dann einen R parallel. Das linearisiert relativ gut.Dann noch nen OP dahinter und gut ist. Kannst du mit LookUp-Tabellen arbeiten ?
Peter Dannegger schrieb: > Du legst einfach alle Tabellenwerte in ein Array und vergleichst sie. > Ist der Tabellenwert < Meßwert, machst Du mit dem nächsten eine > Geradeninterpolation. Schwitz! Treffer, und auch gleich versenkt! Das hatte ich befürchtet: Ich stelle mir einen Weg vor, und dann wird mir gleich bewiesen, dass es anders viel besser wäre. Also, bin umgefallen, und werde von der Erstellung einer Formel Abstand nehmen. Werde dann also dem Rat von Peter Danneger, Lan, Klaus Ra. und Suse hatte das - glaube ich - auch angesprochen folgen, und es mit einer Tabelle versuchen. Aber das kommt für mich zu früh und da möchte ich eure Hilfe nicht überstrapazieren. Da werde ich mich einfach erst noch in C weiter einarbeiten und mich dort mal nach sowas umschauen und mit einer ganz niedlichen Tabelle anfangen. Aber das braucht, und deswegen werden vorraussichtlich etliche Tage vergehen, bis ich mich wieder melde. Danke allen für ihre Hilfsbereitschaft, ist schon toll hier im Forum. Muss jetzt wech, C lernen. Gruß, wilhelmT
:
Bearbeitet durch User
Hiermit kannst Du einfach die Formel für deinen MC erstellen: Beitrag "PolynomMaker - Funktion für nichtlineare Bauelemente finden"
Be Ti schrieb: > Der NTC-Sensor hat eine logarithmische Kennlinie, an diesem einen > speziellen Typen geht kein Weg dran vorbei (nichts anderes möglich). Poste doch mal einen Link ! <edit> Sorry... > Den Hersteller des Sensors hatte ich schon mal angeschrieben. > Die Reaktion war die Zusendung dieses Datenblattes und die Weigerung, > irgendwas anderes noch zu unternehmen oder raus zu rücken. > Der Sensor heißt übrigens: Z- S 088 Da findet man nicht so einfach was ...
:
Bearbeitet durch User
Ich setze mich bei solchen Sachen immer hin und zeichne ein Schaltbild. Dann nehme ich einen Vorwiderstand zwischen Versorgungsspannung und NTC der dem wichtigsten Meßbereich des NTCs entspricht. Dann tippe ich die Temperaturen (z.B. 5°-Schritte) und Widerstände aus dem Datenblatt in eine Excel-Tabelle und rechne mit den Werten etwas rum. Eigentlich ist es so, daß sich aus der Temperatur über den NTC und Vorwiderstand ein Verhältnis von Meßspannung zu Versorgungsspannung ergibt, der von der Versorgungsspannung unabhängig ist. Diese Tabelle speichere ich ab und schreibe eine Routine, die für einen Meßwert die Tabelle abklappert und die Stützwerte interpoliert und in 1°-Schritten den besten Wert findet. Klingt etwas trocken, ist aber quick-n-dirty. Keine aufwendigen mathematischen Formeln (Polynome), nur einfacher Dreisatz (Integer), um aus 2 Stützstellen (x Grad, x+5 Grad) und dem Meßwert einen Treffer zu suchen, und das immer wieder, bis es paßt...
Be Ti schrieb: > Die verlangt die Eingabe irgendeiner Konstanten, und da > gibt - wie gesagt - das Datenblatt nichts her. Dann zeig es doch mal. Oder hast du dafür ein NDA unterschreiben müssen.
Ein NTC ist bestimmt durch ein paar Konstanten. Der exponentielle Steilheit, genannt Beta, und dem widerstand bei 25 Grad. Das eine kann man messen, das andere rechnen. Die Empfindlichkeit ist am Groessten wenn der Serienwiederstand gleich dem Widerstand des NTC bei der gewuenschten Temperatur ist.
Den Polynommaker braucht man nicht unbedingt, die RGP-Funktion in Excel tut es auch. Oder ein Punktdiagramm einfügen, eine Trendlinie wählen und die Formel im Diagramm darstellen lassen.
Angehängte Dateien:
-
sensor-daten.jpg
2 MB -
tabelle1.jpg
240 KB
Da hier verschiedentlich nach dem Datenblatt des Sensors gefragt wurde, stelle ich das mal ein. Grüße, wilhelmT
Be Ti schrieb: > tabelle1.jpg In der Form wird das wohl kaum ein Programm zur Bestimmung der Funktion verarbeiten können. Da wird irgendjemand die Werte aus den Spalten für Temperatur und Nominalwiderstand in eine rechnerlesbare Form übertragen müssen.
0815 schrieb: > Be Ti schrieb: >> tabelle1.jpg > > In der Form wird das wohl kaum ein Programm zur Bestimmung der Funktion > verarbeiten können. Da wird irgendjemand die Werte aus den Spalten für > Temperatur und Nominalwiderstand in eine rechnerlesbare Form übertragen > müssen. Das macht auch insofern Sinn, als man dann gleich mit dem zur Temperatur gehörenden Widerstandswert in die übliche Spannungsteilerformel geht und dann gleich komplett auf den ADC Wert zurückrechnet. Im Endeffekt kriegt man dann eine Tabelle, die direkt einen Zusammenhang zwischen ADC Wert und Temperatur herstellt. Ob man dann durch diese Werte ein Polynom legt, oder eine Spline Interpolation oder ob man zwischen den Stützstellen linear interpoliert ist eine andere Frage. Wenn man mit Mathe auf Kriegsfuss steht, ist lineares Interpolieren wahrscheinlich das einfachste und dürfte bei 5° voneinander entfernten Stützstellen nicht wirklich das große Problem in der Praxis darstellen. Aber: wie gut die Werte dann passen sieht man meist in einem Diagramm recht schön.
:
Bearbeitet durch User
Glaub mir, selbst wenn du die korrekte Formel hättest würdest Du Sie auf einem PIC nicht rechnen wollen. Du bräuchtest dafür logarithmus aus... Das hab ich mal auf einem Atmega probiert: etwa 2500 Taktzyklen. Das ist ja nicht das Problem. Aber: Es lädt die floating point library und braucht darum massig Platz. Bin auch ganz schnell bei Tabelle und Interpolation gelandet. viel Erfolg hauspapa
S. K. schrieb: > Glaub mir, selbst wenn du die korrekte Formel hättest würdest Du Sie auf > einem PIC nicht rechnen wollen. Du bräuchtest dafür logarithmus aus... > hauspapa Das Thema "Formel" hatte ich ja schon beerdigt, aber...Aber ich hatte von vornherein damit geliebäugelt, nach dem Erlernen von "C" mit Hilfe der 8-bittigen PICs für mein Projekt auf einen 16-Bit-Pic, also z.B. einen PIC24Fxxx umzusteigen, weil der 16-Bit-Matheroutinen in Hardware mitbringt. Wäre bei dem eine Formelrechnung immer noch als zu (zeit- und/oder platzmäßig-) aufwendig abzulehnen? Zur Mess-Hardware: Da ist geplant, den Sensor mit Konstantstrom zu versorgen. Entsprechend findet sich dessen Kennlinie in der variierenden E-Spannung ja wieder. Ist es korrekt, aus dem bekannten Wert für den K-Strom und jeweiligen Widerstandswert (aus der Tabelle entnommen) auf die Spannungshöhe zu rechnen/ zu schließen, schlicht nach Ohmschen Gesetz? Oder gibt es da noch andere zu berücksichtigende Einflüsse (Sensorerwärmung durch zu hohen Strom ist klar,aber sonst) ? Gruß, wilhelmT
Be Ti schrieb: > von vornherein damit geliebäugelt, nach dem Erlernen von "C" mit Hilfe > der 8-bittigen PICs für mein Projekt auf einen 16-Bit-Pic, also z.B. > einen PIC24Fxxx umzusteigen, weil der 16-Bit-Matheroutinen in Hardware > mitbringt. Wäre bei dem eine Formelrechnung immer noch als zu (zeit- > und/oder platzmäßig-) aufwendig abzulehnen? Wenn du in C programmierst, interessiert dich das nicht. Du schreibst deine Multiplikation einfach hin und der Rest ist Sache des Compilers. Der weiß schon, wie rechnen in 16 Bit geht, selbst wenn du nur einen 8 Bit Rechner hast. Sowas ist ja schliesslich nicht Raketentechnik. Du kannst ja auch beliebig große Zahlen multiplizieren, obwohl du nur das kleine Einmaleins auswendig kannst. In der Grundschule hast du ein "Verfahren" gelernt, wie du damit auch mit größeren Zahlen hantieren kannst. Nichts anderes macht ein Computer. Eine 8 Bit CPU kann zwar nur mit 8 Bit Einheiten hantieren, aber mit dem richtigen Verfahren kann man das auf beliebige Bitzahlen aufbohren. Ähnlich wie du bei der Aufgabenstellung "58743 mal 129876" das Ergebnis Schritt für Schritt zusammensetzt, setzt das deine 8 Bit CPU auch Schritt für Schritt zusammen. Der Compiler hat die entsprechenden Verfahren mit und setzt sie ein. Das ist nicht dein Problem. Und ja. Dein µC kann schneller rechnen als du. Viele tausend mal schneller. Selbst wenn er als 8 Bit CPU die Berechnungen in kleinen Happen zusammensetzen muss. > E-Spannung ja wieder. Ist es korrekt, aus dem bekannten Wert für den > K-Strom und jeweiligen Widerstandswert (aus der Tabelle entnommen) auf > die Spannungshöhe zu rechnen/ zu schließen, schlicht nach Ohmschen > Gesetz? Solange es um Gleichstrom und Widerstände geht, gilt das Ohmsche Gesetz IMMER. Kennst du von den 3 Größen Widerstand/Spannung/Strom 2 Stück, dann kannst du die 3. errechnen. Allerdings: Du brauchst ja die Umkehrung. Denn du kennst ja die Temperatur (und damit den Widerstandswert) nicht. Das ist ja genau das, was du feststellen willst. Was du misst, das ist die Spannung über dem Widerstand. Und da du durch die Konstantstromquelle weißt, wieviel Strom durch den Widerstand rinnt, kannst du dir mittels Ohmschen Gesetz ausrechnen, wie gross der Widerstandswert ist. Aus der Tabelle kannst du diesen Widerstandswert wiederrum in eine Temperatur umrechnen und die wird dann angezeigt.
:
Bearbeitet durch User
Ach schau an ein AB-Sachsen-Fühler :oD Einen anderen Typ von denen, hab ich zigfach im Einsatz: Öltemperaturmessung bei Motorrädern (Conrad 188103). Wie ich gesagt hab: Parallel-R und ein OP. Mit einer Widerstandsdekade eine Wertetabelle erstellen (Temperatur zu ADC) und in der Software eine LookUp-Tabelle. Ich messe so mit 1°C genau von -10..155°C. Als Controller verwende ich ATMega/ATXmega.
Be Ti schrieb: > Zur Mess-Hardware: Da ist geplant, den Sensor mit Konstantstrom zu > versorgen. Entsprechend findet sich dessen Kennlinie in der variierenden > E-Spannung ja wieder. Ist es korrekt, aus dem bekannten Wert für den > K-Strom und jeweiligen Widerstandswert (aus der Tabelle entnommen) auf > die Spannungshöhe zu rechnen/ zu schließen, schlicht nach Ohmschen > Gesetz? Konstantstrom ist nicht notwendig, wenn man ratiometrische Messungen macht. Aktuell hatte ich dazu etwas geschrieben, und wenn Du ganz ans Ende des Beitrages gehts, findest Du eine Auswertung mit Tabellen. Beitrag "PT1000, einfache Auswertung mit AVR (ATmega328)" Bei Deinen Ansprüchen würde ich keinen NTC nehmen. Auch ein PT1000 muß es nicht unbedingt sein. Ein guter Kompromiss wäre m.E ein KTY81/110, der eine gut definierte Kennlinie hat und von Hause aus mit 1% Toleranz geliefert wird. Der TK ist etwa doppelt so groß wie bei einem PT1000. Siehe hier: http://www.reichelt.de/KTY-81-110/3/index.html?&ACTION=3&LA=446&ARTICLE=9594&artnr=KTY+81-110&SEARCH=kty81
Angehängte Dateien:
-
NTC.png
31 KB
Hier ist ein schönes Projekt zum NTC berechnen: http://sourceforge.net/projects/thermistor/files/ Hab ich mal für die Tabellenwerte des speziellen NTC gemacht (wenn ich alle richtig gedeutet habe). Das Ergebnis in Libreoffice-calc als Bild. c1 bis c4 sind Koeffizienten für den NTC und die Formeln zum berechnen der Temperatur aus dem Widerstand sind auch ersichtlich. Die sind aber nicht wirklich µC-freundlich :-) Ich denke die sinnvollste Variante ist nachher eine Tabelle mit der Zuordnung: ADC-Wert(8bit) -> Temperatur. Ist nur die Frage wie die am leichtesten für die Anwendung zu erstellen ist. Ich würde die Schaltung aufbauen die über LED erst Mal den ADC Wert ausgibt, den Sensor in einen Topf Öl auf den Herd stellen und langsam erhitzen und mit Vergleichsthermometer die Zuordnung ADC-Temp notieren. Geht natürlich auch beim abkühlen oder automatisiert. Z.B. hab ich hier ein Multimeter das auch Temperaturen messen kann und einen Triggereingang hat. Das könnte bei jeder ADC-Wert Änderung einen Impuls kriegen und die Temperatur speichern. Möglichkeiten gibt es viele...
Karl Heinz schrieb: > Solange es um Gleichstrom und Widerstände geht, gilt das Ohmsche Gesetz > IMMER. Das "IMMER" gilt allerdings nur für ohmsche Widerstände, da sich das Ohmsche Gesetz darauf verläßt, dass ein linearer Zusammenhang zwischen Strom und Spannung besteht ;-)
m.n. schrieb: > Konstantstrom ist nicht notwendig, wenn man ratiometrische Messungen > macht. Da ich durch den Dschungel der vielen alternierenden Möglichkeiten einen Weg finden muß, gestatte ich es mir, den obigen Satz mal umzukehren: Warum sollte ich mich auf komplizierte Steuerungen einlassen, wenn es ein simples und preiswertes Stromregel-IC nicht nur tut, sondern sogar sehr gut tut. > Bei Deinen Ansprüchen würde ich keinen NTC nehmen. Dass geht jetzt hier wie in vielen anderen Freds: Wer in der Mitte einsteigt, bekommt die Info vom Anfang nicht mit: An dem genannten Sensor führt aus technischen Gründen kein Weg vorbei, dieser oder keiner. @ crazy_h: Jawoll, du Sachse! Der Sensor ist von TT-electronics, wird vertrieben von AB Elektronik Sachsen, von privat zu beziehen aber nur über so freundliche Beschaffungsvermittler wie Condrad. Ein sehr ähnlicher S ist in deren Katalog gelistet, dieser hier geht nur über Einzelbezug. Und ja doch, auch dieser soll die Temp von Öl messen, diesmal im Auto. Und weil im konkreten Fall 8,5 Liter (in Worten: ACHT) dauernd um die Fühlerspitze umeinander schwappen, ist an eine Eigenerwärmung des Sensors nich zu denken, solange man irgendwo bei 1 bis 5 mA bleibt. @hp-freund: Das Eichen, bzw. Selbstauslesen der Sensor-Temp!!! Schwitz!!Is klar, lag auf der Hand, aber nicht in meiner! Hatte mir eine Messanordnung aufgebaut mit mittelgroßem Kunststoffkanister, den innen ausgeschäumt, darein einen Glasbecher, darein einen Wärmestab für Ätzanlagen, den mit hochgenauer Regelelektronik (ehemals Farbfoto- Entwicklung) angesteuert und verdammt, verdammt nur streuende Temp-Werte erhalten. Dann den Sensor raffiniert in mehrere Lagen Schrumpfschlauch über- und hintereinander eingeschweißt, damit kein Wasser an die Anschlüsse gelangt. Voll raffiniert, aber das Wasser war raffinierter. Immer diffundierte da Feuchtigkeit durch und verdarb jedwede Messung. Irgendwann hab ich's aufgegeben und hoffe nun darauf, dass die einfache, ohmsche Umrechnung der aus der Tabelle entnommenen Widerstandswerte auf die "richtige" Spannung und damit die Temp führt. Gruß, wilhelmT
Be Ti schrieb: > Irgendwann hab ich's aufgegeben und hoffe nun darauf, dass die einfache, > ohmsche Umrechnung der aus der Tabelle entnommenen Widerstandswerte auf > die "richtige" Spannung und damit die Temp führt. Wie kommst du da drauf? Es ist ja nicht das warme Wasser, das dich narrt, sondern die Messung mit dem ADC, die keinen stabilen Wert ergibt. Ich geh mal davon aus, dass du dein warmes Wasser auch umgerührt hast. Denn generell ist dieser Unsinn ja recht verbreitet, Temperaturen auf hunderstel Grad anzugeben. Weil schon mal irgendjemand in freier Wildbahn irgendein Medium gesehen hat, dass in einem nennswerten Volumen eine wirklich homogene Temperatur hat. Langer Rede kurzer Sinn: es ist völlig normal, dass 2 Thermometer ohne besondere Vorkehrungen eben nicht auf 2 Nachkommastellen identische Ablesungen ergeben. Alles in allem. Ob du mit einer bekannten Temperatur kalibrierst oder ob du das theoretisch aus dem Widerstandswert herleitest, ist Jacke wie Hose. Wenn du da keine sauberen Werte kriegst, kriegst du auch dort keine sauberen Werte und du musst nachsehen, wo du in deinem Aufbau elektrisch geschlampt hast.
:
Bearbeitet durch User
Be Ti schrieb: >> Bei Deinen Ansprüchen würde ich keinen NTC nehmen. > Dass geht jetzt hier wie in vielen anderen Freds: Wer in der Mitte > einsteigt, bekommt die Info vom Anfang nicht mit: An dem genannten > Sensor führt aus technischen Gründen kein Weg vorbei, dieser oder > keiner. Gut, das hatte ich überlesen. Be Ti schrieb: >> Konstantstrom ist nicht notwendig, wenn man ratiometrische Messungen >> macht. > Da ich durch den Dschungel der vielen alternierenden Möglichkeiten einen > Weg finden muß, gestatte ich es mir, den obigen Satz mal umzukehren: > Warum sollte ich mich auf komplizierte Steuerungen einlassen, Ratiometrisch ist die unkomplizierteste Methode. Be Ti schrieb: > Und ja doch, auch dieser soll die Temp von Öl messen, diesmal im Auto. Das hättest Du am Anfang schreiben sollen. Dann laß Dir die Tabelle von Crazy H. geben und sieh zu, daß die Toleranzen so gering sind, daß garnicht abgeglichen werden muß. NTCs haben in der Regel die gröbsten Toleranzen, aber wenn sie auf 1% selektiert sind, kann man nicht meckern. Karl Heinz schrieb: > Es ist ja nicht das warme Wasser, das dich narrt, sondern die Messung > mit dem ADC, die keinen stabilen Wert ergibt. Da könnte man einen 2. Kanal zur Referenzmessung verwenden. Wenn der ADC mehr als 8 Bit liefert, sollte er hinreichend genau arbeiten.
Karl Heinz schrieb: > Es ist ja nicht das warme Wasser, das dich narrt, sondern die Messung > mit dem ADC, die keinen stabilen Wert ergibt. > Ich geh mal davon aus, dass du dein warmes Wasser auch umgerührt hast. > Denn generell ist dieser Unsinn ja recht verbreitet, Temperaturen auf > hunderstel Grad anzugeben. Nein, "kbuchegg", doch das warme Wasser! Aber bevor ich das erläutere: Wenn ich einen Namen fürs Zitat nenne, wird dann der erste Teil genommen oder der "Blaue" in Klammern? Also nein, es ist wirklich das Wasser, welches mich narrte. Soweit war ich ja noch lange nicht, dass ein µC zum Einsatz kam. Stattdessen kam - das wird vielleicht unseren Sachsen freuen - ein Thermometer (T) aus DDR-Zeiten zum Einsatz, ein hochgenaues Spezial-T, das via Ebä aus Laborbeständen verkauft wurde. Dazu noch für die unteren Bereiche ein T aus dem Farbfoto-Labor-Bedarf. Dazu noch ein hoch genauer Meßzusatz für ein Multimeter. Alle 3 können nicht gleichzeitig gesponnen und auch noch die gleiche Abweichung angezeigt haben! Umrühren..? Au man, da habe ich die Glas-Ts aufs Äußerste strapziert beim Rühren. Ne, so unbedarft bin ich nicht. Immer war Wasser unter den Schrumpfschläuchen hindurch diffundiert und hatte sich in Pfützen am Anschluss-Sockel zur Fete eingefunden, und schwups - verschwanden die Messwerte im Nirwana. Ich bekam den Sensor nicht dicht. Der ist auch mitnichten so niedlich wie die Üblichen, hier kolportierten. Den kann man auch nicht einfach in ein Glasrohr stecken und das unten verschweißen. Gebraucht würde ein Schlosser, der ein Gewinde zu drehen in der Lage ist, und dann.... Die Ansprüche an die Genauigkeit der Anzeige sind bescheiden. Genau sollte es nur in einem einzigen Bereich sein, so um die 70 Grad. Aber auch da würden 2 % schon sehr gut sein. Nachkommastellen sollen eh' gar nicht angezeigt werden. Ob z.B. angezeigte 30° C nun 26° C oder 34° C "in Echt" wären, ist weitgehend belanglos und bleibt dem persönlichen Ergeiz überlassen. Gruß, wilhelmT
:
Bearbeitet durch User
Be Ti schrieb: > Wer kann mir einen Weg aufzeigen, aus den Wertepaaren eine Formel zu > erstellen, die eine 8-bit-MPU zur Umrechnung gebrauchen kann? > Grüße, wilhelmT Das mit Fließkomma auf einem 8-bitter zu rechnen ist Schwachsinn. Nimm ein "selbstgebautes" Festkomma. Der Sensor ist mit einem 470R nach +5V gespannt, Mittelabgriff geht auf den ADC (+5V - 470R -o(ADC) - NTC - GND) Der Sensor kann dann über ein Polynom 4.Grades approximiert werden. Excel gibt mir aus: y = -3,94E-13x4 - 9,11E-10x3 + 1,97E-05x2 - 8,63E-02x + 1,76E+02 y= TEMP [0...120] x = Digit[12 bit] Die ganze Rechnung machst Du int32. Coeff1 = 1760; Coeff2 = -(Digit * 863) / 1000; Xpower2 = (Digit * Digit) / 10000; Xpower3 = -(Xpower2 * Digit) / 10000; Xpower4 = (Xpower2 * Xpower2) / 100; Coeff3 = (197 * Xpower2)/100; Coeff4 = (911 * Xpower3) / 1000; Coeff5 = -(4 * Xpower4) / 100; Temp = Coeff1 + Coeff2 + Coeff3 + Coeff4 + Coeff5; // Temp ist der zehnfache Wert, also mit einer Nachkommastelle). (ohne besondere Optimierungen, geht sicherlich noch genauer). Nach Excel (Festkomma nachgebildet) komme ich damit auf etwa +/-1,5Grad Abweichung. rgds
6A66 schrieb: > Be Ti schrieb: >> Wer kann mir einen Weg aufzeigen, aus den Wertepaaren eine Formel zu >> erstellen, die eine 8-bit-MPU zur Umrechnung gebrauchen kann? >> Grüße, wilhelmT > > Das mit Fließkomma auf einem 8-bitter zu rechnen ist Schwachsinn. Nicht unbbedingt. Kommt drauf an, was der µC sonst onch so zu tun hat. Für nicht benutztes Flash gibt es kein Geld zurück. Genausowenig wie für nicht benutzte Rechenzeit. Ein µC in einem Fahrzeug, welche die Öltempertur anzeigt, hat alle Zeit der Welt. Dafür hat er erst mal keine Probleme mit den Faktoren in der Festkommarithmetik. PS: Wenn schon Festkommaarithmetik, dann mit Vielfachen von 2. Mit Vielfachen von 10 kannst du dir den Aufwand auch schon sparen. Da kosten dir diese ganzen Divisionen mehr, als wenn du simpel Fliesskomma rechnest. (OK, ist jetzt übertrieben ausgedrückt)
6A66 schrieb: > Das mit Fließkomma auf einem 8-bitter zu rechnen ist Schwachsinn. Wenn genug Flash und Cpu-Zeit frei ist... who cares? Für ungenutzten Flash oder CPU-Zeit gibts kein Geld zurück. Und ein bisschen Messwerte geradebiegen sollte immer noch ein paar 1000 mal pro Sekunde möglich sein. > Nimm ein "selbstgebautes" Festkomma. Aber immer schön durch so ungerade Zahlen, wie 100, 1000 oder 10000 teilen... Edit: Lol. da war KHB schneller und das fast mit gleichem Wortlaut :-) Notiz an mich: nach dem Tee holen noch mal aktualisieren.
:
Bearbeitet durch User
Ähm...."6A66".....das ist wirklich sehr reizend von dir, dass du dir die Arbeit mit einer Excel-Tabelle, bzw. einer Formel gemacht hast. Danke sehr. Jetzt habe ich ein neues Problem: Meine aktuellen Mathekenntnisse reichen nicht aus. Hatte zwar ein Gymnasium besucht, aber das war ein altsprachliches G. So Neumodisches wie Naturkunde, wozu auch Mathe gehörte, lief dort unter ferner liefen. Und das alles ist lange her. Was sollen die ganzen "Xpower" und "Coeffs" bedeuten? Hm.... Zur Rechenzeit des µCs. Der soll genau drei Dinge tun: Den Messwert des Sensors einlesen, das Umrechnen und drittens alles auf eine dreistellige LED-Anzeige ausgeben (wobei nicht multiplext werden soll, der Platinenplatz ist reichlich, und der angestrebte PIC hat 5 ganze Ports). Die Aktualisierung der Anzeige ist mehr als ausreichend alle 10 Sekunden, da wäre nach meinem laienhaften Verständnis vermutlich viel Zeit, den µC mit Rechenaufgaben zu beschäftigen. Gruß, wilhelmT
Be Ti schrieb: > @ crazy_h: Jawoll, du Sachse! Der Sensor ist von TT-electronics, wird > vertrieben von AB Elektronik Sachsen, von privat zu beziehen aber nur > über so freundliche Beschaffungsvermittler wie Condrad. Ein sehr > ähnlicher S ist in deren Katalog gelistet, dieser hier geht nur über > Einzelbezug. > Und ja doch, auch dieser soll die Temp von Öl messen, diesmal im Auto. > Und weil im konkreten Fall 8,5 Liter (in Worten: ACHT) dauernd um die > Fühlerspitze umeinander schwappen, ist an eine Eigenerwärmung des > Sensors nich zu denken, solange man irgendwo bei 1 bis 5 mA bleibt. Als Bayer nehm ich das jetzt persönlich :oD :oP Ersten hießen die vor ca. 10 Jahren nur "AB-Sachsen" und 2. wenn die den nicht herstellen, wie konnte ich dann damals (aufgrund eines netten Mails an die) ca. 50 Temperatursensoren (die die in den Fühlern eingebaut sind) von denen bekommen ? 4.7 KOhm an +5V und einen Verstärker (ich nehm den TS912). So berechnen, daß dein gewünschter Temperaturbereich optimal als Ausgangsspannung 0..5V raus kommt. Parallelwiderstand mit Excel-Tabelle ermitteln und eine LookUp-Tabelle.
6A66 schrieb: > Der Sensor kann dann über ein Polynom 4.Grades approximiert werden. Wenn man den Sensor alleine approximiert, handelt man sich eine relativ hohe Dynamik der Messdaten (i.e. geringe Auflösung bei hohen Temperaturen) ein. Einen Widerstand parallel zum NTC sollte man schon einsetzten und dann entsprechend bei der Approximation mit einbeziehen. Crazy H. schrieb: > Probiers mal mit einem Parallel-Widerstand zum NTC
Da ein bestimmen des Temp/R Verhältnis ein Problem zu sein scheint, hier ein anderer Vorschlag: - mit einem REF02 eine Referenzspannung von 5V erzeugen - diese über 1k R an den NTC, dann Masse - den Ref Eingang vom PIC/AVR ebenfalls von REF02 speisen - die Verbindung vom R zum NTC über einen Rail-to-Rail OPV puffern und an den ADC vom Controller Die Tabelle für das Verhältnis von 8bit ADC zu Temperatur gibts im Anhang. Zusammengefasst bedeutet das die vorgegebenen Tabellendaten aus dem NTC Datenblatt werden verwendet und im µC ist für den Temperaturbereich von 0-120°C nur eine Tabelle mit 121 Einträgen nötig.
Wenn man sich die Tabelle ansieht, dann stellt man schnell fest, dass man mindestens einen ADC mit 10bit benötigt. Besser wäre es einen 12bit-ADC zu nehmen.
@ Helmut, wieso stellst Du das fest? Die gforderten 2% Genauigkeit werden nur im oberen Temp. Bereich ein paar Mal berührt, sonst ist es eine Auflösung von 1°C. Z.B. kann ADC-Wert 29 für 114 oder 115°C stehen. Damit sind die Anforderungen erfüllt ...
Helmut S. schrieb: > Wenn man sich die Tabelle ansieht, dann stellt man schnell fest, dass > man mindestens einen ADC mit 10bit benötigt. Besser wäre es einen > 12bit-ADC zu nehmen. Bei der Öltermperatur in einem Auto ist die Abweichung aber sowas von egal. Egal was angezeigt wird, sie stimmt ja sowieso nicht damit überein, was sich im Zylinderkopf abspielt. Im Grunde würden es 5 Led 'kalt', 'lau', 'mittel', 'warm', 'aber sowas von heiss' auch tun.
:
Bearbeitet durch User
Wenn sich jemand mit einem 10bit-ADC besser fühlt, ist das aber auch kein Problem. Es genügt übrigens, statt der absoluten ADC-Werte nur jeweils die Differenz zweier benachbarter Einträge zu speichern. Dann benötigt man für die Tabelle auch weiterhin nur 121 Bytes (sonst das Doppelte). Falls dagegen Speicherplatz üppig zur Verfügung steht, könnte man sogar in der Tabelle gleich die entsprechenden Ziffern der drei Displaystellen mitablegen. Dann erschöpft sich die Rechenarbeit des µC praktisch nur noch in der Bestimmung des korrekten Tabellenindex aus dem gemessenen ADC-Wert.
Meßtechnik ! Wer mißt mißt Mist! Ein Parallel-R zum Sensor ist Sch.... Das stammt aus einer Zeit, wo man mit analoger Technik arbeitete und mit diesen Parallel-Rs versuchte, die krumme Gerade zu linealisieren... braucht man in Zeiten eines uC nicht mehr, der kann rechnen(!). Konstantstromquelle !! Super Idee, starkes Wort, aber Sch.... Da mißt man an dem NTC eine Spannung und weiß gar nicht, welche Versorgungsspannung des ADC hat, wenn mann nicht hochgenaue Quellen einsetzt. Jede zusätzliche Schaltung (REF-xx oder OP-Amp) bringt nur Ärger und Ungenauigkeit. Rechne den ganzen Kram mit einem Vorwiderstand (ca. 470 Ohm oder weniger) in ein Spannungsverhältnis runter, das gibt der ADC direkt aus. Tabelle, Stützpunkte, interpolieren, Integer-Arithmetik... (oder das h an anderer Stelle). Anbei mal eine Excel-Datei zum Spielen. Man kann ja mal die VCC-Spannung ändern (Ungenauigkeit Versorgungsspannung) und sieht, daß sich der ADC-Wert nicht ändert, auch wenn die Meßspannung durch die Gegend geistert.
:
Bearbeitet durch User
Bernd Rüter schrieb: > Rechne den ganzen Kram mit einem Vorwiderstand (ca. 470 Ohm oder > weniger) in ein Spannungsverhältnis runter, das gibt der ADC direkt aus. > Tabelle Würde ich (und viele obige) auch so machen. 8bit ADC reicht hier doch vollkommen aus, die Interpolation schon vorher machen (wenn es unbedingt sein muss in Excel - schneller gehts bestimmt nach Gefühl ;-) Das Ganze in ein array und fertig. @Wilhelm Falls du jetzt nicht weisst, wie das mit dem array (der Tabelle) gemeint ist und du meine Doku noch nicht wutentbrannt gelöscht hast, dann schau mal bei analog Signale ausgeben. Da ist ein Beispiel mit einer Wertefolge unsigned char signal_data[32] = {6, 7, 8, 7, 6, 6, 6, 4,22,31,0, 3, 6, 6, 8, 9,11,12,11, 8, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6}; //EKG an 5 bit DAC Das entspräche deine Temperaturen. Das Ergebnis der ad Wandlung gibt dir dann die Position in dem Feld welches natürlich dann die Werte deiner Interpolation enhält unsigned char temp[...]; ... Temperatur = temp[ADC_ergebnis];
Karl Heinz schrieb: > Egal was angezeigt wird, sie stimmt ja sowieso nicht damit überein, was > sich im Zylinderkopf abspielt. Im Grunde würden es 5 Led > 'kalt', 'lau', 'mittel', 'warm', 'aber sowas von heiss' auch tun. "Karl Heinz", "Karl Heinz"! Bleib bei µCs, da kennst du dich besser aus! Eine Debatte über den Sinn und Unsinn von Anzeigegeräten im KFZ wollen wir in diesem Forum sicher nicht exaltieren, nur in Kürze: Eine brave Hausfrau braucht im Auto weder Wasser-Temp-Anzeiger (WTA), noch Öl-Temp-A. (ÖTA), noch 4 Leds und 99.99% aller Autofahrer brauchen auch keinen WTA, das Ding ist so überflüssig wie der berühmte Kropf. Einzig die ÖTA macht Sinn, weil nur die seriös ausgibt, bis zu welchem Zeitpunkt man tunlichst den Motor nicht belasten sollte, und ab wann dann doch. Und das ist etwa bei 70° C ÖL-Temp. @ LostlnMusic: im PIC18F stehen 256 Byte EEprom zur Verfügung, bei den 16-Bittern PIC24F gibts auch 512 Byte. Dein Gedanke, in einer Tabelle sofort den 7-Segm.-Code abzulegen, klingt gut, aber in Tab. kenne ich mich noch nicht aus. @ Bernd Rüter: Stimmt, Linearisierungs-Bemühungen halte ich auch für wenig zielführend. Dann lieber genau messen und in einer Tabelle nachschauen. Aber Arbeit mit Tabellen, siehe unten..... @ Vloki: Deine Doku, also das Script löschen? Nützt nix, die hatte ich doch komplett ausgedruckt! Zudem wäre ich ja mit mehreren Klammerbeuteln bearbeitet, wenn ich solche Hilfen nicht annehmen und nutzen würde. Aber auch hier gilt: verstanden habe ich deinen Hinweis nicht. Mit der genannten Zahlenreihe auf S. 71 kann ich schlicht nix anfangen, noch nicht...! Wie soll ich mir das vorstellen mit so einer Tabelle? Wenn der ADC (aus Bernds Tabelle[danke]) einen Wert von genau 500 (dual) ausspuckt, wie oder woher weiß der µC dann, in welche Speicherzelle er springen soll? Oder ist das so, dass man dem µC den Job verpasst, "von unten" in der Tabelle fortlaufend "nach oben" hin nachzuschauen, ob die 500 nun gleich oder z.B. größer (kleiner) ist als der in einem Zellenplatz abgelegte Wert? Falls das so gehen sollte, is ja prima, aber außer der Freude, dass eine best. Zelle einen "passenden" Wert enthält, was genau nutzt das dem µC? Findet der in derselben Zelle einen Verweis auf eine andere Zelle, in welcher dann z.B. der von "LostlnMusic" [danke] angesprochene 7-Segm.-Code für die LED-Ausgabe stehen könnte? Gruß, wilhelmT
:
Bearbeitet durch User
Das dachte ich mir ;-)
Also die Tabelle ist nur eine Folge von Werten. Die Werte stehen in
einem Feld (Array). Jeder Eintrag hat eine Nummer. Die Nummer ist das
was in den eckigen Klammern steht. Ok bei der Initialisierung am Anfang
steht da nicht die Nummer sondern die Anzahl der Werte (die Größe des
Feldes).
Das Array kann in verschiedenen Speicherbereichen stehen.
Im EEPROM, im ROM oder im RAM. Wenn es im RAM steht, dann muss es
natürlich erst von einem der anderen Bereiche dahin geschrieben werden.
Das verschieben wir aber jetzt mal auf später !
Die Werte die in dem Feld stehen bekommst du, wenn du Bernds ? Tabelle
komplettierst und für die Zwischenwerte interpolierst indem du für jeden
ADC Wert eine Temperatur festlegst. Also füllst du praktisch die letzte
Spalte a uf, damit alle Werte darin stehen. Dann hast du theoretisch für
jeden ADC Wert eine zugehörige Temperatur.
In den Bereichen die aus deinem Interessensbereich raus laufen brauchst
du nicht weiter zu machen.
Ich habe die Tabelle jetzt nicht vor mir, aber sagen wir einfach mal für
0 Grad bekämst du den Wert 13 als Resultat vom ADC.
Dann würde das der erste Eintrag in deinem Feld sein. Der nächste
Eintrag wäre die Temperatur für den ADC Wert 14.
Den hast du natürlich nicht, deshalb die Geschichte mit der
Interpolation.
Nehmen wir wieder einfach an, der Wert für 5 Grad wäre 23, dann hättest
du 10 ADC Schritte auf 5 Grad und müsstest ungefähr bei jedem 2. mal den
Wert erhöhen. -> {*0*,1,1,2,2,3,3,4,4,5,*5*, ...
Die x Positionen sind jetzt die 0 und 5 Grad aus der Tabelle.
Dazwischen sind die aufgefüllten (interpoliert)
Vermutlich saublöd erklärt, aber vielleicht raffst du es ja trotzdem.
Wie kommt es nun zu der richtigen Zuordnung ?
Weil dein kleinster Wert in der Tabelle (Array / Feld) zum ADC Wert 13
gehört, musst du die 13 von ADC Wert abziehen um den Index Null zu
erhalten, welches der erste Eintrag im Feld ist.
Angenommen du erhältst einen Wert vom ADC von 20. Dann gibt das 20-13 =
7 als Index, was dem achten Wert entspräche. Das führt im obigen
Beispiel zu einer Temperatur von 4 Grad.
Am oberen Bereich deines Interesses kannst du genauso verfahren. Wenn
beispielsweise der ADC Wert von 187 der Temperatur von 120 Grad
entspricht, dann ist alles größere uninteressant und muss nicht in das
Feld mit den Temperaturwerten.
Bevor du den Index berechnest, prüfst du auf die Grenzen. Ist (in
unserem Beispiel) der Wert kleiner als 13 zeigst du "---" oder so was
an, bei einem Wert größer als 187 "888"
Wie gesagt, ich würde eine 8bit Auflösung wählen, dann sind die ADC
Werte von 0..255. (8bit erhält man, wenn man von 10bit 2 ignoriert)
Das mit dem 7-Segment Code in der Tabelle würde ich nicht machen. Kann
man natürlich, aber ich würde eine Funktion schreiben. Den Anzeige würde
ich auch nur aktualisieren, wenn der Wert sich geändert hat ...
Ja ja, das mit der Lookup-Table (so nennt man das wohl) könnte man auch
sehr einfach in Assembler realisieren (retlw ...), aber du willst dich
ja mit C beschäftigen ;-)
UND man kann das alles auch rechnen mit Koeffizienten und pi pa po, ICH
würde es eben so machen.
Hoffentlich hast du jetzt nicht mehr Fragen als vorher ...
:
Bearbeitet durch User
>Oder ist das so, dass man dem µC den Job verpasst, "von unten" in der >Tabelle fortlaufend "nach oben" hin nachzuschauen, ob die 500 nun gleich >oder z.B. größer (kleiner) ist als der in einem Zellenplatz abgelegte >Wert? Falls das so gehen sollte, is ja prima, aber außer der Freude, >dass eine best. Zelle einen "passenden" Wert enthält, was genau nutzt >das dem µC? Ja, genau. Über einen Index (z. B. k), der inkrementiert wird ("k++") klapperst Du die Tabelle von oben nach unten ab. Bei jedem Eintrag prüfst Du, ob er größer (*) ist als der aktuelle ADC-Wert. Bei irgendeinem Tabellenindex ist das garantiert der Fall. Dort brichst Du die Suche ab. Der Wert, den die Indexvariable dann k hat, gibt direkt die Temperatur in °C an. Daraus musst Du dann nur die drei im Display anzuzeigenden Digits generieren. Oder Du bist ganz clever und läßt parallel zum Index k einen dreistelligen Dezimalzähler mitlaufen. Damit hättest Du dann sofort nach der Suche schon die Digit-Information vorliegen, ohne noch irgendetwas rechnen zu müssen. So würde ich es machen. Meine Tabelle bestünde also aus 120 Einträgen mit ADC-Werten. Bei einem 10 bit ADC wäre sie (ohne Tricks) 240 Byte groß (mit Trick die Hälfte davon), würde also z. B. gerade in Dein EEPROM passen. Der Vorteil dieser Methode besteht darin, dass Du nichts interpolieren musst. (Achtung, bitte nicht durcheinanderbringen: Andere Kollegen hier schlagen eine Tabelle mit 256 Temperatur-Einträgen vor - sie ist zu meiner gewissermaßen invers. Auch so funktioniert es. Wenn Du allerdings einen etwas besser auflösenden 10-bit-ADC verwenden willst, dann musst Du entweder zusehen, wo Du eine 1024 Einträge große Tabelle unterbringst, oder wie Du Zwischenwerte interpoliert. Auf beides hätte ich weniger Lust.)
@ Volker: Es ist etwas zu spät, als dass ich das beim ersten Durchlesen verstehen, geschweige denn repetieren könnte. Das wird noch 'ne Nuss werden. Dass du soviel Geduld mit mir aufbringst, ist erstaunlich...... ähm....was trinkst du??? Hasso, Platz! schrieb: > Der Wert, den die Indexvariable dann k hat, gibt direkt > die Temperatur in °C an. Daraus musst Du dann nur die drei im Display > anzuzeigenden Digits generieren. Kuck an: schlichtes Deutsch und nur eine Variable drin!:) Sollte dem so sein (der Aufbau der Tab.), dann sehe ich Chancen, das zu verwirklichen. Für die Umrechnung auf die drei Digits habe ich schon ein Gerüst, sicher nix Raffiniertes, eher bodenständiges Abzählen......aber lass ma, als C-Anfänger muss ich nicht gleich raffiniert ans Werk gehen. Danke, Hasso, der Nebel wird schwächer. Gruß, wilhelmT
Bernd Rüter schrieb: > Ein Parallel-R zum Sensor ist Sch.... Das stammt aus einer Zeit, wo man > mit analoger Technik arbeitete und mit diesen Parallel-Rs versuchte, die > krumme Gerade zu linealisieren... braucht man in Zeiten eines uC nicht > mehr, der kann rechnen(!). Es geht dabei nicht um das Linearisieren und das Vermeiden irgendwelcher Rechnereien, sondern um die Verringerung der Dynamik. Hättest du dein Excel-Worksheet über den vollen relevanten Temperaturbereich ausgedehnt, wäre dir das klar. Wenn man etwas mehr als die Mindestanforderungen bezüglich Auflösung abdecken möchte, kommt ohne die Dynamikreduzierung ganz schnell der Ruf nach einem höher auflösenden Wandler, weil die Kennline bei hohen Temperaturen ziemlich flach wird und die Messung zusätzlich noch anfälliger für Störsignale wird. Du hast noch nie Sensoren entwickelt, oder?
Na dann werfe ich noch mal meinen Vorschlag von oben ein. Die Datei: Temp-ADC8.txt habe ich für den Temperaturbereich 0-120°C aus dem Datenblatt des Z-S 088 erstellt und als LookUp Table im Prog eingesetzt. Bei einem ADC Wert kleiner 25 also grösser 120°C wird von der Funktion 121 zurückgegeben, bei ADC Wert grösser 218 also kleiner 0°C dann 255. Diese Werte setzen eine stabile 5V Spannung voraus die über einen 1k Widerstand an den NTC gelegt werden. Die Messspannung muss mit einem OPV gepuffert werden, es sei denn das der µC ADC-Eingang einen hohen Eingangswiderstand hat. Siehe Datenblatt. Im Anhang die Funktion in der ntc.h und ein Testprogramm das die ADC Werte von 0-255 Auswertet.
Hat der TE denn sein Dichigkeits-Problem gelöst? Bis dahin ist jegliche weitere Diskussion vollkommen Banane, weil es nichts Brauchbares zu messen gibt ...
Be Ti schrieb: > @ Volker: Es ist etwas zu spät, als dass ich das beim ersten Durchlesen > verstehen, geschweige denn repetieren könnte. Das wird noch 'ne Nuss > werden. Die Lösung ist eigentlich viel simpler als die von HP, sogar ohne Variable und das Suchen entfällt ( also das was ein fauler Assembler Programmierer gerne vermeiden würde ;-) ABER wie er schon anmerkte, doch etwas unpraktikabel falls du dir einreden lässt 10bit ADC Auflösung zu brauchen. Bei deinen Ansprüchen ist das meiner Meinung nach aber Quatsch. Be Ti schrieb: > Die Ansprüche an die Genauigkeit der Anzeige sind bescheiden. Genau > sollte es nur in einem einzigen Bereich sein, so um die 70 Grad. Aber > auch da würden 2 % schon sehr gut sein. Nachkommastellen sollen eh' gar > nicht angezeigt werden. Ob z.B. angezeigte 30° C nun 26° C oder 34° C > "in Echt" wären, ist weitgehend belanglos und bleibt dem persönlichen > Ergeiz überlassen. Du kannst es dir natürlich trotzdem aussuchen, du hast ja 10bit. Bei wenigen möglichen Mess-Werten auf jeden Fall die Interpolation der Mess-Werte. Bei vielen - die der Temperaturen und den Suchalgorithmus. Natürlich gibt es auch noch viele andere Möglichkeiten. Wenn du jede Rechnerei vermeidest und nur im Sekundentakt misst, dann läuft den PIC ja nachher auf 31kHz Taktfrequenz mit einer Auslastung von <1% (habe ich jetzt natürlich nicht nachgerechnet ;-) PS: Ich kann mir nicht vorstellen warum die Tabelle ausgerechnet in das EEPROM sollte. Das ist meiner Meinung nach dafür da, Werte die sich während der Laufzeit des Programms ändern könnten zu speichern, damit man sie (die geänderten) auch nach Ausschalten und Wiedereinschalten noch zur Verfügung hat.
Mike A. schrieb: > Wenn man den Sensor alleine approximiert, handelt man sich eine relativ > hohe Dynamik der Messdaten (i.e. geringe Auflösung bei hohen > Temperaturen) ein. Einen Widerstand parallel zum NTC sollte man schon > einsetzten und dann entsprechend bei der Approximation mit einbeziehen. Hallo Mike Der Sensor war mit einem normalen Spannungsteiler approximiert. Natürlich kann man auch noch Parallelwiderstand verwenden, kommt hat ein anderes Polynom raus, kann man wieder durch Integer nachbilden. Sinn und Zweck war zu zeigen, dass das mit einfachen Integer-Rechnungen geht. Die Tabelle geht natürlich auch - wie es beliebt. Vlad Tepesch schrieb: >> Das mit Fließkomma auf einem 8-bitter zu rechnen ist Schwachsinn. > Wenn genug Flash und Cpu-Zeit frei ist... who cares? > Für ungenutzten Flash oder CPU-Zeit gibts kein Geld zurück. > Und ein bisschen Messwerte geradebiegen sollte immer noch ein paar 1000 > mal pro Sekunde möglich sein. Right, das stimmt auch. BTW: Ich hab' das hier als Int32 ausgelegt. Das geht - wie im implementeriungsfall auf einerm Cortex-M3 -in nullkommanichts. Das ist auf einem 8-bitter natürlich schwieriger, speziell auch die division durch 100,1000,... . Kann man aber auch umrechnen so dass die division dann durch shift machbar ist. Helmut S. schrieb: > Wenn man sich die Tabelle ansieht, dann stellt man schnell fest, dass > man mindestens einen ADC mit 10bit benötigt. Besser wäre es einen > 12bit-ADC zu nehmen. Das Beispiel war mit 12-bit gerechnet ohne Betrachtung der Bauteiltoleranzen und ADC-Fehler. Be Ti schrieb: > Ähm...."6A66".....das ist wirklich sehr reizend von dir, dass du dir die > Arbeit mit einer Excel-Tabelle, bzw. einer Formel gemacht hast. Danke > sehr. War etwa 30...45min - halt mal eine Herausforderung. Be Ti schrieb: > Was sollen die ganzen "Xpower" und "Coeffs" bedeuten? Hm.... > Zur Rechenzeit des µCs. Der soll genau drei Dinge tun: Den Messwert des > Sensors einlesen, das Umrechnen und drittens alles auf eine dreistellige > LED-Anzeige ausgeben (wobei nicht multiplext werden soll, der > Platinenplatz ist reichlich, und der angestrebte PIC hat 5 ganze Ports). > Die Aktualisierung der Anzeige ist mehr als ausreichend alle 10 > Sekunden, da wäre nach meinem laienhaften Verständnis vermutlich viel > Zeit, den µC mit Rechenaufgaben zu beschäftigen. > Gruß, wilhelmT Xpower2 = x^2 Coeff2 = 2.Koeffizient (gesamt) des Polynoms. Sind Variablen die ich in C so als Int32 verwenden würde. Wenn Du soviel Zeit hast könntest Du auch Floating-Point Arithmetik machen. Aber das ist sicher nicht das größte Problem. Die Werte die Du vom ADC bekommnet - hier mal mit 12-bit wie bei uns auf einen Cortex-M3 implementiert - werden sicher um ein paar Digits hin- und hertanzen. Was Du dazu brauchst ist eine vernünftige Glättung die auch beim ersten Einschalten schnell reagiert. Sieh auch unter Oversampling nach. Thema Mathematik: Jou, das was ich im Gymnasium mal hatte und dann im Studium ist auch schon sehr lange her, da müsste ich mich auch noch mal aufsynchronisieren. Daber dafür hat's dann doch gereicht :) Einfach mal nach Polynomen schauen udn ein bischen mit Excel spielen. Hasso, Platz! schrieb: > So würde ich es machen. Meine Tabelle bestünde also aus 120 Einträgen > mit ADC-Werten. Bei einem 10 bit ADC wäre sie (ohne Tricks) 240 Byte > groß (mit Trick die Hälfte davon), würde also z. B. gerade in Dein > EEPROM passen. Der Vorteil dieser Methode besteht darin, dass Du nichts > interpolieren musst. Das wäre so die einfachste Art, Nachkommastellen sind nicht vernünftig da das Ergebnis ohnehin ungenauer als 1 grad werden wird (Bauteiltoleranzen, Messtoleranzen). rgds
Hasso, Platz! schrieb: > Ja, genau. Über einen Index (z. B. k), der inkrementiert wird ("k++") > klapperst Du die Tabelle von oben nach unten ab. Bei jedem Eintrag > prüfst Du, ob er größer (*) ist als der aktuelle ADC-Wert. Bei > irgendeinem Tabellenindex ist das garantiert der Fall. Dort brichst Du > die Suche ab. Der Wert, den die Indexvariable dann k hat, gibt direkt > die Temperatur in °C an. Daraus musst Du dann nur die drei im Display > anzuzeigenden Digits generieren. Der Temperatur könnte doch aber viel näher am kleineren Wert liegen, oder ? (ok, muss ja nur auf 1° genau sein) Hasso, Platz! schrieb: > Oder Du bist ganz clever und läßt > parallel zum Index k einen dreistelligen Dezimalzähler mitlaufen. Damit > hättest Du dann sofort nach der Suche schon die Digit-Information > vorliegen, ohne noch irgendetwas rechnen zu müssen. Das mit dem dreistelligen Dezimalzähler kapiere ich nicht.
:
Bearbeitet durch User
Au man, jetzt schlagen die hilfreichen Angebote schon - wenn auch per Zufall - aber immerhinque im Minutentkt ein. Ein offenes Wort: Und sie erschlagen mich! Das soll natürlich keine Beschwerde sein. Ich möchte damit nur ausdrücken, dass es mir sehr leid tut, zu sehen, wieviel Mühe ihr euch gebt und wieviel Zeit ihr da auch aufwendet.....und ich komme da auch im Ansatz nicht hinterher. Für mich ist ja noch eine einfache Schleife in C ein Abenteuer. Ich speichere aber fleißig alles ab, drucke es teilweise aus, hefte ab, und blättere im Datenwald (D-Handbüchern). Es ist so schade, dass ihr keine adäquate Rückkopplung für euren Einsatz bekommt. Es wird aber NICHTS übersehen oder nicht beachtet oder nicht vergessen! (Hab' ich jetzt eine Verneinung zuviel drin???) Frank Esselbach schrieb: > Hat der TE denn sein Dichigkeits-Problem gelöst? Nein, hat er nicht. Aber heute werde ich versuchen, einen Schlosser aufzutreiben, der mir helfen kann, den leider sehr großen Sensor in irgendein Gehäuse - vielleicht Metall-Rohr mit unten angelöteter Platte und da drin ein Gewinde für den S - zu verpacken. Evtl. ist das aber auch gar kein Problem, denn letztendlich kommt der S als direkter Ersatz für die Ölablassschraube unten in die Ölwanne. Und das wird bestimmt dicht, ist schließlich ein orig. Ersatzteil und auch kein China-Import. Zudem: Auf meine versuchten Eichmessungen kann ja verzichtet werden, wenn man die exakt angegebenen Widerstandswerte aus der Tabelle des Herstellers nimmt und dann schlicht sich an den Herrn Ohm erinnert. Die Genauigkeit der Anzeige soll ja nur bei 70°C hinreichend sein, in allen anderen Bereichen reicht es aus, zu wissen: Ne, das Öl ist noch genauso kalt wie mir auch oder aber: Nu' kocht das Öl, also runter vom Gaspedal! @ hp-freund: Alles wieder runtergeladen, schaue heute im Laufe des Tages rein. DANKE! Gruß, wilhelmT
Be Ti schrieb: > Die Genauigkeit der Anzeige soll ja nur bei 70°C > hinreichend sein, in allen anderen Bereichen reicht es aus, zu wissen: > Ne, das Öl ist noch genauso kalt wie mir auch oder aber: Nu' kocht das > Öl, also runter vom Gaspedal! Na, dann kann man ja die Tabelle noch kürzer machen :) zwischen 0 und 60 Grad in 5 Grad Schritten, danach in 1 oder 2 Grad Schritten, ab 80 Grad dann wieder in 5 Grad Schritten. Ich denke Du hast jetzt ausreichend Spielmöglichkeiten, Viel Erfolg. rgds
Be Ti schrieb: > Au man, jetzt schlagen die hilfreichen Angebote schon - wenn auch per > Zufall - aber immerhinque im Minutentkt ein. Ich weiß ja nicht, was an Vorschlägen hilfreich sein soll, die vor 30 Jahren als Lösung taugten. Teilweise in Assembler, dann soll nicht im Dezimalsystem gerechnet werden, 'float' ist böse und die Wandlung eines zweistelligen Wertes für die 7-Segment-Anzeige wird zum riesigen Problem aufgeblasen. Be Ti schrieb: > Das Prog soll in C erstellt werden. In C ist die Programmierung doch Kinderkram. Für jeden einzelnen Programmpunkt gibt es in der Codesammlung genügend beispielhafte Lösungen. Einfach einmal suchen!
6A66 schrieb: > Be Ti schrieb: >> Die Genauigkeit der Anzeige soll ja nur bei 70°C >> hinreichend sein, in allen anderen Bereichen reicht es aus, zu wissen: >> Ne, das Öl ist noch genauso kalt wie mir auch oder aber: Nu' kocht das >> Öl, also runter vom Gaspedal! > > Na, dann kann man ja die Tabelle noch kürzer machen :) zwischen 0 und 60 > Grad in 5 Grad Schritten, danach in 1 oder 2 Grad Schritten, ab 80 Grad > dann wieder in 5 Grad Schritten. Nö, jetzt reichen sogar 3 Leds und ein einfacher Fensterkomparator. ;-)
ich hab den quatsch oben nicht gelesen. die ist ein auszug aus einem alten programm. das ordnet einer frequenz ein volumina zu. und interpoliert zwischen den werten linear. kann also als 2 zeilige tabelle betrachtet werden oben frequenzen unten volumina. das alles ohne float usw sonden maximal 16 bit int
1 | // feld der frequenzen
|
2 | usint freq[31]={2277,2330,2386,2441,2496,2561,2623,2694,2759,\ |
3 | 2841,2932,3001,3099,3195,3297,3413,2519,3626,3767,3902,4050,\ |
4 | 4210,4380,4570,4810,5040,5290,5570,5880,6230,6550}; |
5 | // feld der zugeordneten volumina
|
6 | usint volu[31]=\ |
7 | {3152,3127,3102,3077,3052,3014,2945,2856,2755,2642,2519,2390,2255,2115,1971,\ |
8 | 1824,1676,1526,1377,1228,1081,937,789,662,533,411,298,196,108,37,0}; |
9 | /*!!! aus der später folgenden interpolierung dürfen
|
10 | die jeweiligen deltas der frequenzen multipliziert
|
11 | mit den deltas der volumina nicht 2^16(65xxx) überschreiten
|
12 | also bei 150 volumenschritten max 436hz schritte im freq bereich*/
|
13 | |
14 | ......
|
15 | ......
|
16 | ......
|
17 | |
18 | MAIN
|
19 | |
20 | |
21 | { // zuordung des messwertes ins frequenzfeld |
22 | for (arraypos=0; freq[arraypos]<=messwert;){ |
23 | arraypos++; |
24 | }
|
25 | if (freq[arraypos]==messwert) // gleicheit des messwertes mit feldelement? |
26 | volout=volu[arraypos]; // wenn gegeben, berechnung nicht nötig |
27 | else // bei ungleicheit, inerpolation notwendig |
28 | {i=arraypos-1; // i zeigt auf vorhergehendes feldelemnt |
29 | |
30 | // berechnung des volumens durch interpolieren
|
31 | volout=((((volu[i]-volu[arraypos])*(freq[arraypos]-messwert))\ |
32 | /(freq[arraypos]-freq[i])))+volu[arraypos]; |
33 | }
|
m.n. schrieb: > Be Ti schrieb: >> Das Prog soll in C erstellt werden. > > In C ist die Programmierung doch Kinderkram. Für jeden einzelnen > Programmpunkt gibt es in der Codesammlung genügend beispielhafte > Lösungen. Ich glaub meine Assembler Andeutungen sind etwas missverständlich. Ich wollte damit nicht sagen "programmiere das gefällig in Assembler" Natürlich ist die Programmierung in "C" Kinderkram. Wilhelm will sich ja Anhand des Projektes mit C beschäftigen also genau das richtige. Nur weil jetzt aber in C programmiert wird, muss man doch aber die Architektur des verwendeten Controllers nicht ignorieren oder völlig unnötig komplexe Rechnungen anstellen weil das in C ja so einfach ist. Be Ti schrieb: > Au man, jetzt schlagen die hilfreichen Angebote schon - wenn auch per > Zufall - aber immerhinque im Minutentkt ein. > Ein offenes Wort: Und sie erschlagen mich! Ja, scheint in diesem Forum so zu sein. Ich bin auch neu hier und etwas erschlagen von den Längen der Threads. Leider ist ausgerechnet meiner eine Ausnahme :-( Ich glaub ich muss mal ein bisschen zurückhalten und abwarten, wenn es eh schon 100.000 Meinungen gibt ;-)
m.n. schrieb: > Ich weiß ja nicht, was an Vorschlägen hilfreich sein soll, die vor 30 > Jahren als Lösung taugten. In C ist die Programmierung doch Kinderkram. > Für jeden einzelnen Programmpunkt gibt es in der Codesammlung genügend > beispielhafte Lösungen. Einfach einmal suchen! Wie gut, "m.n.", dass du alles besser weißt und für dich eh' alles Kinderkram ist. Erstaunlich, dass dann doch hier zahlreiche, teils sehr unterschiedliche Vorschläge unterbreitet werden. Alles Fachunkundige? Es ist offensichtich, dass du nicht verstanden hast, worum es in diesem Fred hauptsächlich geht, nämlich einem C-Anfänger bei den ersten, unsicheren Schritten zu helfen, und genau das haben die allermeisten User bisher getan. Angebliche oder selbsternannte Profis, für die alles so einfach ist, dass ihre beste Empfehlung : "Such mal" lautet, werden hier nicht gebraucht. Ich habe nie nach einer fertigen Lösung gefragt, es geht um den Weg und die ersten Schritte. Suche dir bitte ein anderes Betätigungsfeld für deine hochprofessionelle Hilfe. Danke! @ "Udo Schmidt": Mag sein, aber wenn man alle Freds hier daraufhin untersuchen würde, ob sie für den Einstellenden lebenswichtig sind, würde es vermutlich sehr, sehr ruhig im Forum werden. Wer will schon eine einzelne Led irgendwo glimmen haben? Ein gewisser Anspruch sollte akzeptierbar sein, und wer sagt denn, dass ich nach dem allerersten gelungenen Lauf des Projektes nicht vom Ergeiz gefasst werde, die Anzeige im kompletten Bereich in gute Genauigkeit zu bringen? Ich bin Anfänger und suche nach dem einfachsten Weg, das allererste Projekt zum Laufen zu bekommen. Aber ich lerne nicht C, um anschließend nichts draus zu machen. Da ist mein Ergeiz ein anderer. Also: Niemand muss sich zurückhalten, es sei denn, aus eigenem Wunsch. Lasst uns hier einfach machen, wer etwas beitragen möchte zu meinen ersten Schritten, ist hoch willkommen. Wer das nicht möchte, darf sein Engagement ja gänzlich entspannt auf andere Freds verteilen. Grüße, wilhelmT
Udo Schmitt schrieb: > Nö, jetzt reichen sogar 3 Leds und ein einfacher Fensterkomparator. > ;-) Radio Eriwan: Im Prinzip Ja - gefragt war aber ein Display. Obwohl: "eine dreistellige LED-Anzeige" - kann auch so wie von Dir interpretiert werden :) rgds
A6AA schrieb: > Udo Schmitt schrieb: >> Nö, jetzt reichen sogar 3 Leds und ein einfacher Fensterkomparator. >> ;-) > > Radio Eriwan: > Im Prinzip Ja - gefragt war aber ein Display. was aus ergonomischer Sicht im Auto gar nicht mal eine so gute Idee ist. Denn dann wandert der Blick alle 3 Sekunden dort hin um den Zahlenwert abzulesen. Der Zahlenwert an sich interessiert aber gar nicht, sondern eigentlich der Vergleich mit dem Grenzwert: sicher / nicht sicher Von daher sind ein paar LED, die sich ruhig verhalten solange alles im 'grünen Bereich' ist, allemal besser. Interessant ist ja im praktischen Betrieb nur der Ausnahmezustand. Alles andere ist Spielerei. Und ja. das kann man lernen. Ich war auch Zeit Lebens daran gewöhnt, die Wassertemperatur am Armaturenbrett irgendwo zumindest ungefähr ablesen zu können. Mein neuer C4 hat gar keine derartige Anzeige mehr, was am Anfang ein wenig irritierend war. Aber genau betrachtet, ist mir die Wassertemperatur ja wurscht, solange sie sich im günstigen Bereich bewegt. Interessant wird es nur, wenn das Kühlwasser zu heiss wird, und darauf macht mich die Karre mit einem Ping und einer Anzeige aufmerksam (denke ich mal, ist noch nie gekommen). Und dass ich bei kaltem Öl und Minusgraden nicht mit 7000 Touren aus dem Parplatz rauspresche, weil mir sonst der Ölfilm reist, ... dazu brauch ich wirklich keine Anzeige sondern ein bischen Hausverstand. Gut. Als Spielerei ist so eine Öltemperatur in einem PKW nett. Aber brauchen, brauchen tut die als Zahlenwert niemand. Eine Aussage 'kalt', 'heiss' bzw. normal (keine Warnung leuchtet) reicht völlig und lenkt bei vorliegen des Normalfalls nicht ab. Im Zweifel ist mir nämlich das Geschehen auf der Strasse wichtiger als die Öltemperatur. Meine Meinung. Da kann mir der Herr Willi so viel Ahnungslosigkeit unterstellen, wie er will.
:
Bearbeitet durch User
Karl Heinz schrieb: > Von daher sind ein paar LED, die sich ruhig verhalten solange alles im > 'grünen Bereich' ist, allemal besser. Das bringt mich ja auf eine ganz neue Idee. Wie wäre es mit einer RGB LED die man dann von Blau über Grün nach Rot durchmischen kann (also wenn mal wieder Langeweile aufkommt ;-) Karl Heinz schrieb: > Im Zweifel ist mir nämlich das > Geschehen auf der Strasse wichtiger als die Öltemperatur. Fährt er überhaupt auf der Strasse ?
Karl Heinz schrieb: > was aus ergonomischer Sicht im Auto gar nicht mal eine so gute Idee ist. > Denn dann wandert der Blick alle 3 Sekunden dort hin um den Zahlenwert > abzulesen. Früher hatten die Autos so ein analoges Schätzeisen. Das war mir gerade recht. Das mit der LED wäre ein 95/5 Ansatz (95prozent der Nutzer mit 5% Aufwand erschlagen). Und für die restlichen 5% der Nutzer brauchst Du entweder garkeine Anzeige (beratunbgsresiste Hausfrau ohne nennenswerte Motorkenntnisse) oder die hier besprochene. Der TO will die letzte Gruppe. Klar will ich das auch nicht - aber Kunde ist König :) Bin wieder raus. rgds
Karl Heinz schrieb: > Gut. Als Spielerei ist so eine Öltemperatur in einem PKW nett. Aber > brauchen, brauchen tut die als Zahlenwert niemand. Eine Aussage 'kalt', > 'heiss' bzw. normal (keine Warnung leuchtet) reicht völlig und lenkt bei > vorliegen des Normalfalls nicht ab. Ahnungslosigkeit ist so ganz falsch nicht, denn offenkundig unterwirfst du deine persönlichen Meinung, deinem eigenen Bedürfnis dasjenige aller anderen. Natürlich braucht der Großteil eine solche Öltemp-Anzeige (ÖTA) nicht, genausowenig wie die Wasser-Temp-Anzeige. Aber es gibt sehr wohl technisch interessierte Autofahrer und dann auch noch solche, für die es wirklich ein echter Zugewinn wäre, eine solche ÖTA zu haben. Da wäre z.b. die Gruppe derjenigen, welche einen Beruf ausüben, der werktägliche Mobilität in größerem Ausmaß erfordert. Und diese Autofahrer finden wenig Sinn darin, unnötige Zeit beim Fahren zu vertrödeln, und möchten andererseits den berufsnotwendigen Fahruntersatz nur dann zu beschleunigtem Einsatz bringen, wenn das technisch vertretbar ist. Und da ist eine ÖTA extrem sinnvoll. Die könnte übrigens sehr wohl als analoges Rundinstrument ausgeführt sein. Aber wo paßt sowas vom Styling her noch in ein Armaturenbrett, und dann - nicht übersehen - noch als Nachrüstung?!?! Was ich hier ganz deutlich von einigen - bitte auf die Differenzierung achten - von einigen vermisse, ist Toleranz. Weil ich wußte, dass es immer wieder Forenmitglieder gibt, die nicht fachlich helfen wollen, stattdessen sich aber völlig abarbeiten in einer von ihnen vom Zaum gebrochenen Debatte über den angeblichen Sinn des Projekt-Zieles, habe ich versucht, möglichst lange den Einsatzzweck nicht zu nennen. Und - tusch - kaum ist das doch passiert, fahren hier wieder User Sonderschichten in Selbstdarstellung ihrer persönlichen, unverbrüchlichen Ansichten. Schade Leute! Ihr könntet eigentlich zumindest in einem Fach-Forum darauf verzichten, euer Besser-Wisser-Tum anzubringen. Es gibt doch die berühmten "sozialen Medien", engagiert euch dort, das wäre für alle besser. Gruß, wilhelmT
Be Ti schrieb: > Und diese Autofahrer finden > wenig Sinn darin, unnötige Zeit beim Fahren zu vertrödeln, und möchten > andererseits den berufsnotwendigen Fahruntersatz nur dann zu > beschleunigtem Einsatz bringen, wenn das technisch vertretbar ist. Ich wußte bislang garnicht, daß Autobahnraser Probleme mit der Öltemperatur haben. hp-freund schrieb: > Be Ti schrieb: >> in einem Fach-Forum > > Genau. Wie weit bist Du mit deinem Projekt? Er macht seine ersten Schritte: Treten auf der Stelle ;-) Oder ist nach den vielen Empfehlungen, von ihm schon irgendein Codefitzel gezeigt worden?
m.n. schrieb: > hp-freund schrieb: >> Be Ti schrieb: >>> in einem Fach-Forum >> >> Genau. Wie weit bist Du mit deinem Projekt? > > Er macht seine ersten Schritte: Treten auf der Stelle ;-) Geht schon länger (*) Beitrag "Anfänger in C und welcher PIC (evtl. uno32) ist geeignet ?" (*) genau wie seine arrogante Art.
:
Bearbeitet durch User
Karl Heinz schrieb: > Geht schon länger (*) > Beitrag "Anfänger in C und welcher PIC (evtl. uno32) ist geeignet ?" > > (*) genau wie seine arrogante Art. Du hattest so etwas ja schon erwähnt, Deinen Beitrag aber wieder zurückgezogen. Daß es solche Abstauber gibt, kann man nicht verhindern. Schade ist nur, daß man auf ähnliche Anfragen anderer Personen zunehmend gereizter reagiert, obwohl es völlig zu Unrecht sein kann.
Das war ich glaub noch schuldig ..... DEIN Fühler so wie er ist und mit 270 Ohm parallel (soweit ich den Widerstand in der Tabelle richtig entziffern konnte).
Harry schrieb: > Das war ich glaub noch schuldig ..... DEIN Fühler so wie er ist und mit > 270 Ohm parallel (soweit ich den Widerstand in der Tabelle richtig > entziffern konnte). hättest im ersten Plot ja auch bis 300 max zeichnen können. Da hätte man besser sehen können, wie es im für ihm wichtigen Bereich aussieht. Wahrscheinlich auch so gut wie linear.
:
Bearbeitet durch User
Angehängte Dateien:
-
RTwPR_0-120_C.JPG
49 KB
und noch der Bereich mit Parallel-Widerstand. Der Knick kommt wohl von einem falschen Wert .... das konnte ich nicht richtig entziffern auf dem Scan.
Kennlinien Linearisierungen, davon habe ich ja ~1985 in der Ausbildung zum Elektroniker auch mal gehört. Aber wozu soll das hier gut sein ?
sieht ja nicht schlecht aus - würd ich nehmen. Wobei ich mit seinem interessanten Bereich eher so um die 70 (+- 15 oder +-20) meinte.
Für eine sinnvolle Berechnung werfe ich noch eine Taylorreihenentwicklung in die Runde. Die ist gar nicht mal so schwer zu implementieren, selbst in Fixed-Point. Nur die Skalierung ist eklig. Habe damit letzthin eine e^x-Berechnung in ca. fünf Zeilen Fixed-Point (nur mit Multiplikation, Addition und Rechtsshift) implementiert. Da war die Vorlesung Höhere Mathematik I und II mal wieder für was gut, auch wenn sie 20 Jahre her ist. Selbst mit Abbrechen nach dem 2. Glied wart der Fehler < 1%. Logarithmieren geht natürlich auch, siehe http://de.wikipedia.org/wiki/Taylorreihe#Exponentialfunktionen_und_Logarithmen Max
Angehängte Dateien:
-
RT_50-90_C.JPG
60 KB
Vlad Tepesch schrieb: > sieht ja nicht schlecht aus - würd ich nehmen. > > Wobei ich mit seinem interessanten Bereich eher so um die 70 (+- 15 oder > +-20) meinte. auch das noch ......
Es ist etliche Zeit vergangen, aber mein Programm steht vor der Fertigstellung. Das ist doch in Assembler geschrieben und läuft auf dem PIC18F14K22. Bei den letzten Arbeiten ist es mir auch gelungen, das Problem, das diesem Fred den Titel gegeben hat, selbst zu lösen. Nach dem von "thomas s" vorgegebenen Grobraster - danke sehr - hatte ich mir vor 3 Tagen endlich das Micr. Office zugelegt und auch Excel noch "nieder gerungen". Das kam für meine o.g. Tabelle dabei heraus: y= -4E-07xhoch5 + 0,0002xhoch4 -0,0379x³ +3,7723x² -208,18x +5.423,6 //R²=1 [ Für die ersten beiden Exponenten fand ich keine Möglichkeit auf meiner Tastatur, die "hochzustellen". ] Dieses Polynom werde ich für mein Prog mit einem PIC18 nicht nutzen, die Datentabelle kommt in den Prog-Speicher, die Zwischenwerte werden interpoliert, und nachdem ich auch die Tableread-Hürden geschafft habe, gelingt das ohne dieses P.. Aber mein ursprüngliches Ziel, auf einen PIC24 zu kommen, habe ich nicht vergessen. Meine Frage, gänzlich unabhängig davon, ob eine Alternative - z.B. wieder eine Tabelle zu nehmen - die bessere Lösung wäre: ist die Abarbeitung einer Formel wie oben in einem 16-bit-µC machbar, insbesondere unter der Berücksichtigung, dass Zeit fast kein Thema ist, also z.B. die Erneuerung des nächsten AD-Wertes alle 10 Sekunden keinerlei Ungemach bedeuten würde? Ein PIC24 hat auch für die Division eine Hardwareroutine (wenn auch nur 8 bit), für die Mulitpl. sowieso. Wäre das für diesen µC zu schaffen? Gruß, lippe1audi
Be T. schrieb: > Meine Frage, gänzlich unabhängig davon, ob eine Alternative - z.B. > wieder eine Tabelle zu nehmen - die bessere Lösung wäre: ist die > Abarbeitung einer Formel wie oben in einem 16-bit-µC machbar, Was'n das für eine Frage? Du scheinst unter der Prämimsse zu leben, dass man für fast alles einen Superboliden mit mindestens 32 Bit, 8GHz braucht und man sich mit weniger als 32MByte Speicher nicht abgeben braucht. Schon ein Wunder, dass man vor 45 Jahren zum Mond fliegen konnte und das mit einer Rechenleistung, die heute von jeder Kaffeemaschine locker überboten wird.
Karl H. schrieb: > Be T. schrieb: > >> Meine Frage, gänzlich unabhängig davon, ob eine Alternative - z.B. >> wieder eine Tabelle zu nehmen - die bessere Lösung wäre: ist die >> Abarbeitung einer Formel wie oben in einem 16-bit-µC machbar, > > Was'n das für eine Frage? Nur um das klipp und klar zu stellen. Die Berechnung ist auch für einen 8 Bit Rechner eine Fingerübung. Er braucht ein wenig länger als eine 16 Bit CPU. Aber wenn ein paar 100 Ergebnisse pro Sekunde reichen, dann ist das überhaupt kein Problem. Die angestrebten "1 Update alle 10 Sekunden" unterbietest du immer noch derartig heftig, das man befürchten muss, dass der PIC wegen Unterbeschäftigung eingeht. Irgendwie scheinst du auch nach einem halben Jahr noch immer keine Vorstellung davon zu haben, was du da eigentlich vor dir liegen hast und welche (erstaunliche) Leistung dieser kleine schwarze Käfer erbringen kann. Der hat mehr Rechenleistung als alle Menschen des 19. Jahrhunderts zusammen aufgebracht hätten.
:
Bearbeitet durch User
Karl H. schrieb: > Karl H. schrieb: >....auch nach einem halben Jahr noch immer keine Vorstellung davon zu > haben, was du da eigentlich vor dir liegen hast. Wie du vermutlich gelesen haben wirst, habe ich dieses Polynom erst vor 3 Tagen erstellt. Und meine Rechenerfahrung mit PIC beschränkt sich auf schlichte 16-bit-Addition, Subtraktion und 8-bit-Division. Das Ausrechnen des Polynoms mit meinem Taschenrechner war nicht gerade nach 10 Sekunden erledigt. Nein, ich hatte keinerlei Vorstellung davon, wielange ein eher noch kleinerer µC zum Ausrechnen solch komplexer Formeln benötigt, und ich geniere mich deswegen überhaupt nicht. Als fortgeschrittener Anfänger muss ich nicht wissen, bzw. können, was z.B. Profis oder aber Informatikstudenten wissen oder können. Wenn ich mal aus deinen aufgeregten - warum eigentlich ? - Vorwürfen eine Antwort auf meine Frage extrapoliere, dann bin ich beruhigt und freue mich auf diese späteren Zeiten. Und - ach ja - danke für den Kern der Antwort. Anbei sei gesagt, dass die Antwort ohne Aufregung noch willkommener gewesen wäre. Da du, Karl-Heinz, gerade mal zufällig da bist, sei persönlich für dich noch dieses gesagt: Für die Erstellung meines Programms habe ich drei fertige Routinen aus fremden Händen benutzt: Aus den Microchip-Handbüchern diejenige für die Initialisierung von Ports (3 Zeilen), und für die Init. des ADC-Wandlers, und dann aus einem Fachbuch ("Mit dem PIC-Controller erfolgreich arbeiten") die Routine für 16-bit-Subtraktion. Für die Tabellenerstellung gabs aus einem anderen Forum noch 7 Zeilen als Muster. Den "Rest" des Programms habe ich selbst geschrieben. Hat gedauert, und ist mir nicht immer leicht gefallen, aber immerhin selbst geschrieben. Mal sehen, ob dir dazu was einfällt. Grüße, wilhelmT
Be T. schrieb: > Nein, ich hatte keinerlei Vorstellung davon, wielange ein eher noch > kleinerer µC zum Ausrechnen solch komplexer Formeln benötigt, und ich > geniere mich deswegen überhaupt nicht. Als fortgeschrittener Anfänger > muss ich nicht wissen, bzw. können, was z.B. Profis oder aber > Informatikstudenten wissen oder können. Entschuldige das ich lache. Aber das hat nichts mit Informatikstudium zu tun. Das ist ganz einfach beobachten! Dein PIC macht (je nachdem wie schnell du ihn taktest) irgendwas ab ca 1 Million Befehle aufwärts. Was denkst du was die tun? Der Kern deiner Frage reiht sich nahtlos in den Rest dieses Thread (und des vorhergehenden) ein. Kaum zu glauben, dass du in früheren Zeiten schon jemals irgendetwas programmiert hast. Soll heissen: ich glaubs jedenfalls nicht. So und jetzt bin ich wieder raus. Hab mir den Thread noch mal von Anfang an durchgelesen und da kommen Erinnerungen hoch. > 16-bit-Subtraktion. Für die Tabellenerstellung gabs aus einem anderen > Forum noch 7 Zeilen als Muster. Den "Rest" des Programms habe ich selbst > geschrieben. Hat gedauert, und ist mir nicht immer leicht gefallen, aber > immerhin selbst geschrieben. > Mal sehen, ob dir dazu was einfällt. Ja. Schwach. (wenn du mich schon so fragst). Und nein. Das ist auch für einen Amateur schwach. Das wäre selbst für einen blutigen Anfänger schwach (der du ja vorgibst nicht zu sein) Beschwer dich jetzt nicht - du hast es herausgefordert.
:
Bearbeitet durch User
Schade. Erwartet hatte ich, dass du erkennen und auch zugestehen würdest, dass die damaligen Vorwürfe (sinngemäß "nur abkupfern wollen") voreilig und vor allem falsch waren. Zudem: Dass du es auch jetzt dir immer noch nicht verkneifen kannst, über einen Anfänger im Programmieren her zu ziehen, ist bedauerlich und wirft ein gewisses Licht auf dich! Dass ausgerechnet ein Moderator derart agiert, ist bedenklich. Schade, ich hatte mir vor deinem obigen Statement vorgenommen, einen verbalen Schlussstrich unter die damaligen Aufgeregtheiten zu ziehen. Leider kann ich nicht erkennen, dass du zu einem Entgegenkommen bereit bist. Grüße, wilhelmT
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.