Engineering Degree Project

Soil moisture monitoring system

using LoRaWAN technology

Author: Marcus Johansson

Lnu Supervisor: Daniel Toll
Semester: Spring 2021
Subject: Computer Science
 Abstract
An IoT device measuring soil moisture to help a municipality improve the work
surrounding irrigation is deployed for testing and used by the concerned municipal
workers. The IoT device is an initial prototype using Pycom’s LoPy4 with expansion
board 3.1 and 3xAAA batteries as power supply. The prototype is not suitable for
larger-scale testing due to the size, cost, and power consumption. This thesis focuses
on decreasing the cost and size while increasing the battery life for the IoT device.
The IoT device is communicating using the LoRaWAN protocol. For the device to
be as energy-efficient as possible, the LoRa and LoRaWAN protocol are explored
to use all possibilities to save energy. Active time and power consumption between
different spreading factors are examined and discussed for power consumption and
range concerns.

The prototype produced by the work performed in this thesis is used to measure
soil moisture. The microcontrollers selected and tested will not restrict to that pur-
pose. The microcontrollers can integrate with many kinds of sensors. Integration
with other types of sensors is under future work in this thesis. The integration pos-
sibilities making the thesis relevant for anyone with an intermediate knowledge in
programming wanting to get introduced into the IoT development cycle, develop a
LoRa node, and learning how to use the LoRaWAN stack with MicroPython.
Contents
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Problem Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Scope/Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Theory 6
2.1 LoRa and LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Sleep Mode for Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Power Consumption Measurement LoRaWAN Device . . . . . . . . . . . 11

3 Method 13
3.1 Research Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Selection Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 Microcontroller Second Selection . . . . . . . . . . . . . . . . . . . 15
3.2.3 LoRa Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.4 Battery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.5 Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.6 Prices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Reliability and Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Ethical Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Microcontroller Selection 17
4.1 Microcontroller First Iteration . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2 Consequences for Design . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Current Measurement on Raspberry Pi Pico . . . . . . . . . . . . . . . . . 19
4.2.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Microcontroller Selection Second Iteration . . . . . . . . . . . . . . . . . . 21
4.3.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.2 Consequences for Design . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 Current Measurement on LoPy4 . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4.1 LoPy4 with expansion board 3.1 . . . . . . . . . . . . . . . . . . . 24
4.4.2 LoPy4 without the expansion board 3.1 . . . . . . . . . . . . . . . 27
4.4.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.4 Consequences for Design . . . . . . . . . . . . . . . . . . . . . . . 30

5 LoRa Module Selection 31

5.1 LoRa Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 Consequences for Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6 MicroPython Library 34
6.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 Current for Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4 Consequences for design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 Battery Selection 36
7.1 Battery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.3 Consequences for design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

8 Box Selection 39
8.1 Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

9 Analysis 41

10 Discussion 42

11 Conclusion 43
11.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

References 44
1 Introduction
This report is a bachelor thesis focusing on developing a cost and energy-efficient Internet
of Things (IoT) device to use as a prototype to help a municipality with work regarding
irrigation. This thesis is continuing an existing IoT project measuring soil moisture for a
municipality. The IoT project’s primary goal is to make the municipality’s work regard-
ing irrigation more efficient and environmentally friendly. The existing project uses the
LoPy4 with expansion board 3.1 to transmit the soil moisture value using the LoRaWAN
protocol. This thesis is a project that focuses on finding a microcontroller that’s cheaper
and more energy-effective while reducing the device’s size significantly. An evaluation
between microcontrollers, Lora modules, batteries, and boxes for protection is performed
to find a suitable device. During the process, the evaluations and selections performed
resulted in a device reduced significantly in size, cost, and power consumption. The se-
lected device in this project uses a soil moisture sensor. The device is not restricted to this
sensor. Many different types of sensors can be integrated into the microcontroller selected
for the device. Making the project relevant to anyone with an intermediate knowledge in
programming wanting to get introduced into the IoT development cycle, develop a LoRa
node, and learning how to use the LoRaWAN stack with MicroPython [1].

1.1 Background
Cities continue to attract new people, and by 2050 United Nations estimates that more
than 68 percent of the world’s population is expected to live in large cities [2]. Com-
bined with the population growth, another 2.5 billion people can be added to urban areas
by 2050. Cities need to face the challenges this vast increase in population brings. One
solution to confront the challenges is to develop technologies that use sensors, collect in-
formation, and use that information to perform some tasks concerning making a city more
effective. The tasks can concern streetlights, traffic lights, garbage handling, parking, and
irrigation. Systems collecting information about a city’s responsibilities can be trained
to make predictions and make intelligent decisions, and a city that develops intelligent
systems becomes a so-called smart city [3]. Cities need to become smart cities, and to
achieve this, a city needs to evolve with the progress within IoT, using it in innovative and
intelligent ways. The writer of this report has developed an IoT solution to help a mu-
nicipality with its work regarding irrigation. The IoT solution is motivated by removing
unnecessary trips to control water levels for plants and trees in remote locations, making
a municipality more cost-, time- and energy efficient, benefiting the taxpayers. The IoT
solution is a prototype that this project aims to improve; see Fig. 1.1 for details about the
prototype’s components.

It exists similar solutions on the market already, but non found using a capacitive soil
sensor. The existing solutions are using resistance sensing technics, and Sensefarm pro-
vides one such solution with a battery life between five to ten years [4]. Resistive sensors
at the same price class as the capacitive sensor tested and selected for this project are un-
reliable as they are susceptible to corrosion due to exposed metal. The corrosion change
low and high values read from the sensor, and sensors need to be recalibrated continu-
ously. This was experienced during the testing of soil sensors for the existing prototype
and by others [5], [6]. The resistive sensors used in similar solutions on the market do not
have a problem with corrosion; however, the price for these sensors is significantly higher
than the one selected for the existing prototype.

1
 An interesting existing solution is one from the Finnish company Soil Scout. Soil
Scout provides underground wireless soil sensors with a battery life of up to twenty years
and is an "Install and Forget" solution. The sensors have a range of about 400 meters and
then use a base station to forward the data to a cloud. If the distance is greater than 400
meters, a repeater needs to be included [7]. The use of a base station is where the solution
differs from the solution designed in this project. The prototype designed in this project
will use existing network solutions, and no installment of base stations is needed.

The IoT solution mentioned consists of a prototype developed as a get-started fast

solution, and its main aim was to evaluate different types of soil sensors. The evaluation
resulted in the selection of the DFRobot SEN019. Fig. 1.1 present the components of the
existing prototype. The goal of this project is to create an improved prototype compared
to the existing prototype components. The microcontroller used in the existing proto-
type is the LoPy4 with expansion board 3.1, and the power supply is 3xAAA batteries.
During the test period for different soil sensors, the battery life was around two weeks.
The existing prototype box is suitable for protection; however, the box’s volume is much
too large for the components inside and can be reduced significantly. Reducing the vol-
ume will remove the unnecessary use of space and make the device easier to hide, and
decrease the possibility of theft. Therefore, an improved version of the prototype must
contain components that increase the battery life and decrease the volume. The project
will explore options to decrease the cost of the prototype by evaluating microcontrollers
and possibilities to integrate these microcontrollers with a LoRa module.

(
2)

(
3)

(
4)
(
1) (
5)

(
6)

Figure 1.1: The existing IoT device and its components: (1) Existing IoT device (2)
LoPy4 with expansion board 3.1. (3) Soil sensor DFRobot SEN0193. (4) AAA battery
holder. (5) AAA Batteries. (6) Pycom Sigfox/LoRa antenna kit.

2
1.2 Related Work
Mekki et al. present LoRa as advantageous in battery lifetime, capacity, and cost. The
paper presents the LPWAN technology as superior to other cellular technologies such as
2G, 3G, and 4G in energy consumption. The technical differences between Sigfox, LoRa,
and NB-IoT are evaluated, for example, battery life and latency. Mekki et al. present the
LoRa and Sigfox to be very suitable network technologies for smart farming. The concept
of smart farming refers to farms using sensors to help with the everyday work at a farm
(e.g., checking water levels, soil moisture levels, and temperatures). Mekki et al. show
that typical characteristics for devices in smart farming are that they primarily are in sleep
mode, transmitting only a few times a day. The paper summarizes that LoRa and Sig-
fox are technologies suitable for serving lower-cost devices with long battery life. This
project’s device communicates using LoRa and LoRaWAN and will exist mainly in sleep
mode. Mekki et al.’s conclusion enhance the fact that LoRaWAN is a suitable technology
for an IoT device located in a remote location and relies on long battery life [8].

Boursianis et al. discuss IoT in agriculture and perform a survey of the latest research
on IoT in agriculture. Types of sensors such as sensors measuring pH, soil moisture,
temperature, and wind are discussed. Relevant sensor networks, as LPWAN and IoT ap-
plications used in Smart farming, are presented and discussed. The LoRaWan is presented
as a much suitable network with regards to low cost and long battery life, as it offers very
low power consumption. Boursianis et al. conclude by stating that agriculture is at a turn-
ing point in the transformation to become "intelligent," so-called "Agri-Food 4.0." [9]

Olsson and Finnsson are in their thesis evaluating the use of LoRa and LoRaWAN
to send weather station information in the Gothenburg archipelago. Tests performed on
packet error rates for the different spreading factors at various distances are evaluated.
Olsson and Finnson are successfully transmitting distances up to 7 km with a free line of
sight during the tests. Olsson and Finnsson also design a range extending protocol and
motivate the protocol by showing that the protocol will reduce the number of gateways
necessary for a network [10].

San Cheong et al. investigate the power consumption for LoRaWAN, especially for
class A. San Cheong et al. conclude that a typical device using class A is battery powered
and will have a battery life of ten years on a single battery. To obtain an operational goal
of ten years for a LoRaWAN device, considerations regarding payload size, transmission
intervals, and low spreading factors must be addressed [11]. LoRaWAN classes and the
concept of the spreading factor are presented in section 2.1

1.3 Problem Formulation

The price for the prototype components; see Fig. 1.1 is 969 SEK; see section 3.2.6,
and size dimensions 158x90x60mm. Using Design Science, see section 3.1 and iterative
produce a prototype more suitable from the following requirements.

Req1 Decrease the volume and cost while enhancing battery life compared to the existing
prototype.
Req2 A microcontroller (MCU) shall have qualities focused on size, cost, and energy
efficiency.

3
Req3 The MCU shall communicate using the LoRaWAN technology, and therefore a
LoRa transceiver must be integrated with a focus on qualities matching the MCU.
Req4 A battery option providing the MCU with a minimum estimated battery life of five
years. Ten years is typical for most similar devices [11]. However, this project is
designing a prototype, not a finished product. Therefore half that time is considered
good enough.
Req5 A box appropriately protecting the device and matching to the size and cost require-
ments included in Req1.

The expected result after solving these problems is an IoT device to use during product
development.The device will monitoring moisture levels in soil in a cost, energy-effective,
and compact solution. A MicroPython library for integration between a LoRa module and
a microcontroller is also an expected result and goal.

1.4 Scope/Limitation
The selection of MCU, LoRa module, battery, and box are restricted to the retailer’s
Mouser, Digi-Key, RS, electrokit, RAK, and DFRobot1 . Table 1.1 provides URLs to
each retailers. Mouser, Digi-Key, RS have a massive selection of the necessary compo-
nents, and documentation is primarily included. The search filters these vendors provide
simplifies the search for a suitable component. Electrokit and RAK do not have a massive
selection but compensates with an inventory relevant to the project.

Retailer URL Retailer URL

Mouser https://www.mouser.se Digi-Key https://www.digikey.com
RS https://se.rs-online.com/web electrokit https://www.electrokit.com
RAK https://store.rakwireless.com DFRobot https://www.dfrobot.com
Table 1.1: URLs to the retailers within the scope of the project.

Prices and availability refer to the period [22-03-2021 to 13-05-2021]. LoRa section;
see section 2.1.1 is limited to a basic understanding, focusing on two key concepts behind
the technology Chirp Spread Spectrum (CSS) and Spreading factor. The project’s focus
is not on a deeper understanding of LoRa signals; therefore, the CSS or Direct Sequence
Spread Spectrum (DSSS) is not explained in detail, and no Spread Spectrums will be il-
lustrated. For a deeper analysis of these technologies, see Olsson and Finnsson [10]

The project aims to implement a MicroPython library to integrate a LoRa module and
a microcontroller. The implementation is limited to MicroPython due to the author’s limi-
tations in lower-level languages such as C/C++. The implementation is a demonstration of
how LoRaWAN can be implemented using MicroPython and can also be used to compare
power consumption during transmission against the LoPy4, which is using MicroPython.

1.5 Outline
The following chapters are:

2 Theory includes a basic overview of the LoRa and LoRaWAN technologies and the
UART protocol.
1
The retailer was added due to findings in section 4.3

4
 3 Method is presenting the Design science method used in the project and the decision-
making strategies characterized as compensatory and non-compensatory. Methods
used for each component selected are presented.
4 Microcontroller Selection contains the design process for microcontroller selec-
tion and power consumption measurement performed on selected microcontroller.
5 LoRa Module Selection contains the design process for LoRa module selection.
6 MicroPython Library presents the implementation of a MicroPython library for
integration between the selected microcontroller and the LoRa module. Provides
an example on how to use the library.
7 Battery Selection contains the design process for battery selection.
8 Box Selection contains the design process for box selection.
9 Analysis Present the finding while doing power consumption measurements on the
Raspberry Pi Pico and difference in MicroPython and C. Furthermore, a discussion
on why the selected battery Saft LS14500 is a well-suited battery to use with the
prototype.
10 Discussion consists of a discussion on how the methods used helped achieve the
project’s requirements and why LoRaWAN was a well-suited network option.
11 Conclusion contains the finding during LoRa and LoRaWAN exploration. The
findings during the microcontroller, LoRa module, battery, and box selection pro-
cesses. It also contains a discussion about future work.

5
2 Theory
This chapter includes the theoretical knowledge required to understand the work per-
formed in this project. It covers LoRa, LoRaWAN, and UART.

2.1 LoRa and LoRaWAN

This section aims to provide the reader with a basic understanding of LoRa and Lo-
RaWAN by introducing the concept Chirp Spread Spectrum and Spreading factor. These
concepts are two fundamental properties that make LoRa an suitable LPWAN technology
regarding power consumption, range, scalability, and cost. Basic knowledge about these
concepts is essential to program a device taking full use of these properties.

2.1.1 LoRa
LoRa is a radio frequency modulation technology created by Semtech to create a standard
for LPWANs (Low-Power Wide-Area Networks). LoRa provides communication up to
five kilometers in urban areas and up to 15 kilometers in rural areas. One essential quality
for LoRa is the low power consumption it brings to end devices (nodes). Nodes can reach
an operational lifetime of up to ten years [12].

LoRa is the lowest layer (Physical Layer) of the LoRaWAN stack, utilizing the spread
spectrum technique Chirp Spread Spectrum (CSS). The CSS is an alternative to the tradi-
tional Direct Sequence Spread Spectrum (DSSS). DSSS is multiplying a data signal with
a pre-defined bit pattern, know as the spreading code. When the data signal arrives at
the radio frequency receiver, it is multiplied with an exact copy of the spreading code,
resulting in a reproduction of the original data signal. By executing this code sequence
multiplication, a transmission can be done over a long range. CSS does not require a
highly accurate reference clock which the DSSS does. This makes LoRa a cheaper and
more power-effective technology [13], [10].

According to Semtech, the key property for LoRa is the spreading factor (SF). The
spreading factor is the spreading code applied to the original data signal. LoRa has a total
of six spreading factors, SF7 - SF12. Spreading factors are inherently orthogonal, mean-
ing that signals transmitted on the same frequency with different spreading factors will
not interfere with each other, making signals with different spreading factors appear as
noise to each other, therefore two packets arriving simultaneously and on the same chan-
nel with different spreading factors will not collide, and both packages will demodulate.
If two packets have the same spreading factor, channel and arriving simultaneously, the
packets might collide. However, if one of the packets is stronger by six dB, that packet
will survive.

As can be seen in Table 2.2, a lower spreading factor offers a higher data rate but a
shorter distance, while a higher spreading factor offers a lower data rate but a larger dis-
tance. The use of an adaptive data rate mechanism is essential for the power consumption
of a node. Battery life for a node is prolonged by transmitting using a low spreading
factor near a gateway, minimizing air time. When a node is located farther away from a
gateway, a trade-off is made; a higher spreading factor gives greater distance and a longer
air time, resulting in higher power consumption [17].

6
 DataRate SF Bit rate Range Time on Air
(125kHz) (bps) (km) (ms)
5 7 5470 2 56
4 8 3125 4 100
3 9 1760 6 200
2 10 980 8 370
1 11 440 11 740
0 12 290 14 1400
Table 2.2: EU867∼869 MHz table; packet Error rate 1% [14], [15], [16]

LoRa operates on license-free frequencies, 868 MHz band is the band used in Europe.
LoRa devices are allowed to operate on frequencies between 863 to 870 MHz to comply
with the ETSI (European Telecommunications Standards Institute) wideband modulation
regulation [18].

2.1.2 LoRaWAN
This section introduces a typical LoRaWAN implementation and the component it in-
cludes. The essential concepts of LoRaWAN and the LoRaWAN implementation a device
in this project will use is presented.

As mentioned; see section 2.1.1, LoRa operates on the physical layer, and LoRaWAN
is the networking protocol used to create secure bi-directional communication between
an end-device (node) and an end-user. Fig. 2.2 illustrates a typical LoRaWAN implemen-
tation.

Typical LoRaWAN implementation

Gateways

LoRa Network
Server

Secure IP
Secure IP

Application Data Portal

Servers
ur e IP
Sec

Join Server

* Radio Frequency (RF)

F*
aR
LoR
Figure 2.2: A typical LoRaWAN implementation and the LoRaWAN implementation
this project uses to join a network, send data to an application, and send data from the
application to a node.
Nodes

7
 While the traffic is still on the physical layer, the signal is received by any LoRaWAN
gateway within the hearing distance, as seen in Fig. 2.2. This arrangement reduces packet
errors, considering the chance that at least one gateway will receive the package are promi-
nent. The gateway is nothing else than a package forwarder with the responsibility to
check the package integrity. The integrity checks using cyclic redundancy check (CRC);
if the CRC is incorrect, the package will be dropped. If the CRC is correct, the gateway
will forward the package with IP. A gateway can have a setup using a Wi-Fi, Ethernet, or
cellular connection A package forwarded to the LoRa Network Server (LNS) is attached
with metadata. Together with the metadata, an RSSI (Received signal strength indication)
level is included. The RSSI level is used when the LNS sends back a downlink. The
gateway with the highest RSSI level typically receives the downlink. A gateway with the
highest RSSI level indicates that the gateway is closest to the node sending the uplink.
The concept of uplink and downlink is important in the LoRaWAN technology. An up-
link is sent from a node to a gateway. A downlink is sent to the node from a gateway [19].

LoRaWAN divides nodes into three classes. Class A, Class B, and Class C.

Class A allows bi-directional communication. Two short downlink receive windows

follow each uplink transmission. These windows typically are open for about a second
but can be configured. Nodes in this class are primarily in an idle state (sleep mode). The
transmission slots are scheduled in the node based on the node’s communication needs.
Downlinks from the server have to wait until a node wakes up and an uplink has been
sent. There is no way for an end-user to wake up the device, making devices in this class
not suitable for use with actuators [20], [21].

Class B allows bi-directional communication with scheduled receive slots, giving a

node possibility to receive downlinks on a fixed schedule. To make this communication
working a beaconing process is required [21]. The beacons are sent from the gateways
periodically, and a node needs to receive one of these beacons to align an internal timing
reference to the network. When a device received a beacon and is aligned, it does not
need to process the next beacons arriving. However, realignment needs to be done several
times a day but can be configured with a minimal impact on the battery life. A ping slot in
the node is opened periodically based on a beacon’s timing reference. The network uses
the ping slot to send downlinks to the node. For this communication to work, all gateways
need a built-in GPS timing source for synchronizing purposes. Class B is more suitable
for actuators, but this class costs more than Class A for battery life concerns [22].

Class C, bi-directional communication with nearly continuously open receive win-

dows. The windows are only closed when an uplink is transmitted. Nodes in this class
have high power consumption and are not recommended to use when battery power is
the only option. The class, in return, offers the lowest latency between server and node.
Nodes in this class have use cases in such things as electric meters, street lights, etc [23].

Moving from the physical layer to the data link layer, an IP package sent from a
gateway to an LNS will only be accepted if the node sending the package is activated.
LoRaWAN allows for two types of activation: Over-the-Air Activation (OTAA) (the pre-
ferred way) and Activation by Personalization (ABP). For security, billing quality of ser-
vice, etc, a node shall be commissioned when activated on a network. A node is commis-
sioned securely by using identifiers, server locations, and encryption keys. A node using

8
ABP is tied to a specific network with IDs and keys attached to the node at fabrication.
ABP nodes are working the moment they are turned on; no join sequence is required. For
security reasons, ABP is not recommended. This because keys remain the same through-
out the node’s lifetime.

The recommended activation method OTAA follows a join procedure before data ex-
change participation with a network server. A node shall contain a globally unique identi-
fier (DevEUI), a Join Server identifier (JoinEUI), and an Advanced Encryption Standard
(AES)-128 key (AppKey). A DevEUI is similar to a MAC address because it is linked to
the hardware and cannot be changed. JoinEUI is used to identify the join server uniquely
and is a global application ID IEEE EUI64 address. AppKey is specific for a node and is
used to derive session keys specific for the node and allow the node to encrypt and verify
network communication and application data [24].

These keys are securely are stored in the join server, and a join sequence starts with
a node sending a join request to a Join Server with a payload of JoinEUI, DevEUI, and
DevNonce. DevNonce is a counter starting at zero and is incremented by every join
request. If the Join Server authenticates the node, it returns a join accept to the node. In
the payload of the join accept, there is a JoinNonce, a NwkSKey, AppSKey, among other
fields. A node derives session keys based on the DevEUI, DevNonce, JoinEUI, AppKey,
JoinNonce, and several other fields in the join request and join accept. The session keys
are stored on the node allowing a node to send data without redoing the join sequence until
a session context is lost. These keys are also derived in the join server. The NwkSKey is
shared with the network server and the AppSKey with the application server. The method
ensures that neither a gateway nor a network server can read the data sent between a node
and an application server. After this, uplinks and downlinks can be sent and received by
the application server and a node in a secure manner using the NwkSKey to ensure data
integrity and the AppSKey to encrypt and decrypt payloads [25].

2.2 UART
This section amis to provide the reader with a basic understanding of the hardware com-
munication protocol, UART. UART is the hardware protocol used to communicate be-
tween the LoRa device selected in chapter 5 and the microcontrollers selected in sections
4.1 and 4.3. A basic understanding of UART is essential to perform the implementation
and integration between the microcontroller and LoRa module.

Universal asynchronous receiver-transmitter (UART) is a hardware communication

protocol with one primary purpose: to transmit and receive serial data. Asynchronous
means there is no clock signal from the transmitting device to synchronize the bits trans-
mitted to the receiver. One example of asynchronous vs. synchronous is a phone call
vs. a text message. A phone call happens simultaneously for the transmitter and the
receiver (synchronous); participants can receive feedback immediately. A text message
does not happen simultaneously. The receiver can read the message when time allows
(asynchronous).

The UART interface uses two wires for communication. One wire transmits signals
from the transmitter (TX), and the other wire receives signals to the receiver (RX). Two
devices with direct communication connect with device one RX to device two TX and

9
 Device one Device two
TX TX

RX RX

Figure 2.3: Two devices with direct communication over UART.

device two RX to device one TX, see Fig. 2.3. The TX receives data in a parallel form
from a data bus, translates the data into serial, and transmits the data in a serial form to
the RX on the receiving device. The receiving device translates that data into a parallel
form for a data bus to forward the data into the device.

For two devices to successfully transmit data, the speed for which the data transmits
needs to be the same on both devices. This speed is called the baud rate and is the number
of bits transmitted per second. Some standard baud rates are 9600, 19200, 57600, and
115200. The baud rate is used instead of a clock signal. The receiver uses an internal
clock to sample incoming data, and synchronization is managed by having the same baud
rate on both devices. If the baud rate is not the same on the transmitting and receiving
device, this can cause variance in the data handling. The allowed difference of baud rate
between two devices is up to 10% before the timing of bits is too far off and data variance
occurs.

A transmission in UART is in the form of a packet. A packet consists of a start bit,

data frame, a parity bit, and stop bits, see Fig. 2.4.

Start bit Data frame Parity bit stop bits

(1 bit) (5 to 9 bits) (0 to 1 bit) (1 to 2 bits)
Figure 2.4: UART package

The start bit starts transmission by pulling the transmission byte from high to low. The
data frame contains the actual data transmitted. The length of the data frame vary from
five to nine bits depending on if the parity bit is used. The parity can be used to tell if
data has been modified during transmission. And the stop bits signal that the end of the
package. A typical shorthand notation for the data frame, parity bit, and stop bit settings
in a device data sheet is baud rate/8-N-1–> baud rate (ex 115200), 8 (data bits), N (no
parity bit), 1 (stop bit) [26].

2.3 Sleep Mode for Microcontroller

The possibility to achieve an operational lifetime of up to ten years, as mentioned in sec-
tion 1.2, low power consumption is essential. Many microcontrollers have ways to handle
low power consumption, and this section aims to provide a basic understanding of how

10
this low power consumption is achieved.

A microcontroller (MCU) consumes power in two different states: dynamic and static.
The dynamic power state is when the microcontroller is active and performs some task,
for example, performing a LoRa transmission. The static power state is when the MCU
is not performing any task. The static power state can be configured and optimized to
lower the power consumption and set the MCU into a state of sleep [27]. The way sleep
functionality is implemented can vary between manufacturers and types of sleep mode.
As the implementation for sleep modes varies between manufacturers, an ESP32 chip, the
chip in the LoPy4, is used to explain the different sleep states.

The simples sleep mode is the modem sleep mode. In modem sleep mode in ESP32,
everything is active except Wifi, Bluetooth, and radio. The lowest power consumption in
modem sleep mode is 3mA for the ESP32. This mode is suitable to use if the device needs
to wake up quickly, meaning go to an active state quickly. Light sleep is another sleep
mode provided on the ESP32. In light sleep, the CPU is paused by powering off its clock
pulses, leaving the ULP coprocessor and the RTC in an active state [28]. ULP (Ultra Low
Power) coprocessor is designed to perform ADC measurements while the main processor
is in sleep mode [29]. RTC (Real Time Clock) is used to keep the system time during
sleep modes [30]. Power consumption during light sleep is 0.8mA for the ESP32. The
light sleep mode is suitable to use when the device operates in a static state for a more
significant amount of time than a device suitable for modem sleep but still needs to wake
up quickly. The last and the sleep mode with the lowest power consumption is the deep
sleep mode. In deep sleep mode, the only part that remains powered on is the RTC,
alternatively the RTC and ULP. If both the RTC and the ULP remain active, the power
consumption in a deep sleep mode is 0.15mA, and if only the RTC is active, the power
consumption is 10µA for the ESP32 [28].This mode is suitable for devices that only wake
up a few times a day and perform a task for a couple of seconds before entering deep sleep
mode again. The deep sleep behavior is the one desired to achieve the long operational
lifetime of ten years.

2.4 Power Consumption Measurement LoRaWAN Device

To understand a device’s actual power consumption, power consumption measurements
need to be performed. This section aims to provide a reader with a basic understanding of
how power consumption measurements are performed on an IoT device using the power
consumption measuring tool Otii arch by QOITECH.

The Otii used in this project is a tool measuring electric current requested by a circuit.
The current measured is referred to as the current consumption for the activity measured
[31], [32]. To understand the current consumption during activities for a device, the activ-
ities need to be measured multiple times. A typical active activity for a LoRaWAN device
is waking up from deep sleep, reading sensor values, transmitting the value, checking for
downlinks, and going back to deep sleep. The current consumption measured during such
activity will differ depending on what type of sensor and how code is optimized. An-
other typical activity is when a device is in a deep sleep mode. The current consumption
measured for such activity will typically not differ for different types of sensors included
in the device. An active activity must be measured multiple times and for transmissions
made on more than one data rate. The data rate set to a LoRa device positioned far from

11
a gateway probably has a lower data rate, resulting in an extended active time for the
activity; see table 2.2. The activity needs to be measured for use cases when a device
receives a downlink and does not receive a downlink to understand how this affects the
device [33]. Battery capacity, together with the average current consumption and time for
an active activity and the average current consumption and time for a deep sleep activity
can then be used to calculate the power consumption for the device using the battery life
estimator provided in the Otii software [34].

12
3 Method
This chapter provides the results requirements are met, using an iterative approach when
selecting and evaluating microcontroller (MCU), LoRa module, battery, and box.

3.1 Research Project

This section aims to provide the reader with information about Design Science and the
decision-making strategy characterized as compensatory and non-compensatory used to
meet the project’s requirements.

Design Science is a widely used process when developing or researching a new prod-
uct. The process is iterative; it usually starts with defining and motivating a problem that
needs to be solved, followed by defining objectives for a solution, e.g., terms in which
one solution would be more suitable than another. The next step is to create the artifact
and evaluate that artifact. An artifact in this context is the product selected in each itera-
tion, and together every selected product (artifact) creates the prototype. If the evaluation
supports the problem, the iterative process will end, and a result will be communicated.
Suppose no solution is found; the process starts over, using the knowledge from the pre-
vious iteration. This iterative process can continue until a supported solution is found or
when no supported solution is found. When no supported solution is found, the failure
will be communicated [35].

To find a suitable artifact to evaluate among a vast amount of products, an artifact

is selected using the decision-making strategies characterized as compensatory and non-
compensatory. A decision made under a compensatory strategy compares attributes be-
tween products. All available information is exhaustively processed. A decision made
under a non-compensatory strategy generally does not make use of all available informa-
tion, and trade-offs are usually ignored. Using these strategies number of MCU’s, LoRa
modules, batteries, and boxes to evaluate in detail are significantly reduced, improving
the effectiveness of the process [36], [37].

3.2 Selection Methods

This section describes how the methods introduced in section 3.1 are used for selecting
a MCU, LoRa module, battery, and box suitable for the prototype. The section aims
to provide the reader with a good understanding of how each selection was made and
enough knowledge to replicate the selections. Subsection 3.2.1 is much more extended
than the following subsections. The reason is that most aspects regarding price and power
efficiency are relaying in a suitable selection of a MCU. The majority of evaluations and
analyses performed on selections for the prototype is focusing on the MCU selection, and
the MCU selected has the most significant impact on the finished prototype regarding the
project’s requirements; see section 1.3.

3.2.1 Microcontroller
This section presents the selection process of a suitable MCU. After utilizing the method
and strategy presented in section 3.1, the power consumption measurements procedure is
described and how calculation for estimated battery life results in a decision for a suitable

13
MCU.

The non-compensatory strategy is utilized during product evaluation. For the selected
MCU, a LoRa module needs to be integrated. To meet Req1, see section 1.3, the MCU
selected for the prototype need to cost less than 707,75 SEK, the price for the existing
MCU; see section 3.2.6, and leaving room for the cost of a LoRa module. The goal is to
select an MCU that reduces the MCU price significantly, and therefore a limit of 200 SEK
is set for an MCU to even be considered, leaving plenty of room for the LoRa module.
However, if a first iteration of selecting a suitable MCU results in no suitable MCU with
the 200 SEK limit, the limit will be reconsidered. A critical aspect for a selected MCU is
the availability of the MCU within the project’s timeframe. Most of the selected retailers,
see section 1.4, can provide a product within three to four workdays, know by experience
by the author. An MCU planned to be in stock in three days can be considered, result-
ing in an estimated delivery of seven days. An MCU with an estimated delivery time
longer than seven days will be ignored due to the risk of not receiving the MCU within
the project’s time frame. If an MCU lacks documentation, it will be ignored. Products
not ignored utilizing the compensatory strategy were trade-offs, and available informa-
tion is processed and evaluated. Evaluation is categorized into three categories derived
from within the project’s constraints; Price, Availability, and Documentation. For further
details of each category, see section 4.1.

If the selected MCU has MicroPython support, power consumption measurements

will be performed on both a MicroPython deep sleep and a C implemented deep sleep, so
the two can be compared. The current is measured using the Otii Arch by Qoitech; see
section 2.4, with the main voltage set to the voltage used for power consumption mea-
surements in the MCUs datasheet, or if that information is not provided, the voltage will
be set within the input voltage for the MCU. The Otii Arch will however not be able to
keep a constant voltage for voltages above 4.55V [38] so if the voltage used in a datasheet
is above 4.55V, 4.55V will be used as input voltage. The average current during one
minute is recorded. If information about deep sleep measurements is found in the MCUs
datasheet, the measured values will be compared, and the estimated battery life is cal-
culated with the battery capacity 1200mAh, the typical capacity for the existing battery
[39]; see section 1.1, using the lowest measured value.

Suppose the power measurement in sleep mode keeps an MCU alive for more than
five years with a battery capacity of 1200mAh. In that case, the MCU will be selected
for further evaluations and a more in-depth power consumption analysis. To perform a
more in-depth power consumption, a battery to use for the prototype must be selected
so the correct main voltage can be set to the Otii; see section 3.2.4 and chapter 7. The
more in-depth power consumption analysis measures the time the MCU is awake and in
a deep sleep mode, receiving the average power consumption during each mode with the
main voltage set to the voltage of the selected battery. The measurement is performed
for 6 minutes and 20 seconds with three transmissions. This allows for measurements for
the average power consumption under 2 minutes between the three transmissions. The
lifetime for the MCU when in constant deep sleep is calculated by using the Battery life
estimator included in the Otii software.

