06/02/2019 at 15:22 •
The software is stable. Time to fiddle about with it a bit more! It seems that sometimes it can produce duplicate rows of results if not connected to internet for a long time.
04/30/2019 at 12:02 •
After a bit of head scratching, I realised I'd need to charge the capacitor from another pin via a diode or else when the pin goes low again, the charge will be lost back to the MCU. I was also worried that the act of reading the capacitor using the analogRead() function would also discharge the device and it took a bit of trial and error to select a capacitor that was big enough such that it did not discharge too quickly. In an ideal world it would not discharge at all, until it rains, of course.
The other thing that caused slight confusion was the 'sharp' saw tooth pattern on the 'scope until I realised that the same thing was happening - the 'scope probe was also absorbing charge from the capacitor:
04/28/2019 at 15:34 •
To get the deep sleep function and supervisory watchdog playing nicely with each other required a bit of tuning using well placed delay() functions in the code. Previously, all timings could be done using the millis() function, but with deep sleep, this no longer works as millis() does not operate in deep sleep.
The watchdog chip needs to be pulsed regularly with 3.3 v to stop it from pulling the reset bus low and resetting the MCU. This was easy enough when taking wind and rain readings, but slightly more challenging when it came to reading from the BME260 at the 5 minute interval and allowing 10 seconds for a callback from the raspberry pi internet 'gateway'. A bit of trial and error whilst connected up to a 'scope was the answer. The above image shows the Adafruit M0 feather LoRa radio power profile with deep sleep very close to zero between each set of wind readings in red and the watchdog pulse in blue.
04/27/2019 at 15:15 •
It could be said that building a weather station is trivial - it's just a bunch of sensors plugged into an MCU - too easy to take seriously. But once we get stuck into the details of low power everything becomes more challenging (thankfully). The photo below shows a 'state of the art' watchdog chip and circuit which lurks underneath the Adafruit LoRa Feather module:
04/20/2019 at 08:59 •
A 5.5V power supply was connected to the Vin / USB bus pins on the two devices with a high accuracy 20 Ohm resistor in series for current measurement. An oscilloscope was connected either side of the resistor and it's measurements are displayed in red below:
On the left is the Arduino and n the right the feather and the 'pulse' represent the Adafruit 'Sleepy Dog' deep sleep function kicking in. We're interested in the minimum values and the Arduino gave 11.5 mA in deep sleep and the Feather 2 mA. Also, in 'steady state' operation the Arduino consumed a lot more power, 20 mA compared to 11.5 mA for the feather. The MCUs and radios are the same so there's obviously other devices burning up a lot of power in the Arduino such as the 5V to 3.3V regulator.
I then tried to perform a LoRa transmit on the MKR1300 and the oscilloscope showed one hell of a mess, with a large zone shown by the large area where nothing much seems to happen, in spite of the code! The best that Sleepy Dog could achieve was about 18 mA.
Compare this with the feather:
04/15/2019 at 14:16 •
I've been really struggling getting the Arduino MKR1300 to work properly - A simple delay after powering up moisture pin seemed to fix it:
Old code: digitalWrite(moisturePowerPin, HIGH); // Powers up the moisture sensor for 0.1 seconds to prevent corrosion. moisture = (analogRead(sensorPin)*0.120)-9; New code: digitalWrite(moisturePowerPin, HIGH); // Powers up the moisture sensor for 0.1 seconds to prevent corrosion. delay (50); moisture = (analogRead(sensorPin)*0.120)-19;
Also, I think there was some type casting of variables problem which I fixed at the same time (eg we cant just cast integers to floats without using memcpy function in 32 bit system or similar) but on top of that there's a well known hardware fault with the device that stops it going into sleep mode. I say well known, but when I selected the device, I did not know about it! Nevertheless, swapping out for the Adafruit version was only a few hours work on DesignSpark PCB software and here's the new version:
As the name of this project suggests, having a low power consumption is vitally important, and from the Adafruit documentation it looks like those guys actually went through the various power profiles and it certainly looks like it works properly from the various graphs at: https://www.adafruit.com/product/3178 . The MCU on the feather has 256k of flash and 32k RAM memory so it's easily big enough for all my code. It's also pretty fast although speed is not really an issue. There are also 3 spare input pins which can be hacked if necessary in the future. PCB and Gerber files are on the GitHub page and have just been sent to JLC PCB for a 10 day turnaround for $10 including postage - they now have a swanky airmail service which should speed things up quite a bit.
Looking at the image above, you might notice a crazy small chip inside the yellow feather module box. This is a programmable watchdog that will trigger reset if the MCU crashes or starts producing erratic data. It works really well with the current MKR1300 setup, but will it work with the various Adafruit sleep modes? I'm guessing I can put the device into deep sleep for 3 seconds at a time, which is within the current watchdog timeframe. Should be interesting to see how it performs.
The current draw for the device is documented as being 11mA for the MCU and an additional 2mA for the radio. To transmit a data payload of 20 bytes, about 130mA is required for 70ms. When the radio is actively listening for data, the whole device consumes 40mA and when in deep sleep, about 300uA. Will the rain gauge work in deep sleep mode?
04/13/2019 at 08:19 •
Having tried both capacitive and resistive moisture sensors, I found the resistive much more stable and accurate and then spent a bit of time calibrating it against changes in temperature:
The blue line shows how the moisture readings change with temperature and it appears to be a straight line. In reality, it tapers off as temperatures rise above 50 degrees C. I used a very simple formula:
moisture = moisture - (moisture * soilTemp * 0.065)
by trial and error to get the red line. As can be seen, it's not a flat line so the cobbled formula could be refined by incorporating a cobbled sine function, but accuracy to +- 2% moistre is absolutely fine foe me at least!
Calibration files for the weather station are available here: https://github.com/paddygoat/Weather-Station/tree/master/Calibration%20calculations
I also fixed some of the graphs on the GUI so that, among other functions, soil moisture and temperature can be viewed side by side: http://www.goatindustries.co.uk/weather2/soilMoistureTemp01.html to check that the calibration is going to work. It should display a steady decline, irrespective of temperature, until it rains again.
03/12/2019 at 12:48 •
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.
03/08/2019 at 11:25 •
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.
03/07/2019 at 11:26 •
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.