We are a community sailing club based in Berkeley, CA and use the Tempest to show wind strenght to our water sports members.
We are trying to resolve an issue we are seeing on windy days where wind speeds are above 20 knots. The wind is around 20 knots with gusts around 24-25 knots, sometimes even close to 30 knots.
An example of such day (we are running WeeWx to display the data but the data is the same directy on the Tempest website): Cal Sailing Club - Archive
Then suddenly we get a spike around 45 knots or even more. We know this is totally wrong both because it doesn’t reflect reality, and there is another wind sensor nearby that shows similar wind to the Tempest, but without these extreme gusts.
I was wondering if anyone else has experienced something similar, and what could be causing this.
The sensor is on the top of a roof at around 40 feet, and there are no obstructions in front of it (just water from the San Francisco Bay)
I know nothing of that particular WeeWX station driver, except that it seems to be hard-coded for situations with one single Tempest device with no ability to change sensor_map settings or select individual packets…
Thanks for opening a github issue on the driver. We can play around a bit to see if/how the obs_st packets vs rapid wind might adjust this but based on past experience I suspect we’ll find they have the same issue. If the hypothesis is around the spray having a higher density and therefore moving the ultrasonic deflection further I’d suspect that to impact obs_st the same as rapid_wind unless you’re getting a gust average vs max in that field. We can ask weatherflow too.
Also, I like the suggestions about a map etc… Captain Coredump did that for the UDP based driver however I didn’t follow suit since I found it quite tricky to manage in config and opted for ease of use. It would be nifty to go there too though. I didn’t build initially for station based readings since I don’t have a test case but that’d be interesting to try out. Not sure if they support websocket for stations or only for devices.
It’ll be fun to compare rapid_wind to obs_st data…
One more note WRT the hypothesis. Sound travels faster through water than through air which implies the deflection would be less however the transition from air to water and vice versa is unpredictable which would scatter the signal to the receiver I’d think. In that case, not sure that the change of sensor field will help. But we can try it.
I have not seen this issue in exactly this way on a Tempest. If it was water then it usually is a drop of water sitting on the lower face of the slot or hanging under the top but that is usually in lighter wind and in my experience is always a lingering bad reading and much stronger.
I am thinking that it might be an insect or something hanging on a spider web that blows into the gap for a moment.
But it can be a ‘glitch’. There are sometimes random readings which appear for unknown reasons. I once tested a Tempest for several days in constant wind inside and found occasional glitches can occur for no reason. Usually they would blend into the other values and not be noticed.
It may be a faulty Tempest, you could ask support what they think: Open a support ticket from top of this window to ask them.
In my personal display software I have included several algorithms which attempt to remove any glitches in any values from causing a disruption.
The historical link you gave shows the time of the gusts and their value on the graph but not in the table for the same time.
So if the graph used the same values from the table then the random gusts would not be displayed. That would be a weewx issue which I currently dont know.
And you say that the same gusts are also directly on the Tempest web site but I can not see that to know. Now as it is from several days ago it is not so simple to see the one minute values but they are still there. One way to get them is to use this google sheets method:
Not ideal, but another method to tidy the graphs may be to remove your gust line.
cheers Ian
They might not understand the rationale for a third-party integration. My thought is that WeeWX will use its internal gust calculations with rapid_wind, versus the Tempest’s per-minute gust observations, which may come out with different results or trim the errant gusts…
