After a few years of pause, I decided it's time to return to making this work.
(I actually wrote this back in April, and other things took over)
The previous blogs detail the plan (and any variations)
Mounting considerations and revision
This blog will be detailing my ideas for controlling the Remote RPi and shutting it down to conserve power.
Power
There is no power to the remote site.
The camera and communications will run from a 12v battery, which is charged by a solar panel.
The field runs from 9am til 5pm, but images from 0700 until 1700 would be ideal.
Hence there is no requirement to run it 24/7.
There are times when the weather is such that the field is closed, and no staff are present, so how we handle that is another consideration.
The intention is to use an Arduino and real time clock to do the actual power switching.
Block Layout
Back in Mounting considerations and revision
I suggested this was the approach that I'd use.
My current thoughts are to connect the temperature sensor directly to the RPi (possibly two of them if I can sort out an external housing)
I'm also going to use a normal Arduino, and possibly a latching relay for the power control.
What is not shown here is that the Nanostation uses POE and is 12v.
This means it is the 12v that needs switching, which will depower the RPi and Nanostation at the same time.
I also haven't indicated sending the battery voltage data.
Obviously the RPi cannot do analogue without some form of interface, but the Arduino can.
I can use serial to pass data between them, and this seems like a sensible way to exchange information.
Power Control
Since the RPi uses an SD card as the OS storage device, you can't simply pull the power without risking corrupting the SD card.
Ideally it should be shutdown using the 'Shutdown now' command.
You can also achieve this with a Python script.
When the RPi is running, it will hold a GPIO low.
While this pin is LOW, the Arduino will not remove power (I may need to look at lockup situations)
If the RPi has finished taking an image, transferring the file, and anything else it was asked for, it will initiate a shutdown.
An arduino will monitor the time, and make one GPIO go high.
The script will detect this and if suitable, will also initiate a shutdown.
The idea is to avoid removing power while the RPi is running.
Some things to consider, if I allow video to be streamed, how long should I allow it to run.
The intention is to send battery data out, so perhaps this can be used to predict the time it is allowed to run.
Capacity
The intention is to use a 100AH Gell Cell as the battery.
If the capacity is managed, it will avoid the problems of swapping batteries.
My favourite NZ supplier Hadley did this.
https://nicegear.co.nz/blog/what-size-solar-panel-and-battery-do-i-need/
His calculations assume a constant load, but mine is to be controlled.
The amount of charge available is a guess until we have it fitted and running for a period.
I know the sun angles, and the solar panel capacity, but I cannot predict the amount of snow and ice that will form on the panel.
Some of this will dissipate during the day, but overall there is a reduction of charge hours available.
The panel is 10W @ 12v, which equates to 830mA (when it's running 100%).
Assumming 20% losses and 4hrs per day, this gives me 8 Watts for 4 hrs = 32 Watt-Hrs charge capacity.
Load
There is some debate on the exact power consumption of a RPi3
At idle it can be as low as 160mA ( https://raspberrypi.stackexchange.com/questions/43285/raspberry-pi-3-vs-pi-2-power-consumption-and-heat-dissipation )
If I use 400mA as a figure that represents the image taking, file storing and exchange..
5v at 400mA = 2 Watts.
The Arduino will run as low as a few milliamps, but to be sensible we'll use 50mA.
5v at 50mA = 0.25 Watts
The converters are not 100% efficient, but lets assume we have one that is 95%.
2 + 0.25 = 2.25 / 0.95 = 2.36 Watts
The Nanostation consumes 4 watts @ 12v ( 330mA)
I'm using latching relays so there is no ongoing load.
This represents a constant load of 6.36 Watts per Hour.
With the skifield running 10 hours 6.36 x10 = 63.6 Watt-Hrs of Load
If the charging is 32 W/H and the Load is 63.6 W/H, you can easily see the battery will be discharging even on good days.
Load Control
We don't need the RPi to be sitting doing nothing, and if the RPi is turned off, then the link via the nanoStation is also surplus during this time.
The Arduino needs to keep running.
NanoStation = 4w
RPI 5v = (2Ww at 95%) 2.1w
Using our figure of 10 hours (0700 -1700), we only need a picture every 15 mins.
If we allow 5 mins to do the startup, image and transfer, we have 4 x 5 mins = 20 mins or 0.3Hrs
This reduces the load to 6.1 W x 0.3Hrs = 1.83 + Arduino (0.25W at 95%) 0.263 = 2.093 Watts per Hr.
If we round that to 2.1 Watts x 10Hrs = 21 Watt-Hours Load.
This means we have approx 11W/H per day of excess charge, which is half our load.
In theory for every day we have no charging (and the system continues running), it will take 2 days to recover.
Overnight
Several things happen during night time on a skifield
Obviously the sun doesn't shine, but more importantly the temperature drops.
Cold soak starts to invade everything, and buildings rely on high insulation values to prevent freezing.
In our location, there is no heat, and apart from a cover, the battery box will be covered in snow, and therefore will be cold.
It may gain some warmth during the day, but the reality is it will be about the temperature of the snow pack.
Battery capacity drops significantly with temperature
I found this very useful piece of information about all sorts of factors.
http://prod.sandia.gov/techlib/access-control.cgi/2004/043149.pdf
It suggests that a battery at -10deg is about 70% capacity.
This means my 100AH battery is now about 70AH. (840 Watt-Hrs)
With a load of 21W/H and no charging at all, it should give 40 days run time.
My feeling was if the battery required swapping every week, that would be acceptable and managable.
Obviously it is not desirable, but it is an option if the panel gets damaged.
Image Transfer
My next blog should cover the software used to transfer an image.
Since I first embarked on this project, the method of transfer of the image has changed.
Top Comments