Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of 
@aufdenkampe
Active 3 months agoForum Replies Created
-
AuthorPosts
-
Matt, unfortunately, I’m nearly sure that it has to be changed.
See the warning in: https://envirodiy.github.io/ModularSensors/group__sensor__hydros21.html#sensor_hydros21_ctor
I recently had this problem too!
The solution was to type:
INI1lib_deps = envirodiy/EnviroDIY_ModularSensors@0.28.1So, drop the “0”. Everything worked well, and it properly fetched v0.28.01.
I’m not sure why Sara added that 0 to this version, but I suspect is was for a reason, but unfortunately the PlatformIO library registry doesn’t like having that 0 there.
@brianjastram, I’m glad to hear that replacing the cable with a shorter length worked!
@shicks, that’s great to hear that you have a bunch of tipping buckets connected directly to the Mayfly. Could you share that code with us? Is it integrated with ModularSensors? It would be very valuable to do that.
I can’t remember all the reasons for developing the TippingBucketRainCounter device application for the Pro Trinket. I do remember exploring lots of options and getting lots of opinions back in the winter of 2018, and my memory was that there were good reasons for not using the Mayfly directly. I’ll see if I can dig up my notes on that.
@brianjastram, I think my colleagues in Washington DC have experienced a similar problem to yours, and after a bunch of troubleshooting, we figured out that it was due to electromagnetic interference in the analog signal line from the tipping bucket to the counting device. They had used unshielded cable and also had some unshielded connectors on the outside of the box. We solved the problem only after shielding the entire length of cable, and grounding one end (and only one end) to the battery negative.
I had never seen that my other installations, and those same stations worked fine our Ann Arbor office but started showing those tips at odd times of day in busy urban Environment at our DC office. Our clue was that two tipping buckets sitting next to each other on a desk were showing those random tips at the same time.
Let us know if this might make sense for your situation.
Matt, LoRa is a big leap beyond the Xbee 900 MHz self-meshing and local network stuff.
Shannon set up an Xbee 900 MHz network for us in 2012, which I think is still in use. Short story is that 1 km range is max and bandwidth is low for standard HTTP Post requests.
LoRa is much longer range (5-10 miles or more) and lower power. It does this with very low bandwidth, but it uses its own data transmission protocol that is hyper efficient. A special LoRa server platform needs to receive the data, which decodes the packet and forwards it in any format you want (i.e. HTTP Post to Monitor My Watershed). We use The Things Network (TTN), but there are also commercial options. You do need a LoRa receiver, which costs $50 to $2000, depending on capabilities and range (I’m happy with my $250 Laird RG191). TTN has many community gateways around the US, so you might not even need one.
I’ll keep you in the loop, and reach out to you for help testing.
Dale, I’m not familiar at all with the Semtech SX1272MB2DAS Shield LoRa radio module.
I am, however, quite familiar with the MultiTech mDotTM LoRa radio modules, which come with an XBee interface that plugs right into the Mayfly and works without any trouble. My colleagues at LimnoTech’s Ann Arbor office have been using them successfully in the field for over a year, and I’ve started working with them myself in the last month. I’m hoping to share a full integration with the EnviroDIY ModularSensors library in the next month or two.
BTW, if you are not yet using ModularSensors, I strongly encourage you to do so. You can learn how to use it by following our Learn EnviroDIY Programming tutorial at https://github.com/EnviroDIY/LearnEnviroDIY.
Neil & Matt, thanks for that very good news from your testing!
I’m really glad to hear that everything seems to be working well again!!!
We think we found and fixed the major issue with slowness and 502/504 Gateway errors that have been increasing since this spring!
Please let us know if you see any slowdowns from the web-browser or gateway errors from devices trying to post data, just in case there’s yet another issue we didn’t notice.
@tslawecki , @htaolimno and LimnoTech’s IT team have done numerous fixes, tweaks and optimizations to our servers, virtual machines, network, routers, and firewall over the last 2-3 weeks. For example, we had some internal DNS issues and some internal API calls were going out to the global internet rather than staying inside our firewall, slowing things down. There were other similar issues. A lot of those tweaks appeared to make differences, but the outage this weekend showed us that we hadn’t found the root solution.
We now believe that a major factor in the outages was that the database holding the measured values grew to be bigger than the RAM we allocated for the database virtual machine, which caused a major performance slowdown when combined with the other issues. We increased the database server virtual machine RAM to 60 GB (our max available), which gives us about a year of breathing room given the current database size of 43 GB (177 million data points!) and our current growth rate of almost 8 million data points per month.
The long-term solution is to optimize software stack so that we’re not so constrained by server RAM, which we know is possible. We would want to do this in combination with work on the first 4-7 issues in our Release 0.12 – Tech Debt / Refactor Code milestone, and we are actively looking for funding to do this work, as I mentioned above.
Hey All, we found an issue that cropped up in late June on the database server for Monitor My Watershed. We’ll be doing a planned maintenance shutdown today at around 12:30 ET to fix the issue, and it will likely take about an hour. We’ll let you know when it is back up and running.
-
AuthorPosts
