Wetlands BME280 Datalogger - NEW Upgrades and Performance
ฝัง
- เผยแพร่เมื่อ 16 มิ.ย. 2024
- This video summarizes recent upgrades and performance metrics for a solar-powered Arduino-based weather datalogger installed at the Canelo Hills Preserve in southeastern Arizona. This installation measures temperature, humidity, and atmospheric pressure using a Bosch BME280 sensor.
Generic Datalogger:
Adafruit 32U4 Adalogger: www.adafruit.com/product/2795
6W Solar Panel: www.adafruit.com/product/1525
2500 mAh Lipo Battery: www.adafruit.com/product/328
Solar Lipo Battery Charger: www.adafruit.com/product/4755
Sensors and RTC:
DS3231 Precision RTC www.adafruit.com/product/3028 (or eBay)
BME280: www.adafruit.com/product/2652 (or eBay)
More Arduino-based datalogging examples and recommendations:
Logging Weather Data with an Arduino Microcontroller:
• Logging Weather Data w...
Code and data here: drive.google.com/drive/folder...
Other projects and videos filed here: modestmaker.com/arduino/part2...
Thanks for dropping by! - วิทยาศาสตร์และเทคโนโลยี
The mystery of the hardware lock up. For my data loggers, after they record their data, I put them into a deep sleep mode, then have the RTC wake them up at the desired interval, which performs a reset, reads the time and data; writes the data, then goes back into deep sleep.
Yes - I have to do a little more research on making these deployments more power efficient. With so much sunlight in Arizona, power has never really been an issue but I'd like to make this more cost effective via elimination of panels and chargers. I like the idea of having a reset done programatically-- will investigate. Thanks You!
I endorse this because, in addition to the deep-sleep trick which I do use and it does save power, your scheme's reset-per-sample will bulletproof the machine against all kinds of glitches known or unknown, hardware or software, if they're the kind that can be solved by a reset. Besides that, code that only has to run one sample all the way to completion one time is surely easier to maintain than code that hopes to run forever. (Fingers crossed it might be smaller too.)
Unassigned IO pins can become noisy gremlins that sap power and cause trouble, especially during long delays during which interrupts may be unknowingly enabled because delay() may not stop all activity, depending on your processor. A nearby lighting storm can also cause havoc to trigger such a sensitive system into the weeds. Ground loops and unshielded wires make matters worse. During void setup() declare any unused floating IO pin a pulled up input.
A good practice in autonomous systems is to comment out your Serial.prints after development debugging.
For very long delays, instead of using delay(), which is prone to many risks, I recommend millis(). There are many great tutorials and examples.
I use millis() for autonomous systems that operate continuously for many months, even taking account of its counter’s overflow.
Excellent feedback. What you state makes sense and is not to difficult to implement.I appreciate your thoughtful response and advice-- thanks for giving me another venue to explore.
I've had similar issues with long term sensors, specifically using ATmega MCUs. One issue is because you're accessing the file system on an SD card with a relatively small and incapable 8-bit micro-controller with a lot of limitations, one thing that can happen is your RAM becomes fragmented or simply just full, the memory management on those little micro-controllers isn't smart enough to manage the memory in the same way a desktop PC can so will just lockup.
You can solve this issue by resetting it regularly in software, you can put the ATmega32u4 into sleep mode and use an internal timer and interrupt to wake it up again, this also has the added benefit of using significantly less power however there are limitations on max sleep time and resolution.
Unfortunately it's rather complex and involves editing the registers of the MCU directly, but a first example you can try on your ATmega32u4 to go to sleep for 8 seconds is:
```
// start going to sleep
USBCON |= _BV(FRZCLK); // freeze USB clock
PLLCSR &= ~_BV(PLLE); // turn off USB PLL
USBCON &= ~_BV(USBE); // disable USB
ADCSRA &= ~(1
Yes - I'm going to have to do a separate video just on testing various remedies to address these lock up issues. Yours is yet more excellent feedback for which I'm sincerely thankful. I am glad I'm not alone and that others are coming up with remedies- that's why I share all this stuff online. Thank You!
I have across the same problem with some of my data loggers. What I did is install a small mechanical clock which powers the system down every Sunday at 2AM. That minimized system crashes to less than once a month so far. I have several commercial system that have this feature built in. That's where I got the idea.
Mechanical clock - interesting. I'd love to hear more details on your design. Thanks, and at least I don't feel too bad about the halt in logging since it's starting to sound like something fairly common for these little microcontrollers with multiple remedies out there.
@@ModestMaker Well my systems are much different then what you are doing. My alarm/recording systems are centrally located indoors, so I have a 120 volt power supply readily available. My systems monitor the air quality of large compressor rooms at cooling and freezing food processing plants mostly sniffing for ammonia refrigerant leaks.
I use one Intermatic ET8215C 7 day time clock to reset my data monitoring systems every Sunday at 2am, the time with the least demand on the compressor rooms. Since I only sample the air quality every 10 minutes, a simple reset time of 1 minute means no loss of data.
Government and insurance underwriter regulation of confined spaces preceded data alarm/monitoring and recording systems. So we had to build our own. Tough to do when my father ran the company.
Now days alarm monitoring and recording systems are commercially available. But I still build my own Arduino based systems to monitor and record data remotely via various internet apps. This gives me the capability to monitor trending data. Thus I can notify the compressor room operators prior to an alarm trip. Something the commercial monitoring systems do not provide.
This also allows me to monitor the compressor rooms independently and without a paid subscription to the manufacturers of the commercial recorders and alarm companies.
I still have the occasional system reset like you have, but no more than once or twice a month since I started resetting the systems on a regular basis. I tried several times to locate the error in the system causing the resets, but with no luck. I'm just a novice programmer and haven't taking it any further since the time clock solution. They seem to make my systems much more reliable so I didn't see the need to get a professional programmer involved.
Although someday I would like to build systems like yours to remotely monitor my property and a few greenhouse operations. But I'm currently just too busy to get around to it.
Thanks for you videos. They are very informative.
Thanks for the summary. Sounds like you enjoy the low cost and customization freedoms that this platform offers (like me) 👍. Agreed- much more you can do when you can customize like this.
This is some good work all right! I'm in the PNW and solar doesn't go as far for me, but the deep-sleep maneuver of Mr. Donnelly also works well for me. A question: have you ever had trouble with the SD card interface? Or put another way, if the data were at some point to cease being written successfully onto the SD, how much time might go by before you'd find out?
Excellent question-- I only get out there once a quarter at best, so the possibility of losing large volumes of data is significant. Having said that, I've gotten a lot of good feedback on potential fixes which I will be testing and posting to this channel - sounds like this is a common issue needing remedy! (In the past, I've used satellite and cellular, but that costs money.)
I used a watchdog timer to automatically reboot my microcontroller if it got hung up. You can set the watchdog timer to whatever time you think is sane for it to do its work, like 4 seconds. If the microcontroller is not done in 4 seconds, then the watchdog timer will reach over (you have to look real fast 🙂) and hit the reset button. That might help you out.
Will check if out- thanks!
How did you manage processor so that it wouldn't drain the battery? Did you put it in sleep mode? I have a flood monitor using an ultrasonic sensor and am using a 5110 timer from Adafruit to completely turn off the system for 10 minutes, then back on to take a measurement.
Because we get so much sunlight in Arizona and since these are relatively low power systems, I haven’t had to deal much with power management but it is something I am exploring at this time 👍.