Weather Station Ideas

[Gina]

Since the Mean Speed is summed over a long period I could read it to greater precision than integer but I guess wind speed in whole miles per hour is quite sufficient and "if it ain't broke, don't fix it".  The gust speed is only accurate to units of 1.5mph as the calibration factor is mph in 4.5s and I'm reading in 3s periods and correcting afterwards.

The test rig has been running correctly for a while now so I guess I can put everything back together and put the rig back on the observatory.  Having found a definite cause of problems and fixed it I feel reasonably confident that it should be ready for deployment - again.

The anemometer rotation rate has just increased a bit - guess the mains voltage has increased and with it the fan speed.  I'll just watch it a bit longer and see if the mean speed increases too as it should (slowly).

Edited September 5, 2020 by Gina

[Gina]

Mean speed has now increased to 10mph.

Got one more test before deploying the wind sensors - reduced the fan speed.  Now watching for the speed readings to decrease over the next 10m or so.  I don't expect the gust speed to change until more than 10m have elapsed but the mean speed should gradually decrease over the 10m period.

Edited September 5, 2020 by Gina

[Gina]

It was going well with reducing the fan speed until I turned the fan off and the anemometer stopped then I got this!

[Gina]

Mean speed have now decreased to zero which is right but the gust continues to show 73mph!!  Back to the drawing board then and no deployment!! 

[Gina]

Update...  Gust gauges now show zero so it seems the 73mph was an instantaneous value which propagated through the gust ringArray until it was replaced by the correct zero value.  I'll do some more testing...

Fan on low and anemometer rotating at about 1 rev per second.  Gust showing 3mph.

Edited September 5, 2020 by Gina

[Gina]

[Gina]

Gust speed now zero and no funnies!

[Gina]

Urck!!  Just thought I'd test the rig with the top assembled.  Doesn't look like it'll be deployed today!!  Fan on and 10mpg gust speed.  Mean rose to 9 as usual.  Turned fan off and let the anemometer slow down and stop.  While this is only a display and for information only I don't really want ridiculous readings!!

After 10m the giant gust had propagated round the ring Array and the mean speed gone down to zero.  Next minute the gust speed read zero too.

Edited September 5, 2020 by Gina

[Gina]

What to do now - that's the question...

The mean speed seems to be working alright now.  Mostly the gust speed is alright but sometimes getting these rogue values.  Guess it's time to add some debugging.

[Gina]

Watching the ringIndex, windGust and windSpeed.  Got the fan a bit closer and gust speed of 13mph.  Number is the raw gust speed (counts in 3s) and Number2 is the speed summed over 21 3s intervals for the mean.  Next to switch off the fan and see what happens.  I may have to extend the debugging to show all the ringArray values - quit a lot of data!

[Gina]

Fan and anemometer stopped and this :-

Followed by this :-

Showing one rogue raw gust value (of 17 equating to a speed of 25mph) followed by the correct zeros.  So where did that rogue raw count come from???

As usual the rogue gust value persisted in the gust ringArray until replaced by 10 zeros (ringIndex=1).

The rogue value only seems to exist in the windGust variable - there is no sign of any perturbation in the windSpeed, eliminating a rogue PulseCount value.  This limits the part of the code under suspicion to the timer ISR code relating to the gust speed.

void IRAM_ATTR onTime() {
  portENTER_CRITICAL_ISR(&timerMux);
  interrupts=1;
  windSpeed += PulseCount;  //  Accumulate mean speed
  if (PulseCount > windGust) {windGust = PulseCount;};  // Get max speed for gust
  PulseCount = 0; // clear count 
  timerCount++;  // count number of timer interrupts for 1m speed sum                                      
  portEXIT_CRITICAL_ISR(&timerMux);
}

This would appear to be the line of code that causes the rogue gust speed

  if (PulseCount > windGust) {windGust = PulseCount;};  // Get max speed for gust

Or is it???  If windGust is high when this line of code is run it won't be changed!

Edited September 5, 2020 by Gina

[Gina]

This leads to this code where the windGust variable was last accessed.

