Data Fusion for Reducing Power Consumption in

Arduino-Xbee Wireless Sensor Network Platform

Solahuddin Y. F.

W. Ismail

School of Electrical and Electronic Engineering

Universiti Sains Malaysia
solahuddin21@gmail.com

School of Electrical and Electronic Engineering

Universiti Sains Malaysia
eewidad@usm.my

AbstractData fusion is one of the subsystems in data

aggregation that aims to conserve power consumption by
reducing the size of the transmitted data. The purpose of this
paper is to present a simple data fusion mechanism called local
data differentiation (LDD) for actual implementation in microcontrolled sensor nodes. LDD requires the end node to calculate
the average value of an initially sampled data and afterwards, to
only transmit the difference between the newly collected data
with the average value. Usage of buffer in conjunction with LDD
is also explored and empirical results are shown based on a
hardware prototype to verify the benefit of the proposed method.
The hardware for the test run is based on the Arduino platform
and Xbee modules, as both are very popular in small-scale
research and wireless automation solution.
Index TermsWSN, data aggregation, Arduino, Xbee Series 1

I. INTRODUCTION
WSN has been making strides in recent years as a
monitoring as well as automation solution. However, there still
exist huge issues and challenges in WSN design framework
that are being addressed by the research community in order to
achieve higher efficiency, feasibility and usability. These
challenges are often categorized into power efficiency, data
collection, networking and deployment strategy issues [1]. The
absence of WSN node standardization, save the radio
frequency (RF) spectrum [2], has become a major contribution
factor in the diverseness of WSN design and thereby activeness
of the research community is this particular field of study.
Data aggregation is a process of gathering data from
different nodes to eliminate redundant transmission and
provides compact information to the main node [3]. The aim of
data aggregation is to extend network lifetime by reducing the
transmission time or the size of the transmitted data through the
use of smart algorithms. In general, data aggregation, also
coined as in-network processing, can be categorized into two
distinct subsystems; network protocol and data fusion. The idea
of network wide data aggregation protocol is the cooperation of
spatially and temporally correlated sensor nodes [4] in
diffusing the collected data. Densely deployed nodes would
benefit hugely from this approach and numerous research have
been proposed such as LEECH, HEED and PEGASIS. Data
fusion on the other hand, aims to reduce the size of data
transmitted which can be executed by the sink (cluster

978-1-4799-0059-6/13/$31.00 2014 IEEE.

head/router) or the end node itself. The data size can be cut
down by employing techniques such as mathematical operation
[5] (median, average, moving average, etc.), compression, data
estimation and modeling.
Xbee is a radio module from Digi International and is wellknown for its usage in low-data rate wireless projects.
Generally Xbee can be categorized into two versions, the IEEE
802.15.4 (Series 1) and ZigBee (Series 2 family). The 802.15.4
standard defines the physical (PHY) and medium access
control (MAC) layers and is typically suitable for point-topoint or star connection. However, Series 1 module could also
be upgraded to DigiMesh firmware, a proprietary peer-to-peer
networking that supports dense mesh topology. On the other
hand, the ZigBee specification defines the network and
application layers on top of the 802.15.4 standard and thereby
allows wider network deployment such as mesh, star and tree
topologies.
The beauty of using 802.15.4/ZigBee especially in the
default AT mode is that the PHY and MAC layers frames are
transparent to users. This means that a typical user would not
see the acknowledgement (ACK) frame or the retransmission
of the radio frequency (RF) module including all the actual
bytes sent. Users would instead only witness whether the data
was successfully sent or not, with all the technicalities such as
Carrier Sense Multiple Access - Collision Avoidance (CSMACA) hidden from plain sight and hence offers simpler
interfacing. Extensive information pertaining to understanding
the operation of 802.15.4/ZigBee could be referred to the paper
in [6].
Alternatively, Xbee module can be used in Application
Programming Interface (API) mode which offers higher
functionality such as supporting larger node deployment,
routing and encryption albeit with more complex setup. The
API packet which encapsulates multiple integral protocol
structures such as header and checksum would also result in
larger overhead and hence system design should be duly
implemented to balance the trade-off.
Arduino is an open-source hardware prototyping platform
based on the Atmel Atmega microcontroller known for its
simplified electronics and rapid prototyping. Since several
years ago, Arduino, along with MSP430 and the more powerful
Raspberry Pi and BeagleBone, are becoming the mainstay in
hardware prototyping, which greatly ease device development.

