Verlässlichkeit Luftdruckwerte PWS

[Gyvate]

wir bemühen uns z.Zt., diese Funktionalität in die Konsolenfirmware implementiert zu bekommen.
Der Anwender muss dann die Barometerhöhe einmalig eingeben, genau so wie z.B. die geographischen Koordinaten.

[Dirk27]

@Gyvate: klingt super!

Meine Vorstellung:

Weil die klassische Barometrische Höhenformel ja davon ausgeht, dass sich die Temperatur mit der Höhe nicht ändert, würde man die Erweiterte Barometrische Höhenformel brauchen, dann wäre zumindest der (trockenadiabatische) Temperaturgradient erfasst. Ob das wirklich nötig ist? Für Höhen ü.NN bis 2-3 km unterscheiden sich Ergebnisse der beiden Formeln kaum!

Atmosphäre.png (136.43 KiB) 479 mal betrachtet

Auch dann gehen beide Formeln aber immer noch davon aus, dass die Atmosphäre trocken ist. Prinzipiell könnte man also zur Erfassung der Luftdichte auch noch die Luftfeuchte einbeziehen. Damit wäre der "feuchtadiabatische Temperaturgradient" zu ermitteln. In der Standardatmosphäre wären das 0,65 °C pro 100m, den Wert kann man ja in manchen Rechnern angeben. Ob eine Berechnung mit Luftfeuchte bzw. der Luftdichte für PWS Sinn macht? Man darf zweifeln. Ich denke, die Annahme einer Standardatmosphäre wäre hier wohl ausreichend.

Die Temperatur (T) kann man auch immer mit (T + [T-12h]) / 2 angeben, wenn gewünscht. Für die genannten Formeln muss das nicht sein.

Aber: wem sage ich das alles?

Kurzform:
Wahrscheinlich wäre es schon völlig ausreichend, die Erweitere Barometrische Höhenformel in Konsolen/Gateways einzubauen. Genauer braucht das wohl nicht zu sein.

"Programmtechnisch" stelle ich mir das UI so vor (Beispiel GW2000):
1. Im Menü Calibration bleibt alles gleich bis auf eine zusätzliche kleine Checkbox "Auto [Rel Offset]" hinter oder vor dem "Rel Offset" Feld, die nur dann dort erscheint, wenn die Konsole über eine gültige Standort-Information (Koordinaten), einen abs. Luftdruckwert und die Außentemperatur verfügt.
2. Aktiviert der User diese Checkbox, versucht die Konsole, die Höhe ü.NN am Standort aus dem Internet zu laden und zeigt diese als "Lokale Höhe ü.NN" mit der eingestellten Einheit an.
3. Mit "Übernehmen" kann der User diese Höhe akzeptieren oder eine eigene Höhe ü.NN eingeben (das muss auch möglich sein, wenn die Internet-Abfrage der Konsole mit Timeout scheitert oder nicht möglich ist).
4. Der User kann dann noch eine Höhe seiner Meßstation über Grund angeben oder diese bei 0 [Default] belassen.
5. Aus den Angaben errechnet die Konsole sofort den aktuellen Korrekturfaktor und stellt diesen fortlaufend im vorhandenen Feld "Rel Offset" dar. Dadurch kann ich als User immer nachsehen, welcher Korrekturfaktor gerade verwendet wird. Bin ich nicht zufrieden oder scheint der Faktor nicht plausibel, kann der User einfach die Checkbox "Auto [Rel Offset]" wieder deaktivieren und den Rel Offset manuell eingeben.
6. Wenn Auto Rel Offset aktiviert ist, berechnet die Konsole intern z.B. einmal pro Stunde den Korrekturfaktor neu und wendet ihn für den Rel. Luftdruckwert an. Wenn T und [T-12h] vorhanden sind, werden diese verwendet, sonst nur T. Benötigt zur Berechnung werden: Koordinaten, abs. Luftdruck, Außentemperatur (T), optional Außentemperatur vor 12h [T-12h], Höhe der Meßstation (= Höhe Standort ü.NN plus Höhe Meßstation über Grund).

