envirodiy / tippingbucketraincounter Goto Github PK

From Slack conversations with @bschulz1701.

In June @Volk3rJ noticed that his rain gauge returned a -9999 during a very intense rain event:

Just a curious question. We seemingly had a pretty intense short rainfall event yestarday. Our LAF rain gauge read about 0.55” in 15 minutes (see first image below). Our McF gauge had 0.22” in one 5 minute intervall but a reported an outage (-9999) in the intervall before (second image below). Is it possible that the rainfall counts exceeded the max value in the trinket script or something like that? Just wondering since it just hapopened during a high intense event. Or was this likely just a coincedence?

He has let me know that this has happened a few other times.

Here is a description of the requested feature:

Currently our precip. graphs look like this, a bar graph of tips per 5 min. interval.

We want them to look more like this

A 24 hour total, but in inches.

As I gather from envirodiy.org https://www.envirodiy.org/topic/accumulating-precipitation-graph/ I need to set up a count function that resets every 24 hours but I haven’t been able to find specific directions about how to do this.

This would also solve the problem of tip data being missed by failed cellular transmissions because the count would be maintained and have every opportunity to be sent. The only problem would be if tips happened just before the reset and then there was a transmission failure.

You can probably use millis() since last request instead of trying to communicate with an RTC and assume the requests will be more frequent than the millis() rollover (49.7 days).

From TippingBucketRainGauge.
Make sure all docs in ModularSensors are also changed.

Adafruit is deprecating the Pro Trinket!
Here's their waring:

Deprecation Warning: The Pro Trinket bit-bang USB technique it uses doesn't work as well as it did in 2014, many modern computers won't work well. So while we still carry the Pro Trinket so that people can maintain some older projets, we no longer recommend it. Please check out the Metro Mini (ATmega328 @ 5V 16 MHz), ItsyBitsy 32u4 5V 16MHz, ItsyBitsy 32u4 @ 3.3V 8MHz or ItsyBitsy M0 @ 3V 48MHz. All have built-in USB and are comparable in price! The ItsyBitsy's especially are about the same size and have native USB and tons of pins, so they're a very close compatible.

Given that we need it to be:

• 3.3V to be powered from a lipo battery powered loggers such as the EnviroDIY Mayfly, and
• low power itself because it always needs to be powered on,
  the only candidate listed by Adafruit is the ItsyBitsy 32u4 @ 3.3V 8MHz.

Are there other candidate boards?
What would it take to adapt them to function as an I2C counting device?

Modifications to the firmware code could enable this to count the higher frequency signals of a reed-switch anemometer such as https://www.store.inspeed.com/Inspeed-Version-II-Reed-Switch-Anemometer-Sensor-Only-WS2R.htm

This might not be a great idea, given that the Project Tally device and Tally Library all do this quite well.

If someone is interested in doing this, here are some ideas from @bschulz1701 (Mar. 2019):

I just glanced back at the code, and using the debounce I have, you would be able to measure windspeeds up to ~ 100 m/s, realistically I would not want to push it beyond ~75 m/s (Still plenty). The bigger issues are that right now it is just set to return 1 byte (0 ~ 256 values) which would mean if you're measuring every 15 minutes, you would have a max average wind speed of 0.28 m/s, not even enough to spin the cups. This can be fixed of course, we would return a 4 byte (0 ~ 4.29billion) value no problem, of course, the code on both ends would have to be modified to send and accept that, but not a big deal. I think the biggest issue if that we could hedge a bit of a hacked system I made for you because we would only wake up when the rain bucket would tip, maybe a few times an hour, and on average 50 tips in a day would be a good amount, where as with the anemometer, we get several counts per second, which means the device never can go to sleep and we draw much more current (several mA) all the time, which is less than desirable.

tl;dr The [Trinket] counter I made could work with some software modification, but it would consume a decent bit of power (a few mA) being on all the time, the Project Tally device I designed would be a better fit I think (unless you need I2C, which is going to be added, but not on there yet), because it sips power at <uA when it is recording counts, and has the range designed to handle the rapid ticks of anemometers