Page 1 of 1
How is dominant wind direction calculated by MX?
Posted: Fri 30 Oct 2015 1:49 pm
by freddie
I ask the question because my "yesterday" stats (
http://www.hosiene.co.uk/weather-test/yesterday.htm) say the dominant direction was NNE'ly. Using MK1 eyeball on the wind direction chart (
http://www.hosiene.co.uk/weather-test/trends.htm) suggests that it would be a tricky call to make,considering the variability of the direction on that day, but the strongest winds were from a southerly direction and the most persistent direction was west-south-west. Hence my question in the topic title
Re: How is dominant wind direction calculated by MX?
Posted: Fri 30 Oct 2015 2:32 pm
by steve
It's very similar to how it calculates the average bearing. the daily figure is basically an average of all of those averages. Once a minute, it takes the current average speed and average bearing, and calculates the X and Y components of a vector using those figures. It maintains a running total of those during the day, like this:
Code: Select all
DominantWindBearingX += (minutes*averageSpeed*Math.Sin(DegToRad(averageBearing)));
DominantWindBearingY += (minutes*averageSpeed*Math.Cos(DegToRad(averageBearing)));
During normal running, 'minutes' will have the value 1.
It then computes the bearing of the vector with those X and Y components, like this:
Code: Select all
private int calcavgbear(double x, double y)
{
var avg = 90 - (int) (RadToDeg(Math.Atan2(y, x)));
if (avg < 0)
{
avg = 360 + avg;
}
return avg;
}
Your figure for yesterday does look odd, given your graph, so perhaps there's a bug in the calculation - maybe I'm using the result of
atan2() incorrectly - it does make my head hurt, and I was unable to find a definitive solution on the web. But today so far looks reasonable, yes? It could be that there's a bug in the saving and restoring of the counters over a restart - did you you restart MX at all yesterday? Or today?
Are you generating NOAA-style reports? If so, what does that show for the dominant wind bearing for yesterday? That's done in a similar way, but using only the entries in the log file.
Re: How is dominant wind direction calculated by MX?
Posted: Fri 30 Oct 2015 3:56 pm
by freddie
Thanks for the explanation - that's useful.
steve wrote:But today so far looks reasonable, yes?
Yes, today looks spot on.
steve wrote:It could be that there's a bug in the saving and restoring of the counters over a restart - did you you restart MX at all yesterday?
Yes, the connection to the station dropped around 1103 (when I was away from home - it is always well timed!!) and I performed a re-start at around 2230 last night when I got home. You might be on to something there.
steve wrote:Are you generating NOAA-style reports?
No, I'm not.
Thanks as ever for the speedy response.
Re: How is dominant wind direction calculated by MX?
Posted: Fri 30 Oct 2015 5:03 pm
by steve
I've tested the code, going around the compass, and it seems to produce the correct results (I'm pretty sure I did the same when I first wrote it). I had a quick look at the save/restore code and it looked OK. As you had it stopped for most of the day I now think the most likely explanation is that it goes wrong when logger data is used - I'll check that.
Re: How is dominant wind direction calculated by MX?
Posted: Fri 30 Oct 2015 5:13 pm
by steve
That didn't take much finding, once I knew where to look. The bearing stored in logger entries is only supplied as an integer from 0 to 15, representing N to NNW, rather than a full bearing as with live data. I was using the integer directly in the dominant direction calculation rather than multiplying it by 22.5. This skews the result towards N. I'll fix it in the next build.
Re: How is dominant wind direction calculated by MX?
Posted: Sat 31 Oct 2015 8:24 am
by freddie
steve wrote:That didn't take much finding, once I knew where to look. The bearing stored in logger entries is only supplied as an integer from 0 to 15, representing N to NNW, rather than a full bearing as with live data. I was using the integer directly in the dominant direction calculation rather than multiplying it by 22.5. This skews the result towards N. I'll fix it in the next build.
Good detective work! Thanks Steve