Klingt so, als wäre es nicht sooo schwierig. Man darf ja träumen ...

Ich finde, ein gutes Argument für den Hersteller FÜR eine solche Auto Rel Offset Funktion könnte folgendes sein:
Rufe ich eine Map in Ecowitt Weather mit dem Rel. Luftdruck auf, sehe ich in meiner Umgebung extreme Abweichungen, obwohl die Fine Offset Hardware den abs. Luftdruck recht genau messen kann. Würde man den darstellen, hätte man evtl. nur Abweichungen von max. +- 0,5 hPa (wenn nicht in den PWS vom User mit Abs Offset verändert!). Das sähe schon gut aus und spräche für die Qualität der Stationen.
Sieht man aber die Rel. Luftdruck Karte, könnte ein Laie fälschlich meinen, dass die Geräte eben "Hobby-Klasse" und minderwertig sind, weil allein bei mir hier Abweichungen des Rel. Luftdrucks von knapp 40 hPa im Radius von ca. 20 km bei weitgehend flachem Gelände zu sehen sind.
Stattdessen liegt das daran, dass die User "nur" den Rel Offset nicht richtig angeben (können).
Also wäre es auch für das Image des Herstellers gut, wenn der Rel. Luftdruckwert in der Region die Genauigkeit der PWS widerspiegeln würde. Für den Außentemperatur-Wert ist das z.B. kein Problem: regional alle nahezu identisch!

@Peter: die o.g. Funktion könnte auch als EINMALIGE Berechnung der Konsole erfolgen und dem User zumindest die fehlerträchtige Eingabe des Korrekturfaktors ersparen. Dafür müsste/sollte man dann die Standardatmosphäre zugrunde legen (1013 hPa, 15 °C).

[Gyvate]

Ob der Hersteller für die fehlerhafte Kalibrierung der Benutzer verantwortlich gemacht wird ... ?
Ich denke, dass jedem, dem die generelle Problematik klar ist und ggf. deshalb an zu hohen Werten zweifelt, es deshalb auch ziemlich klar ist, das hier der Anwender etwas falsch gemacht hat.
Bevor das alles sehr verkompliziert wird:
die Eingabe der Barometerhöhe als Festwert ist ausreichend. Der Rest ist aus Stationsdruck und Temperatur ableitbar. Und wenn die Konsole z.B. jede Minute den Wert neu berechnet, werden auch Änderungen hinreichend schnell erfasst.

[Dirk27]

Ob der Hersteller für die fehlerhafte Kalibrierung der Benutzer verantwortlich gemacht wird ... ?

Das kann ich nicht sicher einschätzen.
Aber ich habe mal spaßeshalber die lokale Station (Höhe hier: ca. 70-80m ü.NN) in meinem engeren Umkreis mit dem niedrigsten rel. Luftdruck aufgerufen, Korrekturfaktor des Betreibers: -18,5 hPa

PWS_low.jpg (204.22 KiB) 467 mal betrachtet

Ohne Worte ...

Zum Vergleich: die lokale Station mit dem höchsten rel. Luftdruck, Korrekturfaktor: +32 hPa

PWS_high.jpg (200.95 KiB) 467 mal betrachtet

Auch ohne Worte ...

Auffallend ist aber, dass sich der abs. Luftdruck der beiden Stationen nur um 1 hPa unterscheidet, auch Temperatur und Feuchte sind gut vergleichbar. Die Messwerte der PWS selbst sind also ok! Die rel. Werte liegen aber um sage-und-schreibe 49,5 hPa auseinander!
Das könnte sich doch durch eine gewisse Automatisierung wesentlich verbessern, oder ...

Bevor das alles sehr verkompliziert wird:
die Eingabe der Barometerhöhe als Festwert ist ausreichend. Der Rest ist aus Stationsdruck und Temperatur ableitbar. Und wenn die Konsole z.B. jede Minute den Wert neu berechnet, werden auch Änderungen hinreichend schnell erfasst.

Ja, reicht natürlich. Ich habe da schon eine Luxusvariante beschrieben.