track 4 session 1 - st dev con 2016 - body area network and sensor synchronization

October 4, 2016

Santa Clara Convention Center

Mission City Ballroom

October 4, 2016

Santa Clara Convention Center

Mission City Ballroom

Wearables:

Setting up a

Body Area Network (BAN)

with sensor synchronization

Francesco Doddo

Agenda 2

10:00 Body Area Network Francesco Doddo

Quick Guide to BLE

connectivity

BAN Synchronization

The SensorTile Solution

10:45 Conclusion

Time

Speaker

Presentation

Body Area Network

Body Area Network applications2 sensors on arm 1 sensor on stomach 2 sensors on leg

• Fitness application:

• track you training exercise.

• Medical application:

• track your rehabilitation exercise

SYNCHRONICITY of the sampling and streaming

activities is essential

BAN Graphical User Interface / data loggerColor depends

on Temperature8 Slaves/nodes4 Slaves/nodes

Sound level from digital microphone,

barometric pressure, received signal

strength…

SensorTileSensing, processing and BLE connectivity

6

Sensors

Ultra Low Power

Connectivity

Low-Power MCU

MP34DT04

LPS22HB

LSM6DSM / LSM303AGR

STM32L4

BlueNRG-MS

SensorTile is a Bluetooth Smart “sensorized” development kit.

The miniaturized tile-shaped design includes all that is needed to

remotely sense and measure motion, environmental and acoustical

parameters.

13.5 mm

13

.5 m

m

Miniaturized Tile that can be

soldered or plugged on a host board

Flexible BLE connectivity solutionsPlug-in for MCU or Programmable BLE

+

STM32 BlueNRG BlueNRG-1The single chip

Programmable

Network Processor

Programmable BLE processorScalable MCU + BLE bundle

BlueNRG-1

The single-chip solution

• Wireless Sensor Networks (WSN)

• Beacon and Tag applications

• Automotive connectivity

• Smart remote controllers

Scalable Performances with BLE

Connectivity

• Pluggable BLE architecture

• One BLE, Multiple MCU choices

• Full-featured MCU peripherals

• Memory and MIPS scalability

• Package / GPIO flexibility

7

The BAN: 1 master, 8 slaves

BLE connectivity,

low-latency target

Data must be

synchronousMax 8 slaves?

Body Area Network

SensorTile

8

How many slaves?

BlueNRG-MS can play multiple roles: concurrent master-slave

• Single role: as a master it can support up to 8 simultaneous connections

• Dual role: as master can support up to 4 simultaneous connections, while

being a slave of another master

SensorTile(MS)Remote

device

SensorTile(MS)

SensorTile(MS)

SensorTile(MS)

SensorTile(MS)

SensorTile(MS)

SensorTile(MS)

SensorTile(MS)

SensorTile(MS)

USB

Today’s demo

You can extend this by

having each of the 8 nodes

connect to 4 sub-nodes

Each nodes aggregates

data from its sub-nodes

and send it to the hub

hub 8 nodesBLE

9

How many slaves?


device

SensorTile(MS)

SensorTile(MS)

SensorTile(MS)

SensorTile(MS)

hub 4 nodes sub-nodes (optional)

SensorTile(MS)SensorTile(MS)SensorTile(MS)SensorTile(MS)




BLEBLE BLE

If also the hub is dual-role

then topology changes.


device

SensorTile(MS)

SensorTile(MS)

SensorTile(MS)

SensorTile(MS)

SensorTile(MS)

SensorTile(MS)

SensorTile(MS)

SensorTile(MS)

USB

Today’s demo

You can extend this by

having each of the 8 nodes

connect to 4 sub-nodes

Each nodes aggregates

data from its sub-nodes

and send it to the hub

hub 8 nodesBLE

10

The dual-role BlueNRG-MS

• Hub first role

• Connected to receive data

• Hub second role

• Advertise to send sync trigger

• Sensor node first role

• Connected to send data

• Sensor node second role

• Scan to receive sync trigger

You get synchronization!(well this is one of the solutions which have

been explored, works but +/-5msec accuracy

as we will see later in this presentation)

11

Quick Guide to BLE connectivity

Quick Guide to BLE Connectivity

• Master/Slave vs. Client/Server

• Services/Characteristics/Values vs. Attributes

• Anchor period, connection interval, connection length

• Events (and timestamps)

13






14


• Who controls the radio

network?

• The master, also known as

central: it controls the time

base of the communication

slots

• Who controls the data

flow?

• The client: it reads data from

the server, and it writes data to

server

In the TYPICAL case the master is the client

And the slave is the server

15


The master can be BOTH client and server.

The slave can be BOTH client and server

