|
|
|
microcontroller reliability
Sunday, March 22 2020
Gretchen worked her last conventional day at the bookstore today, though the bookstore will continue with limited hours during the pandemic. Unfortunately, Neville the Dog will not be able to work there during the pandemic (and he didn't work there today either). Gretchen says she practiced good social distancing despite people coming into the store and a brief visit to the Garden Café (which is operating as a take-out only restaurant). The bookstore still functioned somewhat normally today, but during the reduced pandemic hours, customers will not be allowed into the bookstore and will have to pick up their books from a table placed out on the sidewalk.
As you know, I've built and been trying to perfect a Raspberry-Pi-powered weather station (called the Weathertron). The data acquisition and storage component has been done for awhile now, with the most recent data it collects being humidity. I'd been hoping to build out a web page for viewing that collected data in graphical form, but I keep being delayed by unexpected reliability problems. It's easy to quickly build an Arduion or Raspberry-Pi based device that does something useful or interesting, but it's a much harder task to make it so it does so reliably. I first experienced this when I built the Arduino-based controller for the hydronic solar panels (starting in 2006). I'd get weird glitches from power transients or communication unreliability, and I'd have to find work-arounds. Eventually I implemented a watch-dog-based system to automatically restart the Atmega328 microcontrollers (there are two) in problematic situations. Perfecting this system took a lot of trial and error. Now the system is pretty reliable, and I can ignore it for months at a time. But getting there was not easy. More recently, I've had similar trouble with systems as diverse as the Arduino-based Mohammed Ahmed clock (whose audio component is still almost uselessly unreliable) to the Raspberry-Pi-based surveillance robots (which are sometimes beset by wireless communication unreliability, particularly when sited outdoors). Interestingly, the battery-and-solar-powered Disturbatron (which allows me to remotely produce audio from a megaphone) is one of my more reliable devices.
The Raspberry Pi component of the Weathertron is actually fairly reliable, and it's rare that I can't reach it. It also has a script to automatically reset should it experience connection difficulties. The problematic part of the Weathertron is its Arduino Mini Pro, a tiny board that handles interrupt-driven data (such as from the precipitation counter and windspeed sensor) as well as raw analog data (from the wind direction sensor). The Arduino will work for hours or days and then suddenly become unreachable across the I2C bus (which is how the Raspberry Pi talks to it). It became so bad that I implemented a way for the Rasberry Pi to perform a hardware reset on the Arduino when it senses that it has become unreachable. It actually sends a low-going pulse directly to the Arduino's reset pin, and that usually fixes the problem.
But today, not even a hardware reset could make the Arduino reachable. What was the problem? Initial theories included bad hook-up wire, a crappy Atmega328 (I tend to buy my devices as $2 board that arrive on a slow boat from China) or temperature problems (today was unseasonably cold, with temperatures only rising into the 40s after the sun had been shining on the land for hours). Eventually I figured out that the hardware reset actually would work, though I had to wait 1.5 seconds after performing it before attempting to do any communication with the Arduino.
A male cardinal photographed through the laboratory window today. On Facebook, I jokingly referred to it as a "crimson jay."
For linking purposes this article's URL is:
http://asecular.com/blog.php?200322 feedback
previous | next |
