Power management - crestlinesoaring/ArduinoWeatherStation GitHub Wiki
Introduction
The weather station's power source is a solar panel and a rechargeable battery.
The goal is to sustain basic operation for up to a week, the estimated time it takes for somebody to drive out and check/rerpair.
Carefully managing this limited power is important, especially with relatively high power-consumption components such as the long-range radio or the cameras.
By their nature, Lithium-Ion batteries are dangerous and can cause fires.
Since a service schedule or supervision is not guaranteed at MWX, a 7Ah/12V SLA battery was chosen.
That battery is mostly to support a week of "hybernated" weather data gathering and sending.
If charging drops below a certain level, all other functions (cameras, sending data each minute) stop immediately.
Once charging picks up again, the other functions can be enabled again.
Saving power for the most important function of this station, i.e. recording and sending weather data, is highest priority.
On 20th October 2017 we had low fog, clouds, and rain, leading to nearly no charge. We must be able to sustain a week of such days. Or even a broken solar panel, or a break in the power cables with no charge whatsoever.
Power consumption
This is a list of the approximate power consumption of various devices:
| Consumer | Turned "on" | Power usage (Watts) | Notes |
|---|---|---|---|
| Weather Station Controller | Always | 1.3W(full),0.7W(power saver), 0.2W (hibernation) | Arduino Mega2560, Sensors, Relays |
| Static System Usage | Always | 0.5W | Always on: Fan, Charge Controller, DC/DC converter, Sensors etc |
| Ubiquiti Access Point, LZ | 60sec for transmissions | 5-8 W | Wireless connection to AJX |
| Ethernet shield | 4sec for transmissions | 1 W | Wired connection to Ubiquiti Access Point |
| South Camera | When solar energy is available | 4W | looks South and LZ |
| North Camera | When solar energy is available | 4W | looks up North , Crestline |
| Camera security | When energy is available or intrusion alarm | camera: 4W, 5W w IR LEDs on | Security, one camera looking down onto Brain Box |
| Flood light | When energy is available and intrusion alarm at night | 12 W | Security |
| Ethernet switch | When any camera in use | 3.1 W (2.1W+1W extra for Ubiquiti's second Eth port) | Provides the 3 cameras with access to the network |
| Speed Display | during flyable times, when solar energy is available | 12 W | 7 Segment Speed Display (during flyable times) |
"Staus mode" stages
Based on available power and power generation history, a series of power stages will regulate the allowance of power spending by controlling the functionality (cameras off/snapshot/streaming) and transmission frequency (5m,10m,hourly) of the MWX.
MWX needs to communicate errors like problems with the solar panel or broken vane or cups.
The status mode number is part of the string sent to CSS and can be used by CSS to superimpose an informational text (see CSS overlay text below) onto the MWX CSS weather chart if needed.
Or to warn (handeled by the website) maintainers about the issue (broken solar).
The status can also be updated/overwritten by sending a preformatted string to CSS, for instance right before MWX is taken offline for maintenance.
| Satus # | Satus mode | CSS updated | CSS overlay text | Description | Notes |
|---|---|---|---|---|---|
| 0 | no power | once | no power | Total hibernation if battery goes below 11.5V. No data is collected. RTC or Pboot restart M to reevaluate conditions. | Critical situation, results in battery damage if not repaired within a day |
| 1 | lowest power | each Pboot | hourly updates | Minimal data reading during a bad panel or dirt on the panel and such. Hibernation but wakes up to Anemometer reed interrupts, does it's work and goes back to hibernation. | Critical situation, must be cared for within 3 days. |
| 2 | low power | 30 minutes | 30 minutes | Like P1 + sends data more often maybe each 30 minutes or so | RTC timer set to wake up each 30 minutes. |
| 3 | Power Saver | 10 minutes | 10 minutes | Like P2 + camera 3&4 snapshots each 30 minutes and data transmissions ea 10 minutes | |
| 4 | medium power | 5 minutes | 5 minutes | Like P3 + Data is sent each 5 minutes with life video streaming of cameras 4&5 and cameras 1&2 snapshot only. | |
| 5 | full power | 1 minutes | none | Daytime full power operation. Minutewise weather updates, U stays on, all cameras stream. Speed display on | |
| 6 | night time | update @ sunrise | update @ sunrise | Over night data is collected each minute and stored. With the first transmission at sunrise all accumulated data is sent. | |
| 7 | service mode | start/stop | service until ??? | message sent out before the MWX is updated or lowered for maintenance | String can be sent from laptop. |
| 8 | experimental mode | start/stop | experimental | to collect special data or for tuning and adjustment procedures | String can be sent from laptop. |
| 9 | direction bad | until fixed | Direction off | vane is broken | supress direction graph? |
| A | speed bad | until fixed | Speed off | cups broken | supress speed graph? |
| B | too hot | @start+1minute | too hot | turn off solar and go into sleep? | |
| C | too cold | @start+1minute | too cold | add heat element to Rel3 n.o.? | |
| D | too humid | @start+1minute | too humid | go into hibernation? | |
| E | no contact | @start+5minutes | no contact | updates missing or pings failing to MWX | CSS generates Status code itself |
| F | TBD |
Some of these status levels can be submitted to CSS manually, for instance before a service takedown and when service is finished. Or if an error is detected (like a broken cup from the Anemometer).
Some errors the CSS might detect and generate apropriate overly text as needed.
U [Ubiquiti] and Eth [Ethernet Shield] power control
(updating, doesn't belong here, really)
U and Eth both consume much power and must be turned off if not in use.
Eth also generates much heat.
U and Eth are powered up by default with some pull ups, they can be turned off only by M's pins.
The default "on" state is to ensure the possibillity to make remote updates in case the program was bad.
Depending on time of day and power status, U and/or Eth may be turned off right after a reboot, or kept on.
There are several situations with the power state of U [Ubiquiti] and Eth [Ethernet Shield].
-
During regular operation:
U takes 80 seconds to come life, Eth needs 5 seconds.
75 seconds before something needs to be sent to CSS, U is turned on.
After that period, U is kept on and Eth is now turned on also.
After 5 seconds both U and Eth should be ready to transmit and receive data. -
During hourly Pboot or (WD) resets while U and Eth were powered down (f.i. at night).
As mentioned, after a reboot/reset U and Eth are powered "on" by default.
The bootloader Adriane waits 10 seconds for an update via TFTP and then resumes normal operation.
Since it is night, M will turn U and Eth off.
So at nights (or bad weather), at each (hourly) Pboot, U and Eth are turned on for 10 seconds and then turned off again. -
reset while U and Eth were on already (f.i. during day time and strong power).
If a reset happens while the U and Eth were on already, they both keep to stay on.
Video streaming or anything related to the cameras continues to work seamlessly.
Remote updates are possible in these situations.
Notes: There is too little time for the U (80 seconds) to come online during Adrianes' 10 second waiting-for-upates loop, so no remote updates are possible when U and Eth were powered down (night).
- Since we don't have yet an automated update mechanism, and hitting the narrow window of opportunity during Pboots manually is difficult, Lance kindly implemented a software "all on" period to guarante that both U and Eth are turned on to receive updates if needed. This period starts 10 minutes before 12 every day.
Later this can be replaced by the RTC's hardwired SQW pin, so an update can be made right after each Pboot. Depending on daytime, the RTC could be programmed after each reboot to either turn on U ahead of the next Pboot, or not (nights).
TODO: elaborate