Temperaturabhängigkeit der Distanzmessung

[maehw]

Hallo zusammen,

ich grabe mal dieses alte Thema auf, da es der Foreneintrag ist, der am besten passt.

Ich habe ein wenig im Forum gestöbert und auch in der Firmware. In der Firmware finden sich Hinweise darauf, dass ein BPM280 Luftdruck/Temperatur-Sensor (per I2C) angeschlossen werden kann und ausgelesen wird. Verwendet das jemand?

Denkbar wäre für Temperaturkompensation der Schallgeschwindigkeit. Zur Temperaturabhängigkeit habe ich auch was gelesen.

Man findet auch eine Tabelle unter Wikipedia:

Schallgeschwindigkeit | Temperaturabhängigkeit

Zwischen 0°C und 30°C (vielleicht ein realistischer Temperaturbereich in DE?) gibt es eine Schwankung von grob 5%.

Haltet ihr das für relevant bzw. wurde das schon mal untersucht/berücksichtigt?
Habe gesehen, dass ja auch die ein oder andere Forschungsbeteiligung oder Abschlussarbeiten hier mitwirken (oder zumindest wollten).

[gluap]

Ich habe das Thema in einen neuen Thread verschoben, damit es auch gefunden wird - Im alten Thema ging es um die Temperaturdrift der Elektronik - Hier geht es um die Temperaturabhängikeit der Messung. Der Grund für den BPM280 war tatsächlich, dass überlegt wurde, das mit einzubeziehen.

Ist aber etwas schwierig, weil die Temperatur im Openbikesensor Gehäuse stark von der Außentemperatur abweichen kann (z.B. bei Sonnenschein und im extremfall schwarzem Gehäuse können da schon mal 40 grad drin sein bei außentemperatur 15 Grad).

Ein weiterer Weg wäre, die Temperaturdaten im Postprocessing anhand der Wetterdaten zu machen.

So weit ich weiß fährt niemand mit der BPM280 Variante herum.

[opatut]

Das Datenformat für OBS-Lite sieht das auch vor, dass TOF-Zeiten zusammen mit der Distanz geschrieben werden. Das macht das OBS-CSV zwar auch, aber dort will ich eigentlich die Logik beibehalten, um identische Werte zu den im Display angezeigten zu behalten. Beim OBS lite wird das Portal dann die Umwandlung TOF->Distanz machen und da evtl. dann Wetterinfos einbeziehen. Falls wir eine „freie“ Wetterhistorie importieren können. Der DWD bietet das immerhin an, aber einfach ist anders

Mal sehen.

Mich interessiert aus Hardwaresicht eher das Accelerometer

[simse]

Hi,
ich hab mal die OBS-Daten mit den stündlichen Temperaturdaten aus den etwa 500 aktiven DWD Station abgeglichen. Sieht auf den ersten Blick ziemlich stabil aus:

Voronoi um jeweilige OBS Daten der nächsten Wetterstation zuzuordnen:

Frage zu den OBS-Daten Zeitstempel:

Wie ist der zu interpretieren? Einfach ganz normal UTC, also London?

Kann den Code dazu auch noch hochladen (und aufräumen), wenn sich jemand dafür interessiert.

[gluap]

Die Zeit ist GPS Time, was für Wetterzweike UTC entspricht. Wenn du den Code ohnehin hast würde ich fast sagen: Könnten wir doch sinnvoll ins Portal einbauen? Müssten wir dann nur kennzeichen, nicht dass jemand hinten drauf noch mal temperaturkorrigiert.

[opatut]

Hast du auch so einen Boxplot ohne Wetterkorrektur? Wäre interessant zu sehen ob da dann der Fehler zu erkennen ist.

[simse]

Hi,
entschuldigt die späte Rückmeldung.

Hab den Code jetzt mal hier reingelegt:

OpenBikeSensor_Analysis/code/monitoring/weather_temperature at gh-pages ·...

Das Helper-Skript createVoronoiFromDWDweatherStations_OBSv02.ipynb baut erstmal ein Voronoi für die aktiven DWD Wetterstationen, die aktuell, stündliche Temperaturdaten liefern.
In obs_publicData_overview_v04_WETTER.ipynb werden dann die öffentlichen OBS Daten aus den Portalen mit den stündlichen Temperaturdaten der jeweils nächsten DWD Station basiered auf dem Voronoi gemerged.

@gluap Ok, danke, die paar Sekunden Abweichung von GPS-Time zu UTC sollte für diesen Zweck wirklich kein Problem sein.
Ich weiß nicht genau, wie man das in ein Produktivsystem integrieren würde, hatte das ja eher so als Post-Prozess mit den Bestandsdaten gemacht um zu schauen ob es einen sichtbare Abweichung gibt.

@opatut Da ich nur die öffentlichen Portaldaten genutzt hab, bin ich nicht sicher ob diese bereits eine Wetterkorrektur haben/hatten bzw. wie ich an die OBS-Daten ohne Wetterkorrektur rankommen würde.
Könnte das aber gerne nochmal entsprechend mit anderem Input durchlaufen lassen.

[gluap]

@simse Es gibt noch kein Portal mit Wetterkorrektur, also alles gut erstmal Ich meinte nur, dass wir, wenn wir es im Portal durchführen auf der json schnittstelle deutlich machen sollten „ich bin ein Portal, das schon Wetterkorrekturen gemacht hat, mache diese nicht noch mal auf diesen Daten“.

[drooembueddel]

Welche Schallgschwindigkeit wird denn aktuell angenommen? Ich habe in einem Datenblatt zum JSN-SR04T ( https://www.openbikesensor.org/docs/hardware/general/collective-order/jsn-sr04t-en.pdf ) 340m/s gefunden. Ist das der genutzte Wert?

[gluap]

Ja, wir nutzen auch (fast) 340 m/s, oder genauer: wir rechnen 58 microsekunden bis zum echo pro zentimeter abstand. Genaueres zum „warum“ findest du hier in den Kommentaren der Codestelle

Man kann die Temperatur auch im Nachhinein korrigieren. Eine Temperaturmessung am Gerät ist (weil Sonneneinstrahlung dafür sorgt, dass die Gerätetemperatur stark von der Umgebungstemperatur abweicht) dafür zwar nicht hilfreich, aber man kann beim DWD historische Wetterdaten bekommen, das hatte simse mal gebaut. Gerade gesehen dass das schon oben im Thread war, mit der Temperaturkorrektur.