Patient Monitoring #1 - Critical choices: hardware, OS, software architecture

Patient monitoring is a crucial tool for medical professionals to acquire the most accurate information on the physical condition of a person such as blood pressure, body position, temperature, or glucose level.

In a series of articles, we aim to present a full software patient monitoring solution which describes the challenges of system integration from a hardware and software perspective.

In the medical field, monitoring is the constant checking on a patient's condition or phenomenon, either personally or by means of a mechanical monitor. The technique of monitoring vital processes and transmitting data without wires to a point remote from the subject is known as biotelemetry.

This first article will describe the requirements of the chosen components alongside with OS and software technologies that best fits the patient monitoring solution.

Components choices after setting the key objectives & requirements

The overall integration of the software and hardware layers is a key factor for the success of an embedded system project. For that reason, choosing the right components is a key decision.

Set and share your requirements

In order to make the right decisions you will have to think about your key expectations first.
In this case, our requirements are:

  • Low power consumption: as our application could very well come in multiple flavors (full bed-side monitoring system or portable device)
  • High CPU performance: in order to treat multiple sensors at once and being able to drive an advanced UI
  • Hardware accelerated graphics: enabling us to build an attractive user interface along with multiple graphs depicting each sensor feedback
  • Customer support: from the Silicon Vendor and/or its partners if need be

How to tackle the challenge of low consumption using ARM architecture

Microcontrollers would not allow us to easily develop a high-end graphical user interface. In terms of performance vs power consumption, the ARM architecture is a clear choice. In regard to CPU speed, a frequency equal or above to 800MHz would most likely do the trick. Lastly, we need OpenGL ES support (the version of OpenGL for embedded devices), as CPU rendering is not ideal to deliver a satisfying user experience.

Texas Instruments has been a big player for a long time when it comes to powerful, yet power-aware ARM System-on-Chip solutions. Looking at their various offerings, there's a few which could match our requirements, and our choice is the AM437x. This processor is based on the Cortex-A9 architecture and paired with a PowerVR SGX530 GPU.  For more information, visit

Decide for a hardware

am437xThe next decision we have to make is in regard to the actual hardware we want to start with. In other words, what is the reference design we should use. Due to the popularity of the AM437x, finding a development board is an easy task, provided we choose one with the required connectivity and ports for the application we want. Moreover, the AM437x is a stable and affordable development platform that can be used to develop a low cost and high-performance network application suitable for the patient monitoring solution. If you would eventually like to design your own hardware and prefer not to layout the processor and RAM directly on your PCB, TI has a myriad of partners they work with offering System-on-Module solutions. For this exercise, we will go ahead and use TI's own Starter Kit:

Choice of sensors – Luckily Arduino e-Health sensor platform

Another important decision in regard to the components is the sensors we are about to use and what information we want to monitor. We could obtain commercially available sensors individually, but this presents the drawback of having to investigate, and in some cases physically adjust, the sensors in order to connect them with the development board; not to mention having to figure out the protocol used to communicate between the modules.

Fortunately, a kit developed for the Arduino platform is available: the e-Health Sensor Platform. This set contains the following sensors:

  1. Pulse
  2. Oxygen in blood (SPO2)
  3. Airflow (breathing)
  4. Body temperature
  5. Electrocardiogram (ECG)
  6. Glucometer
  7. Galvanic skin response (GSR - sweating)
  8. Blood pressure (sphygmomanometer)
  9. Patient position (accelerometer)

The signals for each sensor have been conditioned for the Arduino platform that will communicate with the AM437x. To understand the communication protocol for each sensor, the source code provided with the kit is an invaluable resource. The latest version at the time of writing can be consulted here:

Software stack solution including OS and graphical framework

Once the basic hardware is selected, we need to make sure there is software available to support it.

Set your objectives for the OS

The set of requirements for our operating system are the following:

  • It needs to be well-supported, not only now but for years to come
  • It has to offer a good choice of software technologies helping us develop our application
  • It needs to allow for real-time capability
  • Low cost is better
  • Fast boot time is preferable
  • Of course, it needs to be available for the AM437x

