Das Wetterstationen Forum

Die Karte in Post #1 mit den hohen rel. LD Abweichungen um mich herum deute ich so, dass es für viele Wetterstations-Besitzer, die auch nicht so tief in der Materie drin sind wie ihr, offenbar nicht einfach ist, ihren LD zu kalibrieren, oder dass sie sogar daran scheitern.
Die absoluten Messwerte werden nicht das Problem sein,- die heutigen I2C Mess-Chips sind schon recht genau. Meine drei (s.o.) weichen nur um 0,2 hPa voneinander ab, sogar mein Torricelli-Barometer liegt so mit +- 5 hPa ganz gut (nur nebenbei...).
Also, was soll ein Anfänger machen, um seinen rel. LD gut einzustellen?
Mein Flughafen in der Nähe (21km) gibt nur QNH und QFE an, dem METAR kann ich auch die Landebahnhöhe, auf die sich ja der Druck bezieht, entnehmen. Auch T und T-12 finde ich für den Flugplatz und für meinen Standort heraus. Aber, was hilft mir das für eine praktikable Lösung?
Wäre also mein Vorgehen in Post #6 zusammen mit der Ermittlung meiner Stationshöhe (Post #4) erstmal o.k. für den Anfang? Und wenn ja, was könnte danach (später) noch eine Verbesserung bringen?

Also, meiner Meinung nach genügt es vollkommen, mit dem Starpath-Druckumrechner (https://www.starpath.com/barometers/baro_cal.php) das relative Offset zu berechnen.
- Höhe der Konsole bzw. des Drucksensors über N.N. bestimmen
- aktuellen lokalen Druck (ABS) ablesen
- (aktuelle Temperatur + Temperatur vor 12 Stunden*)/2 berechnen und eingeben
- die richtigen Einheiten wählen (°C, m, hPa)
ausrechnen - den SLP Offset in der Konsole unter "Rel. Offset" eintragen
das war's.

*) der Durchschnittwert der vergangenen 12 Stunden kommt daher, dass sich die Temperatur erst mal richtig verteilen muss (Luft durchmischen), um den zusätzlichen Druck der vertikalen Komponente der Luftteilchenbewegung einigermassen richtig zu erfassen
diesen Ansatz benutzen viele Wetterprogramme (Datenloggerprogramme), was bei der Software weewx dazu führt, dass sie bei bestimmten Einstellungen (Luftdruckbestimmung per Software anstelle des relativen Luftdruckwertes der Konsole) nach der Erstinstallation erst nach 12 Stunden einen Luftdruckwert liefert - und schon manche Erstnutzer zur Verzeifelung gebracht hat )

Wenn Du die Thematik vertiefen willst, findest Du dazu in meinem englischsprachigen WiKi nochmal eine gute Erklärung zur Vorgehensweise
https://meshka.eu/Ecowitt/dokuwiki/doku ... _barometer.
[Bei Übersetzungsbedarf: https://www.deepl.com]
und einen internen WiKi Link ("Barometer", grün), wo sich ein kanadischer Luftdruck-Fan in die Tiefen der Materie begibt.
Ist, wenn man Zeit und Interesse hat, sicher interessant.

Für mich reicht der oben beschriebene Ansatz und ich kann in weiteren Verfeinerungen keinen Mehrwert für mich ableiten. Aber das kann/muss/soll jeder so tun, wie es zu ihm passt.

Mike97 hat geschrieben: 04 Nov 2024, 00:23 Und dann kommt AWEKAS um die Ecke und sperrt deinen LD-Sensor.

AWEKAS war auch der Grund, der mich in das Thema getrieben hat.

Mike97 hat geschrieben: 04 Nov 2024, 00:23 Ich habe es hier in den Bergen in größerer Höhe (1250m) nicht einfach, den Luftdruck genau zu bestimmen. I

Laut dem Deutschen Wetterdienst kann man den auf Meereshöhe reduzierten Luftdruck (relativen Luftdruck) bei Stationen oberhalb von 750 m Meereshöhe nicht mehr sinnvoll bestimmen. Die würden dort den Geopotentialwert der 850hPa-Fläche nehmen.

Mike97 hat geschrieben: 04 Nov 2024, 00:23 Und dann kommt AWEKAS um die Ecke und sperrt deinen LD-Sensor. Ich habe es hier in den Bergen in größerer Höhe (1250m) nicht einfach, den Luftdruck genau zu bestimmen. Ich habe durch Cumulus MX einen Wert, den das Programm anscheinend per barometrischer Höhenformel errechnet, dennoch ist das immer noch rund 4hPa weniger als von der 2Km entfernten offiziellen Station in Sterzing.

Ist das wirklich so verrückt? Ich kann mir immer nicht so recht vorstellen, dass AWEKAS einen Luftdrucksensor sperrt, weil er 4hPa Abweichung zu einer 2km entfernten Station aufweist, die noch dazu 300m tiefer liegt. Und eigentlich sollte AWEKAS auch wissen, dass die Messungen immer komplizierter werden, desto höher man ist....

sollte, ja ...
aber es scheint dort bei AWEKAS wohl einige Eigenwilligkeiten zu geben (oder gegeben haben), die Körperreaktionen zwischen Stirnrunzeln und Aufrollen der Fussnägel nach sich zogen.

Gyvate hat geschrieben: 04 Nov 2024, 06:54 Also, meiner Meinung nach genügt es vollkommen, mit dem Starpath-Druckumrechner (https://www.starpath.com/barometers/baro_cal.php) das relative Offset zu berechnen.
- Höhe der Konsole bzw. des Drucksensors über N.N. bestimmen
- aktuellen lokalen Druck (ABS) ablesen
- (aktuelle Temperatur + Temperatur vor 12 Stunden*)/2 berechnen und eingeben
- die richtigen Einheiten wählen (°C, m, hPa)
ausrechnen - den SLP Offset in der Konsole unter "Rel. Offset" eintragen
das war's.

*) der Durchschnittwert der vergangenen 12 Stunden kommt daher, dass sich die Temperatur erst mal richtig verteilen muss (Luft durchmischen), um den zusätzlichen Druck der vertikalen Komponente der Luftteilchenbewegung einigermassen richtig zu erfassen
...
Für mich reicht der oben beschriebene Ansatz und ich kann in weiteren Verfeinerungen keinen Mehrwert für mich ableiten. Aber das kann/muss/soll jeder so tun, wie es zu ihm passt.

Prinzipiell reicht mir das auch so.

Weil ich mich als Anfänger jetzt gerade damit beschäftige, muss ich aber nochmal etwas nachfragen.
Meine Stationshöhe habe ich jetzt recht gut mit 77,8m +- 1m bestimmt.
Wenn ich dann den Starpath-Druckumrechner benutze, frage ich mich, "welchen" Korrekturwert ich am besten für mich nehmen kann.
Rechne ich das mit meiner Stationshöhe und der Standardatmosphäre (15 °C, 1013,2 hPa), erhalte ich den Korrekturfaktor 9,34.

ABER:
Rechne ich mal interessehalber für meine Höhe und 15 °C bei abs. Druckwerten von 800 bis 1070 hPa die Korrekturfaktoren aus, erhalte ich Werte zwischen 7,37 (@800 hPa) und 9,86 (@1070 hPa).
In einer zweiten Rechnung für meine Höhe und bei abs. 1013,2 hPa ermittele ich dann die Korrekturfaktoren für Temperaturen von -50 bis +50 °C. Die Werte liegen zwischen 12,39 (@-50°C) und 8,24 (@+50°C).

Extremwerte wären dann:
1070 hPa bei -50 °C -> Korrekturfaktor 13,09
800 hPa bei +50 °C -> Korrekturfaktor 6,51

Meine Fragen:
1. Der Korrekturwert 9,34 (Standardatmosphäre, meine Stationshöhe) ist ok? Nehmt ihr das so auch für eure Stationen?
2. Macht es stattdessen Sinn, die in meinem Teil der Welt konkret vorkommenden abs. Min.-Max. Druckwerte und Min.-Max. Temperaturen zu ermitteln (d.h. irgendwo nachzulesen), dann im Sinne der o.g. Extremwerte den höchsten und niedrigsten Korrekturfaktor zu berechnen und den Mittelwert zwischen beiden als meinen Korrekturwert zu nehmen?
3. Müsste es nicht streng genommen eine "Automatische Rel.-Luftdruck-Korrektur" Funktion in den Konsolen geben in der Form, dass ich nur meine Höhe oder meinen Korrekturfaktor (errechnet aus meiner Höhe bei Standardatmosphäre) eingebe. Dann erfolgt in der Konsole fortlaufend eine Berechnung/Korrektur des Korrekturfaktors abhängig vom aktuellen abs. Luftdruck und der Außentemperatur (T)? Auch (T-12h) wäre ja kein Problem ..., sogar die Außenfeuchte ließe sich ja einrechnen.

Hi!

Ich habe hier nie einen Luftdruck unter 978,1 hPa und ueber 1045,5 hPa gehabt.
Auch die Temperaturen sind zumindest hier in Berlin/Brandenburg weit von Deinen theoretischen +-50°C entfernt: min: -13,1°C und max: 39,2°C.
Insofern ist der "Korridor" doch deutlich kleiner als in Deiner Beispielrechnung.

Sofern man nicht die durschschnittliche Temperatur der letzten 12 Stunden hat, ist die Nutzung von 15°C nicht so verkehrt.

Ich finde uebrigens den deutschen Rechner besser verstaendlich und uebersichtlicher.

Und ja - auch wir wuenschen schon lange eine automatische temperaturkompensierte Luftdruckberechnung durch die Konsole.
Man sollte nur die Hoehe des Barometers angeben (der ist im Allgemeinen in der Konsole und nicht im Aussensensor!).
Die SLP-Berechnung sollte dann durch die Konsole geschehen.
Noch aber ist Ecowitt nicht so weit - wir arbeiten daran ...

Mit der Excel-Tabelle anbei kannst Du etwas spielen ...


Oliver

olicat hat geschrieben: 08 Nov 2024, 15:17 Hi!

Ich habe hier nie einen Luftdruck unter 978,1 hPa und ueber 1045,5 hPa gehabt.
Auch die Temperaturen sind zumindest hier in Berlin/Brandenburg weit von Deinen theoretischen +-50°C entfernt: min: -13,1°C und max: 39,2°C.
Insofern ist der "Korridor" doch deutlich kleiner als in Deiner Beispielrechnung.

Klar, das waren zur Veranschaulichung schon extreme Werte. In Frage 2 habe ich ja dann auch von "... in meinem Teil der Welt konkret vorkommenden abs. Min.-Max. Druckwerten und Min.-Max. Temperatur" gesprochen.

Sofern man nicht die durschschnittliche Temperatur der letzten 12 Stunden hat, ist die Nutzung von 15°C nicht so verkehrt.

Da liegt des Pudels Kern: bei einem EINMALIG festgelegten Korrekturfaktor nützen mir die Temperaturen der letzten 12h nichts, weil ich keine "Nachführung" des Korrekturfaktors machen kann/will. Das könnte nur eine ständig intern mitlaufende Berechnung der Konsole (aus den Parametern Höhe *, abs. Luftdruck, Außentemperatur der letzten 12h, ggf. Außenfeuchte) zuverlässig machen. Niemand berechnet z.B. jede Stunde (oder wenn sich die Außentemperatur ändert) den Korrekturfaktor neu und gibt ihn in die Konsole ein! So muss ich mich aktuell einmalig auf eine mittlere Temperatur festlegen: 15 °C.
Zu *) Die Eingabe der Höhe kann ich mir auf 2 Arten vorstellen:
1. Der User gibt die Höhe (der Konsole oder des T&HP-Sensors) nach eigener Berechnung ein. Die Höhenangabe besteht aus der Höhe ü.NN aus Google Earth oder anderen Maps plus der eigenen Höhe im Haus, bei mir im 3. Stock z.B. 9,6m.
... oder ...
2. Die Konsole holt sich selbst via Internet die Höhe ü.NN am Standort und nutzt diese Höhe so lange, bis der User zusätzlich noch die eigene Höhe im Haus eingibt.
So etwa ist das z.B. in der guten Android App für Handys mit Barometer "Genaues Barometer" von AR Labs umgesetzt.

