Difference between revisions of "SmartLights"
(→Test solar panels)
(→Rigol voltage/current measurement)
|Line 42:||Line 42:|
Here's a Rigol DMM measuring voltage
Here's a Rigol DMM measuring voltage and current and putting on the LAN a simple python program can pick it up and log. 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. MCU this idle current the be to .
(), the . a "". the MCU to be the . that . of for the .
And this raises another basic issue, which is the integrity of electrical connections in this system. The first application involves a relatively unprotected environment that may suffer extreme heating/cooling cycles and condensing humidity. to the and the board for to air temperature rise.
And this raises another basic issue, which is the integrity of electrical connections in this system. The first application involves a relatively unprotected environment that may suffer extreme heating/cooling cycles and condensing humidity.
== AG103 MPPT charger and test panel performance ==
== AG103 MPPT charger and test panel performance ==
Revision as of 22:44, 2 May 2017
Motion activated lighting with solar charged battery power - Pete Soper
This project is aimed at three goals:
- Providing an inside lighting system for the Scrap Exchange Little Library to provide short intervals of light during nightime hours. The lights will be switched on by the library doors being opened, someone approaching the library, or some combination of the two.
- Learning about solar energy, maximum power point tracking (MPPT) battery chargers (both off the shelf and eventually a from-scratch, software controlled inverse SEPIC converter), and operation of an MCU-controlled system in a setting with extreme temperature and humidity swings.
After he constructed the library Jeff Crews added strips of LED lights that will be powered by a battery recharged by 7Ah SLA charged with a Silvertel AG103 MPPT charger. The whole thing will be controlled by an Atmega 328P MCU.
Initial charger circuit testing (Silvertel ag103 MPPT charger is small board near corner of yellow meter
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.
The initial target panel was going to be a Coleman unit rated at 2 1/2 watts, but this was judged inadequate. While determining this and shopping for a target panel three low voltage panels at hand were combined in series and mounted on the roof above my shop for testing.
The system controller described later will be a carrier for the charger "daughter board", with the charger on the "back side" and the rest of the components on the front side of the board.
Thermal image of charger board passing a couple watts to battery while it drives an eight watt load" about 20F rise over ambient temperature
During later testing the load being driven by the charger board was increased to the target 13 watt level (the power that will be used by the LEDs at full brightness). A terrible "burned resistor smell" resulted. Then at even much lower power the load switch MOSFET was overheating terribly, such as here while driving a load of around an ampere:
The voltage drop across the MOSFET was terrible: five volts, which translates to five watts being dissipated by the chip, which is a few times it's absolute limit. Replacing the (4407A) MOSFET with an equivalent (IRF9410) didn't change the behavior: something is causing it to be parked in its linear region instead of switching on fully.
After a very brief urge to smash this board on a brick with a hammer I realized it's a non-issue. The battery can be used directly with the second PWM-driven MOSFET required anyway for brightness control. The only advantage would have been the charger disconnecting the LEDs if the battery voltage got too low. Except I have to implement that anyway because the cutout voltage is way, way too low. It's 10.5 for the Silvertel charger, but I insist on disconnecting the battery at a much higher voltage when the battery still has substantial capacity left. This is a conscious policy because batter life will be severely shortened by the battery being chronically discharged deeeply.
Still, if I wasn't intending to make a from-scratch DC-DC converter for the next version of this project I'd be pretty cautious about buying another AG103 without understanding what part of the circuit failed and whether it's a design problem or if (hopefully) I accidentally broke it. This board specifically provides overload protection, so it's hard to see how I inadvertently hurt it.
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.
Test solar panels
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. Later testing with a few tweaks (principally a partially discharged battery and test load to give the charger a very constant requirement for max output) showed this setup puts out 2.7-3 watts in full sun in early May.
Rigol voltage/current measurement
Here's a Rigol DMM measuring voltage and current every 60 seconds and putting measurements on the LAN for a simple python program can pick it up and log. 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. But later samples showed long periods of idle current around eight milliamperes. What could the MCU be doing for an average current draw of eight mA?? But this high idle current makes it obvious the entire MPPT board has to be powered up and down by my controller to avoid sucking a good fraction of an amp hour overnight.
It should be noted here that unlike the charger (that uses DC-DC conversion with about 85% efficiency for getting it's power), the MCU and PIR (and any status LEDs, measurement resistor dividers, etc) need power at much lower voltage than the LED lights. A simple linear regulator to provide five volts for the MCU et al translates to a "seven volt dummy load". That is, if the PIR and MCU were to consume 10 mA while active then 70mW will be converted into heat by the regulator. An alternative supply circuit that is 85-95% efficient at low current levels is available if necessary. I'm torn between going with a simple linear supply while convinced the average current can be extremely low by virtue of the MCU being suspended most of the time anyway vs using a switcher or providing for the power supply choice to be delayed by making it a second daughter board.
And this raises another basic issue, which is the integrity of electrical connections in this system. The first application involves a relatively unprotected environment that may suffer extreme heating/cooling cycles and condensing humidity. After meditating (fretting) about this for some time I've decided to design in screw type terminal blocks for the board but leave these off and solder permanent connections to the board for the library. The alternative to keep the connections from corroding over time would be an air tight box which probably can't be tolerated because of temperature rise.
AG103 MPPT charger and test panel performance
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.
But the latest data from a "wall to wall blue sky" day after so much overcast time this week reveals a new issue, which is way WAY lower charging current than would be expected at this point. The measurement system is precise and its accounting of the amp hours going into and out of the battery should be close to reality (samples are every 60 seconds). But from hours 89 to 95 there was some very wonky behavior observed. First, the roughly 130mA of current from the panels pushed the battery voltage to 15.2, which is way past the limit spec'd for the charger (it should not put out more than 14.6 volts under any circumstances). Then the charger obviously dropped to a constant voltage output of 14.4 volts and the current into the battery dropped to around 50mA. This was too low. There was the same (roughly 180mA) available from the panels, but the charger limited current to 50-odd mA at 14.4 volts after plenty of time for the battery to readjust to the lower voltage. The result was that the remainder of this day was spent putting way too little current into the battery. The testing was started with the battery being able to accept at least 3Ah. It's only accepted a net one and a quarter Ah so far. Something's wrong with this picture. It will be interesting to see what happens in the morning when the charger turns output back on. It ought to put as much current as is available into the battery. If it continues to throttle current to 50mA that's going to be a deal breaker for this charger unless something has caused a gross accounting error and the battery is actually close to fully charged.
Delving into what's actually going on with current flows depends on "counting coulombs" with the battery to have a proper option about the energy really going into the battery. An alternative to an expensive DMM may be needed for in situ measurements. 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.
Target solar panel performance
This graph shows the same panel on a sunny day. Output becomes erratic as the sun is blocked intermittently by a tall pine tree. The step changes in power output are disturbing. The 1/2 watt increase in output at the 3/4 hour mark and more than one watt drop at the 3 1/2 hour mark are hard to understand. It's as if the controller's policy is to establish a new maximum power point much less frequently than the actual rate of change as the panel reaches and leaves peak irradiance. The algorithm for MPPT doesn't seem to be very good: certainly not as good as the "perturb and observe" strategy described in this Microchip white paper. But again, it's possible the controller's policy is simply not applied frequently enough. Still the idea of ignoring a good fraction of a watt hour because inappropriate conversion settings are held for long periods of time is annoying.
Test panel power output on sunny day
This graph shows, at long last, an excellent, "wall to wall blue sky" day with the six watt test panel. The output is close to one half the rated power, a very similar proportion compared to the five watts out of the target "10 watt" panel. Also, the power is nearly constant and this is likely to have been the result of arranging a constant load on the battery to prevent it from appearing to the charger to make progress. The gradual decline in panel output is very puzzling. A rise and then fall corresponding to approach and retreat from most-perpendicular orientation of the sun was expected.
The air temperature peaked at 77F, the panel temperature was almost 120F near mid day, with the roof shingles much hotter as shown by the IR images below.
DRAFT (UNTESTED!) Schematic of management circuit
DRAFT (INCOMPLETE, UNTESTED) Initial PCB layout
This board is far from complete. The high current paths aren't routed with the proper trace widths, the silk screen labels are a total mess, etc. But the final board is expected to be similar to this after the changes listed below. Just as soon as the charger/battery/panel breadboard setup can be confirmed for basic operation PCBs will be ordered. The initial goal was April 19th, but this is slipping with changes of plans.
Changes in the pipes:
- Power via small DC to DC daughterboard.
- Plain solder pad connections to PCB assuming transition to weather proof connector with PCB enclosure
- MCU (e.g. Arduino Mini) as daughterboard