Enviro Weather only gives average wind speeds, not gust speed.

[MrDrem]

Looking at the code for the weather board, I note that the wind speeds reported are the average seen within the recording time, which is one of the two readings that might be taken from the data gathered.

It would be good to see the gust speed also recorded, which could easily be calculated from the minimum time between 2 ticks of the anemometer.

[ZodiusInfuser]

Thanks for the suggestion. Once enviro is a bit more stable then I will look at whether it makes sense to add this

[peter-mount]

Most weather stations do report the gust speed as well as the mean speed so this would be a useful feature

[ZodiusInfuser]

@peter-mount Do you have any info on how those other weather stations record that gust speed. I would assume it's just the peak speed detected since the last reading. If so then this isn't something we can really do with Enviro as the board is in a sleep state between readings, and only captures the wind speed for a few seconds when it wakes up.

[MrDrem]

My understanding of how the wind speed was generated was that each tick was recorded as a time stamp. The number of ticks was then divided by the time between the first and last ticks, and that was fed into the speed calculation.

To get the gust speed, you would just need to find the shortest time between any two recorded ticks, and run the speed calculation using those times, rather than the first and last. The tick number would always be 2 in this case.

Let me know if I've read the code wrong though 🙄.

I was only envisaging picking up gust speed as part of the average speed reading process.

[ZodiusInfuser]

That's how the rain sensor works. The wind sensor isn't wired up that way as it would generate too many ticks, causing your enviro to forever be awake during even mild wind.

def wind_speed(sample_time_ms=1000):
  # get initial sensor state
  state = wind_speed_pin.value()

  # create an array for each sensor to log the times when the sensor state changed
  # then we can use those values to calculate an average tick time for each sensor
  ticks = []

  start = time.ticks_ms()
  while time.ticks_diff(time.ticks_ms(), start) <= sample_time_ms:
    now = wind_speed_pin.value()
    if now != state: # sensor output changed
      # record the time of the change and update the state
      ticks.append(time.ticks_ms())
      state = now

  # if no sensor connected then we have no readings, skip
  if len(ticks) < 2:
    return 0

  # calculate the average tick between transitions in ms
  average_tick_ms = (time.ticks_diff(ticks[-1], ticks[0])) / (len(ticks) - 1)

  if average_tick_ms == 0:
    return 0
  # work out rotation speed in hz (two ticks per rotation)
  rotation_hz = (1000 / average_tick_ms) / 2

  # calculate the wind speed in metres per second
  circumference = WIND_CM_RADIUS * 2.0 * math.pi
  wind_m_s = rotation_hz * circumference * WIND_FACTOR

  return wind_m_s

[ZodiusInfuser]

If you think that knowing the gust speed over this 1 second period is useful, then I can add it, but I feel it will cause more confusion, if people observe a gust between reading times and don't see that on the data, for example.

[MrDrem]

My weather station is normally set to take readings every 2 minutes (or every 5 currently, but that's because I'm not switching it back until the patch code goes to main). I also extend the recording period for wind to 2 seconds. For me, picking up the gust speed during that reading is of interest.

I think that it would be good to have what each of the readings are and when they are taken within the documentation. So from memory for the weather board that would look something like:

Rain - volume of rain between recordings. Average Wind - Average wind speed taken at the time of recording. Gust Wind Speed - Maximum wind speed seen at the time of recording. Wind direction - Wind direction at the time of recording. Light - Light level at the time of recording. Temperature - Temperature at the time of recording. Pressure - Pressure at the time of recording. Humidity - Humidity at the time of recording.

That also means that everyone know what & when recordings are taken and what they represent. Each of those sections could also be expanded to explain how they are calculated, and what chip is recording them etc. which increases the educational uses of the board.

[ZodiusInfuser]

Thanks for your thoughts. Could you raise that documentation note as a separate issue please, for better tracking

[peter-mount]

@peter-mount Do you have any info on how those other weather stations record that gust speed. I would assume it's just the peak speed detected since the last reading. If so then this isn't something we can really do with Enviro as the board is in a sleep state between readings, and only captures the wind speed for a few seconds when it wakes up.

