Step 7 Windrichtung Messwert beruhigen

JesperMP · 8 Januar 2020

Über die Schwankungen wurde ich auch überlegen ob man ein "Qualität" von den Messung berechnen sollte.
Eine einzelne aussenliegende Wert (z.B. 10° - 11° - 12° - 11° - 10° - 11° - 12° - 11° - 90° - 11° - 12° wurde den Mittelwert nicht ekstrem beeinflussen.
Aber wenn den Messwert immer stark schwankt (z.B. 10° - 71° - 120° - 11° - 32° - 355° - 12° - 190° - 286° - 41° - 311°) dann stellt sich die Frage ob den "beruhigte" Wert überhaupt Sinn macht.
Ich wurde den Qualität so berechnen:
Summierte Abstand gebildet von die summierte X und Y Werte, dividiert durch die summierte Abstandswerte (ohne Vinkel).
Wenn diesen Wert nah zu 1.0 ist, dann ist die Qualität "gut".
Wenn diesen Wert nah zu 0.0 ist, dann ist die Qualität "schlecht".

Heinileini · 8 Januar 2020

Moin Harald,
was bedeutet "Ansprechschwelle: 0,1 m/s (für Windrichtung einstellbar)"?
Ist das die minimale WindGeschwindigkeit, ab der überhaupt ein "gültiger" Winkel ausgegeben wird?
Wenn ja, woran erkennt man bei der analogen WinkelWertAusgabe, ob der Wert "gültig" ist oder nicht? Muss man wohl selbst prüfen, ob die Geschwindigkeit ausreichend hoch ist?
Und die "eigene" AnsprechSchwelle sollte höher sein, als die des Sensors.
Als Ausgang ist u.a. RS 485 angegeben. Hat Dein Exemplar des Sensors diese Möglichkeit? Der physikalische Sprung vom MinimalWert 4 mA zum MaximalWert 20mA ist erheblich und gibt nicht wirklich den Sachverhalt wieder, dass sich der Winkel nur "minimalst" ändert. Mir wäre deshalb eine digitale Übertragung lieber. Zwei aufeinander folgenden Telegrammen ist schliesslich egal, ob sich die Werte von Telegramm zu Telegramm sprunghaft ändern. Da kann einem keine Trägheit von sich ändernden AnalogWerten in die Suppe spucken.
Gruss, Heinileini

PS:
Wenn der Sensor seine RichtungsWerte selbst schon mittelt/glättet, bevor er sie in ausgibt, wäre mir schon klar, dass Sprünge z.B. nach 180° und zurück auftreten, wenn sich die Richtung zwischen 0° und 359,9° so gut wie kaum ändert. Bohr mal beim Hersteller nach, ob dies der Fall ist!

PPS:
Schieb doch mal "gestreamte" Daten des Sensors rüber!

Heinileini · 8 Januar 2020

JesperMP schrieb:
Summierte Abstand gebildet von die summierte X und Y Werte, dividiert durch die summierte Abstandswerte (ohne Vinkel).
Wenn diesen Wert nah zu 1.0 ist, dann ist die Qualität "gut".
Wenn diesen Wert nah zu 0.0 ist, dann ist die Qualität "schlecht".

Hmmm. Ich glaube Du willst die Summen über mehrere/viele Messungen damit auswerten. Und dann die vielen Werte komplett wegwerfen, wenn das Ergebnis schlecht ist?
Ich glaube, es geht eher darum, einzelne Ausreisser zu erkennen und zu ignorieren.
Aber das ist alles spekulativ - möge sich Harald erstmal wieder mit neuen Erkenntnissen/Infos melden und mit realen vom Sensor kommenden Daten.

Wenn das zutrifft, was ich in #22 unter PS angesprochen habe, ist es eine Macke, um die sich der Hersteller kümmern sollte - aber diese Macke wäre auch relativ leicht zu erkennen, weil sie immer nur bei einer bestimmtem Richtung auftreten dürfte.

JesperMP · 8 Januar 2020

Heinileini schrieb:
Hmmm. Ich glaube Du willst die Summen über mehrere/viele Messungen damit auswerten. Und dann die vielen Werte komplett wegwerfen, wenn das Ergebnis schlecht ist?

Ich stelle mich vor die Messwerte befindet sich in eine zyklisch aktualisierender Kreispuffer, und die Berechnungen von "Vinkel" und "Qualität" passiert auch zyklisch. Eine einzelne Ausreisser wurde die "Qualität" nur von 0.99 auf 0.90 verschlechtern. Ob den beruhigte Wert nicht akseptiert werden wäre eine Frage von welche "Qualität" gefordert werden.

Heinileini · 8 Januar 2020

JesperMP schrieb:
Ich stelle mich vor die Messwerte befindet sich in eine zyklisch aktualisierender Kreispuffer, und die Berechnungen von "Vinkel" und "Qualität" passiert auch zyklisch. Eine einzelne Ausreisser wurde die "Qualität" nur von 0.99 auf 0.90 verschlechtern. Ob den beruhigte Wert nicht akseptiert werden wäre eine Frage von welche "Qualität" gefordert werden.

Ja, aber dann weiss man noch nicht, wo der Ausreisser steckt? Man könnte zyklisch einen Wert oder eine Gruppe von wenigen, aufeinander folgenden Werten ausblenden und dann vergleichen, ob sich die Qualität dadurch deutlich bessert.

PN/DP · 8 Januar 2020

Vielen Dank erstmal für die vielen Überlegungen und Vorschläge, ich werde erstmal Werte aufzeichnen.
Zur Zeit bin ich anderweitig beschäftigt. Ich melde mich wieder.

Heinileini schrieb:
was bedeutet "Ansprechschwelle: 0,1 m/s (für Windrichtung einstellbar)"?

Keine Ahnung, außerdem steht da "0,1 ms" und nicht "0,1 m/s".

EDIT: auf der Webseite steht "m/s", in der pdf-Betriebsanleitung steht "ms"
Das ist jetzt mein erster Kontakt mit diesem Sensor.

Heinileini schrieb:
Als Ausgang ist u.a. RS 485 angegeben. Hat Dein Exemplar des Sensors diese Möglichkeit?

Ja, der Sensor hat eine RS485-Schnittstelle - da bräuchte ich aber einen CP340 (oder einen COM-Server), der kostet erheblich mehr als zwei Analogeingänge, und auch etwas mehr Programmieraufwand zum Einlesen der Datentelegramme. Da wäre der Anschluß des Windsensors nicht so auf die Schnelle eine Woche vor Weihnachten gegangen

Harald

Maagic7 · 8 Januar 2020

Code:

FUNCTION "m7b_DampingReal" : VOID
TITLE =Damping of a REAL value
//AUTOR: S.Maag
//DATUM: 9/2015

//
//AENDERUNGSVERMERKE:
//--------------------------------------------------------------------------------
//DATUM        NAME            AENDERUNG
//--------------------------------------------------------------------------------
//28.11.2017   S.Maag        Fehlerabfragen SPU err hinzugefügt, da es 
//                           bei ungültigen Gleitpunktzahlen zu einem 
//                           Dauerhaften Fehler kommt, der sich selbst nicht
//                           mehr korrigiert, da die Rechnung abgebrochen wird.
//                           Das ist ein sehr seltens Phänomen und konnte nicht
//                           ganz nachvollzogen werden warum das passiert.
//                           in der Gleitpunktzahl steht dann der HEX-WERT
//                           DW#16#7FC0 0000
//                           Aufgetaucht ist dies nach einem Sensordefekt und
//                           Sensorwechsel (Wiegezelle)
//--------------------------------------------------------------------------------
//
//HINWEISE:
AUTHOR : 'S.Maag'
FAMILY : Maagic7
VERSION : 0.1


VAR_INPUT
  rVALUE : REAL ;    
  rising_edge_1s : BOOL ;    
  rDampingFactor : REAL ;    
END_VAR
VAR_IN_OUT
  IO_VALUE_DAMP : REAL ;    
END_VAR
VAR_TEMP
  rDamping : REAL ;    
END_VAR
BEGIN
NETWORK
TITLE =



NETWORK
TITLE =Dämpfung des Sensorwertes 
//Durch das aufaddieren eines Teils der Differenz zum aktuellen Analogwert
//läuft der gedämpfte Wert dem Analogwert immer etwas hinterher. Es ergibt sich 
//ein exponentieller Nachlauf (vgl. Kondensator Ladekurve) bei einem 
//Dämpfungsfaktor von 2 erhält man nach 5 Impulsen ca. 96.9%, nach 7 Impulsen ca. 
//99.2% Sensorwertes. Je höher der Dämpfungsfaktor, desto langsamer läuft der 
//Wert hinterher.
//
      UN    #rising_edge_1s; 
      SPB   ne6; 

      L     #rDampingFactor; // sicherstellen, dass
      L     1.000000e+000; // Dämpfungsfaktor >=1.0
      <R    ; 
      SPB   sav; 
      TAK   ; 
sav:  T     #rDamping; 

      L     #rVALUE; 
      L     #IO_VALUE_DAMP; 
      -R    ; 
      SPU   err; // Wenn Fehler, z.B. ungültige Gleitpunktzahl
      L     #rDamping; 
      /R    ; 
      SPU   err; // Wenn Fehler, z.B. ungültige Gleitpunktzahl
      L     #IO_VALUE_DAMP; 
      +R    ; 
      SPU   err; // Wenn Fehler, z.B. ungültige Gleitpunktzahl
      T     #IO_VALUE_DAMP; 
      BEA   ; 

err:  L     #rVALUE; // Wenn Fehler, dann Eingangswert direkt
      T     #IO_VALUE_DAMP; // durchschleusen
ne6:  NOP   0; 
END_FUNCTION

Heinileini · 8 Januar 2020

PN/DP schrieb:
Keine Ahnung, außerdem steht da "0,1 ms" und nicht "0,1 m/s". EDIT: auf der Webseite steht "m/s", in der pdf-Betriebsanleitung steht "ms"

Die Variante m/s dürfte zutreffend sein.
Wenn Du bei dem Sensor die AnsprechSchwelle selbst festlegen kannst, würde ich sie niedrig ansetzen und mich allein auf die eigene AnsprechSchwelle in der eigenen Software verlassen.
Wenn das Problem darauf zurückzuführen ist, dass der Sensor gemittelte/geglättete Daten ausgibt (gar nicht so unwahrscheinlich), dann dürften die Daten in Telegrammen dasselbe Problem mit sich bringen wie in der AnalogAusgabe. Damit entfiele ein Grund, auf RS 485 umzustellen.
Ausserdem hättest Du dann ohnehin schon zu viel Glättung und jegliche weitere Glättung (per Elko oder SW) sollte tunlichst vermieden werden, solange die "Spikes" noch nicht ausgeblendet sind.

VBA in Excel.
1. Umwandlung REAL Winkel 0.0..359.9 in INT SektorNr 0..15
2. Korrektur von SektorNr, aber nur wenn SektorNr vorher 0 war:
- wenn neuer Wert 8, dann 0 belassen

- wenn neuer Wert 1..7, dann 1
- wenn neuer Wert 15..9, dann 15

Code:

Tmp.Dir = Target.Value ' Winkel in ° einlesen (REAL, 0°=N, 90°=O, 180°=S, 270°=W)

' ---< SektorNr aus Winkel berechnen >---
xTmp& = Tmp.Dir * 4# + 45#
Do While xTmp& < 0: xTmp& = xTmp& + 1440: Loop ' "MOD zu Fuss" fuer neg. Werte
xTmp& = xTmp& Mod 1440
xErg& = Int(xTmp& / 90)

' ---< Korrektur >---
xNewVal& = xErg&
If xOldVal& <> 0 Then ' nix tun, wenn vorherige SektorNr nicht 0
ElseIf xNewVal& = 8 Then
    xNewVal& = 0      ' 0 -> 8 : ignorieren
ElseIf xNewVal& > 8 Then
    xNewVal& = 15     ' 0 -> 15..9 : begrenzen auf 15
ElseIf xNewVal& > 0 Then
    xNewVal& = 1      ' 0 -> 1..7  : begrenzen auf 1
    End If
xOldVal& = xNewVal& ' "FlankenMerker" fuer SektorNr

Cells(xRow&, 2).Value = xNewVal& ' korrigierte INT SektorNr 0..15 ausgeben
'Cells(xRow&, 3).Value = xErg&  ' unkorrigierte INT SektorNr 0..15 ausgeben

PN/DP · 9 Januar 2020

Heinileini schrieb:
Schieb doch mal "gestreamte" Daten des Sensors rüber!

Hier eine Aufzeichnung über 5 Minuten, jede Sekunde ein Datensatz: Windgeschwindigkeit (*0,1m/s) + Windrichtung (0..359°)
(Wind = 18 bedeutet 1,8 m/s)
Die 4-20mA wurden eingelesen mit einer AI8x12Bit 6ES7 331-7KF02-0AB0

Für das Archiv sollte für diesen 5-Minuten-Zeitraum ein Durchschnittswert von circa 230 für die Windrichtung errechnet werden.
(Vielleicht müsste ich auch jede 1 Minute einen "Durchschnittswert" speichern?)

WindLog_1.csv.txt - glücklicherweise war da Südwind vorherrschend, der nie über Nord (0/360) drehte
WindLog_2.csv.txt - das ist WindLog_1.csv.txt um 180° gedreht, damit zum Test auch 0/360-Übergänge vorkommen

Tip: zum direkten Öffnen der csv-Dateien mit Excel die Endung .txt entfernen

Harald

PN/DP · 9 Januar 2020

Heinileini schrieb:
Wenn Du bei dem Sensor die AnsprechSchwelle selbst festlegen kannst, würde ich sie niedrig ansetzen und mich allein auf die eigene AnsprechSchwelle in der eigenen Software verlassen.
Wenn das Problem darauf zurückzuführen ist, dass der Sensor gemittelte/geglättete Daten ausgibt [...]

Die Daten sehen eigentlich nicht so aus als ob der Sensor da schon viel geglättet hat.
Wie die Ansprechschwelle selber einstellbar sein soll - ich habe leider noch keine Zeit gefunden den Hersteller anzurufen. In der Sensorbeschreibung und der Betriebsanleitung gibt es keine konkreten Hinweise zu einer Parametriersoftware ...

Vielen Dank erstmal für Dein drüber nachdenken und den Code. Heute werde ich das nicht mehr testen können...

PS: ich hoffe, mein Thema lenkt nicht vom Programmierwettbewerb ab

Harald

Kabeläffle · 9 Januar 2020

PN/DP schrieb:
PS: ich hoffe, mein Thema lenkt nicht vom Programmierwettbewerb ab

Super Idee für die nächste Aufgabe.
Du könntest das ja parallel laufen lassen.

Zu deiner Aufgabe:
Da Richtung und Betrag bekannt sind, wäre das doch ein typischer Fall für die Vektoraddition?!
https://www.mathematik-wissen.de/addition_von_vektoren.htm

JesperMP · 9 Januar 2020

Kabeläffle schrieb:
Da Richtung und Betrag bekannt sind, wäre das doch ein typischer Fall für die Vektoraddition?!

+1
...................

Heinileini · 9 Januar 2020

PN/DP schrieb:
WindLog_2.csv.txt - das ist WindLog_1.csv.txt um 180° gedreht, damit zum Test auch 0/360-Übergänge vorkommen

Moin Harald,
hmmm, eigentlich stören bei den 0/360-Übergängen nur die dort irritierenden VerbindungsLinien im Diagramm.
Das vermeintliche Sensor-RundungsProblem könnte man nur erkennen, wenn der Sensor 0/360-Übergänge "ausführt".
Aber das ist auch nicht in der 1. csv zu sehen.
Wahrscheinlich habe ich mich zu sehr durch die in Beitrag #1 genannten Sprünge um 180° bzw. 90° beflügeln lassen.
Da kann mein KorrekturVersuch laut Code auch nichts ausrichten.

PN/DP schrieb:
Die Daten sehen eigentlich nicht so aus als ob der Sensor da schon viel geglättet hat.
Wie die Ansprechschwelle selber einstellbar sein soll - ich habe leider noch keine Zeit gefunden den Hersteller anzurufen.

PS: ich hoffe, mein Thema lenkt nicht vom Programmierwettbewerb ab

Die Themen "AnsprechSchwelle" und "Glättung durch den Sensor" sind zwei Paar Schuhe.
In Deinen Daten/Diagrammen kann man sehen, dass die RichtungsWerte stärker schwanken, wenn die GeschwindigkeitsWerte niedrig sind.
Da man nicht weiss, inwiefern tatsächliche RichtungsSchwankungen vorliegen und zu den Ausreissern beitragen, ... keine Ahnung ... ich neige momentan dazu, wenigstens die Messungen bei WindGeschwindigkeiten unter 2,5 m/s zu ignorieren ... aber andererseits, was heisst ignorieren? Alten Wert aufrecht erhalten, bis wieder 2,5 m/s überschritten werden? Dann gibt es wohl Sprünge beim "WiederEinklinken" der gemessenen Werte. Und eigentlich sind 2,5 m/s nicht so wenig, dass man sie ignorieren möchte.

Ich muss zugeben, ich bin ziemlich ratlos.
Weiterhin die 0/360-Übergänge der tatsächlichen WindRichtung im Auge behalten (ggfs den Sensor so ausrichten, dass sie häufiger erfasst werden - nur um zu testen, ob der Sensor tatsächlich eine Änderung in der falschen Richtung "vortäuscht").
Versuchen, zu ergründen, was der Hersteller mit der AnsprechSchwelle macht. Und, ob es bei 0/360-Übergängen durch Glättung "im Sensor" zu FalschMeldungen kommen kann.
Beobachten, ob Vögel oder Flatterlinge im n-SekundenTakt am Sensor vorbeifliegen. ;o) [das Smiley-Einfügen funktioniert mal wieder nicht ;o( ]
Kabeläffles VektorAddition anwenden - als VektorLänge die Geschwindigkeit nehmen (statt EinheitsVektor), wie ich schon mal mit anderen Worten vorgeschlagen hatte.
Damit werden die Ausreisser aufgrund der Geschwindigkeit automatisch schon verkleinert.

ProgrammierWettbewerb: ich war ganz verblüfft, dass Dein Thread so gut zum Thema des Wettbewerbs passt ... bis ich den Eindruck hatte, dass der Sensor ein Problemchen durch Glättung bereiten könnte.

Gruss, Heinileini

Heinileini · 10 Januar 2020

PN/DP schrieb:
Für das Archiv sollte für diesen 5-Minuten-Zeitraum ein Durchschnittswert von circa 230 für die Windrichtung errechnet werden.

Ergebnisse aus den Daten von csv1 (die nicht gedrehte Variante):

1. VektorAddition mit Geschwindigkeit als VektorLänge: 246,41°

2. Kreis in 16 Sektoren eingeteilt, Sektor 0 von -11.25° bis + 11,25° entspricht N ... Sektor 4 von 78,75° bis 101,25° entspricht O ... u.s.w.
2a. Zählen der Häufigkeit in den Sektoren ergibt Maximum von 123 im Sektor 11 entsprechend WSW (236,25° bis 258,75°, Mitte des Sektors: 247,5°)
2b. Summieren der "Geschwindigkeiten" in den Sektoren ergibt Maximum von 4884 in Sektor 11 - also denselben Sektor wie in 2a.

Die Ergebnisse bei den gegebenen Daten sind nach den 3 Methoden nah bei einander, aber ganz knapp neben der Vorgabe von ca. 230° entsprechend SW.
Ich hoffe, ich habe den DrehSinn (im Uhrzeigersinn) richtig gewählt? Ansonsten Zuordnung Ost und West tauschen.

Onkel Dagobert · 10 Januar 2020

Ich habe meinen Gedanken aus #7 noch einmal aufgegriffen. Auch wenn es nicht perfekt ist, so poste ich es mal. Vielleicht hat ja jemand noch eine Idee.

Folgende Problembeschreibung steht auch im Quelltext.

Code:

[FONT=Verdana]Bis hier her wurde eine lineare Funktion in Sinus- und Cosinus umgewandelt. Durch diese Umwandlung
ist der Sprung bei 0°/360° beseitigt. Die Sinusfunktion wiederholt sich mit jeder Umdrehung stoßfrei.
Jetzt können die Werte gedämpft werden, ohne dass bei 0°/360° ein falsche Werte entstehen.
[/FONT]
[FONT=Verdana]Durch die Dämpfung werden die Messwerte verzögert. Der Wermutstropfen ist allerdings, dass bei relativ schnellen
Signaländerungen die Amplitudenwerte von -1 und +1 nicht mehr erreicht werden. Die Folge sind Signalsprünge
aufgrund dieser fehlenden Werte an den Amplituden bzw. an den Übergängen zwischen den Quadranten.
Diese Sprünge sind bei langsamen Änderungen kaum zu bemerken. Sie vergrößern sich extrem bei hohen
Änderungsgeschwindigkeit des Signals sowie mit der Stärke der Dämpfung. Daher wurde auch nur eine Dämpfung
ersten Grades (PT1) vorgesehen.
[/FONT]
[FONT=Verdana]Um das Ausmaß dieser Sprünge dennoch möglichst gering zu halten, wurden quadrantenweise entweder das ASIN-
oder das ACOS-Signal zur Ausgabe verwendet. Ausgegeben werden jeweils die Segmente, welche von den Amplituden
am weitesten entfernt sind. An den Umschaltstellen entstehen dennoch mehr oder weniger große Sprünge.[/FONT]
[FONT=Verdana]Ab hier ist das Programm also etwas "experimentell".

Vielleicht hat ja jemand eine Idee und macht hier weiter?[/FONT]

Thomas_v2.1 · 11 Januar 2020

Ich habe eine Lösung die recht gut funktioniert und ohne Winkelfunktionen auskommt.

Und zwar nutze ich einen PI-Regler im Geschwindigkeitsalgorithmus (d.h. Ausgabe von Stellinkrementen) der einen intern simulierten Winkel entsprechend nachführt, sodass der gemessene Winkel erreicht wird. Bei der Regelabweichung wird einmal Modulo "gerechnet" und bei der Berechnung des neuen Istwinkels ebenfalls.

In Pseudocode:

Code:

PhiAbw = PhiSensor - PhiSim	
	
Wenn PhiAbw > 180° dann:	
	PhiAbw = PhiAbw - 360°
Wenn PhiAbw < -180° dann:	
	PhiAbw = PhiAbw + 360°
	
PI-Geschwindigkeitsalgorithmus:	
PhiAbw = kp * (PhiAbw - PhiAbwAlt + 1/TN * PhiAbw)) // In Excel-Tabelle anders
	