Nevertheless, Arduino has excellent community support and its

open-source specification (together with all the different
versions) makes it suitable for small-scale and experimental
projects.
In this paper, we present a simple technique of data fusion
for the end node and provide experimental evidence of the
improvement brought by the proposed method using Xbee
modules in Arduino platform. In addition, we also discuss
limitations of present data fusion techniques found in the
literature when applied in actual hardware, particularly with the
Xbee-Arduino combination.
The rest of this paper is organized as follows: In Section II,
we briefly discuss on the works that have been done on data
fusion. Here, we also mention plausible issues related to the
implementation of data fusion techniques beyond conceptual
scope. Section III is where the methodology of our work is
defined. Discussion and analysis are carried out in Section IV
while Section V marks the conclusion of our work.
II. RELATED WORK
A. Data fusion techniques
[3], [7] & [8] provide insights on many data aggregation
methods. Most data aggregation research is focused on
network-holistic approach as it is evidently crucial that
managing entire network components is essential in ensuring
operational longevity. A simpler side of data aggregation is
data fusion. In particular, data fusion can be further broken
down to compression, prediction and modeling mechanism.
Data compression is a relatively trivial method but often
couldnt be implemented effectively in WSN due to design
requirement and limitation. In [9], the authors have discussed
works based on temporal and spatial data compression where
the former uses lightweight linear approach while the latter
uses direct techniques to reduce redundancy. Further add [8] semantic correlation, lossless and lossy compression, duplicate
and non-duplicate information sensitivity into the
categorization.
Modeling, prediction, estimation and forecasting are of the
same group of lossy data reduction approach. Modeling
attempts to represent the data using mathematical equation and
only important parameters or coefficients are transmitted,
instead of the raw data. Prediction technique is essentially the
same as modeling where data pattern are correlated in
mathematical formulation. For instance, the Kalman filter is a
model which is based on prior knowledge for searching
optimal estimation.
Integration is also another form of data fusion. Some data
can be merged (compressed) into a single frame given that the
data type is the same and thereby reducing the number of
frames sent [8]. In the case such that the data is of different
forms (for example, temperature and pressure), these
information can still be sent in different slots within a single
frame.
B. Data fusion implementation issues
In this subsection we discuss the problems of data fusion in
view with a typical Arduino-Xbee setup to represent traditional

microcontroller-RF module operation. Both Arduino and Xbee

format every data in octet (1 byte) size. This means that all
Arduino serial input/output command or Xbee AT and API
frame would be represented by a basic data size of 8 bits. For
example, if a sensor generates a single data bit 1 to represent
an ON mode, this would later be formatted as a bit stream of
00000001 by the microcontroller, passed to the RF module,
usually
through
the
Universal
Asynchronous
Receiver/Transmitter (UART) and encapsulated into the MAC
and PHY frame which is no less than 7 bytes in size. If API
mode is used, the overall frame size would even be larger as
even a simple API ACK frame is typically 10 bytes in size
before insertion into the eventual PHY frame (not to be
confused with the 802.15.4/ZigBee transparent ACK frame
which is 11 bytes in size). With this information in mind, we
can see that data fusion should not only be discussed at the
application layer, which is just the surface of the OSI model.
A common problem with any type of data prediction is that
pinpoint accuracy is not guaranteed. A three consecutively
incremented sensor data does not guarantee that the fourth data
would register another increment. In fact, there is a higher
probability that the data would hold on to the previous value or
decrement especially for highly sensitive sensors.
Implementation wise, both end node and the sink must be able
to indicate that the next data would be predicted. However,
unless both ends have sophisticated arrangement, a simple
indicator would still take a byte size that would later be
encapsulated in a PHY frame. Similar problems are
encountered in modeling mechanism where every parameter or
coefficient would be formatted in byte size. A smart way
around this has been proposed, for example, by [10] which
utilizes least-mean-square (LMS) adaptive algorithm; if the
sensed data does not fall outside the boundary set, no data is
transmitted which would be understood by the sink as a data
which obeys the predicted model. The downside is that a lost
message will still be interpreted by the sink as a valid data
generated by the algorithm and any indication of
acknowledgment or error checking would incur bytes of
transmission. On the contrary, simple data averaging and
moving average may provide a good balance between precision
and packet size while still remaining simple for
implementation. Nevertheless, special attention should be
given when dealing with burst and infrequent sampling as to
retain an acceptable level of data accuracy.
III. METHODOLOGY
Figure 1 shows the flowchart of the proposed buffered LDD
data fusion. During node initialization, the end node will
collect the average data from N samples and transmit the
information to the main node. After, the node will iterate the
section within the dashed rounded rectangle as in Figure 1
based on the sampling rate. This section is devised to collect n
samples within a short period of time to increase data accuracy.
Conventional sampling only gathers a single data from the
sensor, for example, once in a minute. We propose that n
samples are collected every time the sensor is activated for
sampling. In this study, we collect 5 samples within a little over

5 seconds every 1 minute for both sensors. The average is then

calculated and stored within the buffer. When the buffer size
reaches 4, the LDD data is transmitted to the main node. To get
the actual values, the main node only needs to add LDD with A
value after parsing the data. If a new average measurement, A
is needed, the node can simply reinitiate the averaging process
and update the main node accordingly.

Arguably, the sleep modes for both microcontroller and RF

module should never be neglected for power consumption
efficiency but this feature is not covered here because it neither
affects the algorithm nor being the aim of our study.
Apparently, we have used the most basic setup to get our
system up and running as simple as possible. The size of data
sent by the sensor node with and without LDD (MAC & PHY
frame size are disregarded) are verified in X-CTUs terminal
tab.

Collect N samples

Calculate average, A from N

samples

Sensor
measurement, S

LDD += (S A)

LDD loop
= 5?

No

Yes
Store LDD value
in buffer, B

B size = 4?
No

Yes

Fig. 2: Arduino-Xbee prototype with attached sensors

We employ two types of sensors on the sensor node, the

DHT11 and HC-SR04 to generate the data. The former is an
integrated humidity and temperature sensor while the latter is
an ultrasonic ranging module. The DHT11 reports data in
relative humidity (RH) level and temperature in Celsius
whereas the HC-SR04 measures distance in centimeters by
sending 8 cycles of 40 kHz ultrasonic burst. We format the data
for both sensors as double type with 1 precision point.
IV. ANALYSIS AND DISCUSSION

Transmit data
from buffer, B to
sink/main node

Fig. 1: Flowchart of local data differentiation (LDD)

We specifically referred to [11] and [12] for setting up the

Xbee modules with the Arduino board. The hardware setup
uses 3.3 V and is shown in Figure 2. Although unnecessary, we
have upgraded our Freescale Xbee Series 1 modules to
DigiMesh firmware as to automate network addressing.
Transparent (AT) mode was selected for the Xbees to avoid the
complications of handling API packets. We carried out data
analysis in point-to-point setup as it is deemed sufficient to test
our proposed data fusion.

A. Local data differential (LDD)

Any number in excess of 255 requires more than a single
byte to represent it. As such, transmitting a large number might
consume a few bytes even without counting in the precision
points. As a general rule, the total time taken to transmit 1 byte
of data is 32 s without factoring in CSMA-CA, retries and
ACK [13]. Larger data size would contribute to longer Xbee
transmit and receive phases (sleep & node synchronization are
another matter) and resulted in higher power usage. Obviously,
to an extent, LDD can help reduce unnecessary power
consumption as will be presented in this section.
All the generated data will be queued up at the Xbee
transmit buffer for transmission. Our focus is to reduce the data
size which in turn directly affects transmission time (transmit
and receive) and power consumption. By default, serial.print( )
is the command used in Arduino to send data through the local
Xbee to the remote RF module regardless of AT or API mode
(including the commonly used Xbee-Arduino API library by

Andrew Rapp). This command sends data in ASCII format and

thus every single digit, symbol or character would take a byte
size. Table 1 shows the data size received with respect to the
commands used. Serial.println ( ) formats each data at the
output in a new line and therefore would append 2 additional
bytes for carriage return and line feed. Alternatively,
Serial.write ( ) can also be used to send the data but some
problems may be created while using the command. For
instance, Serial.write ( ) could not send float data type and
negative numbers would be presented in 2s complement form.
Although there are ways to overcome these problems (for
example, doing multiplication to eradicate precision points
before data transmission), Serial.write ( ) is not the first option
as it may add design complexity especially if dealing with API
mode.

The current consumption and data transmission time from

the UART to the Xbee module are obtained using a digital
multimeter and oscilloscope respectively. The Arduino board
(with Xbee shield attached) draws around 30.9mA whilst the
Xbee module consumes around 40.6 mA (transmit power level
4) in active mode. The oscilloscope measurements are shown
in Figure 4 and 5 for LDD and non-LDD implementation
respectively. Evidently, it would take about 1 ms for each byte
to be sent to the RF module from the microcontroller. Note that
the double vertical lines in both figures are the cursors meant to
measure the time period of the data (12.5 ms and 13.55 ms for
LDD and non-LDD respectively).

TABLE I. COMMAND LINE VERSUS DATA SIZE

Command

Data

Size (bytes)

Serial.print ( )

41.0

Serial.print ( )

41

Serial.print ( )

2.6

Serial.print ( )

-2.6

Serial.println ( )

3.3

Serial.write ( )

256

Hello

Serial.write ( ) / Serial.print ( )

Figure 3 shows the cumulative bytes obtained at the sink

from 30 minutes of data collection from both sensors. In our
test, there are many situations where utilizing LDD allows 1 to
2 bytes of data size reduction for each sampling compared to
non-LDD system. For example, if the temperature remains the
same in a period of time, thus the LDD data that is transmitted
is 0.0 (3 bytes) compared to non-LDD which would send the
average data in raw form (4 bytes). From this half an hour
runtime, as much as 5.83% data reduction is achieved. In the
long run, the effect of LDD can become more obvious but may
also be heuristic.

Fig. 4: 12 bytes of LDD data sent from Arduino to Xbee module

Fig. 5: 13 bytes of non-LDD data sent from Arduino to Xbee module

The calculation for the transmission time has been given in

[14] for 802.15.4 / ZigBee as:

ttrans ( n ) =

Fig. 3: Local data differentiation (LDD) versus non-LDD

8 (31 + n)
r

(1)

where n is the payload size in bytes, r is the binary rate of 250

kbps operating at 2.4 GHz with QPSK modulation while the
packet overhead is 31 bytes. Thus, in our setup, ttrans(12) = 1.376
ms and ttrans(13) = 1.408 ms for LDD and non-LDD mode
respectively.
Another experiment was conducted to investigate the
performance of LDD compared with other methods. The
DHT11 module was used to measure the daytime temperature
every 10 minutes from 8 am until 7 pm, which would produce

a bell shape-like graph, while the Arduino UNO board

remained in use for programming all the related algorithms.
The results are shown in Table II.

Accumulated
data (bytes)

Compression
achieved (%)

Total energy
(Ws)

396

0.0105

We have presented a simple yet beneficial data fusion

method that helps reduce data size. The analysis conducted
shows that LDD, although at times being heuristic, is feasible
for implementation beyond theoretical concept. By employing
LDD, data size can be reduced which in turn results in shorter
transmission time and hence, reduced power consumption.
Usage of buffer in conjunction with LDD also contributes to
power saving by eliminating additional listening phases at the
RF module, without any loss of data.

330

16.67%

0.0102

ACKNOWLEDGMENT

384

3.03%

0.0104

The authors would like to thank Malaysia Ministry of

Higher Education (LRGS fund) for sponsoring the research and
development of this project. Also, special appreciation to Prof.
Dr. Mohamad Kamal Abdul Rahim from Universiti Teknologi
Malaysia, head of the LRGS project and Associate Professor
Dr. Alyani Ismail, Universiti Putra Malaysia for the support.

TABLE II. PERFORMANCE COMPARISON BETWEEN LDD WITH OTHER

METHODS

Single hop, single precision point, using serial.println ( ), initialization

data omitted, buffer disabled, Xbee transmit power = 40.6 mA
Method

Without data fusion

(control group)
LDD
2nd order polynomial
modeling

V. CONCLUSION

n-coefficient
modeling

5n x 66

Averaging

396

None (data
size larger
than control
group)
0

Prediction/Forecasting

396

> 0.0105
0.0105
0.0105

REFERENCES
LDD recorded the highest compression percentage while
most other techniques were not able to achieve any
compression. In all fairness, this is due to LDD being deployed
at the end node, where the strategy pays off, whereas other
methods could not provide any benefit without involving
additional setup. The calculations for total energy used can
simply be done using basic formulas of power, energy and
equation 1.
Although the difference seems meager for a single hop
transmission, again, the benefit of LDD would become more
obvious in prolonged operation, retransmission and multi-hop.
B. Buffer
The maximum payload that an Xbee buffer can allocate for
802.15.4 and ZigBee is 100 and 72 bytes respectively. The
benefit of buffer is that multiple sensor readings can be inserted
into the same frame for a single transmission session as long as
buffer overflow is avoided. [15] shows that the current spike
for a ZigBee power up consumes 5 to 10 times in magnitude
than during normal operation. Hence, buffer should be used to
transmit as many data as possible in tolerable interval with
minimum RF module activation.
The current consumption of a buffered LDD as indicated in
Figure 1 would be:
Ibuffer = tlisten Ilisten + ttrans(n) Itrans

(2)

A non-buffered LDD would therefore incur 4 more times the

listening period while the total transmission time is the same
for both cases based on equation 1. In a system where sleep
mode is implemented, factors such as RF module and
microcontroller activation current and time, node discovery
phase and sleep initialization would definitely add more
overhead to the system, resulting in higher power consumption
due to longer active operation.

[1] S. Rhee, D. Seetharam, and S. Liu, Techniques for Minimizing

Power Consumption in Low Data-Rate Wireless Sensor
Networks, IEEE Wireless Communications and Networking
Conference, vol. 3, pp. 1727-1731, 2004.
[2] J. A. Aguirre, N. Gaviria, and J. E. Aedo, Data Collection and
Signal Processing Strategy for Low Power Consumption in
Wireless Sensor Networks Nodes, IEEE Latin-American
Conference On Communications, 2009.
[3] R. Rajagopalan and P. K. Varshney, Data Aggregation
Techniques in Sensor Networks: A Survey, IEEE
Communication Surveys & Tutorials, vol. 8, issue 4, pp. 48-63,
2006.
[4] C. Wang, H. Ma, Y. He, and S. Xiong, Adaptive Approximate
Data Collection for Wireless Sensor Network, IEEE
Transactions on Parallel and Distributed Systems, vol. 23, no. 6,
pp. 1004-1016, 2012.
[5] P. Ghaffariyan, An Effective Data Aggregation Mechanism for
Wireless Sensor Networks, 6th International Conference on
Wireless Communications Networking and Mobile Computing,
2010.
[6] S. C. Ergen. ZigBee/IEEE 802.15.4 Summary, 2004. Retrieved
from staff.ustc.edu.cn/~ustcsse/papers /SR10.ZigBee.pdf
[7] V. K. Sachan, S. A. Imam, and M. T. Beg, Energy-efficient
Communication Methods in Wireless Sensor Network: A
Critical Review, International Journal of Computer
Applications, vol. 39, no. 17, pp. 35-48, 2012.
[8] E. Fasolo, M. Rossi, J. Widmer, and M. Zorzi, In-Network
Aggregation Techniques for Wireless Sensor Networks: A
Survey, IEEE Wireless Communications, vol. 14, issue 2, pp.
70-87, 2007.
[9] C. Cappielo and F. A. Schreiber, Quality- and Energy- Aware
Data Compression by Aggregation in WSN Data Streams,
IEEE International Conference on Pervasive Computing and
Communications, 2009.
[10] S. Santini and K. Romer, An Adaptive Strategy for Qualitybased Data Reduction in Wireless Sensor Networks,
Proceedings of the 3rd International Conference on Networked
Sensing Systems, 2006.

[11] R. Faludi, Building Wireless Sensor Networks, First Edition,

OReilly Media Inc., USA, 2010.
[12] J. Blum, Exploring Arduino : Tools and Techniques for
Engineering Wizardry, John Wiley & Sons, Inc., USA, 2013.
[13] Digi International. Sending data through and 802.15.4 network
latency timing. Retrieved from: http://www.digi.com/
support/kbase/kbaseresultdetl?id=3065

[14] R. Piyare and S. -r. Lee, Performance Analysis of Xbee ZB

Module Based Wireless Sensor Networks, International Journal
of Scientific and Engineering Research, vol. 4, issue 4, pp.
1615-1621, 2013.
[15] J. Song and Y. K. Tan, Energy Consumption Analysis of
ZigBee-based Energy Harvesting Wireless Sensor Network,
IEEE International Conference on Communication Systems
(ICCS), 2012.