From the metoffice:

Because wind is an element that varies rapidly over very short periods of time it is sampled at high frequency (every 0.25 sec) to capture the intensity of gusts, or short-lived peaks in speed, which inflict greatest damage in storms. The gust speed and direction are defined by the maximum three second average wind speed occurring in any period.

So if sampling for 3 seconds with 12 samples (every 0.25s) then:

• Gust is the max speed during that period
• Wind the mean speed during that period

There's also Wind Intensity but thats the average over 10 minutes - so could be calculated later depending on the users setup.

ref: Measuring gusts and wind intensity, MetOffice UK

[daved38]

If it helps Raspberry Pi Foundation have a Weather Station project, part of which covers Wind Gusts and full Wind Direction:

https://projects.raspberrypi.org/en/projects/build-your-own-weather-station

It’s an old project which I have successfully completed previously.

Regarding my progress with Enviro Weather, I have a stable Weather Station running for about 4 days powered by a 1200mah LiPo.

Currently running v0.0.8 with all available patches as at 22/11/2022. Well I think I have its hard to confirm?

I have had Rainfall reported but not convinced by the results despite heavy rainfall.

I am currently getting readings ever 2 mins and sending every 3 readings to adafruit-io (probably will move to influx DB cloud)

Was thinking could benchmark against and building Pi Zero compatible configuration?

Hope this helps

[dave-ct]

@daved38 I have also just got mine stable on the same patch version using a 2000mah LiPo. I have been checking the rain against a manual collector and so far the readings are pretty much identical. I am doing readings every 10 minutes and sending evey 3. Using MQTT locally but then have then setup a listener to push it into influxDB which I use for stats on remote display and also in Graffana (have alot of sensors around the house). Happy to share any results I capture. Below has been running for 6 days with no issues.

[ZodiusInfuser]

Thank you both. So glad to hear the patch branch has been stable for you. As such I have gone ahead and pushed ahead with a v0.0.9 release. https://github.com/pimoroni/enviro/releases/tag/v0.0.9

This will now give a new baseline to check issues against to push towards a 0.1.0 release.

[daved38]

Switched to v0.0.9 earlier today. Replace LiPo with 2000mAh. Looking good so far. Hopefully some rain overnight to trigger rain sensor.

One minor gripe Voltage feed not disabled so if I delete, in my case in adfruit-io, it re-appears Just need to check code to stop it. Also as Luminance has replaced Light its a new feed so for me re. adafruit-io just a tidy-up Both not major in the scheme of things just testing observations.

Otherwise first 12 hours, thumbs up! Just need wind direction improvement and wind gusting then i will be happy. lol

Thanks for your efforts so far.

[ZodiusInfuser]

Hope it goes well for you 🙂

Yea, I probably should have removed the voltage feed, not just have it return zero to avoid the issue with adafruit-io. I'm hoping it won't be that long before we can get it working again though.

Incidentally I tried to set up several enviros today and discovered the 10 feed limit on the free account, so had to disable the voltage (and other readings) to get them working together. FYI, the error returned by this is 422, which seems to be the general "Adafruit IO doesn't like this" 😆

[daved38]

Happy to report been running on V.0.0.9 release since 26/11/22.

Powered by 2000mah3.7v LiPo, readings every 2 mins and uploads every 3 readings to adafrit.io.

Weather Station housed in Stevenson Screen Enclosure from Pimoroni. Wind and Rain sensors same as those available at Pimoroni.

Used same LiPo continuously for 22 days until exhausted. 5 days on V.0.0.9 Patch release, remainder on full release.

There was one intervention required because, for whatever reason, I disabled the “Battery” feed in adafruit.io. This caused the subsequent uploads to fail:

2022-12-02 19:26:13 [info / 118kB] > uploading cached readings to Adafruit.io: dd38adadev

2022-12-02 19:26:14 [debug / 103kB] - upload issue (422 b'Unprocessable Entity')

2022-12-02 19:26:14 [error / 101kB] ! failed to upload '2022-12-02T17_24_05Z.json' to adafruit_io

