counting tipping events of rain gauge

Sensors Environmental
1

Hello,

I have several (3) Micro:Climate Kits, and what follows applies to all of them.

When I measure the rain gauge by using the extension functions from makecode.microbit.org, I see that most rain events (tipping event) add 0.022" (inches) of rain. However, in the guide:

https://learn.sparkfun.com/tutorials/mi … rain-gauge

it says it is 0.011" of rain per event. Which one is the correct? I don’t know.

Moreover, if I divide the rain measure by 0.022, and manually trigger an event, most of the times I read how the counter increases by 1, but other times it increases by 1.5. It is as if the libraries, somehow, are messing with the 0.022 and 0.011 in an inconsistent way.

I tried pouring 1L of water through the gauge and mentally counted the ticks while at the same time I measured the number of events with the micro:bit.

The first liter was poured a bit too fast, and got 390 real ticks while the code measured 444.

Then I repeated the pouring in a reasonably slower way (not superslow either) and got 404 (me) vs 495 (readings) on one run, and 401 (me) vs 494 (readings) on a second run. Overall, it would seem that 1 about 4 or 5 times, the library interprets the reading as 1.5 instead of 1.

If we go to

https://github.com/sparkfun/pxt-weather … therbit.ts

line 178

let inchesOfRain = ((numRainDumps * 11) / 1000)

which seems OK and consistent with the guide (0.011 inches per event).

Code from line 187 is more complicated (I can’t program in TypeScript), but from inspecting the library, I would say that in order to get events, I should divide inches by 0.011 and then I would not get any half-integer measures. However, this means that most of the events (around 80-85% of them), are giving a +=2 instead of +=1, and I can’t understand why.

I would appreciate any help.

Thanks

2

I don’t have that kit, but it sounds like the bucket switch is bouncing, so that sometimes two or more pulses are counted for one tip. Easy to diagnose if you have access to an oscilloscope, but try manually flipping the bucket, while watching the count.

It is a common problem with switches, and usually can be fixed by introducing an appropriate delay and resampling the input. The bounce timing will depend on the switch.

PS: How can a count increase by 1.5?

3

Thank you for the answer,

The switch never reads a 1. It either reads 2 or 3.

Since I can manually move the bucket, I have tried by moving it very slowly, fast…

The result (2 or 3) does not seem to depend on that (as far as I have observed).

The bucket does not visibly bounce (sometimes, but if I manually move it preventing it from bouncing, the readings are the same, just 2’s and 3’s).

Since I am using the makecode library, can I tweak these variables you suggest? Of course I could always cut the RJ11 connector, use an analog reading and write a custom code, but I would prefer not to go down this route since I have the nice RJ11 plugs with the weather carrier board.

Thanks.

4

Regarding your question about 1.5:

If I divide by 0.011, considering that the bucket reads 0.011 inches of rain per event, I get readings of 2 and 3 for every bucket tipping. Since most events read 2, I first considered dividing by 0.022, hence the 1.5 I sometimes get.

5

I suspect that the code counts the initial switch closure plus one bounce as one “tip”, but sometimes you get an extra bounce.

If so, that really is poor code design. Search for “switch bounce” to see how other people handle the problem.

This page clearly demonstrates the issue: https://www.allaboutcircuits.com/techni … l-with-it/

Bouncing is fast (microseconds to a few milliseconds), so you really need a scope to see it.

The bounce timing and count varies even for “identical” switches from the same manufacturer, so a custom solution may be required.

6

The switch is activated by a magnet that goes along a circular arc. The activation occurs at the middle of the arc, so tiny bounces when the magnet arrive at the end of the arc are (imho) unlikely to trigger the switch. In fact, I make the bucket visibly bounce on purpose and many times it does read a 2.

I am not saying the problem is not related to what you say, of course. Perhaps the signal while the magnet is passing close to the switch is noisy and it shows 2 or 3 spikes?

Is there a way to deal with this within MakeCode?

7

There should be, but I don’t know MakeCode. Many, many solutions are posted on line for other coding languages.

8

I have now read the link you provided. It must be something like that, I agree. But this would not be the bucket bouncing, but some kind of noise or bouncing during the magnet-switch encounter.

I have opened an issue on the library’s GitHub as well.

9

I’ve been discussing switch contact bounce all along.

In your case, the switch is a reed relay, and those certainly do exhibit switch contact bounce.

10

I misunderstood, sorry. I was not even aware such a thing existed.

Many thanks for your replies.

If I could have access to the analog signal I could easily code to prevent this, but I think that the MakeCode library for this should be improved as well.

11

In addition to the issue of switch bounces, I have performed the test of slowly (but not very slowly) pouring 1L and consistently counted (mentally) around 400-405 events.

The collecting area of the rain device is rectangular, measuring 10.9cm · 4.9cm = 53.41 cm². The corners are rounded, so it is even less than that.

This mean that, if the area would have been 1m², we would have collected 10000/53.41 = 187.23L = 187.23 mm. Since 25.4mm is 1", we would have collected 187.23 / 25.4 = 7.37" of rain.

Finally, 7.37" in around 405 events means 7.37 / 405 = 0.018 inches per event.

In order to get the nominal 0.011 inches per event, I would have needed about 670 events, something that not even with the switch bounce I get (with switch bounce, I get about 495-500 events).

I must be doing something wrong, but I don’t know what. I would like to know the details that give the 0.011" per event.

We have bought 6 kits like this for some educational projects at my university and it would be nice if the developers could share these details (and fix the switch bounces with better code).

Thank you

12

The rain gauge design is typical, but the software appears to be a complete failure. The “mystery constant” 0.011 is simply wrong.

If the switch bounce is fixed (which should be relatively straightforward), then the rain gauge can be calibrated so that the readings are meaningful.

13

We agree.

I have now performed a very slow pouring of half a liter. I did because it makes sense that a very intense pouring can make the bucket miss some of the water.

And indeed, got 257 counts, which means we would have around 514 counts per liter. If we accept the calculations from before, we would get 7.37" / 514= 0.0143 "/count.

Unless I am missing something here, it would seem 0.0143" (0.014-0.015) would be a more suitable factor.

As you say, this is trivial to change in the code. However, we need the help of the developers for the reed relay issue. I hope that they apply the same new fix to the other relays of the kit (wind speed has one and wind direction a few of them).

14

However, we need the help of the developers for the reed relay issue

Why? Switches, including reed relay switches, bounce. That is a simple fact of life. The problem created can be solved with software.

Any competent programmer, familiar with the programming language, can modify the code to ignore switch bounce, but the bounce pattern should first be characterized using a scope.

15

And here’s a link to Jack Ganssle’s famous article on switches, bouncing, and debouncing… http://www.ganssle.com/debouncing.htm