16

• Who controls the radio

network?

• The master, also known as

central: it controls the time

base of the communication

slots

• Who controls the data

flow?

• The client: it reads data from

the server, and it writes data to

server


BlueNRG(MS)BlueNRG(MS)

master slave

• Can be server

• Can be client

• Can be both

• Can be client

• Can be server

• Can be both

Information flow

Server

• Offers a list of services

• Each service has several characteristics

• Each characteristic has a value

• Values can be read or written by client

• Values can be automatically sent to client

(indications, notifications)

Client

• Writes with/without acknowledge

• Read with/without acknowledge

• Automatic read with ack: indication

• Automatic read without ack: notification

Information flow

Information flow

17






18


• Data goes from the server to the client

• Data structure: an example:

• Services 1 environmental data service

• Characteristics 3 characteristics: temperature, pressure, rel.humidity

• Values Each characteristic has a value

• Real data structure:

• ATTRIBUTES No “names”, UUIDs (unique identifiers): 16, 128 bits

19


Service “environ.data”

Characteristic “Temp”

Characteristic “Pressure”

Characteristic “Rel.Hum.”

Service “Generic Access”

Service “Generic Attribute”

Always present to access device (name, appearance, reconnection address)

and access its data (attributes!)

Service “…”

Your custom services

20






21


Time

Anchor period

• Anchor period is set by master.

• Anchor period: multiple of 7.5msec.

7.5msec unit, 133 units/sec

22


TimeA A A A

Connection interval

Connection Length


• Anchor period, connection length and interval: all multiples of 7.5msec.

• Connections slot A in every anchor period (no skip)

• 1-8 packets per connection slot, 1-20 bytes per packet


• Not all devices can support 8 packet per slot as BlueNRG-MS.

• Min connection slot is 7.5msec

• max throughput: 133 x 8 pkts x 20 bytes x 8 bits = 170 kbps

23


TimeA A A AB B



• Two connections slots, A and B, different length and interval.



Slot interval is multiple of anchor period.• To accommodate new slots, anchor period may change (and be reduced)

24


Time

Anchor period

A A A AB B

Connection interval

Connection Length



• Two connections slots, A and B, different length and interval.



Slot interval is multiple of anchor period.• To accommodate new slots, anchor period may change (and be reduced)

• Position of connections slots is unpredictable.

• For dual role devices, e.g. master/slave: slave communication slots can overlap with

master slots: round-robin policy to accommodate both.

25






26


BlueNRG(MS) BlueNRG(MS)

Master/client Slave/server

Information flow

Host micro

Microcontroller here runs

the radio protocol stack

Microcontroller here runs

your application

Host micro

System overview

Note: BlueNRG-1 SoC can run the radio stack and the user application concurrently, eliminating the need for an additional host

micro.

However, if your application is large and/or has strict timing requirements then an host micro is strongly advised: coexistence of

your application and radio stack may make development and debugging very difficult.

27



client serverInformation flowHost micro

Data packet

over BLEIRQ

Data packet

over SPIPacket is in queue

hciReadPktRxQueue

Packet is

processed

Connection event:

assigned time slot in

anchor period

Timer for

HCI_process()

in hci.c

HCI_Isr()

in hci.c

HCI_event_CB()

in ble_service.c

28



Master/client Slave/server

Information flow

Host micro

When syncing there is the need to take accurate timestamps:

• BlueNRG-MS have special purpose TEST pins that are asserted when the embedded core is

active or when the radio front end is active: most accurate timestamp is taken when these

pins are asserted

• Host micro gets the interrupt from the BlueNRG: timestamp can be taken when interrupt is

received and the handler is executed

• Host micro looks into the packet queue and the correct callback is activated: least accurate

timestamp is taken when callback is executed

(unavailable on

current board)

(next step, for an

improved solution)

(current solution

works with these)

29

BAN Synchronization

The need for synchronization

• Clock of remote sensor units

• May not be an accurate crystal oscillator: because of power, cost and start-up time, it is

probably an RC oscillator which can be +/-5% off with respect to nominal frequency

• Even if an expensive crystal is used, over time the accumulated drift would compromise

the synchronization of the sensors

• Need for synchronization!

31

How-to achieve synchronization

What we have tested:

• Broadcasting a trigger signal: master advertises and slaves scan (while connected! Needs

dual-role devices)

• Exploiting the low-level radio network synchronization: dependence on availability high

quality timestamps.

• Slave activity is synchronized to communication slot, master resamples all the data

based on accurate timestamps

32


• Broadcasting a trigger signal: ADVERTISE data packet

• Multiple role needed: master/hub must advertise and receive data, remote sensor must scan

