Hardware components | ||||||
_ztBMuBhMHo.jpg?auto=compress%2Cformat&w=48&h=48&fit=fill&bg=ffffff) |
| × | 1 | |||
| × | 1 | ||||
| × | 1 | ||||
| × | 1 | ||||
| × | 1 | ||||
 |
| × | 1 | |||
| × | 1 | ||||
| × | 1 | ||||
| × | 1 | ||||
| × | 1 | ||||
| × | 1 | ||||
 |
| × | 1 | |||
| × | 1 | ||||
| × | 1 | ||||
Software apps and online services | ||||||
 |
| |||||
 |
| |||||
 |
| |||||
Hand tools and fabrication machines | ||||||
| ||||||
| ||||||
| ||||||
I have always been fascinated with solar trackers since childhood, having seen one in the James Bond film “The Man with the Golden Gun.” So fast forward 35 years and with an engineering degree under my belt, I say “Why not build what I have been dreaming about for years – minus the death ray maybe?"
So the first two (twin) towers where built. They are, like most twins, a bit of a mistake but it all worked out the best, sort of. I designed/built these myself as there was no ready made tracker kits for small to medium size arrays. Tracking a panel or two is child’s play but 8 panels with a sail area of over 9m square is a different proposition especially at wind speeds of over 80km/hr .
These towers a located on a working farm so the arrays are positioned 5.8m above the ground in order that tractors and other equipment not collide with the trackers. If you’re an astute gardener you’ll have worked out they are positioned between avocado trees which do seem to grow a little better under them. The big panels are connected to a grid inverter and the small “pony” panels drive the computers and electronics. There is no parasitic power from the mains to drive the positioning motors, this is largely due to needing power to move the arrays in storms when you are least likely to have mains available.
Approximately one sixth of the tower is buried underground in 1.2 cubic meters of concrete configured as a “top hat” foundation. There is two layers of re-enforcement mesh in the upper section and this is welded to steel ties to prevent the post exceeding the 40Mpa limit of the concrete at it’s interface. The bottom of the foundation is keyed through a rock shelf which happened to lie 1.2 meters below the surface.
So fast forward we have two nice mechanisms (north and south towers). How so we point them at the sun? Optical that sounds logical and easy. I was happy at first but then frustration grew as it was obvious that cloudy days (SCT20 and above) where a real issue for the controllers. They would frantically sweep the heavens in search of the bright spot, wearing out motors and depleting batteries in the process.
Walking into my office, inspiration was right on the floor. Over the previous 2 years it had become adorned with sundial like markings in felt tip pen which in ancient times where used to mark the passage of the seasons. You open the office door at solar noon and read off how far from the equinox / solstice and the exact angle that arrays should be set to. It was so clear you can calculate the suns position and simply “be there” with the solar array. So in an attempt to correct the mistakes of the twins I decided to embark on the “East tower project” which would be nearly 50% bigger than either of the first 2 trackers and would have a computer that would allow it to calculate and point to the sun.
Picking the BoardHaving just helped my son with a school project involving an Arduino I was amazed with the ease of use and sheer volume of libraries available, there be one of everything! A far cry from my early days of embedded work, writing all my own libraries in machine code. So I picked the Uno for this job as a bit of a challenge, it’s nice to have lots of everything but it really “hot” when you shoe horn truckloads into a tiny package. I ran out of space many times, this resulted in me recoding more efficiently and not bringing my lazy “windows” habits into the project. In the end it all fitted into the tiny wee chip.
So obviously the main sensor is the 3 axis accelerometer which is used to work out which way is up. This is compared to the calculated value of the position of the sun with a hysteresis band of course. The motors then activate to move the array so the target angles are within tolerance of the actual measured values. A relay block is used to switch the motors, I did toy with using PWM. But simplicity and electrical noise where on my mind. The whole system is driven by a single 7AH 12V battery with a DC/DC step up used to power the 36VDC motors (at about 20 something volts).
Position of the sun? At this point I admit I’m not an astronomer and didn’t just dream up the equations, I downloaded the algorithm from the NOAA web site. I did a proof of concept program in MS windows which was actually driven from a GPS NEMA stream, once that worked I ported it to the Arduino platform. The GPS was replaced by a simple RTC for initial trials, it was intended that this unit be able to “self calibrate” and point to the sun without setup anywhere in the world .
The algorithm returns values in term of Alt and Az however my tracker/mount type requires Declination and hour angle. This was an easy thing to fix as they are a natural by-product of the Alt/Az calculations. It also means that the program can be used on any tracker type as the sensor used also included a 3 axis magnetometer to measure out Az if necessary. There was a model built which demonstrated the code and outputted to two servos configured as an Alt/Az mount, this had the mandatory “death ray laser” mounted 90 degrees to the plane of the array to project the suns position on the roof of the room. My son suggested we increase the laser power to leave sun trails on the roof of his school class room, fortunately mother stepped in at this point.
GUI for a Wee ComputerNow having got sensors and equations, a GUI was needed. A 2004 lcd display with i2c backpack provides this. The program ended up with 25 screens for settings and diagnostics, everything from setting the time to adjusting the tracking mode and angles etc etc. For input I choose a rotary encoder with integrated push button, in hindsight this was not the best choice. I think a LCD shield with touch input would have been simpler and more suited for the task. There is an “meat-ball” display in the gyro enclosure that allows you to see how far off target the array is and if the tracker is moving to correct the issue. This was sort of a luxury and further evidence of my ever growing Arduino/eBay addiction.
I2C. A confession here, I knew I would have trouble with the cable length but being way too much of a “red neck” I did it anyhow. The tests run in the workshop looked fine but in the real environment there are lots of electrical cables emitting all frequencies of radiation. I built an active terminator for the I2C but this didn’t solve the lockup problem nor did adding ferrite beads or messing with earth configurations on the solar charger. Tired not talking on the I2C buss for a while after motor starts and fitted snubbers to all the actuator motors. The funny part about this process was that for several weeks I had a solar tracking computer that would only run at night, yep as useful as a bull with tits. So the final solution, some buffer chips from Texas Instruments (P82B96). These allow you to drive i2c over large distances with relatively high noise immunity, worked a treat just like they say on the box.
And of course final version of what the sensor box looks like
Tower movement in the wind was somewhat under estimated as it turned out to be as high as 3 degrees. The original 2 degree hysteresis was quickly adjusted to 4 degrees. Full stop was implemented for night hours so the system would not react to winds etc at night… no reason to move after the system has parked and gone to sleep of the night (unless it get windy). Changed the program so one axis can move at a time and to favor E/W motion of N/S.
Low and high angle limits where implemented, along with different tracking methods and parking combinations. There are selectable park angles for both axes. As well as the ability to change target angles provided it is in "tracking none” mode.
All this data is made non-volatile by being stored in CPU internal EEPROM memory along with routines to initialize a blank or senile CPU to safe and sane values.
Given the lockup issues I needed a a hardware watchdog, found the one in the chip and implemented that at 4 second intervals, also programmed a spare pin just in case I needed and external one. Deployment of this had to wait till after I fixed the hardware issues or I risked masking the I2C issues I was having.
The programming contains a Modbus interface that allows you to read and write all of the major memory locations so that I could write a smart phone GUI via Bluetooth and be able to access the unit without the need to use the GUI in the enclosure. A surprise for me was that the memory map worked backwards if simply declared as variables but forward if in an array. It didn’t take long to work this out so all those years working on both Intel and Motorola CPU’s paid off. The Bluetooth is via the Arduino serial port and a HC-05 Bluetooth module.
Yes on sunny days the unit does produce at least as much energy as the optical trackers after you compensate for panel output. However on cloudy days it's a winner, on track all the time and I am expecting less maintenance on the jacks as they move the absolute minimum amount necessary to follow the sun each day. So refit of North and South towers coming up next.
But before we go - ParkingSo you track the sun during the day but where should you park the array at night?
This is one of those “How long is a piece of string” questions. It is a very complex question, the more I observe and record issues the more I’m convinced it requires and “active/adaptive solution”. Obviously wind forces can be minimised when the array is flat BUT if your vortex size is about that of the array it can flutter depending on the relative position of the centre of pressure and centre of gravity. This is BAD in a storm. I’d much rather do the old sailors trick of “point her into the wind” in spite of the increased wind loading than have an array flutter. If your battery runs out in the night best to be pointed towards the sun in the morning so you can get moving as soon as possible. So all said and done things like battery voltage and wind speeds as well as the variation in angles (tower wobble) should be taken into account) , this be the brief for another program/project I think !
I still had a lot of trouble with “random” reboots which would crash the I2C. The kicker was, it would never do this on a sunny clear day. It was battery and seemingly wind dependent. Anyhow 6 weeks ago I caught a lucky break and saw it actually reset. Could have kicked myself it was definitely the solar regulator at fault. I assume that a motor start against wind or with a flatish battery pushed the unit into shutdown/brownout briefly but not long enough to fully reset all the electronics. So a new 30A solar regulator unit replaced the 10A and I have yet to see it reset once in the last 4 weeks including stormy weather. It’s been offline a few times with depleted battery but always seems to start fine when the sun returns (case closed).
You know how they say “inside every problem is another waiting to get out”. Well, once the main computer is 100% reliable you start to notice other things. Mechanically stuck relays arrrhhh, horrid little blighters! The boards I bought must only have the relays that “John West Rejected” soldered on them. They look the same as the genuine quality brand but as with all things cheap on Ebay “buyer beware”. The only real solution, buy an H switch board (I knew it would come to this). So I’ve done the programming for the Uno to implement plain old on/off H switch, the program even fitted in the same number of bytes. I’m just waiting for the board to arrive.
But how can I leave it there? I mean I have an H switch and arduino that naively does PWM. How can I not do soft start on the motors?
OK...That's cool it I cant believe all fitted in the UNO... we now got soft start and recycle counters. The motors glide off to full speed now sweet...
Computer and software running fine, the RTC losses time at an annoying rate. Just not quite enough for me to be bothered to fix it :)
PWM soft start is awesome, really does take the stain off the mechanics. No cracks in the steel work at the last inspection so very happy with this aspect.
Jack may be nimble jack may be quick but jack not be strong enough!
This problem would appear to be a combination of many things. However the most obvious is stay away from "flyable" angles ( 0 to 16 Deg ) in high winds. The preceding weeks had see the clamp slip numerous times, however I never caught it in the act. It had crossed my mind that it was a limit switch failure however that would mean both hard and soft limits failed. The distance between centers of the failed jack is quite a bit less than the hard limit distance so I think it was just simple overloading. It has now been replaced with the same heavy duty jack as used in the east/west axis. All seems good and the clamp has not slipped yet (2018). Fast forward to 2022, we stripped a jack nut in that heavy duty actuator! Yes it's made outa plastic but it rated to lift the weight of my daughters car. More thought required on this one...
A wee bit of documentation on the GUIIn general rotate the encoder to change menu .. push in and rotate to change the value of the setting. When your on a save menu (8 & 18 ) press and hold till the system shows it has saved the data
The menu items all require you to do a save if you want the new settings to flash to eeprom (menu 18 - press button ).. This is so you can test ... if you like it you save... if you don't then just reboot.
Time setting is menus 1->7 Menu 8 is a time set/update - press to save back to RTC and arduino. The display will take a snapshot of the current time to edit as you enter Menu 1 or 7. That way you can set the time and wait at menu 8 for the exact moment to press and synchronize, if your that way inclined.
X and Y min / max angle i.e. soft limit switches ( 4 menus 19->22)
X and Y hysteresis i.e. how accurately you track. ( 2 Menus 16->17)
Tracking mode ( 1 menu 13 )
X and Y Parking angles (2 menus 11->12 )
X and Y angle offsets (2 menus 14->15 ) these are to trim out misalignment's of the circuit board to the final mounting if you need it.
X and Y Set angle ( 2 menus 9->10) If you switch tracking to off you can dial up the angle here (helps with maintenance) otherwise this shows the target angle coming from the calculations and is effectively read only.
There three menu screens for display only.
Menu 23 - GPS coordinates / tome zone - need to set these in code or change via Modbus and then saved either via modbus or menu 18
Menu 24 - Angles - Sensor , Target and Difference
Menu 0 - Time Date , Sunrise , Sunset , Dec / AH and Alt / AZ
Obviously you set the clock to standard time for your time zone. Or you could set it to GMT and use time zone 0 ... whatever floats your boat.
UPDATE (September 2018)UPDATE (July 2020)More problems with wind load. If there was any doubt about the previous jack failure then this photos say it all.
I would contrast this with the north and south towers which have had very little in the way of issues in the north/ south axis. The east tracker has an solar area of 16 ish square meters and the north and south towers have only 9. So the wind forces do get rapidly out of hand as the size goes up.
DougalPlummer
Comments