At Sensoterra we design and produce soil moisture sensors. We give farmers and landscapers the opportunity to look deeper into the soil at multiple places at the same time. This saves them a lot of time going into the fields and optimising their irrigation decisions. Following the moisture level patterns can save you a lot of water and increase your yield by irrigating at the right time with the right amount of water.
We faced a lot of challenges while designing these sensors and the number of requirements increased during the years when we got feedback from the field. In this story, we show a couple of examples of these challenges we faced and how we handled them.
The main challenge: battle the elements
These soil moisture sensors are mostly used by men with big strong hands who are used to throwing their equipment in the back of a truck. After the sensors survive the trip into the field they are placed in the soil out in a wet field with rain, wind, sun, in other words, left exposed to the elements. This brought us to the main challenge: how to make a sensor that is super easy to use, fail-proof, rugged and waterproof?
We stripped the sensors down to the bare minimum. We removed all buttons, switches, LEDs and created a closed box. This didn't come without many tradeoffs including a simple one: How do we switch it on? We needed to be smarter.
Sensoterra Single Depth sensor. Robust design with no buttons.
The next challenge: turn it on and off
The question how do we switch it on was bounced back with: do we need to switch it off? Modern electronics are super energy efficient in a deep sleep. So when the product is not in use it could and should go into the deep sleep mode. Our device has an hourly pattern: measure the soil, encode a payload, send it out, sleep for an hour, wake up, measure the soil, etc. The energy consumption of the measurement is negligible compared to the LoRaWAN radio communication, so if the sensor cannot take a measurement, it isn't installed in the soil, which means it can go back to sleep and skip the battery consuming communication. This means when the sensor is in the warehouse or in storage the sensor is in a very energy-efficient mode, which we call “stock mode”.
When the user installs the sensor in the soil it will notice on its first wake up that it is in the soil and start uplinking. This means that it can take up to an hour before the customer has its first feedback. Therefore we added an accelerometer so when the sensor is kept upside down and then placed in the soil it will wake up immediately. The user will get the measurement available on their smartphone right away and can leave the field knowing the sensor is working properly.
Besides the “standard mode” and “stock mode” we created a couple other modes and configurations to test the device. One uplink per hour is enough for following moisture levels, but you don't want to occupy the test laboratory for days.
Another challenge: switching modes
When the sensors get their battery for the first time they start their life in the “factory mode”. This mode is made so we can do the checks during manufacturing and have good quality control. The results of the checks are stored in our backend and connected to the serial number. In the final step, it is set to the standard mode and the products are customer ready.
When the sensors are out of the factory we can switch modes with a downlink. For example when we would like to switch to a test mode or changing the uplink interval.
A LoRaWAN network is needed to send downlinks and that is where The Things Network comes.
How we use The Things Network (TTN) in these challenges
We need a LoRaWAN network everywhere: at the customers, the office and the warehouse. For the warehouse, we have a couple of specific reasons to set up a LoRaWAN system. First of all, we can check if our stock is correct by the number of sensors online. Secondly, we can manage the energy consumption of the sensors better. Finally, we can control the downlink configurations before we send a sensor out to a customer.
TTN has the great advantage of allowing an unlimited number of sensors for free per user. This gives us the ability to register all our sensors which come from production. We have an API in place that registers the sensors automatically to TTN and deregisters it or leaves it connected when sent to a customer.
We are also testing extensively with our sensors in the office and the test laboratory. TTN doesn’t limit us in our uplink usage, which is great when testing and we collect as much information as possible in a short time. We are hitting the LoRaWAN specification limits regularly.
At the customer level, we leave it to our customers. Mostly a public network is preferred, leaving out the high costs of setting up your own network. Unfortunately, this is not as common as we see with KPN with a nationwide network in the Netherlands. Then we configure the gateways for our customers, so they only need to power it up. TTN provides an easy to setup gateway configuration keeping it easy for us.
In short, TTN enables us to test and break our prototypes to bring us to the point where we are now. It allowed us to make our sensors behave in smart, energy-efficient ways, and ensure a smooth process from the sensor is produced until it ends in the hands of our customers.
Daan Roethof with prototypes of the Sensoterra Multi-Depth sensor