2022-12-02 19:26:14 [error / 99kB] ! reading upload failed

2022-12-02 19:26:14 [info / 97kB] > going to sleep

2022-12-02 19:26:14 [debug / 94kB] - clearing and disabling previous alarm

2022-12-02 19:26:14 [info / 92kB] - setting alarm to wake at 19:28pm

2022-12-03 10:01:10 [debug / 115kB] > performing startup

2022-12-03 10:01:10 [info / 119kB] - wake reason: rtc_alarm

2022-12-03 10:01:10 [debug / 117kB] - turn on activity led

2022-12-03 10:01:10 [debug / 115kB] > 73 blocks free out of 212

2022-12-03 10:01:10 [debug / 112kB] > taking new reading

2022-12-03 10:01:10 [info / 108kB] - seconds since last reading: 52507

2022-12-03 10:01:12 [debug / 99kB] > caching reading for upload

2022-12-03 10:01:12 [info / 111kB] > 63 cache file(s) need uploading

2022-12-03 10:01:12 [info / 109kB] > connecting to wifi network 'BT-G5AWMM'

The good news when I connected via USB indoors. All the 63 cached files were successfully transferred, handled by script/adafruit.io “throttling”. Then Enviro Weather was then returned to the outside world.

The only other point of note there was a number MQTT errors:

MQTT ERROR: error saving data to dd38adadev/groups/enviro, data created_at may not be in the future

Don’t know exactly when they started, guessing this may a time sync issue and perhaps a reset might have cured this.

Apart from the that, all good. The Enviro-Weather Survived, Wind, Rain, snow and sub-zero Icey conditions.

Last 7 days, the hiccup is when I changed the LiPo:

Now: 14:00 14/12/2022:

.

From: ZodiusInfuser @.> Sent: 25 November 2022 16:53 To: pimoroni/enviro @.> Cc: daved38 @.>; Mention @.> Subject: Re: [pimoroni/enviro] Enviro Weather only gives average wind speeds, not gust speed. (Issue #115)

Thank you both. So glad to hear the patch branch has been stable for you. As such I have gone ahead and pushed ahead with a v0.0.9 release. https://github.com/pimoroni/enviro/releases/tag/v0.0.9

This will now give a new baseline to check issues against to push towards a 0.1.0 release.

— Reply to this email directly, view it on GitHub https://github.com/pimoroni/enviro/issues/115#issuecomment-1327701938 , or unsubscribe https://github.com/notifications/unsubscribe-auth/A3L6OIZFYUYNUYV3BK36URTWKDVFFANCNFSM6AAAAAAR6BRBOA . You are receiving this because you were mentioned. https://github.com/notifications/beacon/A3L6OI7PNYTQA425YR74NC3WKDVFFA5CNFSM6AAAAAAR6BRBOCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSPEMP3E.gif Message ID: @. @.> >

[shanestarita]

I know this is a year old but has anyone been able to figure out how to record wind gusts?

[sjefferson99]

@shanestarita I've been working for a while on how to capture gust wind speed as per the MET office standard of sampling every 0.25 seconds and taking the highest average over a rolling 3 second window within that minute reporting period. As a side effect it also gives me a much smoother average wind speed as it's essentially an average of all 240 samples. I have not added a PR for two reasons:

One is I still occasionally get ridiculous gust readings a couple of times a day, which suggests an edge case error in my logic.

The second is it's a massive departure from the original intent and operation of the enviro board as you need to run the board continuously (I've utilised the 2nd core for handling wind data collection and processing) to achieve this and not poll every few minutes. The code I've written so far is a drop in module for the existing code base, so you could give the branch code a try and disable it all with one config value (or reflash back to release version here).

The branch on my fork is here: https://github.com/sjefferson99/enviro/tree/gust_wind_multicore_polling

Or a branch containing all my other pull requests that also contains the gust code so far is: https://github.com/sjefferson99/enviro/tree/sj-develop-multicore

Data from minute polling 2 second sample window for wind:

Data from 0.25 second polls to generate average wind and gust data (I could also add wind direction to smooth this out a little too)

Sudden edge case errors in wind gust example: