SOL is a project to develop a solar powered, connected solar intensity sensor (also known as a pyranometer)
Bill of materials for first custom PCB version
Comma-Separated Values - 1.45 kB - 06/13/2018 at 01:13
Eagle schematic file of first custom PCB version
x-kicad-schematic - 203.59 kB - 06/13/2018 at 01:11
Eagle board file of first custom PCB version
x-kicad-pcbnew - 83.24 kB - 06/13/2018 at 01:11
Schematic of first custom PCB version
Adobe Portable Document Format - 24.17 kB - 06/13/2018 at 01:10
With the polar vortex effecting much of northern North America this past winter, there was some "discussion" among politicians about how solar power would operate in the cold temperatures. Undeniably cold can negatively effect batteries, snow cover on panels can block sunlight, and shorter days (and incidence angle changes, depending on if the panels are on trackers and which direction they face) reduce the total amount of solar energy available. However, solar panels actually perform at a higher efficiency when cold.
Let's look at the data. SOL has been operating in my windowsill for another month. There are still some issues with missing data and timing drift to resolve, but the measurements themselves seem to be quite reliable and repeatable. My apartment is astonishingly poorly insulated, so a fairly wide variety of temperatures on the PCB of SOL are recorded. A quick look at the plots in this paper show that at a given power generation point, a colder cell will have a higher open circuit voltage.
The point of SOL, of course, is to determine how much power is available from sunlight. So, unlike that paper, power is not a known input. We only know, at a given point in time, the internal temperature of SOL, the open circuit panel voltage, the short circuit current, and the power at the maximum power point. Because SOL is in my windowsill, its temperature changes with the outside temperature and the amount of sunlight hitting it. In the plot below, we see a separation of open circuit peak panel voltage based on temperature. As in the paper above, with generated power held constant, the peak voltage is higher for lower temperatures.
Further, it seems likely that there is a link between temperature and sunlight hitting SOL, especially since SOL is inside and my apartment is not 93 degrees F. The fact that SOL measures peak overall power at low temperatures similar to peak overall power at high temperatures may imply that it is more efficiently converting sunlight to electrical power at low temperatures.
Thankfully, for the goal of SOL, which is to determine how much power a large solar installation could produce, the effect of temperature can be assumed the same on SOL and a larger installations, so that we do not need to know the effects of temperature of SOL's efficiency to make these predictions.
I did some further analysis on the data recorded by SOL over the past few days. Of note were the peaks in recorded power in the afternoon of the 7th and 8th, which did not appear the next days. I correlated the data with historical weather data on shortwave light intensity and cloud cover. During the days with the peaks in power, the cloud cover cleared up somewhat, and the peak predicted intensity was relatively high. As noted before, SOL was not in direct sunlight for these tests, so the absolute value isn't important here, but it is encouraging that it seems likely that those higher power sections were due to real phenomena.
In a previous log, I had mentioned that SOL should be set up to adaptively change its sleep time based on the measured solar intensity. There are two main reasons for this. First, this will save a lot of battery during the night. Previously, it would read data at regular intervals (e.g. 60 seconds) all the time. During the night, the power is zero, so there is no need to sample. Secondly, it would allow the system to generate more accurate energy estimates during high-power scenarios. Coincidentally, since SOL is charged by the sun (theoretically at least), it can afford to use more energy during times when it charges faster.
I made a firmware update to test one concept for this adaptive timing. My original thought was to have the timing change according to some tunable filter driven by the peak power measurement. However, if we see the power is high, we ideally would instantly jump to short intervals. I created a very simple algorithm in which a minimum and maximum time interval are given. If the power is over some threshold, the interval jumps immediately to the minimum. If it drops below the threshold, the interval is slowly incremented to the maximum. Here, the minimum interval was 30 seconds, the maximum was 300 seconds, and the power threshold was 7 mW. This seems to work quite well. The below image shows the relative time of each datapoint for 3000 datapoints. The zig-zag is caused by the transitions between 30-300 second intervals over the course of about 4 days.
SOL has now been running for a week and has recorded and uploaded about 6000 datapoints. The single cell 14500 li-ion battery has dropped from 4.02V to 3.80V during that time. It does not appear to be charging, even though I changed the charging control resistor so that the desired charging current is 12mA. The peak current measured through those days was about 5.5mA, so it is expected that the battery has not charged. SOL is in a windowsill, but never in direct sunlight, so soon I will test if it charges in higher intensity light.
Looking at the energy that could be extracted based on the measured peak power from SOL's panel, we see that even in a windowsill, SOL can easily power itself. The battery is about 0.7 Wh, and over about three days, it could have ideally (with 100% charging efficiency) extracted about 0.3 Wh.
RTC Bug Fix
There was a bug with processing the time from the RTC which caused some readings to be corrupted. This has been fixed. The bitmask used when loading the hour value was wrong, so anything after 19:00 was incorrectly recorded.
Due to the above RTC bug, not all the data from the past week is valid. We will consider only the data after that was fixed.
First, consider a calculation of available solar intensity. The solar panel has an effective area of 44x63mm (listed as 50x70mm, but I'm ignoring the bezel), and I assume an efficiency of 10%. That is low for a modern panel, but this one is very cheap so likely not great. Here, SOL was inside, in a windowsill surrounded by tall buildings, so it isn't receiving direct sunlight. Therefore, the peak intensity is fairly low. For reference, peak direct sunlight is typically given as somewhere around 1300W/m^2.
SOL is not installed outside in a reasonable location as it should be, of course, so the following calculations are more academic than anything. Nonetheless, it is interesting to look at the kind of calculations that can be done with SOL's data.
First, consider the energy available to a larger, 33 m^2 (355 ft^2) system. We assume the system has an overall 25% efficiency. Over a little more than 3 days, the total energy was almost 10kWh.
Second, we can take the above and calculate the cost of the electricity generated. Assuming the US national average of $0.12/kWh, this is almost $1.20 worth of electricity.
Third, we can consider the net carbon effect. This is a much more difficult calculation to make. Each state has a different energy source breakdown, so the offset of...Read more »
Version 3 Goals
Version 3 had a few simple goals. First and most obvious was to fix design mistakes in version 2:
Second, version 3 was designed to be easily programmable. All the necessary pins were brought to a ZIF (zero insertion force) connector, and an adapter board for a FTDI Basic 3.3V was made, so that I could use the two onboard buttons to toggle EN pin (to reset) and IO0 pin (to enter bootloader mode), without having to manually touch jumper wires to ground.
On previous versions, I assembled by laying down small bits of solder paste on each pad using the syringe it comes in. However, this process is very slow, and often results in too much solder paste on fine pitch packages. For version 3, the ZIF connector is a 0.5mm pitch package, so I bought a stencil from OSH Stencils, and used that to apply the solder paste. This gives a more even amount of solder paste on each pad, and speeds up the assembly process. The three version 3 boards I assembled are shown below with solder paste applied and the ZIF connector placed.
As previously mentioned, version 2 was a bit of a pain to program, requiring me to manually touch jumpers on the EN and IO0 pins to ground at certain times. I did this by connecting through a breadboard. It worked, but it wasn't good, and I had to be very carefully not to accidentally short something.
To fix this, I built an adapter board for the FTDI basic, which has the corresponding ZIF connector for version 3 programming, as well as female header pins for programming version 2. Below, the adapter board is shown connected to version 2. The two buttons on the adapter board are for reset and bootloader entering.
When used with version 3, the ZIF connector and FFC (flat flexible cable) allow me to program very easily, by just clicking the buttons before (holding the IO0 button while toggling EN to enter bootloader) and after (toggling EN to reset after programming).
Ryan has done some great work setting up a server at solsensor.com (all source is here). This allows us to step away from the simple IFTTT/Google Sheets setup used previously. While that was useful as a proof of concept, it obviously wasn't a long-term solution. It limited the amount of data that could be uploaded at each API call, and had restrictive rate limiting. Our server does not yet have a front end to show the data, but works well as a back-end.
The new server side built by Ryan led me to re-architect the SOL firmware. The old firmware was admittedly hacked together to get it working, but I was waiting to redo it until the server side API was designed. This firmware will be put in the github soon. There are some major changes:
SOL V2 design documents and firmware have now been added to the project Github.
As previously detailed, V2 has some design faults that need to be addressed. Further than that, some upgrades can be made to add functionality and ease setup. Programming was made easier by routing all the needed ESP32 pins to a pin header. The device is programmed with the Arduino IDE through a SparkFun FTDI Basic 3.3V, but it requires three pins to be connected to ground when programming, and it requires IO0 to be held low on boot to enter bootloader, then the EN pin must be brought low to reset the device. This is done currently by alternately plugging in and removing jumper wires from a breadboard. It works, but it's annoying. To make it easier, I designed an interface board from the FTDI Basic with pushbuttons to switch IO0 and EN pins. It has a 6-pin ZIF connector which will be used to connect a ribbon cable to a corresponding 6-pin ZIF connector on SOL V3. Programming will be extremely simple then.
Some people I have discussed the project with have asked if SOL is able to run standalone, completely disconnected from WiFi. This could be useful if evaluating a field mounted PV setup, for example. Currently, this isn't possible. The EEPROM used to store data is small, not large enough to store data for a long time (6+ months is the target).
However, I have been playing with the idea of using the flash storage on the ESP32 for this. Recently, I learned about a port of sqlite to the ESP32. I tested it out, and it is very easy to use and quite fast. Flash has limited lifetime in write cycles per page, but by storing intermediate logging data in the ESP32 RTC sram, and only writing in chunks, recording data over a year should be possible without risking flash degradation. The current SOL firmware only requires about 650KB, and the ESP32 module used has 4MB of flash storage. A rough calculation of storing data at 5 minute intervals over 12 months indicates about 2.9MB needed, so it seems ballpark possible. A similar approach would also allow me to remove the EEPROM storage. The ESP32 also has easy interfacing to an SD card, offering effectively unlimited storage, but that adds components, size, and cost to the design.
As I said in the previous project log, the voltage measured in the IV sweep seemed low, compared to what I expected for the solar panel and based on what I saw on SOL V1. Suspiciously, the voltage seemed to be clamped at around 0.75V. This solar panel can theoretically reach an open circuit voltage higher than the max input voltage of the battery charger IC, so I added a zener diode as a voltage clamp. The 0.75V seemed suspiciously similar to the forward voltage of the diode. Indeed, when I double checked the board, the diode was soldered backwards. I removed the diode, and re-ran the IV sweep test. Now, under a desk lamp, the max voltage is up to about 5V, which is much more realistic. Ill have to wait for tomorrow to see the measurements under sunlight, but I'm expecting good results.
Through assembly and testing, I've also found a number of other issues with this build. I had accidentally run the trace for the temperature sensor output over a ground trace, so it is unable to measure temperature (I may attempt to cut the trace to get it working.) I also forgot a decoupling capacitor for the ADC, although the ADC seems to still be working OK. I will likely make a V2.1 design that makes some of those quick fixes soon, but am waiting to get V2.0 fully tested first.
Working off some of the successes and failures of version 1, I recently designed and built a second version of SOL. There were a variety of goals here:
I will be adding the BoM, design files, and firmware for SOL V2 soon. For now, some pictures of the two assembled devices made so far:
I tested the power measurement sub-circuit, using 5 difference settings of the ADC PGAs (4.096V, 2.048V, 1.024V, 0.512V, and 0.256V full scale ranges.) With the amount of light available (indoor lamp in a mostly dark room), the ADC did not saturate at any PGA level, and the scaled measurements all matched nicely. One example is shown below. A fairly typical solar panel IV curve can be seen in the top subplot. Overall, the levels of measurement seems lower than expected, but I will need to see its performance in direct sunlight to check if it is ballpark correct. For reference, at maximum power this panel should be about 5.5V and 100mA. Note the power density subplot at the bottom is assuming a panel efficiency of 15%, and it just for reference.
It has been a long time coming, but the custom SOL device is finally working.
After assembling the SOL_R1 design, and charging the battery, I measured the output of the 3.3V MIC5205 voltage regulator with a multimeter as about 1.4V. After looking further at the datasheet for the MIC5205, I noticed that it is not compatible with a ceramic output capacitor. I did not have an oscilloscope on hand to examine the output waveform, but it was likely oscillating such that the averaged measurement seen on the multimeter was about 1.4V.
A few solutions seemed reasonable. One option was to switch over to the MIC5245 voltage regulator, which is pin compatible with the MIC5205 and is stable with a ceramic output capacitor. Or I could change the output capacitor for the MIC5205 to the recommended 2.2uF tantalum capacitor. I ordered both options.
Once the MIC5245 device arrived, I built SOL with it. Unfortunately, the output voltage was still bad, hovering around 0.4V. At this point I realized what should have been obvious earlier -- these voltage regulators can only supply up to 150mA, but the ESP32 datasheet recommends a power supply of at least 500mA. While the first version still would have been unstable with a ceramic capacitor as set up, the second attempt likely would have been stable, but was unable to supply enough power.
Thankfully, there is a pin-compatible 500mA voltage regulator (RT9080) which I was able to switch to without making new PCBs. After installing this part, the output voltage was a stable 3.3V!
The next step was to program the device with the SOL firmware. I used the 3.3V FTDI Basic USB-to-serial converter from SparkFun. I connected GND, TXO on the FTDI basic to RXD on SOL, and RXI on the FTDI basic to TXD on SOL. When I attempted to program the device, it did not respond. I then realized that the ESP32 needs to be put into the ROM serial bootloader mode. This website explains the process. GPIO 0 and GPIO 2 must be held low. SOL was designed to use GPIO 0 as a touchpad input, so this pin was easily accessible. For GPIO 2, I had to carefully touch a jumper wire connected to ground to the correct pad on the ESP32 module. Once I did this, the device was programmed!
I confirmed the device was able to measure power from the solar panel, was able to connect to WiFi, and was able to upload data to Google Sheets.
Next, I worked to assemble SOL into its case. I used an off-the-shelf IP65 waterproof case (RP1065.) I added a hole on top for the solar panel connection, and two holes on the side. One hole was for the a panel mount LED, and the other is for a bolt with gasket used as a capacitive touch input. Ideally, this setup will be waterproof, but quick testing showed some leaks. Likely this is from the panel mount LED, which does not have a gasket and is not very accessible for adding waterproofing. Making this setup waterproof will be a next step, so that SOL can be left outside.
As discussed in the last project log, while the hardware is functional at this point, the process for entering WiFi credentials to allow SOL to connect and the process for uploading data were merely hacked together.
I updated the WiFi provisioning process to use the WiFiManager ESP32/ESP8266 library. This library provides the user a list of available wireless networks, and provides a much nicer looking interface to the user while connecting. This update is on the GitHub.
I also want to welcome Ryan to the project. He comes from a computer science background and his help in developing the web interface for SOL is greatly appreciated!
After some cleanup and documentation, I have added the hardware files and initial Arduino compatible library for SOL to a GitHub repo (linked on main page). The sections relating to WiFi provisioning and uploading data will not remain in the future, and are simply some examples I hacked together to get the basics working. Those sections have major usability and security issues so be aware. The code also has a large amount of debugging serial port printing left in (although removed during compilation if desired).
At the same time, I have been learning about web development and trying to spec out the minimum functions of a web app/phone app that SOL would require. Below are some images with results from my brainstorming.
Apologies for my near-illegible writing and drawings, but the idea is to build a basic phone app in Thunkable, which uses React native to generate native iPhone and Android apps using a simple drag-and-drop interface. Thunkable has an interface component called a webviewer, which (obviously) simply displays a certain webpage. This can be used during WiFi provisioning to point the app to the correct IP address on the SOL network where the user can enter their SSID and password. It can also be used to view data served by a web app. How that web app is built is still very unknown, but I have been doing tutorials with the python Flask and Django interfaces and Bokeh for plotting data. Python anywhere could be used to host the web app for free (for small amounts of data throughput, which should be fine for testing SOL).