That formula looks correct but still I’m getting a very suspicious amount of northerly winds when the average windspeed in 1 minute is low but not zero. My sky is in powersave.
What if you rotated the SKY by 90 degrees or so to see if you still get “northerly winds?”
I would, but I’m already happy I managed to put up once. Going up twice for this test is a bit much, but it would help to diagnose of it was a software or hardware /firmware.
Mine are really quite easy to reach. I have both my permanent one and mobile one within a couple of feet of each other with the permanent one about three feet above the other. Look at the wind graphs from 10/10/2018 at around 7pm and see if the data looks similar to what you are seeing. If so, I could go up and turn one of the units and see what the results are like.
E Kelso: https://smartweather.weatherflow.com/station/5075/graph/15788/wind/2
Mobile: https://smartweather.weatherflow.com/station/5080/graph/14695/wind/2
1 Like
At 18:40 PT I went up and turned the SKY on station 5080 so its North faced due West. I’ll probably correct it tomorrow afternoon unless we discover something unusual. I would expect that if the direction calculations are correct that the general wind directions of 5080 should be generally from the East while 5075 should still be from the North. If both are generally North then your suspicion might correct.
1 Like
so, I just looked at your stations, and to me it appears that weak winds are still north for both stations, indicating a bug, because if it were real wind, the non-zero winds should have rotated with your device.
Sorry for the delay. We were really scratching our heads at this one because we actually don’t use “North” when wind speed is zero. When the wind is zero speed, the direction is “NULL”. You can see this in the “rapid wind” data - there is no direction at all when the speed is zero.
However, it turns out we were including those NULLs as zeroes in the average direction calculation - that’s what introduces the North bias at low speeds (the more 0 speed measurements in a given observation period, the more North bias). We’ll fix that in the next firmware update!
5 Likes
@dsj does that mean I can turn SKY - Mobile back to true north now?
FWIW, here is a picture taken from the field on the west side of my house. The SKY - E Kelso (5075) is on the taller pole (8’ vinyl coated wooden closet rod) and SKY - Mobile (5080) is on the shorter pole (~5’ repurposed fiberglass pole). The ridge of my house runs true north-south which makes for aligning the SKY really easy.
2 Likes
Yes! And thank you for running that test!
1 Like
@dsj Glad I could do it. I just hope the slope of the roof doesn’t make a difference in direction calculated between the two units. I assume that the 3’ difference in height does have a measurable speed difference. The lower one (5080) typically records a lower speed than the top one (5075).
When I went up to reorient 5080 back to true north this is what I saw in the other one. Can the unit compensate for such interference critters?
2 Likes
All this has caused me to rethink this. Why is a north wind reported as 0?
I’m not an expert but in the military we always used 360 for north. Airpirts use 360 for north. North runways are labeled 36, not 00. Is there some weather only documentation that suggests north is 0 and not 360?
1 Like
Even the zero hour on clocks has always been labeled as 12 instead of 0.
2 Likes
My digital clock has Roman numerals and there is no zero.
1 Like
David,
I fully understand your reluctance to make a change that may cause an issue in third-party applications. However, weigh the impact of such change now against the confusion in the future with new developers and such change benifits being made now.
I suggest the follow:
- Inform developers that the changes will be made soon,
- Offer the following solution:
Rapid Wind: if obs index 1 is zero set obs index 2 to null.
Sky Obs: if obs indexes 4, 5 and 6 are zero set obs index 7 to null
if speed is greater than 0 and direction is 0 set direction to 360
The above changes to third-party code will ‘fix’ the applications now and when the firmware is update will not cause any adverse affect on third-party applications.
Then in the next possible firmware:
- Set wind direction to null when speed is zero.
- Set wind direction to 360 when wind direction is true north and speed is not zero.
You made changes in the past to the firmware output that had the possibility of “breaking” third-party applications. Nothing disastrous happened and most barely remember having to make any changes.
Post a new topic in “Third-Party Developers” and ask us if we feel these changes will pose an unreasonable burden on us. I will personally ensure that each known developer is informed of the topic and kindly ask that they voice their opinion.
You may have plans to produce a semi-professional station in the future and I think this issue will be handled in a new station correctly. The change now will keep all hardware consistent.
My humble opinion for what it’s worth.
Best regards,
Gary
5 Likes
The old Rooster disappeared from the Vane on the barn last week. Got a note today saying he was in Therapy…
1 Like
I remember those. Where I grew up they were everywhere. I want to put one on my roof.
Now I just have this:
Which demonstrates that the arrow can be left at the old direction when the wind is calm.
Yes. There is the back-end, the data coming from the Hub. That is the two issues David documented. Issues, not options.
What you are referring to is an option for the front-end. What the UI does with the data. The UI is free to do anything the developer wants without regard as to what comes from the Hub.
As stated in point 2, WeatherFlow decided to display the direction as “—”. I decided to display the direction as " " and leave the arrow in the last reported direction, just like a real weather vane.
So, item 1, he states a fact followed by why the Hub is incorrect. I sincerely hope he will direct it to be corrected soon.
Item 2, he states a fact followed by the method used by the UI in the phone and weather applications. Easy enough for WeatherFlow to change. I don’t have a dog in that pony show but I do feel it would be better to change it.
I have outlined what third-party developers should do now to alleviate any issues should WeatherFlow change the firmware. Simple, easy and it should please everyone and offer a better user experience. And it will give you exactly what you want.
I agree with @GaryFunk. With plenty of warning, and perhaps some test data to test our code against, the benefits of making the change outweigh the drawbacks.
This I have to disagree with though. 0 degrees = 360 degrees when describing a position around a circle (and mathematically is also identical), so I’d prefer it to stay as is (although this is very much a matter of taste).
1 Like
There is precedent for using 360. A circle has 360 degrees and counted 1 to 360. Navies across the world use 360, airports use 360. A north runway is called 36, not 00. Every military calls it 360. There are other weather services that use 360 for north so it just makes better sense. 0 is ambiguous and since we count from 1 to xxx it logical to count north as 360. And 0 is just a place holder for none or nothing.
1 Like
I get what you’re saying and certainly accept that the precedent might be set. Saying “36” over radio is certainly less ambiguous than “00”. For the visual display, however, my opinion is that 0 is better than 360. But that is just me 
.
One point to make though is that a circle is counted from 0 to 360 (or 259.9999999…), not 1 to 360. Otherwise how do you describe a wind direction that is 0.1 degrees east of north? 360.1 has to wrap to 0.1.