Difference between revisions of "SmartLights"

From Splatspace
Jump to: navigation, search
(AG103 MPPT charger and test panel performance)
(Motion activated lighting with solar charged battery power)
Line 1: Line 1:
 
'''
 
'''
 
== Motion activated lighting with solar charged battery power ==
 
== Motion activated lighting with solar charged battery power ==
Here's the problem space with the first application. Relatively high powered LED light strips that consume about 13 watts will be being powered by a 7Ah sealed lead acid battery and the available power for recharging the battery is from a 2 1/2 watt solar panel. Figuring roughly 10 watt hours out of the panel on a given day (and this might be quite optimistic), there is only enough power to run the LEDs at full intensity for 46 minutes every 24 hours. This may be plenty, or might fall way short, so if the LED lights aren't smart they may be useless.
+
Here's the problem space with the first application. Relatively high powered LED light strips that consume about 13 watts will be being powered by a 7Ah sealed lead acid battery and the available power for recharging the battery is from a 1 1/2 watt solar panel. Figuring roughly 5 watt hours out of the panel on a given day (and this might be quite optimistic), there is only enough power to run the LEDs at full intensity for 23 minutes every 24 hours. This may be plenty, or might fall way short, so if the LED lights aren't smart they may be useless.[Note: the Coleman panel planned for this project was marketed as a "2.5 watt" panel but more recent information suggests it may be far less.]
  
 
The basic strategy will be to pay attention to outside ambient light/dark cycles and running average usage to pick a default LED light level (set with pulse width modulated switching of power to the LEDs), then wait a few seconds after motion is detected near the lighted area (i.e. the time it takes to walk close), and turn the lights on. The PIR sensor will be hacked to allow as much precision as possible with the determination of "motion vs no motion". After some number of seconds of no motion the lights will be turned off. Alternatively, depending on the state of the battery, the lights will be dimmed before being turned off completely.  
 
The basic strategy will be to pay attention to outside ambient light/dark cycles and running average usage to pick a default LED light level (set with pulse width modulated switching of power to the LEDs), then wait a few seconds after motion is detected near the lighted area (i.e. the time it takes to walk close), and turn the lights on. The PIR sensor will be hacked to allow as much precision as possible with the determination of "motion vs no motion". After some number of seconds of no motion the lights will be turned off. Alternatively, depending on the state of the battery, the lights will be dimmed before being turned off completely.  

Revision as of 16:04, 19 April 2017

Contents

Motion activated lighting with solar charged battery power

Here's the problem space with the first application. Relatively high powered LED light strips that consume about 13 watts will be being powered by a 7Ah sealed lead acid battery and the available power for recharging the battery is from a 1 1/2 watt solar panel. Figuring roughly 5 watt hours out of the panel on a given day (and this might be quite optimistic), there is only enough power to run the LEDs at full intensity for 23 minutes every 24 hours. This may be plenty, or might fall way short, so if the LED lights aren't smart they may be useless.[Note: the Coleman panel planned for this project was marketed as a "2.5 watt" panel but more recent information suggests it may be far less.]

The basic strategy will be to pay attention to outside ambient light/dark cycles and running average usage to pick a default LED light level (set with pulse width modulated switching of power to the LEDs), then wait a few seconds after motion is detected near the lighted area (i.e. the time it takes to walk close), and turn the lights on. The PIR sensor will be hacked to allow as much precision as possible with the determination of "motion vs no motion". After some number of seconds of no motion the lights will be turned off. Alternatively, depending on the state of the battery, the lights will be dimmed before being turned off completely.

If none of this is enough the combination of low light and brief "on period" may have to be with a "tap here to get more light" sign or the like. The sign would of course be illuminated reliably. That is, this would be similar to a cell phone with very low battery, turning it's display off aggressively.

The microcontroller will log some behavior in EEPROM to offer clues about actual performance and feed back "better" default light levels (i.e. throttle the PWM so the lights might, for example, be just bright enough to be usable unless the battery is well charged). One open question is whether usable information can be logged without sense of time beyond the CPU clock. If this system will "just work", a clock will be avoided, otherwise something like a Maxim DS3231 will be added. (The extreme ambient temperature cycles expected would make a cheaper clock like a DS1307 a waste of time). It seems like the simple photocell monitoring outside light cycles should be enough to support a gradual, "good enough" calibration of "cpu cycles per day".

Speaking of temperature cycles, the solar charger is itself quite smart, and one of the things it has to get right is the battery float charge voltage. It will use a thermistor mounted to one of the battery terminals for this, to avoid charging errors that would tend to shorten battery life. Also, the upper limit for charging is 50 centigrade. If the battery and charger regularly go over 50C a small fan may be required. The microcontroller can trivially run the fan as needed to lower temperature as long as circulation is possible.

