Technical Design Brief

A project log for Solar powered Christmas Light Controller

A solar powered Christmas light controller with wireless capabilities to replace multiple little solar controllers

crenn6977crenn6977 08/20/2014 at 23:150 Comments

From the very start of this project, I wanted this project to be cheap, which has flowed into some of the decisions I’ve made about the project. Some other aspects, I won’t be able to make cheap such as the battery packs and the solar panel.

The digital constant current drivers

The constant current drivers are in essence the most important aspect of the project. I need to be able to drive the strands of LEDs with as minimal power loss as I can to extend battery life but also so I can increase what the strands can actually do since the solar lights usually only were solid on or flashing. There are 2 main components of the constant current driver, the current sensing stage and then comparing to a DAC output to determine whether to limit the current further or increase it via a mosfet.

The current sense is a simple case of putting a small valued resistor (500mOhm) and measuring the difference over that signal before amplifying it. The original concept sketch I have done for the constant driver included this, although up until last Sunday, I was using a dedicated IC for this purpose, now I’m going to be using the MCP6L04 to reduce parts on each PCB and to make routing easier in the end. To allow fast changing of common anode and cathode systems, as it could be a variable, dual pins on both sides of the current sense will be used to with a jumper used when the other set is used, this means I can quickly switch it when installing without too much issue.

The DAC outputs to allow the digital current control is from a MCP4728 quad 12-bit output DAC, this should be a cost effective solution and actually give me 4 channels per PCB. Additionally with the changes made recently to the current sense, the same MCP6L04 can be used for both current sense amplification and the DAC control. It does require 2 MCP6L04 per PCB (2 op-amps per channel) but actually reduces the overall cost.

The PCB design is actually going to be a plug in module with a bus to the main microcontroller, addressing each DAC is not an issue as they’ll all have unique I2C addresses in the end, however I need to be able to pull a line low on each MCP4728, it’s not possible to have a single IO line for each MCP4728, however it is possible to have some logic to make an address bus, to reduce the number of IO. However if the logic needs to change later down the line, it needs to be possible to change the logic without having to spin another PCB revision, so a CPLD can be used to achieve this.

Solar and battery charging

A lot of what I need for battery charging is actually already used for the constant current driver, I just need to be able to allow for voltage measurement and for current to flow into the bus. To allow this, I plan to have a few 0 Ohm resistors on the same PCB design as well as some extra mosfets to allow either charging or discharging to go into the bus. The voltage from the batteries is then put though a regulator (switching possibly) to lower it down for the LEDs and associated circuitry.

The solar cell will connect to the main CPU PCB and have a mosfet to let current flow into the main bus for battery charging or powering LEDs if the battery are already charged and power is available from the solar cell when the LEDs are turned on at the specified time. It also needs to prevent when the batteries discharging into the solar cell when active, either 2 mosfets will be needed in a solid state relay configuration or a MOSFET without a diode selected (which I’m not sure exists).

Wireless Control

Some time ago I got a couple of nRF24L01+ modules to experiment with, which makes it a low cost option for wireless communication, as the ICs are cheap and I have a reference design which I can develop with now. As mentioned previously I was looking into creating a USB dongle to control the lights, to help speed up development, I’m switching to having a daughter board for the Raspberry Pi to allow any browser enabled device to program the LED sequences, when to enable and disable the lights, and to run manual checks. Low powered is key to this, so commands need to be buffered for when the main controller wakes up the nRF24L01+ which should be easily possible with the Raspberry Pi.

Main controller board

As mentioned the system needs to be low powered and to do this, a low powered processor needs to be selected, especially during the day when charging is the main priority. I’m a fan of the STM32 series and have an STM32F0DISCOVERY board which will allow for development until I finalise the PCB design; so most likely I’ll be going for the STM32F030 series which will enable me to reduce the power usage and not have additional components for things like the real time clock which is needed for the automatic lights off and on. The other features needed for the processor is a couple of SPI ports (one for NeoPixel driving and one for the nRF24L01+), 1 (ideally 2) I2C ports for the DACs, 2-3 ADC pins to measure battery voltages and spare IO pins for addressing purposes, power features, future expandability and supporting external devices such as the nRF24L01+.

The main microcontroller also needs to be always powered, whereas the LEDs and their associated controller do not need powered the entire time, so switching off the LED supply can help reduce the overall power usage when LEDs are not used. A high current regulator for the LEDs needs to have an enable/disable feature to enable this to occur. There also needs to be a small coin cell to keep time in the RTC when the batteries are flat or for when storage of the controller occurs.