There was a first version of the mirror which can be looked at here ZiegelSpiegel 1.0 at Hannover Maker Faier 2014The 2nd version of the mirror was meant to become "acceptable" to the people who I would ask to put it into their yard. It had to be weatherproof - so they could put it into a corner so its not in their way. It had to be self-sufficient in regards of power supply and connectivity - so no wires were required. It neded to be remote controllable so I would not have to enter their premises to change the target angles or any other control parameter. And lastly it needed to be tested to run for weeks and months without any in-place service.
To make it weatherproof I figured I had to either use weatherproof components throughout or put some or all of the machine into a box. I decided for the later as it would help to make the machine "compact". I used a wooden CD-Tower for up to 3 sets of CD on top of each other. It's slim silhouete is just big enough to house al of the electronics and the mechanics. On top I though I would put a round mirror lying flat if the sun was not shining. This way the mirror protects the machine from direct rain, snow or hail impact - at the times of day when it would be raining the mirror would have no other function anyway. I painted the box with black enamel so even if the bo would be hit by rain sideways it would flow off.
As the machine would draw energy from a solar panel mounted in the bottom of the box it did not have any ties/cables to its surrounding. So I deciced to let the machine turn itself around a2 cm diamter aluminum pole in its center. Why 2 cms? Because this was the best compromise between the sizes of drills available to drill holes into the box, the inner diameter of clamps and cogs that should hold onto the pole and the neccessity to have the pole wide enough to not bend under wind pressure.
Solar Panel - this brings us to the power supply. It sounded easy but did require quite some iterations to get it right. First learning was that the Arduino Mehg, that would be powerful enough to do correct sun angle calculations, did not really allow you to run it at less then 10ma even in sleep mode. This is due to the power regulator and due to the USB chip, also due to the LEDs on the board. In general I believe prototyping boards are not meant to be run on battery power for extended periods. I did not want to replace the mega clone with a more battery friendly version (which are not easy to find). So I decided "let's simply turn off power completely to the Mega when not needed", in particular at night. But who turns it off and on? The clock I have been using (a very precise temperature-compensated ChronoDot) had an alarm signal that would go low when the alarm rings - so a "not" circuit could provide an "on" signal - here I decided to not use a not logic chip but a small Olimexino that is ATTINY85 based. A signal is nice but to turn power on to something consuming 200ma is not possible with a simple logic chip. So I started working with a NPN MOSFET with the most simple way to turn something off - by turning on and off the connection to ground. But the Mega was connected to the clock via I2C, to the power supply via an analog in to measure the voltage, to the Olimexino itself to tell the small Arduino to turn of again and to the wireless module. The Olimexino always had to had power (consumers less then 1 ma when sleeping and when its led is cut) and also the wireless module had to be connected directly to the battery as it draws so much power for a short time when connecting. So the problem with the "low-side-switch" was that all of these connections to other modules that had power and ground led to the mega getting current flowing in and out its GPIO without actually having power - not a good situation.
The second attempt was to use a so-called "high-side switch". It actually can turn the supply voltage to the load off and the load, the switch and all other modules can share a common ground. This was a much simpler set-up with my limited electronics skills to get to work. But this time I had false currents happening still between thepin that would turn the wireless module off and on and the Mega. Maybe with a few diodes this could have been solved. But I instead opted to the following approach: The mega would tell the olimexino (short oli) to turn the wireless module on or off. This way I had decoupled the Mega and the wireless module and I was down to less then 1ma when mega was off and everything else was sleeping.
But, when turning on or off power the simple boolean connection between a Mega output and an Oli input led to false signals - as the Mega turned on the Oli registered it should also turn on the phone. To get this turning one problem under control I went ahead and used PWM frequencies to communicate from the Mega to the Oli to a) turn off everything or b) turn on the wireless or c) turn off the wireless. Now everything worked stable (after a lot of debugging of the wiring, the Mega and the Oli code).
Overall this was the toughest problem and I recommend to anyone putting up a battery operated rig to look for a mainboard that has everything on it and can do low power sleep. Having multiple modules (clock, oli, regulator, solar charger, wireless, mega) each with different on and off states can become a nightmare.
After the power problems were solved I could run my machine for multiple days and the battery would stay stable on cloudy days and the battery would increase its power level on sunny days - Bingo!
The last challenge (in reality all of these challenges happen in parrallel but its easier to line them up for the story) was to remote monitor and control the machine. I first thought of using Zigbee 2 devices that have a range up to 1000m. But with this setup I would have to have arduinos on either end and as I wanted to use the Internet anyway for monitoring I started to think in the direction of Wifi or GPRS based IP connectivity. Wifi would again require to impose on the hosts of the machine to provide their Wifi SSID and password to my machine - so I in the end bought a 40 GPRS module from Adafruit called "Fona". It has a SIM-Card slot and can do Calls, SMS, GPRS in 2G and 3G networks and a few more tricks. The machine posts its key parameters to ubidots.com via a HTTP POST request every hour. I would have liked to post data more often or more data at a time. But the end to end cycle for turning on the device and sending the data is 20 seconds. That would eat up to much power if done more then once an hour. And sending an hours data (from the eeprom of the Mega) also does not work as the 8KB RAM available in the Mega do not really allow to put a 10K string with the hours data together - especially when using JSON and a public cloud IoT solution like Ubidots which eats up 90 bytes for every 2 bytes of payload due to authentication and identifcation of your variables.