PhiSim = PhiSim + PhiAbw	
	
Wenn PhiSim < 0° dann:	
	PhiSim = 360° + PhiSim
Wenn PhiSim > 360° dann:	
	PhiSim = PhiSim - 360°

Hier ein geglätteter Verlauf mit den Beispieldaten, man sieht schön dass der Durchgang von 360 auf 0 annähernd direkt verläuft, und die anderen Werte "geglättet" werden.

Die Excel-Datei mit den Berechnungen anbei.

Thomas_v2.1 · 11 Januar 2020

Der Geschwindigkeitsalgorithmus war im Text nicht ganz korrekt. Muss eigentlich lauten:

Code:

PhiAbw = kp * (PhiAbw - PhiAbwAlt + 1/TN * PhiAbw))

In Excel in Zelle F3 abwärts:
=$Q$3*(E3-E2+1/$Q$4*E3)

In der angehängten Excel-Berechnung ist in der Berechnung sozusagen nur der P-Anteil aktiv. Mit dem neuen Algorithmus ist das wie auch bei Reglern bei entsprechenden Parametern schwingfähig.

Kabeläffle · 11 Januar 2020

Hallo Harald,

für welchen Zweck wird der Sensor denn genau eingesetzt?

Angenommen es wäre ein Boot auf einem See, welches über den Sensor den zurückgelegt Weg ermitteln will, dann ist die Richtung (der Winkel) alleine nicht aussagekräftig.
Ohne zurückgelegte Strecke pro Zeit (Geschwindigkeit ~ Windstärke) kann nichts brauchbares berechnet werden.
Gleiches Prinzip gilt auch für eine stationäre Anlage, die etwas über einen Kamin abbläst und ein gewisses Gebiet meiden muss.