At TI's AM437x web page, the following operating systems are listed as supported:

  • Neutrino
  • Integrity
  • Windows Embedded CE
  • Linux
  • VxWorks
  • Android

Linux, in this case, seems to be the best choice

Most of these operating systems are well-known and supported linuxtoday. Neutrino, VxWorks, and Integrity operating systems would be a good choice, but come at a cost, while Linux and Android do not; to this exercise, let's focus on the last two. Android is very popular, even though it is more targeted towards consumer products, with a very rich middleware, a nice shell, and good application frameworks to work with. Looking at our requirements, the only drawback is in regard to real-time and boot time. Overall, customization on Android is not as straight-forward as on Linux, and requires more engineering effort.

Linux seems to be a good choice: it has a huge community, provides many libraries and frameworks to work with, allows for real-time (with  solutions such as Xenomai) and it's free. Customization is straight-forward and was well thought-through from the get go, allowing us to tailor our operating system to our needs, reduce its boot time and overall fingerprint.

Choice of Qt framework to develop our User Interface (UI)

qt-compa,yIn terms of application development, there are numerous choices available: GTK, Crank, Mono, SDL and Qt, just to mention some. Witekio decided to go with Qt because of its simplicity to design cross-platform, modern and responsive applications using QML.

Qt is designed for developing applications and user interfaces once and deploying them across several desktop and mobile operating systems. Furthermore, the windowing system integration allows the use of 2D and 3D hardware acceleration with ease. It is for those reasons that we chose to use Qt as the framework for our application development.


Environment set up

Now that we have selected Linux as our operating system, we need a way to build a distribution that works for our chosen device.

Texas Instruments provides a Linux Software Development Kit (SDK) for their hardware platforms containing not only a bootloader, Linux kernel, and a filesystem, but also tools for developing on TI Processors (a validated cross-compiling toolchain, for example), pre-built libraries, and documentation to help explain how these pieces work together . All of this is accomplished through Yocto.

The Yocto Project is an open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture. The main advantage to this build system is its concept of “recipes”, which are simple files describing where to get a particular package, how to build it, and where to install it in the resulting file system hierarchy.

An important feature in Yocto is the use of “layers”, which contain theyocto extensions and customizations to the base system. In a nutshell, a layer can consist of new or modified recipes. TI offers a set of layers specifically developed for their processors through the Arago Project.


The Qt Company supplies its own layer dedicated for building Qt modules for embedded devices, called meta-qt5 . The source code for the layer is available here:


ubuntuThe first step in our development is to procure a host computer running Ubuntu. The commands described here assume version 14.04 LTS.

The necessary packages can be installed with the command:



$ sudo apt-get install git build-essential python diffstat texinfo gawk chrpath dos2unix wget unzip socat doxygen libc6:i386 libncurses5:i386 libstdc++6:i386 libz1:i386

To install a cross-compile toolchain, use:

$ wget
$ tar -Jxvf gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf.tar.xz -C $HOME

Scripts to set up the meta-ti BSP layer and meta-arago distribution layer are stored in a git repository, which we will clone with the command:

$ git clone git:// tisdk
$ cd tisdk

We want to use the fido branch of the Yocto Project version 1.8, so we run the script with the appropriate configuration file:

$ ./ -f configs/arago-fido-config.txt

We also want to have the QtGraphicalEffects plugin, so we will need to modify the meta-arago recipe to add it to the image.

In the file below, make the following changes: 

diff --git a/meta-arago-distro/recipes-core/packagegroups/ b/meta-arago-distro/recipes-core/packagegroups/
index 5ac3e74..df9d615 100644
--- a/meta-arago-distro/recipes-core/packagegroups/
+++ b/meta-arago-distro/recipes-core/packagegroups/
@@ -39,6 +39,7 @@ QT5_ESSENTIALS = "\
     qtwebkit-qmlplugins \
     qtquick1-plugins \
     qtquick1-qmlplugins \
+    qtgraphicaleffects-qmlplugins \

 RDEPENDS_${PN} = "\

