Fig. 3.1
StrokeBack data flow cycle for complete rehabilitation process
It allows analysing the state of the patient in regular intervals and then applying respective feedback and/or corrective measures to the rehabilitation process. With reference to Fig. 3.1, the numbered arrows specify the following data flows:
1.
Initially, the clinician or therapist, respectively, analyses the current state of rehabilitation and the patient’s rehabilitation needs.
2.
According to the patient’s needs, individual exercises and a rehabilitation schedule should be specified.
3.
Defined exercises are to be executed at the patient’s training place at home, which is equipped with Kinect capabilities for movement tracking and training supervision.
4.
As all movement data is recorded throughout the day, the BAN in parallel gathers motion data during the training sessions too.
5.
Results and effectiveness of training sessions are stored at the patient’s home station.
6.
Since the patient’s home station is the base station for the BAN at the same time, exercises data and recorded BAN data can be compared. We will investigate whether it is possible to use both recorded data sets for autonomous BAN calibration means. This calibration may be necessary due to changed orientation and location of the sensor nodes that may occur due to daily attachment by the patient.
7.
Right after attachment of the sensor nodes to the body, each sensor node will record raw motion data throughout the day. Needless to say that recorded raw data will of course be much more precise or better analysable, respectively, after the calibration phase.
8.
When the sensor nodes are removed from the patient’s body, they’ll transfer all recorded raw data to the base station, where these data are processed with different algorithms to analyse ADL.
9.
Daily ADL statistics are stored into the patient’s PHR.
10.
Daily ADL statistics can be seen by the clinicians or therapists at any time and from anywhere via remote access. This in principle closes the cycle of StrokeBack BAN data flow.
11.
Access to gathered ADL statistics and training results enables to again analyse and assess the patient’s rehabilitation progress.
12.
Re-definition or respectively adaptation of the training schedule can be done with respect to ADL statistics or training results.
3.6.2 Daily BAN Data Cycle
The BAN will store all data gathered throughout the day, i.e. when the patient wears it, on the sensor nodes and will submit all data to the base station while recharging during the night. There is no need to establish permanent online connectivity from the sensor nodes to a base station (or gateway). From therapeutical point of view, it is merely required to gather statistics about ADL on daily basis, i.e. the patient’s ADL need to be available on the following day in the PHR. In addition, permanent wireless communication would unnecessarily and rapidly drain energy resources from the technical and usability point of view. Last but not least, it would require having a base station in reach of the BAN all day long. For example, the Bluetooth Low-Energy (BT-LE) communication module provides a solicited communication range of up to 10 m within a home environment only.
According to this, the daily BAN data cycle is very simple as well as without the necessity to be triggered by the patient. In principle, the operational mode of the sensor nodes is divided into two phases only, i.e. recording data during the day, when the BAN is worn by the patient, and uploading data to the base station during night, when the sensor nodes reside in recharging position. Each sensor node automatically starts recording and storing data locally right after being removed from the power supply, respectively, the charging device. The sensor node keeps on recording data throughout the day as long as it is unplugged from the recharging station or the battery charge condition undergoes the minimum level required for proper functioning. If any communication between different sensors or between sensors and the base station is necessary, e.g. for synchronisation of time data or calibration issues, this is done automatically without patient intervention.
3.6.3 Sensor Data Requirements
The sensor node gathers raw sensor data of three-dimensional relational orientation and acceleration. Therefore, the sensor platform includes an accelerometer and a gyroscope sensor that calculates acceleration and rotation data for the x-, y- and z-axes, as schematically drafted in Fig. 3.2.


