Paper Title (use style: paper title)

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 I2C/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).

time_diagram

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 ITOT containing its main contributors is:

 

ITOT = IBUS + ISLEEP + falgo * IUCORE * ( Tstart/2 + Talgo )

 

IBUS 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 ITOT 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 IBUS contribution is absent. Another contribution which is completely missing in the embedded solution is Tstart needed for the safe exiting from the sleep state of the microcontroller. ITOT estimation with the two terms Tstart and IBUS at zero leads to 200 µA which means that, using the same formula falgo*IUCORE*Talgo, 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 I2C master. Input sensor data is composed of the axis and the magnitude of the physical sensor (TABLE VI. ).

TABLE VI.  Input Types for MLP

 

AVAILABLE INPUTS

 

Accelerometer

accX

accY

accZ

axis

accV

accV2

 

mag

Gyroscope

GyX

gyY

gyZ

axis

gyV

gyV2

 

mag

External sensor

magX

magY

magZ

axis

magV

magV2

mag

 

 

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

ORDER

TYPE

1

High Pass

Generic IIR

2

Band Pass

Generic IIR

 

 

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

FEATURE

TRIGGER GENERATION

Mean

No

Variance

No

Energy

No

Peak to Peak

No

Zerocross

No

Zerocross_trigger_gen

Yes

Positive Zerocross

No

Positive Zerocross trigger gen

Yes

Negative Zerocross

No

Negative zerocross trigger gen

Yes

Peak detector

No

Peak detector trigger gen

Yes

Positive peak detector

No

Positive peak detector trigger gen

Yes

Negative  peak detector

No

Negative  peak detector trigger gen

Yes

Min

No

Max

No

Duration

No

Clock Feature

Yes

 

 

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).

 

SM_configuration

Figure 5: Finite State Machine configuration tab

 

SM_interrupt

Figure 6: Sensor data and Interrupt generation tab

SM_debug

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.

 DataPatterns

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.

 

 Configuration

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.

 

weka1

 Figure 10: Attributes view in Weka

weka2

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.