Group Actions
Engagement
  • Author Author: genebren
  • Date Created: Date Created
  • Views 621 views
  • Likes 7 likes
  • Comments 4 comments
Related
Recommended

Smart Solar Lighting Project - Update 10/2/2020

genebren

In my prior blogs,Smart Solar Lighting Project - Initial design ideas ,Smart Solar Lighting Project - Detailed design andSmart Solar Lighting Project - Mechanical designs , I discussed my initial design thoughts and detailed design for my smart lighting project.  Today I thought that I would bring you up to date on my progress on this project.  Over the past month and change, I have been working through the software to drive the Smart LED modules and on the Master/Host module and testing the charging and lighting circuits.  For the Master/Host module I am using one of my prototypes of the Master/PIR modules from my Kitchen Light System Phase 2 project ( Kitchen Light System Phase 2 - Drowning in EnOcean... ) , allowing my to send and receive commands/data to/from Smart LED modules.

 

In working through the software development on the lighting modules, I stumbled across a simpler method of controlling the current draw of the EnOcean transceivers.  Initially I was planning on commanding the transceivers to sleep using the CO_WR_SLEEP command and then isolating the control lines between the ATmega328PB and the TCM310U modules.  The timing for this approach was a little loose, as both the ATmega328PB and the TCM310U modules would each need to keep track of the timing, with the TCM310U waking up, and the ATmega328PB re-connecting the control lines to the TCM310U. Early experiments showed that it was possible for the ATmega328PB to make the connections and start to communicate to the TCM310U before it was awake, or for the TCM310U to wake up ahead of the ATmega328PU (wasting precious energy from by battery waiting for commands).  By accident one day, while working on low level communications to the TCM310U, I noticed that the current draw to the module had dropped from the 'Radio Receiver On' level of ~40mA down to the 'Radio Receiver Off' level of ~7mA, while I had disabled the periodic sleep command to the TCM310U.  Looking at the code, I noticed that the READ_EN on the TCM310U was being driven high (used to read firmware version and configuration area).   I decided that this might make a lot more sense, having the ATmega328PB enable and disable the TCM310U directly, allowing me to minimize the Radio Receiver On time.

 

Now the ATmega328PB would periodically (once a minute) turn on the TCM310U transceiver and send a status message to the master (contents of the status message shows internal voltages/currents based on the current state of the module, i.e. Idle, Charging, Schedule mode or Light On mode) .  If the master did not reply in 40mSec, the transceiver would be turned off.  The Master module, upon receipt of a status message, would check to see if it had any queued messages (configuration commands or requests).  If there were any queued messages for this module, they are sent (one at a time) to the lighting module.  If there were no queued messages, a sleep message is sent to lighting module, which cause the unit to sleep (the radio) until the status message. Here is the normal status message processing for the no queued message case:

image

Here is the queued message reply to a status message processing:

image

The total on time for the transceiver is under 40mSec for the normal response and about 75mSec for a queued message response.  Given the ~33mA current draw of the receiver and ~24mA current draw of the transmitter over the responses, over a 1 minute status rate, the average current draw is  ~38uA for normal and ~71uA for the queued replies.

 

I wanted to try and normalized the turn on times for the lights, so had earlier decided to equip the Lighting modules with a Real Timer Clock (RTC) to monitor time of day.  Using a Sun Graph (https://www.timeanddate.com/sun/usa/san-antonio?month=10&year=2020 ) for my location I created a month by month of the sunrise and sunset times of the first of each month, along with the number of days in the month.  Using this data, I can use linear interpolation to estimate the sunrise and sunset of a given day to within a 2 minute margin of error.

 

imageimage

The Light modules will use this data, along with two simple variables (offset from dusk and duration) to schedule when to turn on and turn off the LEDs.  My current setting are for 1 hour after dusk and a duration of 1 1/2 hours.  All of this will be adjusted after I install the LED light on my deck.

 

I still have some more software to write (and debug), but I am getting close to having a working system.  Here are a few things that I need to finish up:

1) complete coding for remote command to the lighting modules (get/set time of day, get/set scheduling information, etc.).

2) complete coding of charging and 'lights on' status messages.

3) rework LED current limit resistors to increase current ( I might also need to change my control MOSFET to reduce Ron).

4) code closed loop PWM function to normalize LED current over the range of battery voltage (I am thinking of a simple PID loop to adjust PWM to achieve desired LED current).

5) finish 3D printed parts for the LED light spacers and diffusser holders.

6) install and commission the complete system.

 

Like any good project, this one has already started to creep.  My wife and I are thinking about adding LED lights to the path to our front door (actually replacing some cheap solar LED lights that have already failed).  Ideally I would like to monitor and control these new lights with the same master module and utilize/adapt my smart solar LED lighting modules into some new housings.

 

Thanks for reading.....