Low Power High Accuracy Weather Station

'Professional' wind instruments are mounted high on a pole in an exposed location with LoRa data transmission

Similar projects worth following
So what's interesting about this project? ... It uses 'industrial grade' wind sensors, a programmable watch dog chip to keep the system alive, it uses peer to peer LoRa for data transission, it's hackable so that other sensors and circuits can be added and it's an upgrade from a system that's been up and running for about 3 years. What's not to like? ❀


  • Wind speed
  • Wind direction
  • Humidity
  • Pressure
  • Temperature
  • Battery volts
  • Soil moisture and temperature
  • Rain
  • 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 »

  • 1 × Arduino MKR1300 LORAWAN
  • 3 × C100nF capacitor (1206)
  • 1 × R100K (1206)
  • 4 × R10K (1206)
  • 1 × C1uF (1206)

View all 20 components

  • Rain Gauge Repair / Service

    Tegwyn☠Twmffat03/12/2019 at 12:48 0 comments

    From memory, the rain gauge is now about 2 years old and, today, the reed switch failed :( . Fortunately, it's quite easy to repair by soldering in a new switch:

    The replacement part is a Cynergy3 TRA291G/20-30

    ... And there's a couple of things to watch out for:

    • The component has flat legs and can be positioned in 2 ways, so check by closely examining the reed, checking that the magnet will actually close the contact when it swivels past.
    • As standard, the reed is positioned on the underside of the board, but positioning on the topside, as shown above, ensures it gets activated by the magnet more readily.

  • Upgrade from Hacked to Hackable

    Tegwyn☠Twmffat03/08/2019 at 11:25 0 comments

    The previous version of this project was hacked on a spare PCB I had lying around and tested in the field for a couple of years. This enabled me to create a 'proper' version that, rather than being hacked is now custom made but still hackable with facility to use the generic Chinese wind instruments and add other sensors if so required.

  • Testing Non Programmable Watchdog Circuit

    Tegwyn☠Twmffat03/07/2019 at 11:26 0 comments

    I really thought that implementing the watchdog (STWD100NYWY3F) was going to be effortless, but after carefully soldering the components and adding the appropriate code, it just would not work!

    Fortunately I had some spare PCBs  and watch dog chips so I set up a test rig to diagnose the problem. Using an oscilloscope it was easy to see where the problem lay as the watchdog was actually responding as expected, but the MCU reset line was not responding. According to the STWD100NYWY3F documentation, a 4.7k resistor is required to allow 'signal contention' between the watchdog and the MCU reset and replacing this with a 2k allowed the signal to come low enough to trigger a proper reset:

    During implementing code to control the watch dog, I realised that I had to disable the device whilst the BME280 sensor chip was 'doing it's thing', which takes about 3 seconds. The watchdog has a window 1.6 seconds long in which it expects a heart beat pulse from the MCU so, unfortunately, it seems that the STWD100NYWY3F is not the best solution. I'm guessing that the chances of the system crashing during that 3 second long period is very low, but for the sake of selecting the correct component, it's worth making another PCB upgrade. It will also give the opportunity to incorporate a switch in the circuit to isolate the reset so that code can be uploaded without having to remove the MKR WAN 1300 from the board. The new watchdog will be the programmable Texas instruments TPS3430WDRCR for which there is an evaluation board to make life easier.

  • Next Step in Debugging Effort

    Tegwyn☠Twmffat03/07/2019 at 11:07 0 comments

    After a few weeks of running the weather station close to my office, I was able to find out what might be causing it to crash so often. Well, actually, whatever I did in the code made no difference and the crash seemed to be entirely random. This could only mean that there was a problem with the track routing on the PCB, so the design was improved to give logical precedence to the wind instrument data lines, particularly the anemometer, which carries a pulse:

    Rebuilding the PCB also gave me the opportunity to incorporate a simple watchdog circuit which would reset the MCU after a crash. 

    Fortunately, after the rebuild, the frequency of crashes diminished to greater than 3 days. Next step is to implement the watch dog.

  • Debugging

    Tegwyn☠Twmffat02/16/2019 at 12:11 0 comments

    Although weather stations are normally quite easy projects with relatively simple electronics, they do have their challenges. I am currently using the LORAWAN 1300 mcu and finding that it is stable for about 24 hours and then crashes for no obvious reason. The most obvious culprit is the anemometer which uses the Arduino pulsein function, but it could also be due to my crappy coding or PCB design. Debugging is ongoing and the PCB has been redesigned with priority being given to the signal path from the anemometer.

    I've also incorporated a watchdog chip (STWD100NYWY3F) which checks every 1.5 seconds for a heart beat pulse from the MCU. If the heart beat stops, it triggers a reset. The component is quite small but can be soldered without the need for a stencil as it has protruding legs and can easily be tested and replaced if there is a problem.

    Obviously, it's still a good idea to find the actual fault in the system!

View all 5 project logs

  • 1
    Pole Construction

    To get meaningful results, it's important to get the wind instruments high up in the air, away from trees, buidlings etc.

    The pole itself is made from 1" high pressure water pipe and can be used with standard 1" BSP plumbing fittings for joining sections together.

    The first section is stainless steel 1" as above and is concreted into the ground.
    The next section is also stainless steel 1" , which then connects to the final section which tapers to 1/2":
    The wind vane is mounted as above. The last section also has the guy rope attachments and the Anemometer

View all instructions

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates