Abstract—MEMS inertial modules are powerful and
versatile converging technologies: mechanical and electronic functions are
merged into a single component, ready to offer physical data to users about the
environment (through wearables or equipment on which a sensor is mounted). In
recent years, drastic reduction in the power consumption of inertial sensors
has opened the door to a new world of applications. IoT is certainly one, but
not the only example of what can be achieved using battery-operated devices. This
technology is ubiquitous and innovative smart sensors, able to further reduce
energy consumption and recognize and interpret their environment autonomously,
are on the horizon. New sensors are able to provide the application with the
right feedback precisely when the application needs it. This paper introduces a
programmable and configurable embedded digital module which further reduces
system power consumption, moving part of the intelligence into the sensor, and
thus keeping the main processor in sleep mode. The digital module is composed of
two embedded reconfigurable blocks able to solve two main sets of application
requirements. The first block has been developed for systematic motion
recognition using a reconfigurable Finite State Machine; application examples
are motion/no-motion, human gesture and industrial applications. The second block
has been developed for statistical-based context awareness; using a decision-tree
approach it is possible to perform human activity recognition (stillness, walking,
vehicle motion, etc.), carry-position detection (on wrist, in pocket, on table,
etc.) and machine activity and movement recognition. These two blocks can be
programmed and mutually concatenated by using a simple GUI running on a common
PC to exploit the full configurability of the digital module and to meet user
needs easily, quickly and effectively. The embedded digital module allows
moving all or part of the algorithm elaboration to a custom, low-power
environment on the sensor side, reducing communication to the main processor,
and thus reducing overall power consumption.

Index Terms— MEMS, smart
sensor, sensor networks, low power, autonomous system, embedded algorithms, gesture
recognition, context awareness, machine learning, decision tree, IoT.

I. Introduction

During the past 10 years, the number of IoT applications
has increased exponentially. Most of IoT applications involve measuring a
physical quantity in a location that may not already have a power source
available. It’s often not feasible to add wiring, so a battery solution is a
preferred option, and wireless connectivity for data transmission is a must. At
a minimum, the IoT application needs a sensor to get data, a medium over which
to transmit and a battery to supply power to both operations. In a design of this
type at this point a trade-off is needed: maximize battery life or frequency of
data transmission?

A key tool available to the application designer to manage
this trade-off is an elaboration unit, which can perform the measurements and
transmission effectively and efficiently. The computational unit is usually a general-purpose
microcontroller, targeted for low-power consumption. Since the wireless data
transmission is critical for low power consumption, with respect to the other processes
involved, the strategy in the IoT application design is to move the elaboration
to the IoT side, if the latter allows reducing communication. For example,
let’s suppose that we have to design a healthcare product which sounds an alarm
when the standard deviation of a certain measured parameter is above a certain
threshold. A good design practice choice, considering battery longevity, is to
write the algorithm on the transmitter side in order to limit the wireless
transmission just during the alarm event.

 

The objective of this paper is to introduce a new step in
the reduction of product power consumption thanks to innovative sensors. The new
inertial module LSM6DSOX from STMicroelectronics allows moving all or part of
the algorithm elaboration to a custom low-power environment in the sensor. The broad
configurability of this approach guarantees a wide spectrum of applications.
This paper is organized as follows: the first section will show the innovative
creativity beyond the embedded algorithms and the advantages in an applicative
case example. Two sections are dedicated to the description of the embedded
algorithms description. The last section is dedicated to custom support
software which is user-friendly and can be rapidly adapted to the creation of
new applications.

 

II. Embedded Algorithms Scenario

As introduced in the previous section, a simple model of
an IoT application is composed of a transmitter/receiver apparatus, an
elaboration unit, actuators or sensors connected to the elaboration unit, and a
battery. In order to show the advantages of embedded algorithms on the sensor side,
we’ll introduce an application use case. Although we provide an example, the
subject can be easily extended to many other use cases.

