Open Concentrating PV Solar Tracker Controller

Great news! We have a sponsor! PCBWay will build our prototypes for free! Actually, the greatest challenge with our present board is the tiny size of the compass chips. They are sub mm and proved to be not hand solderable. So PCBWay is a real game changer here. With automatic machines they certainly wont have an issue.

With renewed motivation I transferred the firmware from the break out board assembly to the single circuit board. Achievement so far:

• Tested the motor controllers. They work like a charm.
• Transcribed RTC operation – tedious bit masking and I2C timing issues, but now it works.
• Connected external MPU9250 compass – because I don’t have the new chips yet.
• Ordered new magnetometer as a breakout for testing.
• Unconventional motor current measurement.

The last point was an open issue. We have an overvoltage surge protection diode to protect the FETs and we measure the spillover current. It works! Yet it will be dependent on the inductivity of the power supply and the cable. Actually current measurement can be quite energy consuming. Hall sensors draw something like 10-20 mA from our 24V supply and would heat up the voltage regulators. They also tend to be costly – not to mention chip shortage. The conventional method with shunts costs voltage and requires an additional op amp. So, I believe our solution is quite elegant.

The current measurement is important to detect blocked motors or damaged gears. If the current rises steeply, the motor is fully blocked and the tracker needs to stop. If the individual tracker reports higher and higher current consumption to the central field control, it is probably time for a service, e.g. lubrication. For both purposes a relative measurement is fine and we proved that our spillover method will do the trick!

So everything works as expected so far. We will wrap up the last necessary changes to the board and then we can have the final version built in a professionally by PCBWay.

Now I have spent a couple of days always testing at noon time and trying big adjustments - only to finally decide for the tiny ones. The complete sensor tracking scheme is as follows:

Up until now
- Measure the difference of four sensor channels e.g. upper vs. lower channels for elevation.

- Divide by the total signal on all four channels to be less dependent on the sunlight level.

- Calculate a floating average for each direction to suppress wind oscillations.

- Perform a tracking step when the floating average (in up or right direction) surpasses a trigger level.

- A hysteresis factor lowers the trigger level for a step in the same direction as the last one. 

--> Thus a low trigger level is possible without risking back and forth movements.

The following issues remained:

- The change of sensor reading in Azimuth depends on elevation with a 1/cos(elevation) relation.

- The reversal in elevation during noon or in Azimuth in special cases in the tropics is very slow and moves against the hysteresis --> relatively high errors build up for several minutes.

Solutions:

- Add a cos(elevation) factor to the azimuth tracking.

- Add timeout counters for azimuth and elevation that allow reversed steps with the same low trigger level as "same direction" steps.

Sometimes you need to test the complicated solutions until you realize that the simple ones are most effective.

I will upload the refined code as OS_CPV_Tracker_2022_09_04_improved_tracking_alpha

I tried to make the tracker stay on track on average in sensor mode with self adjusting routines. This worked to some degree, but I am not sure how stable these routines would be on arbitrary trackers. So I decide not to make these attempts public. 

I believe it is more helpfull for the average user to find the correct settings to achieve small and stable steps in elevation and azimuth direction by adjusting the motor parameters. Then the user can adjust the trigger levels such that the tracker reacts early enough and moves in front of the sun by half of a step. 

There is only one problem. In the morning position an azimuth tracking step has a maximum effect on the azimuth sensor readings. In the zenith position, there is no effect at all. In other words, the effect on the sensor is depreciated with cos(elevation). Very well, I multiplied the same depreciation factor to the trigger level and I am presently testing the result.

In elevation, we don't have this issue. However, elevation comes to a halt at solar noon and then reverses. Considering the direction hysteresis in sensor tracking, this may lead to a long time with bad tracking, until the elevation sensor reading is negative enough to trigger a first down step. To give an example, with my present settings a reverse step requires a sensor reading which is 4 times as high as a same direction step.

This behavior suppresses forward backward oscillations but it is unwelcome if a direction reverses indeed.

Presently I am testing a timeout counter which lowers the "reverse direction" trigger level to the "same direction" level after 5 minutes without a step.

I believe these minor adjustements should work much more reliable than the self adjustment schemes I tried this week with mixed results. The former also require much less program space (still at 81% on ATMEGA328). 

Keep it stupidly simple.

If you want to have the latest version with the improvements above, contact me. For the time being I believe the changes don't justify a new release yet.

P.S. If this project should be adapted by a major manufacturer of CPV systems, I would suggest to vary the motor parameters for the Azimuth steps such that the tracker makes bigger steps at noon-time. However, this adjustment would depend on the hardware and I want to keep this solution universal.

Update: I am now measuring the sensor readings before and after a step and adapt the trigger levels by a factor - only Azimuth, for a start. This looks quite promising. Yet I needed to stop testing since evening got me off guard - pretty much like every day.

I had spent a lot of time building up two insula PV systems for emergeny power. This kept me occupied and away from the project. Now I have some time during my holidays and I am tackling the task of keeping the tracker on track on average, i.e. after a tracking step it should be ahead for some time and then fall behing. Right now, it is usually behind. You can set the parameters such that a step takes the tracker "beyond" the sun position. However, this makes oscillations more likely. I tried a scheme where there is a correction value added to the the sensor readings. This worked well for some time, but then it again led to oscillations. 

One issue is noon time when the elevation "speed" reaches zero and then reverses. Apparently this is a problem, because without movements the correction values cannot readjust.

Another issue is the dependence of the tracker sensitivity on the sky conditions. For some reason, the sensor sensitivity becomes higher when the amount of direct sunlight is low. This again can generate oscillations when the tracker is overshooting too much. 

My next idea would be to measure the change of e.g. azimuth sensor readings during an azimuth step. The trigger level could adjust to half of this step size. A hysteresis is already available to suppress reverses.

Ermanno Antonelli now officially joined the team! Thank you so much, Ermanno. This is going to be great!

May 1st 2022:

Thank god I am living in Europe. I needed to add a video and these project logs to make the submission complete. I have two hours left Phew. The video is online now. I hope the link works. I also added the shading beam 3D-file to my GitHub repository. I am kind of greatfull that hackaday forced me to make a video. This will greatly add to our visibility.

April 27th 2022:

I am swapping through my emails and I am learning about the hackaday contest. Oh dear, only a few days left.

April 25th 2022:

I am presenting this work at the CPV18 conference as an online talk. This is my first conference talk and paper as a private person.

October 2021: I got Ermanno Antonelli interested, a real expert on DCB board design. This started a fruitfull cooperation to make an all in one control board reality.