Weather wind speed false value

[JMBRillie]

My setup

I'm running the latest release (v0.2.0) on the weather board.
Recording every 5 minutes and sending every reading to an MQTT broker.
Using the DFRobot's Weather Station Kit with Anemometer/Wind Vane/Rain Bucket from The Pi Hut

The problem

I've had it running for about 2 weeks now and twice I've had readings of 958.8141 m/s
I'm not sure the anemometer would have survived spinning at almost 3 times the speed of sound... so I think maybe that reading was wrong... XD
I had excatly the same number both times (958.8141)

The code

The relevant code is enviro/boards/weather.py lines 110-126

  # 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

Working this backwards from an output of 958.8141 means there was a rotation_hz value of 1000 and an average_tick_ms value of 0.5

I don't know what len(ticks) would have been but it was at least 2
If it was 2 then time.ticks_diff(ticks[-1], ticks[0]) would have been 0.5, if it was higher than 2 then time.ticks_diff(ticks[-1], ticks[0]) would be higher too
I'm not sure if time.ticks_diff(ticks[-1], ticks[0]) should be an integer or not but the first integer value would be 4 with a len(ticks) value of 3

[sjefferson99]

I wrote a new fork to capture polls at 4Hz and generate accurate gust and average wind speed values once per minute on the second core. I think I reused a lot of the maths, but the collection code was all different.

I occasionally got truly massive wind speeds, but could not see a reason why. I ended up putting some logic in the processing code where if > (highest ever recorded wind speed + a bit) then drop reading and also log a return value that there was an error so I could look into it more. This fixed the problem in the logged data as you would expect, but weirdly never returned an error. I haven't been back to the code since then, but I suppose my point is, it could be the code or maybe it's hardware a bit like button debouncing. Either way a quick fix is to drop any ridiculous readings to not pollute your data and perhaps return some debug information about what intermediate values were generated to help understand the error.

[JMBRillie]

Hey Stephen,

I've found your gust_wind_multicore_polling branch on your fork.

It looks interesting! I'll have to have a closer look another day.
I've also seen your pico-weather repo - I'm also running mine on USB permanently so don't really care so much about power use - I'll take a closer look at that at some point too!

I realise I could remove the erroneous readings in post - but I wonder if they're an indication of an underlying issue?
I didn't think about it being a hardware issue like debouncing - if it is then I suppose rejecting unreasonable values is the best thing for it.

I was going to take a deeper look into how this code operates but at first glance it's not how I would have written it. For example, if you had two ticks 1ms apart then nothing for the rest of 1000ms - the average time between ticks would be 1ms and report as a windspeed of 1 tick per ms. But I think a more sensible value would be 2 ticks in 1000ms aka 0.002 ticks per ms.

As I thought about that I realised - in this use case it's probably not the root cause because the anemometer has physical intertia and rotation, so I think it's reasonable to assume that the ticks will be more or less evenly spaced over a short sample time.
I'm not sure what would count as a short sample time, but for my example of 2 ticks 1ms apart in 1000ms the anemometer would have had to turn, I think, >180deg, <360deg in 1ms and then >1deg, <180deg in the next 999ms. Which I think is unlikely.

So perhaps it is a hardware issue - I still don't think the way it's done at the moment is how I would do it - but I'd like to test it out a bit to understand what exactly is going on there, as at the moment I don't really understand why they've done it that way.

[MrDrem]

I think that this is a timing artifact, I've seen it a number of times, but not yet managed to hunt it down.

I think that it happens only on the hour readings though, which leads to my belief that the timing of the ticks is reset on the hour, so in this case 17:00 would be the 0 point for timing. This leads to issues if the wakeup happens slightly earlier than the hour, so you get a reading taken at 16:59:59.0 for example, and you get a ms value of 3599000 as your first tick, your second is then at 1000 (tick is at 17:00:01.0).

The calculation then uses a time of -3598000 as the time between the ticks.

I did try to add logging to try and catch this edge case and to work out what was going on, but it was always wiped before I got to the device due to the limited storage for logs.

I've not got any of my devices up and logging at the moment, and don't have time to play more, which is frustrating. I wish Pimoroni would have done more trouble shooting these, as I love the form factor and the idea behind them, and would have loved to have had a new version based on the Pimoroni Pico Plus 2 W.

[JMBRillie]

For reference these are the surrounding data points:

Time     ,humidity ,luminance ,pressure ,rain   ,rain_per_second ,temperature ,wind_direction ,wind_speed  ,
16:45:04 ,   87.27 ,    33.42 , 1002.26 ,0      ,   0.0          ,       5.34 ,           180 ,  1.299206  ,
16:50:05 ,   86.87 ,    11.38 , 1002.21 ,0      ,   0.0          ,       5.29 ,            45 ,  2.480761  ,
16:55:05 ,   86.58 ,    14.46 , 1002.25 ,0      ,   0.0          ,       5.08 ,           180 ,  5.217247  ,
17:00:04 ,   85.01 ,     9.72 , 1002.25 ,0      ,   0.0          ,       5.36 ,           180 ,958.8141    ,
17:05:05 ,   82.69 ,     3.32 , 1002.29 ,0      ,   0.0          ,       5.7  ,           180 ,  0         ,
17:10:05 ,   83.22 ,     1.66 , 1002.31 ,0      ,   0.0          ,       5.53 ,           270 ,  0         ,
17:15:04 ,   82.87 ,     1.66 , 1002.25 ,0      ,   0.0          ,       5.42 ,           225 ,  0         ,

and

00:55:05 ,   80.32 ,     0.0  , 1008.78 ,0      ,   0.0          ,       5.79 ,           315 ,  0         ,
01:00:04 ,   80.21 ,     0.0  , 1008.76 ,0      ,   0.0          ,       5.73 ,           225 ,  0         ,
01:05:05 ,   80.31 ,     0.0  , 1008.75 ,0      ,   0.0          ,       5.69 ,           225 ,958.8141    ,
01:10:04 ,   80.35 ,     0.0  , 1008.73 ,0      ,   0.0          ,       5.6  ,           270 ,  0         ,
01:15:04 ,   80.18 ,     0.0  , 1008.72 ,0      ,   0.0          ,       5.79 ,           315 ,  0         ,

Hey @MrDrem,

I think I understand what you mean. But I see two problems with it being a tick rollover issue

1. I can't see anything special in the time stamp when this problem occurs - all the data points for me are 4 or 5 seconds past a 5 minute multiple.
   If it was a problem around the turning of an hour would it not happen more often than 2x in 2 weeks?
   The other time I saw the problem was 01:05:05 - so I don't think it's special to 17:00 either.
2. I think the rollover problem you are describing though was patched in 408c899 as Fixes API usage and possible division by 0 for wind speed #108

I think the rollover you describe happens if you use standard mathematical operators instead of ticks_diff() as per the time.ticks_ms() page in micropython docs:

Note: Performing standard mathematical operations (+, -) or relational operators (<, <=, >, >=) directly on these value will lead to invalid result. Performing mathematical operations and then passing their results as arguments to ticks_diff() or ticks_add() will also lead to invalid results from the latter functions.

How often did you see it happen for you? How often were you recording data?

I share in your frustration but I've seen improvements even by updating to v0.2.0 from what was preloaded - so hopefully it will continue to improve.

I heard the Pico 2 was pin-compatible? Maybe Pimoroni could upgrade to Pico 2 without much difficulty?