and send data.

• Advertise is done on multiple channels (1-3) and remote sensors listen to the channel of their

choice synchronizing on different ADV event

• Even if we restrict advertise on a single channel, it is very unlikely that all sensor will listen to the

same channel and receive the same ADV event

• Advertise may be done with a +/-5msec tolerance with respect to nominal time slot; this is a

lower limit for the synchronization (offset)

• Due to +/-5msec variability, it is not possible to synchronize the clock speed (rate) by measuring

interval over multiple repetitions

33


Exploit the radio network synchronization

• BT classic has an HCI Read Clock Offset function

• BLE does not allow access to low level radio network clock

• BLUENRG does expose auxiliary signals to report:

• Pin TEST8: TX (transmission) state event

• Pin TEST9: TX or RX state event

• 2 bits truth table on TEST9 and TEST8 determines RX state

34


• Slave activity is synchronized to communication slot, master resamples

all the data to compensate

• Using timestamp, the master/hub can reliably measure the actual rate of transmission

from each remote sensor

• The master/hub can also reliably measure the actual offset of each remote sensor with

respect to the anchor period

35

node 1 node 2 …

How to Achieve Synchronization

OPEN LOOP (works nicely - selected)

• The master/hub can resample data based on

measured rate and offset, linear interpolation can

be used

• Open loop does not have stability issues,

computations can be done in real-time or even

offline (post-processing)

CLOSED LOOP (unstable/does not converge)

• The remote sensor can adjust its internal rate

and offset based on information received from

the master

• Speed of closed loop is low and delay is large;

the closed loop can be unstable and/or converge

too slowly

• Slave activity is synchronized to communication slot, master resamples all the

data to compensate

• Using timestamp, the master/hub can reliably measure the actual rate of transmission from

each remote sensor

• The master/hub can also reliably measure the actual offset of each remote sensor with

respect to the anchor period

36

How-to achieve synchronizationWhat we have tested:

• Broadcasting a trigger signal: master advertises and slaves scan (while connected! Needs

dual-role devices): ok, +/-5msec

• Exploiting the low-level radio network synchronization: dependence on high quality

timestamps.

• Slave activity is synchronized to communication slot, master resamples all the data based

on accurate timestamps: ok Currently selected

Selected Synchronization Solution

Slave activity is synchronized to communication slot, master resamples

all the data to compensate; selected

• Packet parser: remote timestamps in the packet are used to reassemble

synchronous data sent in different consecutive packets

• Buffer processing: local timestamps are taken and filtered to drive the

sample-rate-conversion: high quality timestamps

• Sample Rate Conversion: linear interpolation from high quality timestamp to

target common timestamp (loss concealment as a side benefit)

38

Synchronization SolutionDedicated Design Tip

39

SensorTile

SensorTileSensing, processing and BLE connectivity

41

Sensors

Ultra Low Power

Connectivity

Low-Power MCU

MP34DT04

LPS22HB

LSM6DSM / LSM303AGR

STM32L4

BlueNRG-MS

SensorTile is a Bluetooth Smart “sensorized” development kit.

The miniaturized tile-shaped design includes all that is needed to

remotely sense and measure motion, environmental and acoustical

parameters.

13.5 mm

13

.5 m

m

Miniaturized Tile that can be

soldered or plugged on a host board

SensorTile Architecture

Connections

Bottom View

SolderablePlugin

42

SensorTile – Sensor, MCU, Connectivity 43

Barometer0.1hPa accuracy

0.01hPa RMS noise1-75Hz, 4-15uA at 1Hz

3DAcc+3DMag± 50Ga mag,

±2/±4/±8/±16/g accel,Accel/Mag independent

power down mode,10Hz 25uA mag

50Hz 6uA acc

3DAcc+3DGyro0.6mA at 1.6kHz - 10uA at 13Hz

6.6kHz acc, 90ug/sqrtHz3.3kHz gyro, 4.5mdps

Microphone64dB SNR, 120dBSPL

Alt: dual high-dynamic-range

Bluetooth low-energyConcurrent master/slave

BT4.1

Cortex-M4Up to 100DMIPS 80MHz

100uA/MHz 24MHz35uA/MHz 2MHz

13.5mm

13

.5m

m

LPS22HBLSM303AGRLSM6DSM

STM32L476

MP34DT04

BlueNRG-MS

Balun Filter

Antenna

Clearance Area

SensorTile Core System: STEVAL-STLCS01V1

Bottom

SensorTile Development Kit 44

SensorTile Kit: STEVAL-STLKT01V1

Thank You

track 4 session 1 - st dev con 2016 - body area network and sensor synchronization

Devices & Hardware