Hallo Leute, Suche eine Möglichkeit eine halbwegs genaue (+-0,1°C) Berechnung des Taupunktes zu unternehmen. ABER OHNE LOGARITMUS NATURALIS!!!! Es handelt sich um eine Kleinsteuerung, welche nur mit Integerwerte rechnen kann. (-32768 bis +32767) Daher kann ich keine Exponentialfunktion/Logaritmus benutzen :-( Bereits gegeben sind: Temperatursensor (-40°C bis +60°C) Feuchtesensor ( 0% bis 100%) Absolutfeuchtesensor ( 0 g/m³ bis 50g/m³) Lässt sich diese Aufgabe irgendwie lösen?
Mit einer Look-up-table sollte das gehen. Alle 5°C eine Stüzstelle und dazwischen linear oder quadratisch interpolieren.
Dewi schrieb: > Lässt sich diese Aufgabe irgendwie lösen? Wie wärs mit einer Tabelle, wo Stützpunkte der Funktion abgelegt sind? Und dann einfach zwischen ein zwei Punkten interpolieren...
Es würde mich allerdings wundern, wenn das Problem nicht schon in vereinfachter Ganzzahlarithmetik gelöst wäre. Ansonsten: In Zeiten, als es noch keine Taschenrechner gab, hat man für so etwas einen Rechenschieber oder eine Tabelle herangezogen. Leg Dir doch so eine Tabelle an, nicht in normalen, sondern in angepassten Abständen - sonst wird's zu ungenau - und interpoliere den Rest. Ist eigentlich nur eine Frage des vorhandenen Platzes und der gewünschten Genauigkeit.
Vielleicht hilft dir dieses
1 | double pow10(double x) |
2 | {
|
3 | return exp(x*2.30258509299404568402); |
4 | }
|
5 | double t,h,dew; |
6 | int temp,humi; |
7 | |
8 | temp=sbus_measure(MEASURE_TEMP); |
9 | t = temp*0.01-40.1; // calc. temperature from ticks to [°C] for 5V supply |
10 | humi=sbus_measure(MEASURE_HUMI); |
11 | h = 0.0367*humi-0.0000015955*humi*humi-2.0468; // -0.0000028*(float)humi*(float)humi + 0.0405*humi - 4.0; // calc. humidity from ticks to [%RH] |
12 | h = (t-25) * (0.01+0.00008*humi) + h; // calc. temperature compensated humidity [%RH] |
13 | dew = 216.687 * (h/100.0)*(6.1078*pow10(7.5*t/(237.3+t))) / (t+273.15); |
Ich weiss, ein exp ist nicht signifikant anders als ein log10.
Welche Formeln verwendest Du? Ich kenne mich nicht so gut mit der Luftfeuchtigkeit aus. Aber wenn die Formen die Du verwendest diesen hier ähneln, dann sollte das möglich sein. http://www.wetterochs.de/wetter/feuchte.html Die Frage ist nur wie genau es werden soll und wieviel Speicher zur Verfügung steht. Dann kannst Du die Funktionen mal am PC plotten lassen und dann Stützstellen so wählen, daß bei einer (linearen) Interpolation der Fehler unter deinen Grenzwerten bleibt. Diese Stützstellen kommen dann in ein Array auf dem µC. Damit kann man dann die Funktion mit relativ wenig Rechenleistung bewältigen. Ein großer Wertebereich und eine hohe Anforderung an die Genauigkeit können aber den Speicherbedarf stark ansteigen lassen.
Hallo, anstatt Tabellen kann man auch transzendente Funktionen ersetzen durch ein Polynom n-ten Grades, das die gewünschte Funktion im Messinterval genau genug approximiert. Ich verwende z.B. für die Temperatur eines Pt100 die Formel
1 | 3.27946 * R * R + 106.54505 * R - 9.04725 |
anstatt der Exponentialfunktion, das sind nur 3 Multiplikationen und das Ergebnis ist +- 0,1 Grad genau von -20 bis +100 Grad Celsius. Welchen Polynomgrad man für eine bestimmte Genauigkeit braucht, muss man berechnen, ich lasse mir die Koeffizienten von MathCad kalkulieren. Und bevor jetzt das Riesengeschrei losgeht - natürlich kann man auch Tabellen verwenden. Aber so ist das Problem in einer Programmzeile gelöst. Jeder nach seinen Vorlieben und Fähigkeiten. Gruss Reinhard PS wieso muss man Multiplikationen mit "*" als Code deklarieren, damit das Mal-Zeichen nicht verschluckt wird??
@ Reinhard Das geht natürlich auch, ist sogar viel eleganter, aber es wurden sehr enge Grenzen bei der Fragestellung gesetzt. Da könnte es knapp werden mit dem Wetrtebereich. Prinzipiell könnte man den natürlich aufblähen. Aber ob das so leicht vom Themenersteller in seiner Umgebung mit seinen Mitteln zu bewerkstelligen ist? Ich finde deinen Ansatz natürlich auch viel schicker. Dewi schrieb: > Es handelt sich um eine Kleinsteuerung, welche nur mit Integerwerte > rechnen kann. (-32768 bis +32767)
Carsten R. schrieb: > Dewi schrieb: >> Es handelt sich um eine Kleinsteuerung, welche nur mit Integerwerte >> rechnen kann. (-32768 bis +32767) Da hast du recht, das ist eine herbe Einschränkung - da muss man ja ständig hin und her normieren um überhaupt im erlaubten Zahlenbereich zu bleiben. Irgendwie geht immer alles (siehe Turing), aber so recht sinnvoll kann man die Aufgabe nur mit Gleitkommaarithmetik rechnerisch (ohne Tabellen) lösen. Gruss Reinhard
Welche Funktion hättest du denn gerne mit Integerarithmetik berechnet: Die von Carsten gepostete http://www.wetterochs.de/wetter/feuchte.html oder die aus Wikipedia (Gl. 2.3) http://de.wikipedia.org/wiki/Taupunkt#Der_Taupunkt_in_Abh.C3.A4ngigkeit_von_relativer_Luftfeuchtigkeit_und_Lufttemperatur ? Es handelt sich beidesmal um die gleiche Funktion, aber mit leicht unterschiedlichen Parametern. Eine von beiden wird wohl in dem von dir gewünschten Temperatur- und Feuchtebereich bessere Ergebnisse liefern als die andere. Die Frage ist nur welche. Dewi schrieb: > Suche eine Möglichkeit eine halbwegs genaue (+-0,1°C) Berechnung des > Taupunktes zu unternehmen. Ich weiß nicht, ob die ±0,1 K realistisch sind. Alleine die Abweichung zwischen den beiden o. g. Funktionen ist schon größer. Das sind eben auch nur Näherungsfunktionen. > ABER OHNE LOGARITMUS NATURALIS!!!! Die Taupunkttemperatur ist in erster Näherung eine logarithmische Funktion der relativen (und auch der absoluten) Luftfeuchtigkeit. Möchte man den kompletten Wertebereich der Luftfeuchtigkeit ab 0% abdecken, gibt es keine einfachere Näherungsfunktion. Man kann allenfalls versuchen, den Logarithmus in Integerarithmetik zu berechnen. Liegt die relative Luftfeuchtigkeit unter 1%, wird die Taupunktbestimmung aber sowieso ungenau, da in diesem Bereich bereits ein kleiner Fehler in der Feuchtigkeitsmessung zu einem großen Fehler im Ergebnis führt. Dagegen hilft auch die exakteste Formel oder die feinstaufgelöste Wertetabelle nicht. Aber treten solch niedrige relativen Luftfeuchtigkeiten in der Realität überhaupt auf? Wird der Wertebereich der relativen Luftfeuchtigkeit bspw. auf 10%–100% oder gar 20%–100% eingeschränkt, sieht die Sache schon sehr viel günstiger aus. Da sich die Messwerte dann nur noch über eine Dekade erstrecken, kann man den Logarithmus auch – wie von Reinhard vorgschlagen – durch ein relativ einfaches Polynom annähern. > Feuchtesensor ( 0% bis 100%) > Absolutfeuchtesensor ( 0 g/m³ bis 50g/m³) Da die relative und die absolute Luftfeuchtigkeit bei Kenntnis der Temperatur ineinander umgerechnet werden können, reicht prinzipiell einer von beiden Feuchtesensoren. Welcher ist genauer? Oder kann es sein, dass der eine bei trockener und der andere bei feuchter Luft bessere Ergebnisse liefert? Dann müsste die optimalen Bereiche für jeden Sensor kennen, so dass man immer den jeweils günstigsten auswählen kann.
Dewi schrieb: > Suche eine Möglichkeit eine halbwegs genaue (+-0,1°C) Berechnung des > Taupunktes zu unternehmen. Ach ja, diese Genauigkeit ist alles andere als halbwegs genau. Man kann schon froh sein wenn man überhaupt auf 0,5 Grad genau die Temperatur messen kann. Man schafft vielleicht eine höhere Auflösung, diese ist dann abwer nicht genau. Macht es da Sinn die Berechnungen mit einer höheren Genauigkeit auszuführen als es die Sensoren erlauben? Das ist wirklich sehr kontextabhängig was man genau vor hat.
Dewi schrieb: > LOGARITMUS Da krümmen sich einem die Fußnägel. http://de.wikipedia.org/wiki/Logarithmus
Ich würde mich mal beim DWD erkundigen, was für relative Feuchten in unseren Breiten erreicht werden. 10% klingt nach künstlich getrockneter Luft oder nach einer Grußbotschaft aus dem Kühlhaus.
Das Problem ist eben der Integer Wertebereich. Es kann also nicht mit Gleitpunkt gerechnet werden.
Aber man kann den Integer als Festkommazahl mißbrauchen. Ob man nun den Integer beispielsweise als 3141 oder als 3,141 (Pi) liest ist letztlich egal. Bei Festkomma ist ein Cast nur eine Frage der Interpretation. Man muß nur aufpassen daß man mit dem Wertebereich auskommt. Wenn man weiß daß die zahlen beispielsweise nie über 600 hochlaufen, könnte man den Integer 30000 als 600 lesen ind jeder Ingegerschritt entspräche einem Festkommasprung von 600/30000 = 0,02. Dann muß man diese Umwandlung nur ganz am Ende bei der Ausgabe berücksichtigen. Das ist zwar kein Gleitkomma, aber manchmal schon ausreichend genau, wenn die auftretenden Zahlen in ihrer Größenordnung vorher schon absehbar sind. Und das scheint mir in diesem Fall zutreffend zu sein.
Ich kenne ehrlich gesagt keinen µP, dem man nicht, zumindest durch Tricks, eine 64 Bit Integerrechnung aufsetzen könnte. Selbst die 08/15-er 8-Bit-Grübler können das. Die Alternative: Erst dividieren und dann multiplizieren verträgt sich nicht mit dem Begriff "Genau".
amateur schrieb: > Ich kenne ehrlich gesagt keinen µP, dem man nicht, zumindest durch > Tricks, eine 64 Bit Integerrechnung aufsetzen könnte. Das liegt auch sicher nicht am (bisher geheimen) Prozessor, sondern an der Softwareausstattung des Systems. Meine approximierten Polynome habe ich schon im vorigen Jahrhundert auf einem Z80 eingesetzt, und der hatte keinerlei Probleme damit. Gruss Reinhard
und wie wäre es mit einem bereichsflag? dann wären nur die mantissen der logrithmen mit hinreichender Auflösung aus einer tabelle zu entnehmen der Rest ist linear zu berechnen. Der Rechenschieber lässt grüßen. p.s. die Fusnägel folgen in ihrer Krümmung ebenfals dem Logarithmus naturalis ;)
@Reinhard Aber auch Opa z80 kannte bereits ADC und SBC. @Winfried Das mit den Fußnägeln erscheint mir auch nicht unbedingt praktikabel. Die Skalierung anhand der Schuhgröße und die Anpassung über den Platzfußkoeffizienten dürfte das wohl als zu umfangreich disqualifizieren.
Dewi schrieb: > Das Problem ist eben der Integer Wertebereich. Das ist ein Problem, aber nur ein ganz kleines. Prinzipiell könnte man auch auf der Basis von 16-Bit-Integer-Arithmetik eine Floating-Point-Bibliothek mit beliebiger Genauigkeit aufbauen. Das wird auf jedem Mikroprozessor ohne FPU so gemacht. Das löst aber dein eigentliches Problem nicht, da die Ungenauigkeit nicht von der Berechnung, sondern der Messung kommt. Rechenbeispiel: Temperatur: 60 °C Relative Luftfeuchtigkeit: 3,10% Nach der Formel in Wikipedia liegt dann der Taupunkt bei 0,18 °C. Angenommen der Feuchtesensor wäre ultrapräzise und hätte einen Fehler von nur 0,05%. Er misst also 3,15% statt 3,10%. Eingesetzt in die Formel ergibt dies 0,40 °C. Der Fehler im Taupunkt liegt somit bei 0,22 K, also mehr als doppelt so hoch wie die von dir geforderten 0,1 K. Ich glaube aber nicht, dass dein Sensor einen Messfehler von nur 0,05% hat. 2% sind da schon sehr viel realistischer. Bei 3,10% + 2% = 5,1% ,liegt der berechnete Taupunkt schon bei 7,25 °C. Das ist ein Fehler von mehr als 7 K. Weitet man den Wertebereich des Taupunkts auf negative Temperaturen aus (dann heißt der Taupunkt Frostpunkt), wird die Sache noch sehr viel schlimmer. Merkst du etwas? Es bringt überhaupt nichts, an der Genauigkeit Approximation oder der Arithmetik herumzudoktern, bevor du die erwartete Genauigkeit und der betrachtete Messbereich sinnvoll festgelegt hast.
Wenn sich einem da mal nicht die Fußnägel hochrollen. ;-) Reinhard Kern schrieb: > Das liegt auch sicher nicht am (bisher geheimen) Prozessor, sondern an > der Softwareausstattung des Systems. Genau das vermute ich auch. Ich erinnere mich beispielsweise noch an ein System Namens Basic Tiger. Das waren fertige Module die eine lange Zeit immer auf der Rückseite der c't beworben wurden. Die hatten auch eine eigene Entwicklungsumgebung. Das System gibt es bis heute noch. Zudem gibt es noch andere SPS und Mikro-SPS Systeme. Da kommt es darauf an was die IDE zuläßt, bzw. was man leicht damit implementieren kann. Vom darin werkelnden µC bekommt der Nutzer nichts mit. Auch wenn man diesen unter umgehen der IDE direkt hardwarenah programmieren könnte und somit auch Gleitkomma implementieren könnte, so ist bei solchen Systemen davon abzuraten. Zum einen verliert man den Komfort der IDE und zum anderen ist das vorhandensein eines speziellen µC keine zugesicherte Produkteigenschaft. Der µC könnte von Charge zu Charge, je nach Verfügbarkeit, Markt und Preislage und auch durch Modernisierungen der Produktlinie (auch beim Zulieferer), jederzeit wechseln. So gibt es vom Rondostat unterschiedliche Versionen, mal mit Atmel und mal nicht. Der Nutzer wird dank der IDE nicht mit dem Hardwarewechsel hinter den Kulissen belästigt. Das wäre dann Bestandteil den Konzeptes. Man muß sich dann aber nach den Möglichkeiten der IDE richten und nicht nach den Möglichkeiten der Hardware.
Es handelt sich um eine ELC-12 Stuerung von http://www.xlogic-plc.com/ . Es handelt sich um keinen uC. Die PLC wird Blockorientiert programmiert. Daher das Problem mit der Berechnung. Die Steuerung kann nur + - * : Mehr nicht.
>Die Steuerung kann nur + - * : Mehr nicht.
Vielleicht solltest du die Taupunktberechnung mitsamt dem zugehörigen
Sensor einer Sub-Baugruppe zuordnen, die dann das Ergebnis über RS232
oder wie auch immer der besagten Kleinsteuerung zuschickt.
Gruss
ah ein LOGO Clone hehe IDE beschränkung also volltreffer am ende ist da ach nur ein µC drinnen .... also Tabelle Ich wette es geht um Kondenswasservermeidung mittels Heizung/Lüftung deren Energieverbrauch optimiert werden soll.
Dewie schrieb: > Es handelt sich um eine ELC-12 Stuerung von http://www.xlogic-plc.com/ . > Es handelt sich um keinen uC. Selber Schuld, wenn man son SPS Abklatsch verwendet. Die Dinger machen dir n Treppenhauslicht und ne Marquisensteuerung, nicht aber unbedingt gute Regler oder gute Frequenzmesser oder gute Messgeräte... Dafür sind die nicht gebaut worden. Rechnen ist meist garnicht deren Stärke. Ich nutze für sowas immer n µC mit der Peripherie die ich genau für mein Projekt brauche! Guck mal auf der Homepage, wofür dein Gerät gebaut ist... "being specifically designed to replace mini PLCs, multiple components, such as , various timers, relays, contactor and counters etc;" Da du das Ding jetzt aber hast, musst du dir ne Lösung überlegen, Tabelle wird das Ding wohl auch nicht können... Ingo
Hallo, also ich habe mir mal vor einigen Jahren meine Floating Point Library selber Programmiert, weil zu der Zeit noch kein Compiler eine wirklich fehlerfreie hatte. Meine Library hatte mit Log und Exp eine Codegröße von 1,8Kbyte auf dem 8051. Wo liegt also das Problem. (Die Compiler sind doch heute gut!!!) Ich stand vor ca.15 Jahren als ich mit Sensoren angefangen habe auch vor dem Problem, dass ich bemerkte das es auch mit 64 Bit Mathe nicht mehr weiter ans Ziel geht. Also war Floating Point bis Heute der richtige Weg mit unter. Dann zum Thema Tausensor, wie Yalu X. das Rechenbeispiel schon aufgeführt hat, kann ich nur bestätigen du wirst mit dem Feuchtesensor nicht auf deine gewünschte Genauigkeit kommen. Meine Firma hat solsche Tausensoren gekauft, verbaut und anschließend alle verschrottet. Ein ordentlicher Tausensor geht nur mit der Spiegelmessung. Gruß Sascha
Eine Taupunktformel ohne Logarithmus... http://wwwcaps.ou.edu/arpsbrowser/arps5.2.4browser/html_code/adas/mthermo.f90.html t in °C, rh in % x = 1.0 - 0.01 * rh; // dew point depression dpd = (14.55 + 0.114 * t) * x + ((2.5 + 0.007 *t) * x)^3 + (15.9 + 0.117 * t) * x)^14 dpt = t - dpd; > Meine Firma hat solsche Tausensoren gekauft, verbaut und anschließend > alle verschrottet. Ein ordentlicher Tausensor geht nur mit der > Spiegelmessung. http://www.rotronic.de/hc2-hk25-hc2-hk40.html Im Handbuch ist ein Diagramm zur Genauigkeit der Taupunktberechnung und diese reicht in den meisten Fällen aus. Wenn es wirklich auf +-0.1 K genau sein soll, geht es allerdings wirklich nur mit einem Taupunktspiegel...
>(14.55 + 0.114 * t)
... sieht nicht gerade nach Vorzeigeintegerzahlen im Bereich von -32K
bis +32K aus.
Angehängte Dateien:
-
tp-abs.png
44 KB -
tp-diff.png
43 KB
Arc Net schrieb: > Eine Taupunktformel ohne Logarithmus... > http://wwwcaps.ou.edu/arpsbrowser/arps5.2.4browser/html_code/adas/mthermo.f90.html Ja, diese Approximation sieht wirklich nicht schlecht aus. Sie hat im Bereich der relativen Luftfeuchtigkeit von 7% bis 100% und der Temperatur von -40 °C bis +60 °C eine maximale Abweichung von unter 0,5 K bezogen auf die Formel in Wikipedia. Bei sehr geringer Luftfeuchtigkeit steigt der Fehler erwartungsgemäß stark an. Aber wenn die Formel für amerikanische Wissenschaftler gut genug ist, sollte sie es für Dewi ebenfalls sein ;-) Amateur schrieb: >>(14.55 + 0.114 * t) > > ... sieht nicht gerade nach Vorzeigeintegerzahlen im Bereich von -32K > bis +32K aus. In dieser Form natürlich nicht. Das Stichwort lautet "Skalierung".
Yalu X. schrieb: > Aber wenn die Formel für amerikanische Wissenschaftler gut genug ist, > sollte sie es für Dewi ebenfalls sein ;-) Das auf jeden Fall ;) Soll es genauer werden, müsste auch der Luftdruck miteinbezogen werden und wenn es noch genauer werden soll auch, ob andere Gase und nicht nur Wasserdampf vorhanden ist... Von Vaisala gibt es dazu eine gute Formelsammlung http://forms.vaisala.com/LP=605 oder ... http://cires.colorado.edu/~voemel/vp.html http://www.hygrometers.com/wp-content/uploads/CR-1A-users-manual-2009-12.pdf und "ITS-90 FORMULATIONS FOR VAPOR PRESSURE, FROSTPOINT TEMPERATURE, DEWPOINT TEMPERATURE, AND ENHANCEMENT FACTORS IN THE RANGE –100 TO +100 C" http://www.thunderscientific.com/tech_info/reflibrary/its90formulas.pdf
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.