With the battery capacity set to the capacity of the selected battery, the active time and
the sleep time set to 43200 seconds, meaning the MCU sends an uplink twice in twenty-

14
four hours, which is the minimum amount of packages the existing prototype is sending
during the period. The current during transmission is measured for cases when the data
rate is 0 (SF 12) and 5 (SF 7) and when a downlink is received and not received. The data
size transmitted during an uplink and a downlink is one byte, with The Things Network
as the network server.

3.2.2 Microcontroller Second Selection

To meet the project requirement of battery life of five years while meeting the requirement
for reducing the prototype’s size, Req1, Req4; see section 1.3, an MCU needs to have a
deep sleep functionality; see section 2.3. If power consumption measurements performed
on MCUs from a first selection provide information about high power consumption, high
meaning an MCU cannot meet the battery life requirement for the project. If power con-
sumption measurements provide this information, the project will utilize measurements
performed by others to find a suitable MCU. A search with the phrase "Microcontroller
deep sleep measurements" on google and google scholar is executed to find suitable mea-
surements performed by others. A relevant search result must consist of a well-described
measurement procedure. In this context, a well-described measurement procedure is, the
measurement device used is described, code executed on the MCU during measurements
are described, and measurements need to be performed on several MCUs so results can
be compared. Measurements presenting this relevant information and power consump-
tion measurement results with MCUs meeting the requirements for the prototype will be
utilized to select a suitable MCU for the prototype in this project.

3.2.3 LoRa Module

The non-compensatory strategy is utilized during product evaluation. LoRa modules over
200 SEK, not compatible with the selected MCU, and not available for shipment within
seven days are ignored. The limits are set for the same reason as for the MCU; see section
3.2.1. The selection and evaluation are categorized into four categories derived from
within the project’s constraints; Price, Availability, Documentation, and Usability. For
further details of each category, see chapter 5.

3.2.4 Battery
The non-compensatory strategy narrowing down many batteries to select between and
batteries suitable in size is funneled down by analyzing the environment a device will
operate. The size of the device is a significant factor in what size a battery shall have,
and power consumption measurements from the MCUs datasheet are used to analyze the
datasheet of each battery selected during evaluation, see chapter 7 for more details.

3.2.5 Box
A box suitable for the prototype needs to have a high water protection level. Proof of
water protection is using the Ingress Protection (IP) rating defined in the international
standard EN60529 [40]. The standard is used to define levels of sealing effectiveness.
Size is determined by the dimensions of the components included in the prototype. When
the IP and minimum size of a suitable box are determined, a selection at the project’s
retailers is performed.

15
3.2.6 Prices
All prices are calculated, gathered, and calculated at the date 02-06-2021. The exchange
rate is 10.10 SEK per 1 euro and is 8.27 SEK per 1 dollar. All prices are with 25% VAT
included. The LoPy4 costs 485,43 SEK, the Lopy4 with expansion board 3.1 costs 707,75
SEK, and the Pycome LoRa/Sigfox antenna kit 113.62 SEK when bought from the Pycom
webshop, where prices are presented in euro. The DFRRobort SEN0193 is bought from
the DFRobort webshop, where prices are presented in dollars, resulting in 60,98 SEK.
The battery Saft LS14500 costs 119.90 SEK when bought at Clas Ohlsson, in-store. The
AA battery holder costs 44.90 SEK, bought at Kjell & company, in-store. Resulting in
a total cost of 164,80 SEK for the Saft LS14500 battery and the AA battery holder. The
AAA battery holder used in the existing prototype costs 19 SEK when bought from the
electrokit webshop. The batteries used in the existing prototype cost 3.99 SEK per unit
when bought on Kjell & company, in-store. The Firebeetle ESP32 costs 71,33 SEK when
bought from the DFRobot webshop. The LoRa module RAK811 costs 155.06 SEK when
bought from the RAK Store, webshop. The RS PRO IP66 cost 98.06 SEK when bought
on rs-online.

3.3 Reliability and Validity

In order to facilitate replication of this work, the same result should be produced. All
methods used for product selection and power measurements aim to be well described and
understandable. To increase reliability, each power measurement is repeated three times,
and averaged for sleep and sending mode are compared. The availability and prices are
under a specific period and therefore challenging to ensure the same result after the given
period. Many prices are calculated between different currencies and therefore dependent
on the exchange rate. Some specific retailers are selected to use for component selection;
these retailers are selected due to the much suitable assortment they provide together with
documentation. It could be a validation issue as some other unknown (to the author) re-
tailers might have more suitable components.

Low power measurements can be affected by many factors, such as poor connections,
unshielded wires can pick up noise, and improperly grounded circuits will produce inac-
curate measurement. It is essential to use a measuring tool proven to be accurate; this
project uses the Otii Arch. In order to be accurate, the device needs to be calibrated. The
knowledge about these problems during current measurement and using that knowledge
to avoid getting noise included in the measurement increases the validity.

3.4 Ethical Considerations

Each device placed in the environment is containing a battery. There is always a risk that
a battery breaks and contaminates the surrounding environment. A well-sealed box to
protect the prototype from water intrusion and battery chemicals from extruding needs to
be considered to protect the device and the surrounding environment.

16
4 Microcontroller Selection
This chapter provides the result from the selection of a suitable MCU. Fig. 4.5 illustrates
the selection process with two iterations, presenting that the Raspberry Pi Pico deselected
during current consumption measurements, resulting in the selection of the LoPy4.

LoPy4

Raspberry Pi
Pico

MCU current
MCU evaluated
consumption
and selected
measurements

Raspberry Pi Result
Pico deselected
LoPy4

Figure 4.5: MCU selection process, staring with evaluation and selection, leading to cur-
rent consumption measurements and a decision regarding if the selected MCU is suitable
for the prototype or not.

4.1 Microcontroller First Iteration

In this section, a MCU is evaluated and selected, focusing on availability, cost, documen-
tation, and power consumption. Decisions made in this section concern the requirements
Req1, Req2, and Req4; see section 1.3. The suitability can be one of three categories:
not suitable with value 0, suitable with few downfalls with value 1, and suitable 2. Table
4.3 presents the result of categorizing MCU’s selected using non-compensatory decisions;
see section 3.2.1, with use of these conditions:

Price: Shall be as low as possible while requirements for the MCU are covered, Req1,
Req2; see section 1.3.
Conditions:
Price > 200 SEK = 0
Price >= 100 SEK and Price <= 200 SEK = 1
Price < 100 SEK = 2
Availability: The MCU are available in multiple retailers (AMR).
Conditions:
Not AMR and Not shippable < 7 days = 0
Not AMR and shippable < 7 days = 1
AMR and shippable < 7 days = 2
Documentation: The following type of documentation must be available when selecting
a suitable MCU, Datasheet, code libraries, user guides, code examples, and user experi-
ences. User experiences refer to others working with the MCU in similar ways.
Conditions:

17
 Datasheet = 0
Datasheet, user guides = 1
Datasheet, code libraries, user guides, code examples, user experiences = 2
Table 4.3, presents the MCUs found at the projects retailers; see section 1.4, using the
non-compensatory strategy described in section 3.2.1 and the three functions presented
above.

MCU Price Availability Documentation Summary

Raspberry Pi Pico 2 2 2 6
Raspberry Pi Zero 1 1 2 4
ESP32-DEVKITM-1 2 1 2 5
ESP32-C3-DEVKitC-02 1 0 2 3
ESP32-C3-DEVKITM-1 2 0 2 4
Table 4.3: Suitable MCU’s found using the non-compensatory strategy, using the three
functions for scoring, and a scoring summary

Feature Raspberry Pi Pico ESP32-DEVKITM-1

Size 21x51mm 25.40x43.81mm
CPU dual ARM Cortex-M0+@ 133MHz single-core 32-bit LX6 @ 160MHz
RAM 264kB 520kB
Flash 2MB 4MB
Pin 40st 32st
GPIO 30 28
ADC 12bit 12bit
UART Yes Yes
I2C Yes Yes
USB Yes Yes
Wi-Fi No Yes
Bluetooth No Yes
Deep sleep 0.8mA Not included1
Operating temperature -20 to 80°C -40 to 85°C
Price 49 SEK 69 SEK
1 No deep sleep measurements included for the DEVKIT-1, there is a link to the ESP32-mini-1 included in
the datasheet, and the ESP32-mini-1 have a 5µA current consumption in deep sleep. However that value is
not valid for the DEVKITM-1

DataSheet links
Raspberry Pi Pico https://datasheets.raspberrypi.org/pico/pico-datasheet.pdf
ES32-DEVKITM-1 https://www.mouser.com/catalog/additional/Espressif_Systems_ESP32DEVKITM1.pdf

Table 4.4: Raspberry Pi Pico and ESP32-DEVKITM-1 comparison; All information is

found in the respective datasheet.

4.1.1 Analysis
The evaluation presents the Raspberry Pi Pico (pico) and the ESP32-DEVKITM-1 as good
options for the project. The pico is suitable in all categories, and the ESP32-DEVKITM-

18
1 is suitable in all aspects except availability. The availability aspect is acceptable. The
evaluation process continues (see table 4.4) with a more extensive comparison between
the pico and the ESP32-DEVKITM-1. The comparison presents the ESP32-DEVKITM-
1 as superior to the Pico in most aspects. These aspects are redundant, given that the
specification for the Pico is good enough for the project. The pico meets the project’s
constraints better regarding price and availability. The pico also has information about
the current consumption in sleep mode available.

The pico has two sleep modes available in the datasheet; dormant mode and sleep
mode. The datasheet presents measurements made on each mode, and for temperature
25°C, the dormant mode has a mean 0.8mA current and the sleep mode 1.3mA. Calcu-
lations with these values with the pico in constant sleep will give the pico an estimated
battery lifetime of 2.1 months in dormant mode and 1.3 months in sleep mode. Thus,
the estimated battery lifetimes calculated are far from the project’s requirement, Req4;
see section 1.3, of five years. A new MCU must be selected, and a new iteration needs
to be performed. However, before a new MCU is selected, it is interesting to see how
the deepsleep function provided by MicroPython performers against the C implementa-
tions. Therefore, power consumption measurements on the pico in these sleep modes are
performed in section 4.2.

4.1.2 Consequences for Design

The Pico includes well-written documentation and compatibility with MicroPython mak-
ing it possible to implement a library to integrate a LoRa module. The availability, usabil-
ity, and price make the pico suitable for the project. Using the pico as the MCU for the
prototype reduces cost and size. However, selecting the pico will affect the prototype’s
power consumption negatively and therefore a new MCU need to be selected. Fig. 4.6
present the Raspberry Pi Pico board.

Figure 4.6: The Raspberry Pi Pico board.

4.2 Current Measurement on Raspberry Pi Pico

As mentioned in section 4.1.1, the pico has two sleep modes implemented in C. During a
closer look at the code for each mode; it is found that an interrupt, not a timer, wakens the
dormant mode example. If a timer can waken, the dormant mode will not be investigated
further; instead, the sleep mode example will be used as the C implementation to measure.