Fig. 3.2
Schematic of rotation and acceleration data measured in relation to the sensor node
In addition, the StrokeBack sensor platform includes a magnetometer and sensors measuring vibration. Both sensory options may allow even more improved sensing skills to be investigated later on. Data from the accelerometer and the gyroscope are gathered in a frequency of 50 Hz in the basic setting, which equals to 50 samples per second or one sample every 20 ms, respectively. This is currently driven by parallel investigations using state-of-the-art sensor nodes, which do not support changing the sensing frequency with the given driver implementation. However, usage of lower sampling rates will in future be investigated to save memory and power consumption during operation.
According to that, the expected data recorded throughout the day volume per sensor node and day sums up to a maximum of 50 MB. The accelerometer and the gyroscope sensor each provide three channels (x, y, z axes). Hence, the sensor node records 6 sensor values of 16 bit at every 20 ms. Together with a 64 bit timestamp, the sensor node will store a minimum of 6 × 16 bit (sensor values) + 64 bit (timestamp) at every 20 ms as raw sensor data. This is equal to 18 bytes (1 byte = 8 bit) at every 20 ms, which sums up to 900 bytes per second and node. In total, we assume to store approximately 1 Kbyte per second on the node. By recording approximately 1 Kbyte per second, one sensor node will record 3600 Kbyte per hour and therefore 43.2 MB pure sensor data during 12 h.
3.7 Other Technical Requirements
3.7.1 Security/Privacy
All data gathered by the BAN are personal/private data of the patient that need to be protected from non-authorised access for the complete data lifetime, as already mentioned. Therefore, data transmitted from sensor nodes to the base station (and to the PHR later on) need to be protected against eavesdropping and malicious damages or changes. The StrokeBack system makes use of the AES protocol, which provides a symmetric cipher for encryption of data streams. Since it is symmetric, both the sender and the receiver need to know the secret encryption key to be able to access encrypted data. In the simplest setting, this secret key has to be selected during the configuration phase of the sensor nodes and cannot be changed during usage of the system. This approach may be suitable for controlled trials, but will become more or less unsecure when the StrokeBack system would be used in its envisioned application for daily rehabilitation monitoring, since the key can then not be changed during operation. Thus, anybody who possesses the configured AES key can then in principle access all data gathered by the system, regardless whether this access is permitted.
To overcome these problems, the final BAN nodes are empowered by the IHP crypto-microcontroller that provides hardware for AES too, but additionally provides energy-efficient integrated hardware accelerators for the asymmetric cipher protocol ECC and the standardised Secure Hash Algorithm 1 (SHA-1) for generation of digital signatures and hashes. The latter can be used to detect unwanted or malicious changes of data, e.g. during wireless transmission. The hardware support for ECC (software variants for microcontrollers exist, but are much too heavy to be used on sensor nodes as side application) enables to implement a public–private key infrastructure in parallel even on the sensor nodes. This is used to implement access control directly on the sensor nodes and to enable secure exchange of new AES encryption keys at any time if needed. On the other hand, this ensures that no sender or receiver other than the authorised base station can communicate to the sensor nodes to exchange information or patient’s data.
3.7.2 Synchronisation Protocols
Due to the non-precise and cheap clocks on the sensor nodes, these suffer from different clock drifts over time. That means, even if the clock of all sensor nodes is synchronised at the beginning of the day, e.g. during attachment, it may occur that the sensor data is not recorded exactly at the same time in parallel on all sensor nodes. Since sensor data is recorded at all nodes in intervals of 20 ms, the clock drift during the day must not exceed 10 ms in total to avoid incorrect correlation of motion data taken at different nodes. Communication facilities on the sensor nodes are to be used to synchronise all nodes and timestamps while recording data throughout the day.
3.7.3 Communication
For all communication issues between the sensor nodes and the base station mentioned before, each sensor node is equipped with a wireless communication module. According to previous estimations, it is assumed to transfer about 50 MB of data in total for each sensor node in use per day, including overhead data required for instance for packet headers, checksums, MAC (Medium Access Control) and routing data. Provided that a patient wears three sensor nodes in parallel for the maximum setting (wrist, upper arm, chest), about 150 MB of data have to be transferred to the base station during the recharging phase (at night). Taking the minimum time slot of 5 h for charging and transmission of all nodes into account, the BAN needs to transfer about 30 MB per hour. This equals to 500 Kbyte per minute or about 8.3 Kbyte per second, respectively. To summarise, to comply with the requirements set above, the communication module of each sensor node should provide a minimum transfer rate of 10 Kbyte per second (80 Kbit/s).
For wireless communication, the widely used Bluetooth (BT) standard has been investigated while focusing on using the more advanced BT-LE. Both would provide more than sufficient data rates to fulfil estimated transfer rates. The BT-LE allows data rates up to 1000 Kbit per second (1 Mbit/s). The BT standard even provides data rates of up to 2.1 Mbit/s (Enhanced Data Rate (EDR) mode), but usually consumes much more energy. Unfortunately, a dual BT front end that is compatible to both BT standards in parallel (called ‘BT Smart Ready’) was not available at the time of the design phase of the sensor nodes. Hence, a single BT-LE module was integrated.
3.7.4 Memory
Estimated raw sensor data of course need to be stored at the node throughout the day. Flash is the currently most widely used technology of non-volatile memory for small devices. In principle, two options of flash memory are available for our application, i.e. tiny flash modules directly assembled on the sensor board or flash memory cards that can be exchanged. Both options are relatively cheap, but feature different advantages and drawback.
Flash memory cards, or micro-SD cards in our case, are very cheap and available as mass product with capacities ranging from several hundred megabytes up to 64 Gigabyte. Further advantages are that they in principle are compatible to other devices and can be replaced easily and hence provide more flexibility. Their drawback is the required size for the SD-card slot on the board and their power consumption. Very small card slots still require a board area of about 12 × 12 mm, which is already half of the envisioned board size (refer to Sect. 3.9.1). The power supply for micro-SD cards requires around 3.0–3.3 V.
Flash modules for on-board assembly are slightly more expensive than SD-cards and provide less memory capacities. Nevertheless, such modules feature much smaller dimensions than a micro-SD slot and more important: the power consumption is significantly lower. Both features are of utmost importance for the StrokeBack sensor nodes. Hence, we decided to assemble a flash module with 128 MB storing capacity.
3.7.5 Power Supply
Energy efficiency is one of the key aspects when it comes to design of sensor nodes. The more energy the sensor nodes consumes during operation, the more energy need to be available and stored on the nodes to reach a certain minimum operation time. The minimum operation time for each node is assumed 12 h, as introduced before. However, not only the amount of energy consumed by the node itself need to be minimised of course. Obviously, using larger battery packs would solve most of energy supply problems, but there are several aspects that need to be considered as well, in particular from the usability point of view. Larger battery packs might not fit into very small and lightweight sensor cases and will unnecessarily increase weight of the sensor node.
Therefore, the StrokeBack BAN is supplied by very small rechargeable Lithium-Polymer batteries providing several hundred milliamps per hour (mAh). The sensors can commonly be charged via a standard micro-USB adapter. In addition, the StrokeBack sensor nodes integrate wireless power supply based on the Qi wireless power standard [36] for automatically recharging batteries when the sensor node is in charging position. This will enable getting rid of cables and cable plugs and therefore significantly improve patient’s experiences and acceptance.
3.7.6 Application Specific Integrated Circuits
The introduced monitoring cycle does not need to facilitate on-BAN movement classification by default. However, the ultimate research challenge of monitoring with body-worn sensors is enabling the BAN to classify and analyse motion data directly on the sensor nodes, without the need to use a base station for post-processing of sensed raw data. Therefore, the StrokeBack team investigated integration of a novel hardware module, called Application Specific Integrated Circuit (ASIC), for accelerating on-BAN movement classification while reducing the amount of recorded data at the same time. This would provide a novel and unique application.
3.7.7 Patient’s Safety
Safety in this context means the BAN may not put the patients’ health at risk. The StrokeBack BAN is used for monitoring issues only and hence, it does not provide any actuators. Two more features may be considered, i.e. wireless communication and power supply. The exposure of wireless transmission should be kept minimal by reducing the communication frequency and transmission power. This can be neglected for the StrokeBack application scenario, since usage of radio transmission is almost reduced to recharging time when the patient does not wear the BAN. The power supply on the node is very low and the amount of energy stored is small. This should not be a risk for the patient. Furthermore, the charging module on the board includes autonomous temperature control and shuts down the sensor node in case of difficulty while charging and overheating problems.
3.8 StrokeBack BAN Architecture
This section introduces the design and performance of the GHOST platform, which is a tiny sensor platform with inertial sensors, Qi compliant wireless power transfer and an embedded BT-LE (Bluetooth 4.0) front end. In a full package, the complete GHOST sensor platform is of matchbox size only, including a Lithium cell battery pack and a receiver coil for wireless power transfer. This platform is used for detection of ADL within the StrokeBack project, where the platform is worn by patient at the affected limb. It can collect movement data from accelerometer, gyroscope and magnetometer throughout the day, which is uploaded and analysed during the night when the sensor resides in the wireless charging station.
Due to the investigation and implementation of a pre-processing ASIC for the crypto-microcontroller, two variants of the GHOST platform have been designed. In principle, both provide equal functionality as required for the project and trials. The first version is equipped with a state-of-the-art microcontroller of the MSP430x family from Texas Instruments (TI). In the following, this sensor platform is referred to as GHOSTv1. This platform has been rapidly prototyped for testing and necessary CE signing procedure and tests in a third party laboratory.
The second and final version of the StrokeBack sensor node GHOSTv2 is empowered by an individualised crypto-microcontroller manufactured by IHP. This microcontroller is code-compatible to the MSP430x family from TI. The rest of the sensor node components mainly remain the same despite very small changes.
3.8.1 Sensor Node Components
A full list of chosen main components can be found in Table 3.1. Most of these components have been used on both platforms. However, differences in the set of integrated components between both platforms are marked.
Table 3.1
Components of StrokeBack sensor nodes GHOSTv1 and GHOSTv2 according to application requirements at a glance
Component | Specification |
---|---|
Micro Processing Unit (MPU) (GHOSTv1 only) | MSP430F5528 |
2× UART/SPI/IrDA | |
2× I2C/SPI | |
8× ADC | |
47× GPIO | |
RTC, USB | |
128 KB Flash, 8 + 2 KB RAM | |
2.32 mA (active, 8 MHz, 3 V) | |
1.9 μA (standby, LPM3) | |
0.18 μA (LPM 4.5) | |
9.8 × 9.8 × 1.0 mm, QFN-64 | |
Micro Processing Unit (MPU) (GHOSTv2 only) | IHP crypto MPU |
2× UART | |
2× SPI | |
4× ADC | |
24× GPIO | |
AES, SHA1, ECC | |
64 KB Flash, 16 KB RAM | |
2× Timer (16-bit, 32-bit) | |
Package: 9 × 9 × 2 mm, PQFN-64 | |
Communication module | TI CC2541, BlueTooth |
UART, SPI0 @ 4 MHz | |
Low Energy | |
18.2/17.9 mA (tx, rx) | |
270/1/0.5 μA (LPM) | |
6.8 × 6.8 × 1 mm QFN-40 | |
Flash data memory | Micron N25Q00AA |
128 MB | |
SPI0,3 @ 54 MHz | |
64 byte OTP, unID | |
20/6 mA (write, read) | |
200 μA (standby) | |
6 × 8 × 1.2, T-BGA-24 | |
Battery pack | EEMB LP502030 |
Single cell Lithium-Polymer (LiPo) | |
3,7 V, 250 mAh, 0.9 Wh | |
31 × 20.5 × 5.3 mm | |
IR remote control (GHOSTv1 only) | Vishay TSOP 75236 |
RC-5, 36 kHz | |
450 μA (active) | |
6.8 × 3.4 × 3.2 mm | |
IrDA (GHOSTv1 only) | Vishay TFBS 4652 |
9.6–115.2 kb/s (SIR) | |
30 cm | |
2 mA (transmission)
![]() Stay updated, free articles. Join our Telegram channel![]() Full access? Get Clinical Tree![]() ![]() ![]() |