The analyzed
use case is a smart-bracelet able to perform user-activity recognition, and give
a feedback on it: how long the user has walked, has been in a vehicle, etc. Of
course the smart-bracelet should give the date and time to the user, prompted
by a wrist-tilt gesture. A key component to perform both transmission and elaboration
is a Bluetooth low-energy system-on-chip[4].
This solution embeds a complete Bluetooth network processor and an elaboration
unit for running application code. The elaboration unit is composed of a
low-power microcontroller, NVM memory for user programs, memories for data and
programming (mirror of NVM) and common interfaces (SPI, I²C, etc.). With this
kind of solution, the application is able to read/write to the sensor and
actuators from the interfaces, execute an algorithm computation and connect to
an end component (computer/smartphone) by means of Bluetooth communication
protocol. A rough power budget of this solution can be estimated from the
following proposed system example. The
“smart” Bluetooth module with embedded microcontroller in general has different
power modes. The most common modes are listed below:

a)  
Sleep mode: this mode is used to
minimize power consumption by turning off or putting most of the internal
blocks in low-power conditions. In sleep mode an interrupt is monitored for
waking up, or an internal RTZ can be used. Plenty of options can be configured
for blocks in the system in this mode. Exiting from this mode requires some
time to regain full operative mode (0.5-2 ms). Current consumption of this mode
is in the 0.5-2 µA range.

b)  
Microcontroller active mode: radio transmitter/receiver
off, microcontroller fully-active elaborating. Current consumption range of
this mode is 1-3 mA.

c)  
Radio transmitting/receiving mode: Device
is communicating, power consumption is 3-20 mA.

The present “smart” Bluetooth power consumption values are
just a rough estimation based on the product datasheet, the purpose of this
exercise is to show the advantage of embedding algorithms on the sensor side.
Before making the full computation of current consumption usage in this
smart-bracelet case other useful assumptions must be defined. In the first
place the microcontroller in the smart-Bluetooth module is connected to an
inertial module using an I²C/SPI interface, configured to generate
sensor data at 25 Hz Output Data Rate. The microcontroller exits from sleep-mode,
reads data from the sensor and executes the activity-recognition algorithm every
time a sample is generated using an embedded 16 MHz clock domain. The
high-quality activity-recognition algorithm case requires a mean elaboration
time of 4 ms. The Bluetooth transmission is sporadic on user request (once a
day).

Figure
1: Microcontroller sleep to active timing

Figure 1 shows the timing of the duty cycle of the microcontroller
while running the algorithm. Tstart is the turn-on time of the
microcontroller, Talgo is the execution time of algorithm, Todr
is the time between sensor reads.

A basic formula of the mean of the current I_TOT
containing its main contributors is:

 

I_TOT = I_BUS + I_SLEEP
+ f_{algo *} I_{UCORE *} ( T_start/2 + T_algo
)

 

I_BUS is the current related to interface
bus read; for the SPI bus the contribution should be < 1 µA, in case of I²C the
range is 2-5 µA roughly. The other variables have been already introduced, a
power budget can be estimated for sensor plus microcontroller system, since radio
transmission has been considered negligible due to its sporadic nature.
Considering that the middle of the declared range of each parameter has been
taken, an I_TOT around 230 µA is obtained.

The LSM6DSOx embedded algorithm, reconfigured for
implementing “activity recognition”, requires less than 8 µA. We would like to
point out that we’re referring to the same high quality algorithm with exactly the
same performance as running on a microcontroller. A significant advantage of
the embedded solution is that data is already available inside the component,
so the I_BUS contribution is absent. Another contribution
which is completely missing in the embedded solution is T_start
needed for the safe exiting from the sleep state of the microcontroller. I_TOT
estimation with the two terms T_start and I_BUS
at zero leads to 200 µA which means that, using the same formula f_algo*I_UCORE*T_algo,
the porting from the microcontroller to the sensor leads to a reduction of 25
times less power consumption.

Where does the magic come from? The main consideration
comes from the general-purpose microcontroller versus the application-specific
digital logic. STMicroelectronics has been a pioneer and a leader in inertial
MEMS modules since the beginning of the MEMS era. The ST software library and
customer requests are well known and consolidated, so the strategy has been to
collect and divide the most common application use cases into two sets. The first
set is composed of algorithms well-suited to using a Finite State Machine, the
second set is based on applications which need statistical analysis (based on
pattern analysis) and that can be implemented with a decisional net (tree) in
an effective way. For the two sets, a collection of “metacommands” has
been implemented, in order to cover existing algorithms, and to guarantee wide
re-configurability for new custom requests. At the end of the process
arithmetical analysis has been done with the aim to find the best low-power but
effective arithmetical custom logic. Arithmetic simplification has been done to
tailor to application needs, without impacting algorithm performance. In the
two following sections the two blocks and the metadata are presented.

III. Motion Detection Finite State Machine

The purpose of
the FSM block is to provide tools that allow writing compact programs able to
recognize user gestures. Each gesture requires a specific PROGRAM, thus many programs
can be written and concatenated, making an array of programs named PROGMEM, as
shown in Figure 2, to be processed by an interpreter resident in ROM.

Each program is made of two
parts, a data section and an instructions section. In more detail,
a data section is made of a fixed length part, present in all the programs, and
a variable length part, whose size is specific for each program. Finally, the
instructions section, i.e. the executable part, is made of conditions
and commands, the latter sometimes requiring parameters to be executed.

 

Figure 2: Programs
organization in memory

The gesture recognition
interpreter decodes each instruction of a program’s instructions section and
executes it by operating on data located in the data section.  Each program
recognizing a specific gesture realizes a simple, programmable FSM and it is
totally independent from the other programs.

The instructions section is the
operative part of the FSM. It is made of conditions and commands.
Instructions are also called states. Each condition is coded in one
byte; the highest nibble codes a reset condition, while the lowest
nibble a next condition.

A condition is one line of code.
Any time a program is executed, each condition is evaluated in both its parts,
i.e. reset and next, with this priority. If a reset condition is true,
the code is restarted from the beginning, whereas if a next condition is
true the execution progresses to the next line of code. If neither condition is
true, the next sample is awaited and both conditions are evaluated again later
on.

Inside the fixed data section,
two bytes store respectively the address of the reset instruction and the
address of the current instruction, i.e. the program pointer is updated every time
a next condition is true or forced to the reset address in case a reset
condition is true.

Since a condition is coded over
four bits, a maximum of sixteen different conditions can be coded. There are
four types of conditions, namely timeouts, thresholds comparisons, zero-crossing
detection and decision-tree checks. Timeout conditions are true when a counter,
preset with a timeout value, reaches zero, while threshold comparisons are true
when enabled inputs (such as accelerometer XYZ axes or norm
V = ) are higher (or
lower) than a programmed threshold, zero-crossing detection is true when an
enabled input crosses the zero and decision-tree check condition is true when
the tree result matches the expected result. If the counter has not yet reached
zero or an enabled input is not yet higher (or lower) than a programmed
threshold, or no zero-crossing event has been detected, or the decision-tree
result does not match, then the condition is false and the program pointer is
not updated: when the next input sample arrives, the conditions are evaluated again
until one of the two (reset or next) becomes true.

Figure 3: Example of a
program instruction section

TABLE I.  shows the possible
conditions, TABLE II. shows all the available commands. TABLE III. shows an
example of the instruction section of a PROGRAM, mixing conditions and
commands.

 

TABLE I. Conditions

CONDITION		DESCRIPTION
0x0	NOP	No execution on current sample
0x1	TI1	Timeout 1 expired
0x2	TI2	Timeout 2 expired
0x3	TI3	Timeout 3 expired
0x4	TI4	Timeout 4 expired
0x5	GNTH1	Any triggered axis > THRS1
0x6	GNTH2	Any triggered axis > THRS2
0x7	LNTH1	Any triggered axis  ≤ THRS1
0x8	LNTH2	Any triggered axis ≤ THRS2
0x9	GLTH1	All triggered axis > THRS1
0xA	LLTH1	All triggered axis ≤  THRS1
0xB	GRTH1	Any triggered axis > -THRS1
0xC	LRTH1	Any triggered axis ≤ -THRS1
0xD	PZC	Any triggered axis crossed zero pos. slope
0xE	NZC	Any triggered axis crossed zero neg. slope
0xF	CHKDT	Check result from decision tree vs. expected

 

 

TABLE II. COMMANDS

COMMAND		DESCRIPTION
0x00	STOP	Stop execution and wait for new start
0x11	CONT	Continues execution from reset-point
0x22	CONTREL	Like CONT but reset temporary mask
0x33	SRP	Set reset-point to next address/state
0x44	CRP	Clear reset-point to first program line
0x55	SETP	Set parameter in the program data section
0x66	SELMA	Select MASKA and TMASKA as current mask
0x77	SELMB	Select MASKB and TMASKB as current mask
0x88	SELMC	Select MASKC and TMASKC as current mask
0x99	OUTC	Write the temporary mask in the output register
0xAA	STHR1	Set new value to THRESH1
0xBB	STHR2	Set new value to THRESH2
0xCC	SELTHR1	Select THRESH1 instead of THRESH3
0xDD	SELTHR3	Select THRESH3 instead of THRESH1
0xEE	SISW	Swap sign to opposite in selected mask
0xFF	REL	Reset temporary mask to default
0x12	SSIGN0	Set UNSIGNED comparison mode
0x13	SSIGN1	Set SIGNED comparison mode
0x14	SRTAM0	Do not reset temporary mask after a next condition is true
0x21	SRTAM1	Reset temporary mask after a next condition is true
0x23	SINMUX	Set input multiplexer
0x24	STIMER3	Set new value to TIMER3 register
0x31	STIMER4	Set new value to TIMER4 register
0x32	SWAPMSK	Swap mask selection MASKA <=> MASKB
0x34	INCR	Increase long counter +1
0x41	JMP	Jump address for two Next conditions
0x42	CANGLE	Clear angle
0x43	SMA	Set MASKA and TMASKA
0xDF	SMB	Set MASKB and TMASKB
0xFE	SMC	Set MASKC and TMASKC
0x5B	SCTC0	Clear the Time Counter TC on next condition true
0x7C	SCTC1	Don’t clear the Time Counter TC on next condition true
0xB5	SETR	Set external registers at given address with given data
0xC7	UMSKIT	Unmask interrupt generation when setting OUTS
0xEF	MSKITEQ	Mask interrupt if OUTS does not change
0xF5	MSKIT	Mask interrupt generation when setting OUTS

 

TABLE III. example of a program instruction section

STATE 0	NOP	GNTH1	Go to next state if enabled input is greater than TH1; otherwise wait
STATE 1	LNTH1	TI3	Stay over TH1 for TI3 seconds; if goes down before then restart from STATE 0
STATE 2	OUTC		After TI3 seconds output temporary mask and interrupt
STATE 3	SRP		Set reset pointer to STATE 4
STATE 4	NOP	LNTH1	Go to next state if triggered input is lower than TH1; otherwise wait
STATE 5	GNTH1	TI3	Stay under TH1 for TI3 seconds; if goes up before, then restart from STATE 4
STATE 6	CRP		After TI3 seconds clear reset pointer to STATE0
STATE 7	CONTREL		Output temporary mask and interrupt, reset temporary mask and continue from STATE 0

 

The interpreter decodes instructions
and executes them; actions are based on data stored inside the data section.

Each program realizing an FSM
able to recognize a specific gesture has its own data set. For example the
instructions section in the previous example, in order to properly work, needs
the following data:

–       
Threshold
1 value

–       
Timeout
3 value

–       
Mask
to enable the relevant axis among XYZV to trigger the events

–       
Timer
to count wait times

These are the most commonly
used data, also called resources; however five more data are available
to be declared and used:

–       
Hysteresis
value, to be added/subtracted to/from threshold values when performing
comparisons of the kind “greater than” / ”less than” 

–       
Decimation
mechanism, in case the FSM has to be executed not at every input sample but at
a lower frequency; in these cases two bytes must be reserved, one with the
decimation value and another for the decimation counter

–       
Previous
axis sign PAS, declared and used in case a zero-crossing condition PZC or NZC
is present in the instructions section, to store the previous input sample XYZV
signs

–       
Memory
locations to store gyroscope integrated angles and ODR period duration when
using FSM with such input data

–       
Decision-tree
interface handling

Simpler programs other than the
above examples could use less data, whereas more complex programs could use
more data (i.e. thresholds and/or timeouts and/or masks).

In order to implement an
efficient and effective data-instructions structure, a fixed data section,
present in all the programs, stores information about the amount of resources
to be used by the program. The user must carefully fill it and reserve memory
locations accordingly in the variable data section.

 

Six bytes store information about
the variable-data section and the instructions section:

CONFIG_A: masks, thresholds, long
timeouts, short timeouts

CONFIG_B: decimation, hysteresis,
gyro angles, PAS

SIZE: length in bytes of the
whole program data + instructions