Wie Jesper bereits recht früh (#18) vorgeschlagen hatte, sollte es doch mit der Vektoraddition gut zu machen sein.

• Winkel und Geschwindigkeit in X und Y umrechen
• X und Y zyklisch in eine Tabelle schreiben
• Gewünschte Anzahl an Zeilen aus der Tabelle addieren
• Aus der Summe X und Summe Y gemittelte Werte für Winkel und Geschwindigkeit berechen

Thomas_v2.1 · 11 Januar 2020

Erstes Problem ist die Messwerte der Windrichtung zu glätten. Wenn du eine Reihe hast wie 350°, 350°, 10°, 10° dann ist der arithmetische Mittelwert 180°, "richtiger" wäre aber 0°.

Was Onkel gemacht hat ist so wie ich das sehe im Prinzip eine Vektorberechnung mit der Einheitskreislänge (d.h. Vektorlänge) von 1. Das Problem ist dort aber, dass durch die Glättung beim Zurückrechnen aus den Einzelkomponenten der Vektor nicht mehr die Länge 1 besitzt, und das läuft dann irgendwann aus dem Ruder, vor allem bei nur 32 Bit Float.

Kabeläffle · 11 Januar 2020

Anstatt Einheitskreislänge = 1 müsste doch hier die Geschwindigkeit eingesetzt werden!?
Kommt der Wind mit 1 Knoten aus Westen und dann für die gleiche Zeit mit 45 Knoten aus Osten, dann ist die Luft im Mittel mit 44 Knoten nach Osten gezogen.

Bei meiner Tabelle steht nicht X für Winkel und Y für Geschwindigkeit, sondern aus Winkel und Geschwindigkeit wir der Vektor berechnet.
X = Geschwindigkeit * cos(α)
Y = Geschwindigkeit * sin(α)

Step 7 Windrichtung Messwert beruhigen

Level-3

Level-3

Level-3

Level-3

Level-3

User des Jahres 2011-2013;2015-2017;2020-2022;2024

Anhänge

Level-2

Level-3

User des Jahres 2011-2013;2015-2017;2020-2022;2024

Anhänge

User des Jahres 2011-2013;2015-2017;2020-2022;2024

Level-2

Level-3

Level-3

Level-3

Level-3

Anhänge

Level-3

Anhänge

Level-3

Level-2

Level-3

Level-2

Wir schützen deine Privatsphäre