19
The reason for this is that if the implementation would be used in the prototype, the sleep
mode must be able to be set with time. Table 4.5 presents the values measured on the pico
running MicroPython deepsleep script and the pico running the sleep mode, hello_sleep.
Input voltage used for measurements in the picos datasheet is 5V, so the voltage used for
measurements will be 4.55V; see section 3.2.1. Fig. 4.7 present a ten-second caption of a
one-minute measurement for the pico using MicroPython and deepsleep. Fig. 4.8 present
a ten-second caption of a one-minute measurement for the pico using C and hello_sleep.

Raspberry Pi Pico Avg current

deepsleep 23 25.6mA
hello_sleep 1.7mA
Table 4.5: Current measurements for pico, MicroPython deepsleep and C hello_sleep

Figure 4.7: Raspberry pi pico deepsleep, 10 second caption. Avg current consumption
25.6mA

Figure 4.8: Raspberry pi pico running hello_sleep, 10 second caption. Avg current con-
sumption 1.7mA

20
4.2.1 Analysis
The pico using MicroPython and the deep sleep function measured 25.6mA, giving the
pico an estimated battery lifetime of two days in constant "deep sleep." The high value
makes it interesting to measure an empty scrip running on the pico to see how they com-
pare. The empty script measurement gives the same result, indicating that the deepsleep
in MicroPython does nothing on the picos components There are some workarounds in
the making trying to solve this issue [41]. However, these solutions work with the dor-
mant mode, meaning an interrupt is used to wake up the pico. An interrupt to wake up
the MCU can not be used in this project because a timer is needed to wake up the device.
Possibilities to integrate an external RTC will not be investigated, due to the fact that
the dormant modes sleep current of 0.8mA, from the datasheet, is much to high for this
project.

The pico using C and the hello_sleep measurements are significantly better, giving the
pico an estimated battery lifetime of 29.4 days with 1200mAh battery capacity and 2.1
months if the selected battery is used; see section 6. 2.1 months is not near the required
estimated battery life for this prototype. However, 2.1 months can be good enough for
other projects, making the pico suitable from a cost perspective.

The current measured at 1.3mA in the picos datasheet, and the results from these
measurements are 1.7mA. This, of course, comes to question the validity of the measure-
ments performed. The fact that the 1.3mA is measured with a voltage of 5V vs. 4.55V
used when measured at 1.7mA seems unlikely to be the only reason for the difference in
measurement results. Validity methods to reduce noise for the measurements are utilized;
see section 3.3. Multiple measurements are performed, and the result becomes the same
for every measurement, 1.7mA. The datasheet does not describe how measurements are
performed, and therefore it is not easy to replicate the exact procedure for the measure-
ments.

4.3 Microcontroller Selection Second Iteration

Going through the datasheet for the MCUs selected in the first iteration; see Table 4.3, it
was found that not any of these MCUs can meet the required estimated battery lifetime of
five years, Req4; see section 1.3. Utilizing the method for a second selection; see section
3.2.2 the DiyIOt blog was found. DiyIOt [42] is a blog created by Christopher David and
a place where Christopher shares his knowledge about MCU’s. Christopher works as a
data scientist for a German car manufacturer. DiyIOt has performed power consumption
measurements on six different ESP32 developer boards and summarized the result, as
seen in [43, Tab. 4.6], presenting the FireBeetle ESP32 and the WiPy 3.0 suitable for the
project.

21
 MCU Measurement Measurement Percentage
Reference [mA] Deep Sleep [mA] Reduction
ESP32 – DevKitC 51 9 -82.35%
Ai-Thinker NodeMCU-32S 55 6.18 -88.76%
Adafruit HUZZAH32 47 6.81 -85.51%
Sparkfun ESP32 Thing 41 4.43 -89.20%
FireBeetle ESP32 39 0.011 -99.97%
WiPy 3.0 192 0.015 -99.99%
Table 4.6: Deep sleep current compared to a reference measurement [43]. The reference
measurement is measured when a board is running an empty script.

4.3.1 Analysis
The WiPy 3.0 is a board provided by Pycom, the same manufacture as the LoPy4 used
in the existing prototype. Selecting the WiPy 3.0 would no be justifiable from a cost or
time perspective. The LoPy4 has most of the features that the WiPy 3.0 has and also
includes LoRa and Sigfox modules. Selecting the WiPy 3.0 over the LoPy4 in this project
is not an option. The Firebeetle ESP32 with measurements of 11µA in deep sleep and its
low price of 71,33 SEK; see section 3.2.6, makes it a much desirable board to use during
a development phase. The Firebeetle was not found in the first iteration because the
DFRobot retailer was not included in the project’s scope. It is after this finding included.
However, the board needs to be ordered and imported. This fact makes the selection a risk
with a high impact on the project’s success. The measurements made on the Firebeetle
ESP32 by Christopher David were performed with a C implementation. The integration
between the LoRa module and the MCU is implemented in MicroPython, due to the
author’s limitations in the C language. Possibilities to implement the integration between
the LoRa module and the Firebeetle ESP32 in C or possibilities to call a C implemented
sleep function from MicroPython must be investigated and implemented. However, this
investigation and implementation will not be included in this project; it will be future
work; see section 11.1. With the knowledge gained from the first and now the second
iteration in MCU selection, a decision is made to continue using the LoPy4 as the MCU
for the prototype.

4.3.2 Consequences for Design

The LoPy4 is around six times the prices of the pico and five times more expensive than
the Firebeetle. The Firebeetle needs the LoRa module RAK811 to communicate with
LoRaWAN. The Firebeetle, together with the RAK811, is around half the price of the
LoPy4. The LoPy4 is implemented with the soil sensor and tested in the field with success.
The LoPy4 has most of the development completed. Dimensions for the LoPy4 are 55mm
x 22mm versus the Firebeetle 58mm x 29mm. Fig. 4.9 presents the LoPy4 selected to
use as the MCU for the prototype designed in this project and the FireBeetle selected to
be used in future work.

22
Figure 4.9: The LoPy4 and the DFRobot Firebeetle ESP32.

23
4.4 Current Measurement on LoPy4
The existing product is deployed for testing with the LoPy4 and the expansion board
3.1 used for battery connection and easy USB connection. Current measurement are
performed for the LoPy4 with the expansion board 3.1 included and excluded, using the
MCU selection method; see section 3.2.1. Main voltage is set to 3.6V, the voltage of the
selected battery; see chapter 7.

4.4.1 LoPy4 with expansion board 3.1

Measurements for LoPy4 with expansion board 3.1 are presented in the following figures.

• A LoRaWAN transmission is described in Fig. 4.10.

• Fig. 4.11 present the measurement; no downlink received.

• Fig. 4.12 present the measurement; downlink received.

Table 4.7 present average current consumption and the active time for the MCU during
transmission;

LoPy4, expansion board 3.1

data rate avg active time
No downlink
0 81.9mA 5.9s
5 70.1mA 5.1s
Downlink
0 84.9mA 5.7s
5 75.8mA 3.5s
Table 4.7: Current measurements for LoPy4 with expansion board 3.1, sending without
receiving downlink and sending receiving downlink.

The deep sleep for one minute and the average current for the entire sequence; pre-
sented in Table 4.8.

LoPy4, expansion board 3.1

avg time
deep sleep 108µA 60s
entire sequence 5.1mA 6min 20s
Table 4.8: Current measurements for LoPy4 with expansion board 3.1, deep sleep and
entire sequence; data rate 5.

24
 129mA Ac
tiveti
me
Pea
k (
4.969s)
4mi
n5.
876s Cur
rent 4mi
n10.
846s
xi)
s
Upl
i
nk Peak

Downli
nk
Y-a