Now, load the environment variables and set up:

$ cd build

$ . conf/setenv

Add the toolchain to your PATH

$ export PATH=/PATH/TO/TOOLCHAIN/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf/bin:$PATH

Now, we can launch the build command with

$ MACHINE=am437x-evm bitbake arago-core-tisdk-image

If successful, the resulting items will be available in the folder tisdk/build/arago-tmp-external-linaro-toolchain/deploy/

  1. Bootloaders, kernel and rootfs go into deploy/images/
  2. Binary packages go into deploy/ipk/
  3. Devkits go into deploy/sdk/

Create a folder to store your SDK

$ mkdir ~/HealthSensor/ti-arago-am437x-evm-sdk

Run the script 

$ tisdk/build/arago-tmp-external-linaro-toolchain/deploy/sdk/

Enter the recently created folder when prompted.

Create a folder to store the MLO, u-boot and uEnv.txt

$ mkdir ~/HealthSensor/ti-arago-am437x-evm-sdk/boot-images

$ cd ~/HealthSensor/ti-arago-am437x-evm-sdk/boot-images

$ cp ~/HealthSensor/tisdk/build/arago-tmp-external-linaro-toolchain/work/am437x_evm-linux-gnueabi/tisdk-uenv/1.0-r3/image/board-support/prebuilt-images/uEnv.txt .

$ cp ~/HealthSensor/tisdk/build/arago-tmp-external-linaro-toolchain/deploy/images/am437x-evm/MLO .

Next, we need to identify the drive representing the SD card in your system. Connect the SD card to your host machine using an SD card reader and immediately issue the dmesg command. The name of the device should be of the form sdX, where X depends on the number of devices in your system.

Run the script. This script can be run from any location but it must have root permissions:

$ sudo tisdk/build/arago-tmp-external-linaro-toolchain/work/am437x_evm-linux-gnueabi/ti-tisdk-setup/1.0-r29/package/bin/

Select the correct option based on the name of the SD card we had previously identified.

When prompted, choose the custom boot and rootfs file paths to install into the SD card and use the path ~/HealthSensor/ti-arago-am437x-evm-sdk/boot-images for the boot partition and tisdk/build/arago-tmp-external-linaro-toolchain/deploy/images/am437x-evm/tisdk-rootfs-image-am437x-evm-20160510163307.rootfs.tar.gz for the rootfs partition.

In this first post about our Patient monitoring project, we covered the hardware requirements, and described the chosen solution from a software and hardware perspective. We went for TI AM437x alongside with the Arduino e-Health Sensor Platform and Linux as the main operating system. The environment setup has been explained and detailed to easily reproduce the solution to improve or modify according the needs.

Discover soon the next step of our project : the application.

References :

  1. Monitoring (n.d.) Miller-Keane Encyclopedia and Dictionary of Medicine, Nursing, and Allied Health, Seventh Edition. (2003). Retrieved February 16 2017 from
  2. Monitor (n.d.) Miller-Keane Encyclopedia and Dictionary of Medicine, Nursing, and Allied Health, Seventh Edition. (2003). Retrieved February 16 2017 from
  3. Biotelemetry (n.d.) Farlex Partner Medical Dictionary. (2012). Retrieved February 16 2017 from
  4. Arduino
  5. e-Health Sensor Platform Complete Kit V2.0 for Arduino, Raspberry Pi and Intel Galileo [Biometric / Medical Applications].
  6. Qt Company: Technology Partners.
  7. Processor SDK Linux Getting Started Guide.
  8. Yocto Project.
  9. Developing Embedded Linux Devices Using the Yocto Project . Stewart, David. October 2011.
  10. Arago Project.
  11. Aligning with the Yocto Project. Turunen, Tuukka. Published July 1st, 2016.
  13. Processor SDK Linux create SD card script.

Written by Sébastien Ronsse, Director of Engineering Americas