- Wind speed
- Wind direction
- Battery volts
- Soil moisture and temperature
- LoRa connectivity
- MCU watch dog
- Arduino IDE
- Hackable PCB - Other sensors and circuits can be added.
- Server based PHP driven GUI
My previous version of a weather station used 2G GPRS for the data transmission which proved to be very power hungry and, even with a 40 watt solar panel, went dead during the dark months of December and January. The other problem was that, every now and again, the GPRS server would decide to kick the sim card off the network which sometimes required the card to be removed, inserted into a normal phone and an 'upgrade' downloaded. Moving to 3G or 4G would not solve these problems, even though 4G is far less power hungry.
I decided to create a new version of the control system based on LoRa technology which could potentially send data straight to a LoRa gateway if one existed. Unfortunately, I live on an island in the middle of nowhere so there's no chance of a gateway in the foreseeable future so I had to build a LoRa receiver as well.
Other than power requirements and data transmission, the main focus of this project is getting accurate wind measurements using high grade instruments and sensible positioning of those instruments up the top of a pole.
So why use these expensive wind instruments?
The generic wind vanes use eight sets of resistors to give a basic resolution of 45 degrees which can be further refined by using averaging, but wouldn't it be great to have 360 degrees (or better) resolution? The generic wind anemometers are 'ok', but don't last very long before the bearings need changing and are not calibrated so we have no idea how accurate they are.
On a positive note, the cheap generic rain gauges are actually very good and having tested them for over 3 years, the only problem was spiders running up and down the rocker arm playing some kind of game of chase and then getting bored and creating a web to seize everything up. They just needed a quick clean every six months or so.
One of the things that worked really well in the previous version of this weather station was the code for the wind instruments. The anemometer was relatively simple to implement as I could use a simple 'pulsein' command although, technically, this is 'blocking' and will introduce an unwanted delay in the code speed. Also, the rain gauge could theoretically interrupt the pulsein midway during the process causing an error so pulsein is wrapped in 'nointerrupts'. We could still miss rain readings, but this is helped by the fact that the gauge triggers twice per reading so we can filter for one or two interrupts in the code, dramatically decreasing the chances of missing a reading to 'almost' zero.
The wind vane is far more complicated to code as it relies on polar coordinates (0 to 360) which means that normal oversampling and averaging using the 'mean' is not possible. Think of the situation where the wind is blowing from the north ...... one moment we get a reading of say 2 degrees, the next a reading of 355 degrees which would give a mean value of approx:
(2+355)/2 = 180
To overcome this I had to use 'mode', which necessitates creating a large 1D matrix of possible values and then evaluating which ones were most common over a particular time period. This required a bit of tuning as if the resolution is too large and the number of samples too small, the mode value never gets bigger than zero. For convenience, I used a 1 x 360 matrix and filtered the sample rate until I got a mode value of about 5 in a steady wind. This means that, for example, a direction of 237 degrees was detected...Read more »