SETTINGS: flags used in the
instruction section processing

PP: program pointer

RP: reset pointer

 

The variable data section
is normally different in size between two FSM programs. It collects all
parameters needed by the program, such as masks (1-3), thresholds (1-3),
timeouts (1-4) etc. The resources in the variable data part are declared in the
CONFIG_A and CONFIG_B bytes belonging to the fixed data part. In this way the
interpreter can easily process the variable data part of a given program knowing
exactly what is stored there owing to the information obtained from the fixed data
part.

Returning to the previous
TABLE III. example, TABLE IV. and TABLE V. show the data section consistent
with the instruction section.

TABLE IV. example of a fixed data part

CONFIG_A	0 1 0 1 0 0 0 1	1 mask, 1 threshold, 1 short timeout
CONFIG_B	0 0 0 0 0 0 0 0	No other resources
SIZE	00010100	20 bytes length
SETTINGS	0 0 0 0 0 0 0 0	No special flags
PP	00000000	Starting value PP
RP	00000000	Starting value RP

TABLE V. example of a variable data part

THRESH1_LSB	00000000	0.5 g accelerometer X+ axis threshold
THRESH1_MSB	00111000
MASKA	10 00 00 00	X+ accelerometer axis mask
TMASKA	00 00 00 00	Temporary mask A
TC	00000000	Timer starting value
TI3	00001111	Timeout3: 15 samples

 

The whole FSM program shown
as an example thus is made of 20 bytes, respectively 12 bytes of data section
(shown in TABLE IV. and TABLE V. ) and 8 bytes of instruction
section (show in TABLE III. ).

 

This 20-byte long, FSM example
program, starting from data coming from a three-axis accelerometer sensor, is
able to detect on/off wrist tilt, useful in case of a smartwatch or fitness bracelet
application.

IV. Machine Learning Processing (MLP)

Finite State Machine, presented in
the previous section, makes use of its own nature of deductive
reasoning: it starts out with a hypothesis, and examines the possibilities to
reach a specific logical state. For motion detection algorithms this implies finding
“rules” to be satisfied in a sequence of events. This approach works with most
gesture detection algorithms, but surely not for all. For example a phone-up to
phone-down gesture algorithm can be solidly based on the fact that the gravity detected
by the accelerometer in the phone is mainly on one axis and will be inverted on
the same axis over a sequence of time. Gesture definition can be changed based
on a few parameters: definition of axis, threshold and time to complete the
sequence. A different motion algorithm like walking detection could hardly be defined
by means of a simple state machine, since the number of variables would
dramatically increase: sensor positioning, frequency, terrain and personal
behavior render the sensed signal widely variable. From the last example it is
possible to extract a more general concept: while phone-up to phone-down
gesture statistical variance on a population is sharp, and allows deductive-reasoning
application design, walking gesture would lead to broad statistical variance
and subsequently deductive-reasoning should be abandoned in favor of inductive
reasoning.

The idea behind Machine Learning Processing is to allow
the implementation on silicon of data-driven algorithms, exploiting the
capability of building a model from input patterns. Over the last decade the
explosion of the Internet and IOT has made available an enormous quantity of
information. Following the increase in quantity of data, tools to manage these
collections of data have been developed, in order to make them effective for
applications. MLP is considered a suitable solution to implement data-driven
algorithms on inertial sensors. MLP is highly reconfigurable, effective in the
field of inertial sensors, implemented in an ultra-low power domain, and
suitable for power-hungry products, for example IOT algorithms.

An important branch of machine learning is data mining:  “data
mining is an interdisciplinary field bringing together techniques from machine
learning, pattern recognition, and statistics" [1][2]
with the aim of knowledge discovery.

The task output of a data-mining tool is a decision tree: the
application design starts from a collection of patterns, and ends with the loading
of the decision tree obtained on the MLP. The entire process of the application
design is supervised by supporting software that is described in the next
section. In the present section the set of basic blocks behind the MLP is
introduced.

The general scheme is illustrated in Figure 4.

 

Figure
4:
MLP General Scheme

For the figure it possible to deduce the boundary between software
and hardware layers. The application starts from patterns of sensor data which
describe the knowledge that MLP has to understand while running. For example an
activity recognition algorithm starts from patterns involving activities to be
recognized (walking, running, moving vehicle, no motion, etc.) with the aim that
MLP outputs the results of the current activity directly from the sensor data. The
user can configure, as inputs for the algorithm, data from up to 3
sensors.  The gyroscope and accelerometer blocks are internal to the
sensor but data from an external sensor such as a magnetometer can be read over
an embedded I²C master. Input sensor data is composed of the axis
and the magnitude of the physical sensor (TABLE VI. ).

TABLE VI.  Input Types for MLP

 

 

A wide set of configurable filters is available to condition
input data as illustrated in following table (TABLE VII.

TABLE VII.  Filter Types in MLP

 

 

Both raw and filtered data can be used as inputs for the
feature block: this block performs statistical computation of data, and can be
configured to output up to 19 different statistical features. The list of the
available features is given in TABLE VIII. There are two main sets of features,
triggered and windowed: the former are elaborated at a feature event, the
latter at fixed window time intervals. While all features can be calculated as
windowed or triggered depending on user configuration, only a subset of these features
can generate a trigger.

TABLE VIII.  Available Statistical Features in MLP

 

 

At the end of the features configuration step, the
software tool described in the following section can output a configuration
file to be loaded on the device for MLP configuration and an ARFF file for
data-mining tool. The ARFF file obtained is matched with silicon implementation
of MLP computation. The data-mining tool forming the ARFF file is able to refine
(or “determine”) the best set of features to be chosen for a specific application
case, and is able to output a decision tree and the relative statistical
performance.

After elaboration and
feedback from the data-mining tool, it is possible to reprocess the data and
optimize the set of features.

When the performance matches the expectation, the decision
tree can be loaded on the MLP by means of a configuration file produced by the
STM software tool.

V. Supporting Software

Two dedicated tools have been developed to allow the
programmability of the MEMS sensor, the first for the Finite State Machine
configuration, the second for decision-tree configuration using a
statistical-based / machine-learning approach. These tools make the device
configuration process easy and fast.

The tools for Finite State Machine and decision-tree configuration
work as an extension of the Unico GUI (the Graphical User Interface for all the
MEMS sensor demonstration boards available in the STMicroelectronics portfolio[5]). Unico interacts with a motherboard[6][5] based on the STM32 microcontroller,
which enables the communication between the MEMS sensor and the PC GUI. The
software visualizes the output of the sensors in both graphical and numerical
format, and allows the user to save or generally manage data coming from the
device.

Unico allows access to the MEMS sensor registers, enabling
fast prototype of register setup and easy testing of the configuration directly
on the device. It is possible to save the current registers configuration in a
text file, and load a configuration from an existing file. In this way, the
sensor can be reprogrammed in few seconds.

The Finite State Machine and Machine Learning tools abstract
the process of register configuration by automatically generating configuration
files for the device. The user just needs to set some parameters in the GUI and
the configuration file is automatically generated. A set of configuration files
is already available and can be distributed to the users. The user can modify
these configurations, and also create his own library of configuration files by
generating new configurations using the tools.

 

A. Finite state machine
tool:

The State Machine tool extension of Unico allows the user
to configure the state machines and test the functionalities. Different tabs
are available in this tool:

–       
A configuration tab allows setting a configuration for the state
machines, writing the configurations to the MEMS sensor, and loading and saving
configuration files (Figure 5).

–       
An interrupt tab showing sensor data and interrupts generated from the
state machine execution (Figure 6).

–       
A debug tab allows injecting data in the sensor and debugging the state
machine execution sample-by-sample (Figure 7).

 

Figure
5:
Finite State Machine configuration tab

 

Figure
6:
Sensor data and Interrupt generation tab

Figure
7:
Debug tab and step by step data insertion

B. Machine learning tool

The statistical-based / machine-learning algorithms
require the collection of data logs. This is possible using Unico GUI. To each
data log, an expected result must be associated (e.g. no motion, walking,
running, etc.). The tool collects these data patterns to compute some features.

 

Figure 8: Data Patterns
tab

The tool allows selecting filters which can be applied to
the raw data, and features to be computed from the filtered data. The features
computed will be the attributes of the decision tree. After a few steps, an
Attribute-Relation File (ARFF) is generated by the tool.

 

 

Figure 9: Configuration
tab

The ARFF file is the starting point for the decision-tree
generation process. The decision tree can be generated by different machine
learning tools. Weka[7], software developed by the University of Waikato, is
able generate a decision tree starting from the Attribute-Relation File.
Through Weka it is possible to evaluate which attributes are good for the
decision tree, and different decision-tree configurations can be implemented by
changing all the parameters available in Weka.

 

 Figure 10: Attributes view in Weka

Figure 11: Decision-tree
generation in Weka

Once the decision tree has been generated, it can be
uploaded to the ST tool to complete the generation of the register
configuration for the MEMS sensor.

The Unico GUI, by accessing the sensor registers, can read
the status of the decision-tree outputs.

VI. Application Case Example

Starting from the example presented in the second section,
some current consumption measurements have been taken. As an example, an
activity recognition algorithm has been chosen since it shows some benefits: performance
is unambiguously evaluated in a patterns database, and current consumption for
this algorithm, running on common general-purpose microcontrollers, is in the
order of hundreds of µA. MLP can be easily configured, by means of the supporting
software presented in the previous section, to run the activity recognition
algorithm.

TABLE IX.  Current Requirements

Current	Additional current consumption
	Current mean [µA]
MLP on LSM6DSOx	7
Cortex-M3 STM32L152RE@32MHz	240

 

TABLE IX. summarizes the current requirement of the activity
recognition algorithm running on a Cortex-M3[8][9][10], and the additional
current requirement for the same algorithm running on LSM6DSOx MLP.

VII. Conclusions

The world is becoming more connected: devices are linked
together to exchange massive quantities of data. IoT applications rely on three
key building blocks: sensing, intelligence and connectivity. In this paper a highly
configurable digital module embedded in an inertial sensor has been introduced.
The digital module adds intelligence to the sensor,
thus allowing significant power saving at system level. In order to make the
prototype of the application immediate, supporting configuration software for
the digital module is furnished along with the hardware. The application case
in the previous section clearly shows that thanks to the digital module, the reduction
in current consumption is huge. Smart sensors are enablers for new applications
where battery life is crucial.

Acknowledgment

The authors thank the STMicroelectronics Analog Mems
Sensor division for discussions, encouragement and support.

References

[1]    S. Sumathi and
S.N. Sivanandam: Introduction to Data Mining Principles, Studies in
Computational Intelligence (SCI) 29, 1–20 (2006).

[2]   
V. Sze, Y. H. Chen, J. Einer, A. Suleiman and Z. Zhang, "Hardware
for machine learning: Challenges and opportunities," 2017 IEEE Custom
Integrated Circuits Conference (CICC), Austin, TX, 2017, pp. 1-8.

[3]   
V. Sze, "Designing Hardware for Machine Learning: The Important
Role Played by Circuit Designers," in IEEE Solid-State Circuits Magazine,
vol. 9, no. 4, pp. 46-54 , Fall 2017.

[4]    STMicroelectronics,
“Bluetooth® low energy wireless system-on-chip,” BlueNRG-2 datasheet, November
2017, [DocID030675 Rev 2].

[5]    STMicroelectronics
Analog Mems Sensor Application Team ,  Unico GUI User manual, Rev. 5  October
2016.

[6]    STMicroelectronics
Technical Staff,  STEVAL-MKI109V3 Professional MEMS Tool motherboard for MEMS
adapter boards, July 2016

[7]   
Ian H. Witten, Eibe Frank, and Mark A. Hall. 2011. Data Mining:
Practical Machine Learning Tools and Techniques (3rd ed.). Morgan Kaufmann
Publishers Inc., San Francisco, CA, USA.

[8]   
STMicroelectronics, “Ultra-low-power 32-bit MCU ARM®-based Cortex®-M3
with 512KB Flash, 80KB SRAM, 16KB EEPROM, LCD, USB, ADC, DAC,” STM32L151xE
STM32L152xE datasheet,  Rev. 9 August 2017.

[9]    STMicroelectronics
Technical Staff, STM32 Nucleo-64 boards, NUCLEO-XXXXRX NUCLEO-XXXXRX-P data
brief, Rev. 10 December 2017.

[10] 
STMicroelectronics Technical Staff, Sensor and motion algorithm software
expansion for STM32Cube , X-CUBE-MEMS1data brief, Rev. 10 November 2017.