@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) 480 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).