window
r
CurentmA(

S
tar
t End
T
rans
missi
on T
rans
missi
on

Deepsl
eep Backto
curr
ent Wa
keup deepsl
eep
T
imes
econd(
X-a
xis
)

Figure 4.10: LoPy4 with expansion board 3.1 waking up from deep sleep, performing a
LoRaWAN transmission, and going back to deep sleep.

25
 Dat
arat
e0
Da
tara
te5

Figure 4.11: LoPy4 with expansion board 3.1 sending a package. Near one second longer
active time for data rate 0.

26
 Da
tar
ate0
Da
tar
ate5

Downl
i
nk

Figure 4.12: LoPy4 with expansion board 3.1 sending a package and receiving downlink.

4.4.2 LoPy4 without the expansion board 3.1

Measurements for LoPy4 without the expansion board 3.1 by connecting the Otii directly
to VIN (positive) and GND (negative).

• Fig. 4.13 present the measurement for the LoPy4; no downlink received.

• Fig. 4.14 presents the measurement; downlink received.

Average and the active time for the MCU during transmission; see Table 4.9.

LoPy4
data rate avg active time
No downlink
0 55.3mA 5.9s
5 41.1mA 4.9s
Downlink
0 58.6mA 5.7s
5 47.7mA 3.5s
Table 4.9: Current measurements for LoPy4 sending without receiving downlink and
sending receiving downlink.

The deep sleep for one minute and the average current for the entire sequence; pre-
sented in Table 4.10.

27
 LoPy4
avg time
deep sleep 19.7µA 60s
entire sequence 2.0mA 6min 20s
Table 4.10: Current measurements for LoPy4, deep sleep and entire sequence; data rate
5.

Da
tar
ate0
Da
tar
ate5

Figure 4.13: LoPy4 sending a package; no downlink received.

28
 Da
tar
ate0
Da
tar
ate5

Rec
eived r
st Rec
eci
vedSecond
downli
nkwindow downl
inkwindow

Figure 4.14: LoPy4 sending a package; downlink received. Data rate 5 received in first
downlink window, near two seconds longer active time for data rate 0.

4.4.3 Analysis
The measurements made on the LoPy with the expansion board 3.1 resulted in an aver-
age deep sleep current of 108µA. The documentation states that the expansion board 3.1
should be able to have a 32µA power consumption in a deep sleep mode [44]. However,
this low value is obtained using the WiPy board, and a deep sleep value for when the
LoPy4 is connected to the expansion board 3.1 is not found. The measurements made
on the LoPy without the expansion board 3.1 resulted in an average deep sleep current of
19.7µA. Current consumption measurements provided by the LoPy4 datasheet state that
the LoPy4 has a deep sleep current of 18.5µA. The measurements in the datasheet are
measured with a 5V input. The difference in values can be because the measurements are
not performed with the same input voltage.

The LoPy4 with expansion board 3.1 estimated battery lifetime is calculated; see sec-
tion 3.2.1, which gives an estimated battery lifetime of 2.5 years. Calculations with the
LoPy4 without the expansion board 3.1 give an estimated battery lifetime of 10.8 years.
By removing the expansion board 3.1, the average current decrease by 81,78%. The ex-
pansion board has no greater value for the prototype as the sensor to include is already
decided, and the code will not need to be modified extensively. The main reason to include
the expansion board would be to be able to connect different types of sensors and update
code over USB easily. Because the sensor to include is known, wires can be soldered onto
the headers of the LoPy4, making integration possible with the expansion board 3.1 with-
out including the expansion board 3.1 in the prototype, only using the expansion board

29
3.1 when the device needs to be updated.

4.4.4 Consequences for Design

Selecting the LoPy4 as the MCU to use in the prototype does not significantly reduce the
prototype’s cost. However, it is reducing the power consumption and size significantly
by removing the expansion board 3.1. Code updates can still be performed if wires are
soldered to the header pins, this however not recommended by Pycom, the manufacture
of the LoPy4. Regardless of the recommendation, the soldering work was performed and
did not damage the LoPy4. The use of the LoPy4 will save some implementation time
because the specific use case is already implemented and tested.

30
5 LoRa Module Selection
A LoRa module is evaluated and selected in this chapter, focusing on availability, cost,
usability, and documentation; see Fig. 5.15. Even if the LoPy4 has a LoRa module, a
LoRa module is selected and implemented with Raspberry Pi Pico; because one goal of
the project is to implement a LoRaWAN library for MicroPython.

5.1 LoRa Module

RN2483A and
RAK811

LoRa
LoRa
modules
modules
evaluated
compared
and selected

Result

RAK811

Figure 5.15: LoRa module selection process, suitable LoRa modules are evaluated and
selected, the selected LoRa modules are compared, resulting in the selection of the LoRa
module suitable for the prototype

A LoRa module suitable for the project shall be LoRaWAN Certified [45] to be convinced
of the reliability and compatibility with the LoRaWAN specification. If a device is of mi-
crosize and is considered hard to solder for intermediate solderers, a breakout board needs
to be included or integrated with the device.

The suitability can be one of three categories; not suitable with value 0, suitable with
few downfalls with value 1, and suitable 2. Table 5.11 presents the result of categorizing
the LoRa modules selected using non-compensatory decisions; see section 3.2.3, with use
of these conditions:

Price: Shall be as low as possible while requirements for the LoRa module are covered,
Req1, Req3; see section 1.3.
Conditions:
Price > 200 SEK = 0
Price >= 100 SEK and Price <= 200 SEK = 1
Price < 100 SEK = 2
Availability: The LoRa module are available in multiple retailers (AMR).
Conditions:
Not AMR and Not shippable < 7 days = 0
Not AMR and shippable < 7 days = 1
AMR and shippable < 7 days = 2

31
Documentation: The following type of documentation must be available when selecting
a suitable LoRa module, Datasheet, code libraries, user guides, code examples, and user
experiences. User experiences refer to others working with the LoRa module in similar
ways.
Conditions:
Datasheet = 0
Datasheet, user guides = 1
Datasheet, code libraries, user guides, code examples, user experiences = 2
Usability: is focusing on size. A LoRa module in microsize is considered problematic to
solder for an intermediate solderer. A LoRa module a bit bigger is in this context referred
to as millisize and is considered to be possible to solder but is time-consuming and fid-
dly. A LoRa module mounted on a breakout board or have breakout boards available are
considered much suitable in usability.
Conditions:
microsize = 0
millisize = 1
breakout board = 2

LoRa Transceivers Price Availability Documentation Usability Summary

SX1261IMLTRT 2 2 1 0 5
SX1276IMLTRT 2 2 1 0 5
RN2483A 1 2 2 1 6
RAK811 1 2 2 2 7
Table 5.11: Suitable LoRa Transceivers evaluation

5.2 Analysis
SX1261IMLTRT and SX1276IMLTRT are not suitable for the project regarding usabil-
ity. The modules are microsize and hard to solder for an intermediate solderer. The
RN2483A is a bit bigger in size and possible to solder for an intermediate solderer. The
soldering work is time-consuming, and therefore, the usability, set to two. The RN2483A
has, however, a premade breakout board available that the module can be integrated onto
with soldering. With the breakout board, the RN2483A is a good option for the project.
RAK811 is a breakout board designed to simplify LoRaWAN communication, easy ac-
cess to GPIO pins, and antenna included. The core of the RAK811 is an SX1276 Semtech
module, making it possible to take advantage of all LoRaWAN features. However, the
RAK811 provides a breakout board, and the fiddly soldering is reduced compared to the
RN2483A. Therefore, the RAK811 is the LoRa module selected for the prototype.

5.3 Consequences for Design

The RAK811 is well documented, with a well-formulated user guide available. The board
dimension is 42x25 mm, making it much compatible with the pico with the dimension
51x21 mm, and the FireBeetle with the dimensions 58x38 mm. Interaction with the MCU
is over UART using AT commands. Using AT commands creates compatibility with the
project’s goal to use MicroPython as AT commands are written as a string and then en-
coded to bytes by the UART.write function in MicroPython. The usability, availability,

32
and price make the RAK811 a suitable LoRa module for the project.

The datasheet for RAK811 states that the breakout board is equipped with standard
2.54 mm headers. At arrival, the headers turn out to be 2 mm. The pico, FireBeetle, and
experiment board selected for assembly are standard 2.54 mm. The difference in header-
space involves rethinking the assembly process. The experiment board is removed from
the assembly process, which implies a bit more fiddly soldering. Fig. 5.16 present the
LoRa module RAK811 selected.

Figure 5.16: The RAK811 and included antenna, LoRa module selected to use with the
prototype.

33
6 MicroPython Library
This chapter presents the MicroPython library implemented for integration between the
Raspberry Pi Pico and the RAK811. An example of how the library is used and current
measurements for a LoRaWAN transmission are presented.

6.1 Implementation
For implementation, a basic understanding of UART is needed; see section 2.2. The com-
munication between the Raspberry Pi Pico (pico) and the RAK811 is done over UART
using AT commands; AT stands for attention. A command starts with the prefix "at"
and ends with a carriage return/newline (\r\n). Further information about the AT com-
mands for the RAK811 is found in the RAK811 documentation [46]. The command for
sending a LoRa package is written as a string on the pico and written to UART using
the uart.write() function. The return from the RAK811 is received using the uart.read()
function. If the transmission is successful and no downlink is received, the return will be
"OK." An example sending value 1 in hex:
a t +send= l o r a : 1 : 0 1 \ r \ n
OK
And the same example but with a downlink received:
a t +send= l o r a : 1 : 0 1 \ r \ n
OK
a t + r e c v =0 , −105 , −12 ,1 ,2
Values after "=" explained in order 0: LoRa port, -105: RSSI (see section 2.1), -12: SNR
(Signal-to-Noice Ration), 0: length of data received, 2: data received.

An example of how the library is used to send the value 10 in hex 0A is now presented.
For further details of the library, visit the git repository [1]. The main.py file must import
the LoRaWAN class and the dictionary Keys.
from l i b . l o r a w a n i m p o r t LoRaWAN
from l i b . c o n f i g i m p o r t Keys
It is the file config.py the necessar keys to join the LoRaWAN server is set; see section
2.1.2. To configure the RAK811 with these keys the LoRaWAN constructor is used.
l o r a = LoRaWAN( Keys [ ’ DevEUI ’ ] , Keys [ ’ AppEUI ’ ] , Keys [ ’ AppKey ’ ] )
A join request need to be performed and it might take several tries before a join succeed,
The join retries are performed in a while loop as long as lora.has_joined returns false.
i f not lora . has_joined :
while not l o r a . has_joined :
lora . join ()
p r i n t ( ’ Network j o i n e d ’ )
If the lora.has_joined return true, the value "0A" can be sent.
l o r a . s e n d ( ’ 0A’ )

34
6.2 Current for Transmission
Fig. 6.17 presents the transmission using the example code from section 6.1, captured
with the Otii, with the main voltage set to 3.6V, the voltage of the selected battery; see
chapter 7 and the data rate set to 0. The transmission has an average current consumption
of 61.7mA.

Figure 6.17: Raspberry pi pico sending one byte with the RAK811, avg current consump-
tion 61.7mA.

6.3 Analysis
Both the pico and the RAK811 are well documented, and implementation is straightfor-
ward once a basic understanding of LoRaWAN, UART, and AT commands is gained. The
average current consumption for sending one byte and not receiving a downlink and a data
rate set to 0 is 61.7mA. The LoPy4 has an average current consumption of 55.3mA for
the same use case. The difference of 6.4mA is quite substantial if a device is frequently
sending.

6.4 Consequences for design

The library will not be used with the prototype designed in this project since it lacks a
sleep implementation. However, in future work, the library can be used when possibilities
to implement sleep functions to the pico and the Firebeetle will be investigated; see section
4.3.1.

35
7 Battery Selection
In this Chapter, a suitable battery is evaluated and selected; see Fig. 7.18 by learning the
environment the device will operate in, and gaining the knowledge about power consump-
tion and operational voltage from the MCUs datasheet,

Battery Result
evaluated and Saft LS14500
selected

Figure 7.18: Batteries are evaluated and analyzed, the battery most suitable is selected,
resulting in the Saft LS14500 being the most suitable battery to use for the prototype.

7.1 Battery
The device environment must be known to select a suitable battery, especially the temper-
ature, and also knowledge of the power consumption for the MCU. Knowledge about the
MCUs power consumption is gained from the MCUs datasheet. The device will operate
in soil surrounded by plants and trees during late spring, summer, and early autumn in
south Sweden. Average temperatures during the period typically are in a span from 10°C
and up to 24°C for air temperature [47]. The soil temperature typically is above 0°C and
lower than the maximum air temperature [48]. Therefore the primary temperatures a de-
vice will operate in are between 10°C and 24°C.

The LoPy4s datasheet presents the current measurement with an average deep sleep
current of 18.5µA. The device will be in a deep sleep mode most of the time, and max
transmissions during a twenty-four-hour period are ten times. A typical transmission for
the existing prototype is around five seconds. The approximated active time with ten
transmissions in twenty-four hours will be 50 seconds.

The sleep percentage for twenty-four hours is 99.94%; see equation (1).
50
100 − ∗ 100 = 99.94% (1)
84600

According to the datasheet, the LoPy4 takes 3.5 - 5.5V on the VIN pin and regulates
it into 3.3V. Meaning the voltage for a suitable battery must be within the voltage span.
The LoPy4 dimensions are 55x20mm. Dimensions for a AA battery are 54x14.2mm [49].
The size of a AA battery makes it a much suitable battery regarding the requirement for
size, Req1; see section 1.3.

The product designed in this project is a prototype and will not be used on a large
scale. This fact allows the project to use a battery holder in the design. If the project
were designing a final product, a battery holder would not be included due to the risk
of corrosion on the connections. A battery with wire leads, tags, or PCB pins would be
selected for the final product. In the testing phase for the prototype, the ability to easily
change the battery is more important than avoiding corrosion. The discharge rate of the

36
device will be low to medium-low (from µA to mA). A non-rechargeable battery has a
lower discharge rate than a rechargeable for devices with that kind of behavior. Therefore
a non-rechargeable battery is more suitable for the device [50], [51].

The information gathered about the behavior of the device and the device environment
now needs to be used when a suitable battery is selected. To summarize:

• The device will normally operate in temperatures between 10°C and 20°C
• The device will be in a deep sleep mode for 99.94% of the time (during a twenty-
four-hour period) when max amount of uplinks and downlinks (10) are transmitted
and received.
• Voltage for the battery need to be between 3.5 - 5.5V.
• The AA battery size are much suitable for the design.
• The battery will have standard connection and be placed in a battery holder.
• The battery will be non-rechargeable.

With these battery constraints, the following batteries; see Table 7.12 are available at
the retailers within the project’s scope; see section 1.4.

Description Volt Capacity Available DataSheet Chemistry Retailer

Saft LS14500 3.6V 2.6Ah Yes Yes LTC1 RS
Tadira SL-360 3.6V 2,4Ah Yes Yes LTC RS
Tadira SL-760 3.6V 2,2Ah Yes Yes LTC RS
Tadira SL-860 3.6V 2,4Ah Yes Yes LTC RS
RS PRO 3.6V 2,4Ah Yes Yes LTC RS
Mouser has the Tadira batteries available; however, shipping restricted to the USA only
1
Lithium Thionyl Chloride

Table 7.12: Suitable batteries

DataSheet links
Saft LS14500 https://docs.rs-online.com/9e74/0900766b800cc0c8.pdf
Tadira SL-360 https://docs.rs-online.com/9168/0900766b8070972c.pdf
Tadira SL-760 https://docs.rs-online.com/d07c/0900766b80d07d6b.pdf
Tadira SL-860 https://docs.rs-online.com/c107/A700000006543552.pdf
RS PRO https://docs.rs-online.com/dd65/A700000006487651.pdf
Table 7.13: Links to DataSheets

7.2 Analysis
The constrains on the battery resulted in that only batteries with the LTC chemistry is
suitable for the prototype. The specifics presented in the datasheet; see Table 7.13, for
each battery show that the battery’s behavior in the discharge profile and capacity vs. cur-
rent graphs are much similar. The fact that the Saft LS14500 has a capacity of 2600mAh
makes it the most suitable battery to use in the project. The Saft LS14500 datasheet states
the self-discharge rate to less than 1% per year of storage, at 20°C, making it a suitable
option because the device will be switched off the period late autumn to late spring.

37
7.3 Consequences for design
The prototype, needs the ability to change the battery for test reasons. The need to change
the battery enforces the need for a battery holder instead of a soldering option for battery
assembly. The battery holder adds marginally to the device’s size; however, the battery
holder is the most suitable option for the design when using a AA battery. Fig. 7.19
present the Saft LS14500 battery.

Figure 7.19: The Saft LS14500 battery selected to use with the prototype.

38
8 Box Selection
In this chapter, a suitable box for the device is selected to minimize the size and maximize
water protection; see Fig. 8.20. Selecting a suitable Ingress Protection(IP) for protection
and gathering the dimensions for each component in the device. One requirement for
the prototype is reducing the size comparing to the existing prototype. Size and water
protection are essential requirements for selecting a suitable box to protect the device,
Req1 and Req5; see section 1.3.

8.1 Box

RS PRO ABS Enclosure, Light Grey, IP66

Box size Result

calculation
and selection

98mm 64mm

Figure 8.20: A box is selected from calculations made on the dimensions of the compo-
nents to be placed inside.

For a suitable box that will be placed in soil and be exposed to water, IP rated enclosure
needs to be a minimum of IP66 [40]. The Firebeetle is the MCU desired to use for the
prototype but has not arrived when box selection needs to be completed. Therefore the
box is intended to be a suitable choice for both the LoPy4 and the Firebeetle. The main
difference for a box selection between the two MCU’s is the space needed inside the box
for updating the MCU. Because it is a prototype, it is a high possibility that the MCU
36.4mm

needs to be updated over USB. The LoPy4 can be removed more manageable because it
is connected with U.FL and wire to the antenna. The RAK811 used with the Firebeetle is
connected with a Straight Edge Mount(SMA) to the antenna, making it less manageable
to remove. Because of the difficulties with removing the RAK811, space needs to be
added to insert a USB cable, adding the ability to update the MCU without removing it
from the box. The space needed for inserting a USB cable is 30-40mm.
Dimensions for the parts selected for the device with LoPy4:

• LoPy4: 55x20x3.5mm
• Battery: 55x20mm

Dimensions for the parts selected for the device with FireBeetle:

• Firebeetle: 58x28x3.5mm
• RAK811: 42x25x6.35mm
• Battery: 55x20mm

With these dimensions, a suitable box dimensions need to be approximate:

• Length: 100mm

39
 • Width: 40mm
• Height: 35mm
A search at the retailers within the scope of the project; see section 1.4, using the
information gathered for a suitable box. One box matches the given dimensions and IP
requirement; RS PRO ABS Enclosure, Light Grey, IP66 with dimensions:
• Length: 98mm
• Width: 64mm
• Height: 36.4mm
The size of the existing box is 158x90x60mm giving it a volume of 853200mm3 ; see
equation (2):
158mm ∗ 90mm ∗ 60mm = 853200mm3 (2)
The size of the box selected for the prototype is 98x64x36.4mm giving it a volume of
228300.8mm3 ; see equation (3)
98mm ∗ 64mm ∗ 36.4mm = 228300.8mm3 (3)
Giving a volume reduction of 73.2%; see equation (4)
853200 − 228300.8
∗ 100 = 73.2% (4)
853200
Fig. 8.21 present the existing prototype next to the box selected for the new prototype.

Figure 8.21: Existing prototype (left) next to the box selected (right) for the new proto-
type.

40
9 Analysis
The average current of 19.7µA for when the device is in sleep mode makes the LoPy4 a
much suitable MCU to use for an IoT application that spends most of its time in sleep
mode. Calculations in chapter 7 present the device to be in sleep mode 99.94% of a
twenty-four-hour period when the highest rate(10) uplinks and downlinks are transmitted.
The active time of 50 seconds and the average current consumption of 19.7µA, using the
battery Saft LS14500; see chapter 7, will provide the device with an estimated battery life
of ten years. Ten years are much above the device’s expected lifetime because the device
is a prototype.

Current measurements performed on the Raspberry Pi Pico (pico) with the pico run-
ning a MicroPython script and a C implementation for sleep mode showed that the pico
using just MicroPython does not enter sleep mode. The C implementations bring the pico
down in current consumption significantly. The sleep implementation hello_sleep was
measured to a sleep current of 1.7mA, giving the pico an estimated battery lifetime of
2.1 months. Even if 2.1 months is not good enough for this project, it could be for other
projects where a cheap and small MCU is desired for a short period of testing.

The library implemented for integration between an MCU, and the LoRa module
RAK811 is implemented using MicroPython. For it to be helpful for an IoT product, a
sleep mode function needs to be implemented. Implementing a sleep mode function writ-
ten in C into the MicroPython library and running the library on the FireBeetle ESP32
could outperform the LoPy4 in deep sleep power consumption. The Firebeetle with a
deep sleep measurement of 11µA; see table 4.6 vs. the LoPy4 with 19.7µA measured; see
Table 4.10. The possibility to implement the deep sleep for the Firebeetle will be future
work.

The total price for a prototype with the components LoPy4, Pycom LoRa antenna, soil
sensor DFRobot SEN0193, Saft LS14500 with AA battery holder, and the box RS PRO
IP66 is 922.89 SEK. The total price for the existing prototype is 1011,41 SEK; see section
3.2.6. Resulting in a price reduction compared with the existing prototype of 8.8%; see
equation 5.
1011, 41 − 922.89
∗ 100 = 8.8% (5)
1011, 41
The total price for a prototype with the components Firebeetle ESP32, RAK811, soil
sensor DFRobot SEN0193, Saft LS14500 with AA battery holder, and the box RS PRO
ABS Enclosure, Light Grey, IP66 is 550.23 SEK; see section 3.2.6. Resulting in a price
reduction compared with the existing prototype of 45.6%; see equation 6.
1011, 41 − 550, 23
∗ 100 = 45.6% (6)
1011, 41

41
10 Discussion
Three problem with the previous design was the size, cost, and power efficiency. Three
essential requirements for the prototype produced in this project are reducing the size,
cost, and power consumption, concerning all requirements stated in section 1.3. Using
the methods described in chapter 3, the prototypes MCU, LoRa module, battery, and box
could be selected and meet the project’s requirements. The prototype’s low cost and power
consumption aligned with Mekki et al. [8] and Olson and Finnsson’s [10] conclusion; Lo-
RaWAN is a much suitable network for IoT applications with a significant amount of idle
time, a few bytes of data per transmission over a long distance, and while the cost per
device can be kept relatively low compared to other Network options.

The use of strictly MicroPython on the pico board was shown to be a bad design
decision. The lack of possibilities to bring the pico to a sleep mode with low power con-
sumption makes the language much unsuitable to use for an IoT project on its own. A
low-level language like C needs to be used to receive a low power consumption during a
sleep mode. However, integrating a LoRa module with the pico, using a more high-level
language as MicroPython, is desirable. MicroPython provides data structures such as
lists and dictionaries. With C, using such data structures is much more time-consuming.
Luckily MicroPython is implemented using C, and C functions can be called. This opens
up possibilities to implement a sleep function in the C language and the LoRa module
with MicroPython, calling the C function when going to a sleep mode. Possibilities to
implement such a solution will be future work.

The second iteration of selecting a suitable MCU to use for the prototype resulted in
deciding to exclude or include the expansion board 3.1. Including the expansion board 3.1
will negatively affect the power consumption. The main reason to include the expansion
board 3.1 is to update code quickly and include other sensors, excluding the expansion
board 3.1 will reduce the size, cost, and power consumption. Soldering wires to the top
of the headers on the LoPy4, expansion board 3.1 can still be used when USB access is
needed, without including it in the prototype.

Methods used to reduce size have successfully reduced the box size by 73.2%; see
chapter 8. The significant size reduction will produce more opportunities for on-sight
positioning and make the prototype a possible option to consider as part of the IoT appli-
cations and smart farming discussed by Boursianis et al. [9]

42
11 Conclusion
In this report, an IoT prototype for measuring soil moisture using a low-cost and energy-
efficient microcontroller has been improved. The project has aimed to improve an existing
prototype included in an IoT application communicating using LoRaWAN. To be able
to improve the prototype, a better understanding of LoRa and LoRaWAN was needed.
Therefore, the Theory; see section 2, has an extensive focus on these technologies. Using
the method, Design science, a microcontroller, LoRa module, battery, and a box meeting
the project’s requirements; see section 1.3, have been selected, which improved the size,
the cost, and the battery life significantly.

The LoPy4 does have a LoRa module integrated, and the LoRa module selected; see
section 5, is redundant for a prototype using the LoPy4. However, the Raspberry Pi Pico
and the Firebeetle ESP32 need a LoRa module to communicate with LoRaWAN. Possi-
bilities to bring an MCU to a sleep mode using MicroPython and a C implementation are
discovered during the project. The module selected, the RAK811 will be used in future
work where the MicroPython library [1] implemented in this project will be used.

Compared with the existing prototype when using LoPy4 without expanding board
3.1 as the microcontroller, the price decrease is 8.8%. A prototype using the Firebeetle
ESP32 and the RAK811 has a price decrease compared with the existing prototype of
45.6%. In addition, the box’s volume has decreased by 73.2% compared to the existing
prototype and the power consumption by 81.78%.

11.1 Future work

The LoPy4 is a well-suited microcontroller; however, the desired microcontroller for the
prototype is the Firebeetle ESP32. The Firebeetle ESP32 has a lower price and lower
power consumption, according to he analysis performed by DiyIOt; see section 4.3. Fu-
ture work would be to perform current measurements on the Firebeetle ESP32 and imple-
ment integration with the RAK811 together with a sleep mode implemented in C.

The main focus for this report has been on selecting suitable hardware to use with
LoRaWAN, how to increase battery life and protection for the device. Future work would
explore types of sensors the microcontroller can be integrated with and if the sensors can
have any relevant value aligned with the soil moisture value.

43
References
[1] makjohansson, “Pico_lorawan,” 2021. [Online]. Available: https://github.com/
makjohansson/Pico_LoRaWAN [Accessed: 2021-06-23]

[2] UN, D. of Economic, and S. Affairs, “2018 revision of world urbaniza-

tion prospects,” 2018. [Online]. Available: https://www.un.org/development/
desa/publications/2018-revision-of-world-urbanization-prospects.html [Accessed:
2021-04-01]

[3] T. hoon Kim, C. Ramos, and S. Mohammed, “Smart city and iot,” Future
Generation Computer Systems, vol. 76, pp. 159–162, 2017. [Online]. Available:
https://www.sciencedirect.com/science/article/pii/S0167739X17305253

[4] Sensefarm, “Soil moisture sensor,” 2021. [Online]. Available: https://www.

sensefarm.com/products/soil-moisture-sensor/ [Accessed: 2021-06-12]

[5] Shawn, “Soil moisture sensor – getting started with arduino,”

2020. [Online]. Available: https://www.seeedstudio.com/blog/2020/01/
10/what-is-soil-moisture-sensor-and-simple-arduino-tutorial-to-get-started/ [Ac-
cessed: 2021-06-12]

[6] D. Gupta, “Capacitive v/s resistive soil moisture sen-

sor,” 2018. [Online]. Available: https://www.hackster.io/devashish-gupta/
capacitive-v-s-resistive-soil-moisture-sensor-e241f2 [Accessed: 2021-06-12]

[7] SoilScout, “Soil moisture sensor.” [Online]. Available: https://soilscout.com/

solution/wireless-soil-moisture-sensor [Accessed: 2021-06-12]

[8] K. Mekki, E. Bajic, F. Chaxel, and F. Meyer, “A comparative study of lpwan

technologies for large-scale iot deployment,” ICT Express, vol. 5, no. 1, pp.
1–7, 2019. [Online]. Available: https://www.sciencedirect.com/science/article/pii/
S2405959517302953

[9] A. D. Boursianis, M. S. Papadopoulou, P. Diamantoulakis, A. Liopa-Tsakalidi,

P. Barouchas, G. Salahas, G. Karagiannidis, S. Wan, and S. K. Goudos, “Internet
of things (iot) and agricultural unmanned aerial vehicles (uavs) in smart farming:
A comprehensive review,” Internet of Things, p. 100187, 2020. [Online]. Available:
https://www.sciencedirect.com/science/article/pii/S2542660520300238

[10] K. Olsson and S. Finnsson, “Exploring lora and lorawan a suitable protocol for iot
weather stations?” Chalmers University of Technology, 2017.

[11] P. San Cheong, J. Bergs, C. Hawinkel, and J. Famaey, “Comparison of lorawan

classes and their power consumption,” pp. 1–6, 2017.

[12] Semtech, “Lora and lorawan: A technical overview,” p. 1, 2020. [On-

line]. Available: https://lora-developers.semtech.com/uploads/documents/files/
LoRa_and_LoRaWAN-A_Tech_Overview-Downloadable.pdf

[13] ——, “Lora and lorawan: A technical overview,” pp. 5–7, 2020. [On-
line]. Available: https://lora-developers.semtech.com/uploads/documents/files/
LoRa_and_LoRaWAN-A_Tech_Overview-Downloadable.pdf

44
[14] R. Choi, S. Lee, and S. Lee, “Reliability improvement of lora with arq and relay
node,” Symmetry, vol. 12, p. 552, 04 2020.

[15] Semtech, “Lora and lorawan: A technical overview,” p. 10, 2020. [On-
line]. Available: https://lora-developers.semtech.com/uploads/documents/files/
LoRa_and_LoRaWAN-A_Tech_Overview-Downloadable.pdf

[16] A. by the LoRa Alliance Technical Committee Regional Parameters Workgroup,

RP002-1.0.0 LoRaWAN® Regional Parameters, 2019.

[17] Semtech, “Lora and lorawan: A technical overview,” pp. 7–8, 2020.
[Online]. Available: https://lora-developers.semtech.com/uploads/documents/files/
LoRa_and_LoRaWAN-A_Tech_Overview-Downloadable.pdf

[18] “Electromagnetic compatibility and Radio spectrum Matters (ERM); Short Range
Devices (SRD); Radio equipment to be used in the 25 MHz to 1 000 MHz frequency
range with power levels ranging up to 500 mW,” ETSI EN 300 220-1 V2.4.1, 2012.

[19] Semtech, “Lora and lorawan: A technical overview,” pp. 10–11, 2020.
[Online]. Available: https://lora-developers.semtech.com/uploads/documents/files/
LoRa_and_LoRaWAN-A_Tech_Overview-Downloadable.pdf

[20] ——, “Lora and lorawan: A technical overview,” p. 20, 2020. [On-
line]. Available: https://lora-developers.semtech.com/uploads/documents/files/
LoRa_and_LoRaWAN-A_Tech_Overview-Downloadable.pdf

[21] LoRaAlliance, “Lorawan® l2 1.0.4 specification (ts001-1.0.4),” p. 9, 2020.

[22] Semtech, “Lora and lorawan: A technical overview,” pp. 21–23, 2020.
[Online]. Available: https://lora-developers.semtech.com/uploads/documents/files/
LoRa_and_LoRaWAN-A_Tech_Overview-Downloadable.pdf

[23] ——, “Lora and lorawan: A technical overview,” p. 24, 2020. [On-
line]. Available: https://lora-developers.semtech.com/uploads/documents/files/
LoRa_and_LoRaWAN-A_Tech_Overview-Downloadable.pdf

[24] ——, “Lora and lorawan: A technical overview,” p. 18, 2020. [On-
line]. Available: https://lora-developers.semtech.com/uploads/documents/files/
LoRa_and_LoRaWAN-A_Tech_Overview-Downloadable.pdf

[25] LoRaAlliance, “Lorawan® l2 1.0.4 specification (ts001-1.0.4),” pp. 43–47, 2020.

[26] E. Pena and M. G. Legaspi, “Uart: A hardware communication protocol understand-

ing universal asynchronous receiver/transmitter,” AnalogDialogue, vol. 54, no. 4,
2020.

[27] X. Zuo and L. Yaxian, “Low power performance achievement in embedded sys-
tem,” in 2011 2nd International Conference on Artificial Intelligence, Management
Science and Electronic Commerce (AIMSEC), 2011, pp. 4655–4658.

[28] lastengineer, “Insite into esp32 sleep modes and their power con-
sumption,” 2021. [Online]. Available: https://lastminuteengineers.com/
esp32-sleep-modes-power-consumption/ [Accessed: 2021-06-12]

45
[29] espressif, “Ulp coprocessor programming,” 2021. [Online]. Avail-
able: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/ulp.
html [Accessed: 2021-06-12]

[30] ——, “Systemtime,” 2021. [Online]. Available: https://docs.espressif.com/

projects/esp-idf/en/latest/esp32/api-reference/system/system_time.html [Accessed:
2021-06-12]

[31] Paul, “Measure power consumption with otii tool,” 2021.

[Online]. Available: https://www.disk91.com/2019/technology/hardware/
measure-power-consumption-with-otii-tool/ [Accessed: 2021-06-12]

[32] O. Arch, “Otii arch,” 2021. [Online]. Available: https://www.qoitech.com/otii/

[Accessed: 2021-06-12]

[33] ——, “[swedish] tre metoder för att maximera batterilivstiden i

iot-produkter,” 2020. [Online]. Available: https://www.qoitech.com/blog/
swedish-tre-metoder-for-att-maximera-batterilivstiden-i-iot-produkter/ [Accessed:
2021-06-12]

[34] Otii, “Battery life estimator,” 2021. [Online]. Available: https://www.qoitech.com/

help/otii/battery-estimator [Accessed: 2021-06-12]

[35] K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A design science

research methodology for information systems research,” Journal of Management
Information Systems, vol. 24, no. 3, pp. 45–78, 2007.

[36] L. Rothrock and J. Yin, “Integrating compensatory and noncompensatory decision-

making strategies in dynamic task environments,” in Decision Modeling and Behav-
ior in Complex and Uncertain Environments. Springer, 2008, pp. 125–141.

[37] H. J. Einhorn, “The use of nonlinear, noncompensatory models in decision making.”

Psychological bulletin, vol. 73, no. 3, p. 221, 1970.

[38] Otii, “Arc settings,” 2021. [Online]. Available: https://www.qoitech.com/help/otii/

arc-settings/current [Accessed: 2021-06-13]

[39] M. Bluejay, “Your guide to types of household batteries,” 2021. [Online]. Available:
https://michaelbluejay.com/batteries [Accessed: 2021-05-15]

[40] TheEnclosureCompany, “Ip rated enclosures explained,” 2021. [Online]. Available:

https://www.enclosurecompany.com/ip-ratings-explained.php [Accessed: 2021-05-
14]