Ich finde uebrigens den deutschen Rechner besser verstaendlich und uebersichtlicher.

Ja, da komme ich auch gut mit klar.

Und ja - auch wir wuenschen schon lange eine automatische temperaturkompensierte Luftdruckberechnung durch die Konsole.
Man sollte nur die Hoehe des Barometers angeben (der ist im Allgemeinen in der Konsole und nicht im Aussensensor!).
Die SLP-Berechnung sollte dann durch die Konsole geschehen.
Noch aber ist Ecowitt nicht so weit - wir arbeiten daran ...

Die Funktion wäre klasse! Toll, dass ihr euch (u.a.) auch dafür einsetzt! Dadurch würden die erheblichen Abweichungen des rel. Luftdrucks (s. mein Post #1!) von PWS einer Region garantiert wesentlich geringer!

Danke für die Tabelle! Sehe ich mir morgen an.

olicat hat geschrieben: 08 Nov 2024, 15:17 Man sollte nur die Hoehe des Barometers angeben (der ist im Allgemeinen in der Konsole und nicht im Aussensensor!).
Die SLP-Berechnung sollte dann durch die Konsole geschehen.
Noch aber ist Ecowitt nicht so weit - wir arbeiten daran ...

haben wir eine Gleichung (mit (T + [T-12])/2 und möglicherweise inklusive Luftfeuchte ?

Dirk27 hat geschrieben: 08 Nov 2024, 20:50 Da liegt des Pudels Kern: bei einem EINMALIG festgelegten Korrekturfaktor nützen mir die Temperaturen der letzten 12h nichts, weil ich keine "Nachführung" des Korrekturfaktors machen kann/will. Das könnte nur eine ständig intern mitlaufende Berechnung der Konsole (aus den Parametern Höhe *, abs. Luftdruck, Außentemperatur der letzten 12h, ggf. Außenfeuchte) zuverlässig machen. Niemand berechnet z.B. jede Stunde (oder wenn sich die Außentemperatur ändert) den Korrekturfaktor neu und gibt ihn in die Konsole ein! So muss ich mich aktuell einmalig auf eine mittlere Temperatur festlegen: 15 °C.

Ganz ehrlich, ich kann mir nicht vorstellen dass einer der hier mitlesenden Hobby-Meteorologen eine kontinuierliche Nachführung des Korrekturfaktors macht. Ihr könnt mich gern prügeln, falls doch ... Ich glaube, aber das ist jetzt in der Tat "Glaskugel", dass nicht mal eine offizielle DWD-Station das macht.