void speed21sum(){
  int divisor = 140;
  sendringIndex();
  sendNumberMessage(windGust);
  sendNumberMessage2(windSpeed);
  // wind speed mean and gust ring arrays and report
  meanArray[ringIndex] = windSpeed; // put windSpeed into new array index
  gustArray[ringIndex] = windGust;  // put windGust into new array index
  meanSpeed = 0; gustSpeed = 0; windSpeed = 0; windGust = 0;
  for (int i = 0; i < 10; i++) { 
    meanSpeed += meanArray[i];  // sum the windSpeeds 
    if (gustArray[i] > gustSpeed){gustSpeed = gustArray[i];}} // find maximum gust speed
  divisor = timerCount * 10 / 1.5;  // with timerCount=21 this gives a whole number
  meanSpeed /=divisor;  // the first sum was over 21 values and then the second over 10 values
  gustSpeed *= 1.5;  // Speed count over 3s rather than 4.5s
  sendSpeedMessages();
  ringIndex = (ringIndex+1)%10; // move ringIndex on to next location in the ring arrays
}

windGust is reset to zero in this code.  Q.E.D.!!!

I've been through the sketch with Find and there are no occurrences of any of the variables in question other than where I've looked.

I thought one possibility might be that the anemometer stopped right on the edge of the Hall sensor operation and vibration caused multiple pulses but if this happened the mean value would show a small jump, which it doesn't seem to do.  To be sure I would have to check the PulseCount at each timer interrupt event.

[globular]

Vibration causing a one-off blip in the pulse that doubles the gust will not really show in the mean as you are averaging over a large number of pulses and only showing the average in round mph.  One of your earlier tests had a larger gust blip and there was an increase in the mean then too.

I suggest you re-run the test but rather than turning off the fan (with associated vibrations) put a piece of card in the way to divert the wind - very carefully so as not to knock anything.

You'll then know if it's a physical vibration issue or some problem in the code when pulses stop.

Edited September 5, 2020 by globular

[Gina]

To see if it is a burst of pulses as the anemometer stops I think I'll save the PulseCount into a ringArray in the timer ISR then read out the ringArray outside the ISR.

[Gina]

This is the run up.  The PulseCount is in Number.  Mainly showing 8 counts which equates to 12mph but peaking 9 which equates to 13.5mph so 13mph for the gust speed is right and 12mph mean speed is right.  Now for the run down...

[Gina]

Here's the rundown.

[Gina]

1 hour ago, globular said:

Vibration causing a one-off blip in the pulse that doubles the gust will not really show in the mean as you are averaging over a large number of pulses and only showing the average in round mph.  One of your earlier tests had a larger gust blip and there was an increase in the mean then too.

I suggest you re-run the test but rather than turning off the fan (with associated vibrations) put a piece of card in the way to divert the wind - very carefully so as not to knock anything.

You'll then know if it's a physical vibration issue or some problem in the code when pulses stop.

I think you may have a good point so I've moved the fan off the table onto a different "perch" that won't transmit any vibration to the table.  Plenty of space between fan and anemometer so no problem with a piece of cardboard to stop the breeze.

[Gina]

Steady state.  Less breeze.

With wind break!  Voila - no rogue gust.  But this is only one sample I'll need to repeat.

Edited September 5, 2020 by Gina

[Gina]

Next test.  Anemometer was stationary when the pulse occurred!

Tried tapping the table to produce vibrations but no pulses!

Gust cleared out of the ringArray.

[Gina]

Well, I don't know.  It's just a single event - one high count.

[globular]

I'd still like to see some more consistency with your variable types. Mixtures of int, long and float together, without explicitly converting when cross assigning, seems a recipe for disaster; as does having int variables being divided and/or multiplied by 1.5 without explicitly saying how you want the remainders to be treated.
Probably not the issue you're seeing - but until it's ruled out it just might be.  

[Gina]

The rogue PulseCount only occurs when the anemometer is stationary.  I have never seen anything wrong when the anemometer is rotating.

There are no float types in this sketch.  All variables are either integer types, strings or char arrays.  The latter are needed by MQTT.  I could multiply by 3 and divide by 2 rather than multiply by 1.5 I guess but all the calculations now appear to be correct.

I guess I could just detect the rogue value and reject it but I would rather know the cause.

[Gina]

In integer arithmetic the remainder is simply discarded, no rounding up is applied if the remainder is above half.  I agree that this means division should be left until the end of a calculation to keep as much precision as possible provided no values exceed the range of the particular integer type.  I'll go through my code and apply that principle where possible.

Edited September 5, 2020 by Gina

[globular]

Do you know it's a rogue PulseCount rather than a rogue windGust or gustArray[] entry or speedGust value? 

[Gina]

Yes, this is the PulseCount history.