[41] T. Jorquera, “pico-micropython-lowpower-workaround,” 2021. [Online]. Avail-

able: https://github.com/tomjorquera/pico-micropython-lowpower-workaround
[Accessed: 2021-06-23]

[42] C. David, “Microcontroller tutorials and smart home projects,” 2021. [Online].
Available: https://diyi0t.com [Accessed: 2021-06-23]

[43] ——, “Guide to reduce the esp32 power consumption by 95Available:

https://diyi0t.com/reduce-the-esp32-power-consumption/ [Accessed: 2021-05-08]

46
[44] Pycom, “New v3.1 expansion board firmware: v0.0.11,”
2019. [Online]. Available: https://forum.pycom.io/topic/4336/
new-v3-1-expansion-board-firmware-v0-0-11 [Accessed: 2021-06-14]

[45] L. Alliance, “Certifying lorawan® products,” 2021. [Online]. Available: https:

//lora-alliance.org/lorawan-certification/ [Accessed: 2021-04-22]

[46] rakwireless, “Rak811-breakout-board,” 2021. [Online]. Available: https:

//docs.rakwireless.com/Product-Categories/WisDuo/RAK811-Breakout-Board/
AT-Command-Manual/#lorawan-type-at-command [Accessed: 2021-06-23]

[47] SMHI, “Temperatur,” 2021. [Online]. Available: https://www.smhi.se/data/

meteorologi/temperatur [Accessed: 2021-05-13]

[48] L. Dallas, “March 2012 ggic summary,” 2012. [Online]. Available: https:
//www.globe.gov/web/ggic/overview/previous-iops/march-2012 [Accessed: 2021-
05-12]

[49] TenergyPower, “Battery size chart,” 2021. [Online]. Available: https://power.

tenergy.com/battery-size-chart/ [Accessed: 2021-05-13]

[50] I. Sourmey, “How to select the best battery for your cellular iot de-
vices?” 2020. [Online]. Available: https://www.emnify.com/en/resources/
webinar-recap-how-to-select-the-best-battery-for-your-cellular-iot-devices [Ac-
cessed: 2021-05-12]

[51] J. Sather, “Battery technologies for iot,” Enabling the Internet of Things, pp. 409–
440, 2017.

47