How to make a super solar tracker using ESP8266

This project was made by us continuing to evolve, using lessons learned from the first tracker computer while incorporating some new things in the code.

background

I have been fascinated by solar trackers since I was a kid, having seen one in the James Bond film The Man with the Golden Gun. So I thought, why not make something I've been dreaming about for years, aside from the other impractical "death ray".

The project is built with two (twin) towers. Like most twins, they were a little off, but everything worked out for the best in the end. I designed/fabricated these myself as there are no off-the-shelf tracker kits for small to medium arrays. Tracking one or two panels is a piece of cake, but having a sail area of ​​more than 9 square meters for 8 panels is a completely different proposition, especially with wind speeds in excess of 80km/h.

As I was about to remodel/overhaul the "twin", the obvious choice would probably be the south tower first for mechanical reasons. It is built using a mechanism in which things are turned upside down. This was an experiment that taught me that there are good reasons to build things the "right way". The "twins" are smaller units, only 1.5KW each. Both towers feed a single dual-input inverter located on the north tower. Each tower has its own battery bank, solar regulator and tracking computer. However, they all come from the same DC panel located in the south tower. Both of these are 24V systems, not 12V like the East Tower.

I believe you can clearly see the reason why it needs to be replaced along the way:

While improving I would also like the unit to be more compact, preferably in a box so I could mount it on the back of the tracker frame, roughly the same sensor as in the first unit. Of course, I'm determined to get OTA right so I don't have to climb the power ladder with my laptop to change programs.

Bigger CPU

Time to bring the Mega and ESP8266. The advantage of the Mega chip is that it has 4 serial ports, which are the most suitable for serial communication in the chip. So I can connect the GPS and inverter and bluetooth adapter and still have room for a diagnostic port. At the same time, it also has more memory/code space.

Replace GUI for IoT

Yes, we are not putting an LCD panel on the device this time.

coding

We deprecated 80% of the original GUI code. As a result, we gain a heap space that we can then delete and use more load to run the web server.

It's a handy version that's easy to unplug and the I2C code actually stays in place so I can always plug it back in for benchmarking.

I'm using TinyGPS as a parser for GPSNEMA streams. This picks out the 3 bits of information the tracker needs from the vast amount of data provided by u-blox. The GPS lock part seems to be very important, it determines if the data is valid.

Being new to ArduinoIoT, the first thing that happened when writing a web page was that I ran out of variable memory. After some reading, it turns out the "F()" macro is a handy toolkit, this stuffs strings back into the "code segment" where they probably belong.

I have to apologize for web design, being very used to using ASP to generate my pages on a behemoth running a lot of idle stuff (I'm an old school pure HTML fan). In Arduino land, the poor old CPU is screaming to generate a basic page. A better approach would be to use javascript to offload the load to the web browser, as the host CPU is likely to pack at least 10x the computer power of the Mega. That is, my page is compatible with 99.9% of devices/browsers since it is pure HTML and does not require other online services to be generated. Ideal for standalone applications.

This website is also a first entry point as I'm still figuring out what works for me in the world of Arduino. So there are a lot of code examples Frankensteined along with a little bit of me showing it off.

The timing thing is a little daunting because there seem to be so many criteria and details that need to come together. In the end I managed to figure out the how and why of each part and put the calculations all on the same time zone basis regardless of the incoming source of truth. The tracker uses Internet-based GPSNTP via an external RTC. This is overkill, but the code is written in such a way that you can remove the time source in a hardware build and the software will be largely acceptable. One problem is that once you're tied to a live source, you can't cheat and just advance the clock to bias the array or compensate for angular offsets. You actually have to use an angle offset because the clock becomes an absolute variable instead of a variable.

Wireless connections

Back to WeMos, either as a shield or as a standalone interface via serial or modbusRTU interface. Another option is an external ethernet bridge, power is the only issue as around 100mA needs to be drawn manually. Please note that after a few measurements the arduino ethernet shield also turned into a hungry beast.

From my first experience with the ESP8266, it seemed to have a really hard time generating pages. Note though that I have been using the wrong end of the screwdriver, this is an example of why you should load the processing to a better CPU, or in the same situation as me, just keep the screwdriver in the right direction!

Then I bought a new WiFi module, which only has a uart and level converter, nothing more. Connecting it to the CH340 and sending AT commands to it from one of my favorite tools has me reveling in where and how I wasted my time. These work great if you're organized and can spit out all the responses in one go, not so great for just-in-time builds as there's a lot of send overhead when you swap send modes. This is unlike the Arduino Ethernet Shield, which doesn't seem to be affected no matter how small chunks you send. So, based on lessons learned, I reduced the generation time of the tracker configuration page from 10 seconds to a few seconds. This was also done in proof-of-concept code before I hacked into an already working version of the ethernet shield. The end result is two versions of Mega's code,

shell

I decided to put all the electronics except the fuses in a box with a clear lid so I could see my LED matrix from underneath. The web interface allows me to swap the XY axes and flip +/- so I can place the device anywhere and it will still work.

A clear acrylic sheet was also used as the chassis on which all the panels were mounted, as I wanted it to be transparent to both light and microwaves. One issue I haven't tested is if the GPS can see through the solar panel, but that would be a plan B considering an external antenna. The single chassis level quickly became 2 levels with all the extra hangers for functional spread.

The Ethernet shield is a bit like an operating moment, with the RJ45 connector resting against the edge of the case. Perhaps we need to change the socket to a vertically mounted socket, or to a different type of shield that can be mounted on top of the electronic device. Finally, I split the code into two versions, Ethernet and ESP connected via serial interface. Different output interfaces for the same website.

I thought I would have a lot of space in my big box, but feature creep is a killer, power supply, RTC, matrix display, GPS and Bluetooth modules. One of my colleagues always recommends leaving 25% extra cabinet space, as long as you don't want to put in 30% more.

On the tower, the actuator cables to the N/S and E/W motors on the tracker had to be rerouted, using far fewer cables as they did not need to be connected to the control box at the bottom of the tower. While we've just run out of space in the box, the fuses will be mounted on the outside, no big deal, and the unit can be disconnected for service. I will use a makeshift power cord and attach the device to the bottom of the tracker and perform a burn-in test. I won't get it working but not connected to the motor. I can monitor it and make sure it's 100% before swapping.

Power consumption is the only issue that arises. Total power consumption is higher than expected. I actually thought there might be a short circuit but did some measurements on the 12V input supply and found out.

Total power consumption is 250mA

GPS 60mA

WiFi60mA

LED display 10-20mA

Sensor 20mA

RS-23210mA

The rest (Mega and H-Bridge) 90mA

Now, at 24V, the entire battery draws about 150mA, so our nighttime burn will be between 1.2 and 2.1AH, depending on the season. Well, we need it to accommodate the 20% depth of discharge of the 7/9AH battery.