Initial charger circuit testing (Silvertel ag103 MPPT charger is small board near corner of yellow meter

Solar-charger-testing.jpg

First impressions of the Silvertel ag103 charger are good. The PCB is well made, choice of MCU is great (ST STM32 series 32 bit ARM in a nice TSSOP20 package). The whole thing is on a roughly 30x50mm board with two male headers the right length to solder onto a main board. The current plan is to neatly solder to the header pins while confirming this charger is going to get the job done and then move it to a permanent home on a PCB that has the rest of the circuitry.

Using a lab supply to pretend to be a solar panel doesn't cut it, because the charger board is obviously changing it's load presented to the supply and the supply reaction is surprising. But there must be some sweet policy in the firmware, as the "hunting" from one voltage/current demand on the supply to the next eventually stops. It would make for some fascinating graphs to have the supply controlled by a simple Python program while logging the voltage and current consumed.

But three low voltage panels in series are being mounted on a board to live for a while on the roof where the system is being developed, This will be three two watt panels with a combined open circuit voltage similar to that of the target panel (a Coleman 2 1/2 watt panel). An exact match with a second Coleman panel seems desirable, but might be made moot if this initial setup works well enough to get the target application going quickly.

Back to the PCB board, as a carrier for the charger this will necessarily be relatively large in relation to the mount of stuff on it. That will be a refreshing change after a lot of very dense boards that attempted to squeeze very penny out of the cost involved. But an alternative prototype board vendor is available for this design (PCBs.io), and the first rough cut comes out to about $12.50 for four copies of the board, which seems excellent. On the other hand, turn around with PCBs.io is almost three weeks, while oshpark.com is two weeks or less in return for a cost of $16 for three boards.

Thermal image of charger board passing a couple watts to load and battery while battery supplies an eight watt load. About 20F rise over ambient temperature.

Solar-charger-board-temp.png

Breadboard charger testing

Here's the charger being driven by three little five volt panels in series (nearing sunset, but sun long since behind tall trees). From left to right is the Maynuo electronic load asking for a whopping 25mA, the red meter showing volts out of the panels, little yellow showing mA out of panels, propped up red showing battery voltage, and rightmost yellow meter showing amps in/out of the battery. Tomorrow about 11am when the sun gets fully over the trees there should be more action. Solar-breadboard.jpg

Test solar panels

Test-panels.jpg Three 5V, 2 watt panels in series. The MPPT charger settles to a load on the panels around 15 volts in full sun, but current out of the panels was only 140mA the first go around. That's roughly two watts.

Rigol voltage/current measurement

Rigol-DM3068.jpg

Here's a Rigol DMM measuring voltage (and current, alternating) and putting it on the LAN where a simple python program can pick it up and log it. This is after sunset and the charger board is drawing just a few mA out of the battery. The idle current is only 3-5mA in this case, beating the datasheet spec by a factor of two. The MCU should add very little to this, leaving the PIR's idle current the remaining concern. If that's very high another FET can be used to disconnect it during daylight hours.

AG103 MPPT charger and test panel performance

AG103-battery-6w-panel.png

The net watt hours into (positive) or out of (negative) the battery and its voltage as it is charged and discharged is graphed with the charger connected to a 7aH sealed lead acid battery and six watt test panel. Clouds have affected power both days. The panel set is in a heavily wooded area and only gets direct sun a few hours a day in the best case. There is no load attached yet, so when there is no power from the panels the only draw is the charger's idle current, which has been delightfully well below it's 10mA specification. The charger's idle current is mysterious, however, spending long periods around 1.7mA, long periods at 8mA, while other times it is jumping up and down as would be expected if the MCU is suspending itself and periodically waking to check whether it's environment has changed. However (a big however), the big electrolytic cap specified to go across the panel output wasn't properly attached until about hour 40 and so it will be interesting if this makes for more stable idle (dark) conditions leading the charger to use very little current.

It's also obvious now that the simple resistive photo-detector that will tell if any extra lighting is needed or not would be useful as additional data to make sense of the charging process. The big question about this charger is whether it is spending any significant time "hunting" for the maximum power point from the panel, and in so doing, missing out on proper power from the panel.

However, delving into this would be predicated on "counting coulombs" with the battery to have a proper option about the energy really going into the battery. Just by chance collaboration with an area engineer is resulting in the perfect tool for this: an LTC2944 "battery fuel gauge" the MCU can interrogate via I2C. One (for battery) or two (battery and panel) would allow very precise measurements and allow determining just how efficient the system is. This, of course, has nothing at all to do with the interests of users of this lighting system, but everything to do with the interests of the system designer who might steer folks toward or away from the AG103 charger!

But this forces a related issue, which is a choice of MCU. For the simplest imaginable implementation of this project something as simple as an ATTiny85 would be adequate to implement very simple policies to run the lights at X brightness for Y seconds after motion is detected and the battery is deemed OK to draw from. However, this project is aimed at delivering a very small number of prototypes into just a few application scenarios (the "Little Library" at Durham Scrap Exchange being the one that will be published here). It honestly doesn't matter in terms of cost whether a $1 or $4 MCU is used, but that does make a big difference in the range of capabilities that can be supported. The design defined by the schematic below is heavily subscribing the pins of an ATTiny84A and there has already been nervousness about capacity issues. Together with the COLLAPSE of the price of an ATMega328p chip (now $2!), that chip is going to be popped into the design, at least until the build environment for a more interesting chip like an STM32F030F4P6 is prepared.

DRAFT (UNTESTED!) Schematic of management circuit

Smartlights.png

DRAFT (INCOMPLETE, UNTESTED) Initial PCB layout

Smartlights-layout.png

This board is far from complete. One of the high current paths wasn't routed with the proper trace widths, the silk screen labels are a total mess, etc. But the final board is expected to be quite similar to this. Just as soon as the charger/battery/panel breadboard setup can be confirmed for basic operation PCBs will be ordered, probably around April 19th.