Self-powered solar data logger Using Atmel Mega32

Introduction:
My project is a self-powered solar data logger. Put out in the sunlight, it will measure the light level and log this to memory to be later downloaded to a computer. The system is powered by a small solar panel and battery.

Summary:
The solar logger I built uses a photodiode to measure the solar insolation level. It converts the analog signal from the photodiode to a digital value that is stored in flash memory. Every time the system logs a data point, it also logs the time and date so that the data can be analyzed in the future. The logged data is available for a user to download to a computer for analysis.
While the system is logging, real time data is displayed on a small LCD screen as well as information about the battery voltage, the length of time the system has been logging and the length of time it can continue to log before running out of memory.
The logger has a dedicated solar charging system to provide the needed power. A very simple charge controller regulates charging of a small, sealed gel-cell lead-acid battery by a small solar panel. This charge controller is a simple on-off switch that disconnects the PV panel when the battery voltage rises too high.
The user sets the time and date each time the system is reset as well as the frequency with which data is stored. The user can also clear the memory or continue appending data to the previously logged data and extract logged data to a computer for analysis.
High level design:
Rationale and sources of project idea:
There are many reasons for logging solar insolation data for solar electric systems. When planning to install a solar electric power system, one must be able to predict the power output in order to determine the financial costs and benefits of the installation.
When planning an off-grid solar electric power system, the output must be closely matched with the load so as to provide sufficient power without considerable waste. The power output is directly related to the insolation level. While seasonal and annual average insolation levels for most major cities in the United States are available (http://www.solar4power.com/solar-power-insolation-window.html), cloud cover and other weather effects can be very localized depending upon the topography, making extrapolations from the large cities with established data to neighboring areas unreliable. In addition, this data is not available for every part of the world,
For a large installed solar electric system, one would typically install an insolation monitor to determine if the system is performing as expected. If the system output drops below the level expected given the insolation, an alarm would be set off to indicate that the system needs servicing.
Background math:
Power Needs:
Even without optimizing the system for efficiency, the power needs were very small. The absolute maximum power needs from the various components were

Component	Current	Voltage	Power
LCD	1mA	5V	5mW
ATmega32	15mW	5V	75mW
Photodiode	15mA	5V	75mW
Total	31mA	155mW

If all components ran at their maximum power at all times, this would amount to 3.72Wh/day. This does not account for losses in the voltage regulator or other minor components, but as can be seen, there is plenty of power available for the system. A 12V, 5Ah battery could provide 60Wh. However, even with a deep cycle battery one does not want to drain it too low. Five days of solar storage in Ithaca is considered conservative, but due to the reliability needs of an autonomous system such as this, it is worth having a factor of safety. 37Wh of storage allows the system to ride through for ten days with no sun. Even at this level, the battery is not drained to levels that would damage it.
Even with enough storage, it is necessary to be sure that the energy balance of the system is kept positive. Ithaca gets 2.3 sun hours per day in the winter according to http://www.solar4power.com/solar-power-insolation-window.html . What this means is that a solar cell rated at 1W will produce 1Wh of electricity per sun hour. My 3.2W solar panel would therefore be able to produce 7.4Wh of electricity per day during the darkest time of year in Ithaca if kept at its maximum power point. Because there is no maximum power point tracking in this system, it could be expected that my system will get 5.2Wh/day from the panel in the winter, far exceeding the maximum load expected from the system.
How long the system can run:
The flash storage has 264 bytes of storage per page and 1,024 pages. Each time the system logged a data point it used 8 bytes. This allowed the system to log 33,792 data points. The logging interval is user-selectable from one minute to one hour. At an interval of one minute, the system is able to continuously log data for 23.4 days before filling the memory. At an interval of one hour, the system is able to log for 3.8 years.
Logical structure:
The system is run by an interrupt driven program to allow for accurate timing. An interrupt service routine decrements a series of task timers once per millisecond and the main task in the program calls various subroutines at predetermined intervals when their task timers run out and the appropriate flags are set to allow a task to run. Each of the eight buttons is polled separately once every thirty milliseconds. The only button that is not debounced is the LCD wake button as bouncing is not a concern with it. The debouncing routine is based on code written by Bruce Land and provided on the ECE 476 website.
There is one task that prints to the LCD screen that is governed by a state machine indicating which set of messages is to be displayed and a variety of flags indicating which message within the sets is to be displayed. Having all LCD calls within a single task allows for the program to prevent any LCD communication while the LCD is off. If no buttons are pushed for two minutes, the system turns the LCD screen off to conserve power.
The ADC is read once per second through a task called once per second that enables the ADC interrupt and starts a conversion. The ADC interrupt automatically switches between the two channels for the photodiode and the battery voltage, reading the battery voltage once for every five times the photodiode is read. To get an accurate battery voltage reading, the PV panel is disconnected just before the battery voltage reading is taken and then reconnected immediately after if the battery voltage is below 13V. If it is at 13 or above, the PV panel is not reconnected to prevent overcharging.
The instantaneous readings are displayed to the LCD screen and kept in a running average over the logging interval. When the logging interval is complete, a data point is stored in the flash memory.
Hardware/software tradeoffs:
If this system were to be commercialized, the most expensive piece of hardware is the photovoltaic panel. It would therefore be important to increase the efficiency of the system to utilize the PV panel as effectively as possible and reduce its size. This would be done in two ways. The first would be to have a maximum power point tracking charge controller rather than the simple on-off switch used in this project. This would keep the voltage of the solar cells at the maximum power point on the I-V curve and would effectively extract about thirty percent more power from the panel than allowing the battery to determine the voltage. The second way to improve efficiency would be to reduce the power consumption of the system. Because I had plenty of power from my PV panel and sufficient battery capacity, there was no need for this system to do more than turn the LCD screen off when idle. It would however be possible to reduce power needs further by reducing the clock speed of the chip, letting the chip go idle between readings or at night, and eliminating the LEDs on the STK500 board.
The STK500 board was used in this project due to the integral flash memory and switches. Buying these components separately and building a custom board for the project would not have saved any money. However, if this system were commercialized, it is fairly obvious that the STK500 would not be used. It has many features that are unnecessary to this project and a much simpler board could be designed.
Due to budget constraints, I used surplus whiteboards in my project as these were budgeted at $0 while solder boards were budgeted at 2.50. While a solder board would be a more reliable means for building the circuit, the budget limit and time constraints led me to use the white boards. Towards the end I found I had just over $6 surplus and was having difficulties with the LCD display not making secure contact with the surplus whiteboard. At this point I added a new whiteboard at a budget cost of $6 for the sole purpose of holding the whiteboard. In the end, a solder board would have been less expensive, but as I was still within my budget and everything was set up, I left the project as is.
Relationship of your design to available IEEE, ISO, ANSI, DIN, and other standards:
I am not aware of any standards specifically applicable to this system. NFPA 70, the National Fire Protection Associations National Electric Code Handbook gives regulations for solar electric systems but does not apply to a portable system of this size. Were the system to be commercialized, it would be a prudent to have it UL certified.
Discuss existing patents, copyrights, and trademarks which are relevant to your project.
There are no patents, copyrights, or trademarks relevant to this project. It was not reverse engineered from any existing product nor did it employ protected intellectual property. There is also nothing from this project that would be considered both novel and unique, and thus suitable for patenting.
Program/hardware design:
Program details:
The data logger needed an external memory for storing measured data. The older STK500 have flash chips build into them, making this an obvious choice, but I did not have any instruction set for interfacing with the flash memory. The Big Red Map project by Shirlyn Jean-Louis and Chethan Pandarinath in the spring of 2004 used the flash memory and based on their code and comments I was able to learn how the flash interface worked. They used a program named dFlash, written by Terje Frostad of ATMEL Norway. I received permission from Jan Havard on the Atmel AVR Technical Support Team to use dFlash in my project as well. The dFlash program provides a set of routines to interface with the flash memory by writing to a 264 byte buffer. This buffer is then written to one of 1,024 264-byte pages of the flash memory.
The flash memory can be read either through a buffer or directly. Because the routines take byte size data as input, I had to break the insolation value, stored as an integer, into two bytes and then put it back together again when storing or retrieving it. Additionally, if the user calls for the data to be retrieved before the buffer had filled and written the data to flash, there would be no data to retrieve. It was thus necessary to write the buffer to flash just before the data retrieve routine was entered as well as when the buffer became full. It was also necessary to give the microcontroller a brief period to finish writing the buffer before the read command was executed or the same problem would occur.
One thing I did not realize that caused a considerable amount of difficulty was that PORTB.4:7 are used for interfacing with the flash. I had initially been using PORTB as input for the switches, but found that three of the switches did not work. Once we realized that dFlash was re-initializing these pins, I was able to switch these buttons to PORTA.
A core feature of the logging system was how it handled the data input. Initially the system only sampled the light level with the frequency at which the user wanted data stored. However, with logging frequencies of one minute to one hour, this did not allow a satisfying real-time display that showed changes in light intensity. Additionally, it allowed less accuracy if only one sample was taken per stored data point. Instead, the final system polls the light level five times in six seconds (every sixth second is used to poll the battery voltage). The program keeps a running average over each logging interval and stores this average to memory before beginning a new sampling interval. This frequency is more than twice the expected frequency of fluctuation in natural light intensity, a desirable feature of analog to digital conversion systems. It also allows for real-time data to be displayed to the LCD.

Natural sunlight ranges in intensity from 0 to approximately 1000 Watts per square meter. The photodiode used in this project puts out its maximum voltage at 10 Watts per square meter. With hardly any light striking the sensor, it reached its limit. It was thus necessary to attenuate the intensity of the light striking the photodiode to increase the range over which the sensor could differentiate intensity. Ideally, this would have been done with neutral density filters, but as these were not available, electrical tape was found to be quite effective. Once two layers of electrical tape were placed over the sensor, it gave reliable readings over the full range of expected intensities. The ADC in the microcontroller has a maximum value of 255, this needed to be multiplied by four to roughly convert the ADC reading to Watts per square meter. Ideally, this system would be precisely calibrated and the factor would be more precise than 4, but this approximation gave reasonable results with a range of readings from 0 to 1020 Watts per square meter.

Initially the program was written with each of the subroutines that updated a parameter sending its update to the LCD. This avoided updating the LCD more frequently than needed. However, when the code was incorporated to turn the LCD screen off when the system was idle, the system would freeze every time it went idle. The LCD sends and receives messages from the microcontroller. If the LCD is off when the microcontroller send it a message, it is not able to respond and the microcontroller hangs, waiting. The program thus had to be rewritten to prevent the LCD from being called when the LCD screen was turned off. Additionally, there was some difficulty with the LCD not making proper contact with the surplus whiteboard. When the LCD lost contact, it would cause the system to freeze. I thus added an extra new whiteboard solely to hold the LCD screen securely because I was not able to solder the borrowed LCD to my project. One other problem that was had with the LCD was when the STK ground was not properly connected to the system ground (the negative terminal of the battery). This happened during testing with the STK500 plugged into an AC/DC power supply. When the two grounds were not at equal voltages, the voltage across the LCD was not in its operating range. The positive voltage was coming from the STK port pin and the negative voltage from the battery negative terminal. Once the two systems were joined by connecting to the STK ground pin and then also powering the STK from the battery, the LCD resumed normal operation.