Antidote IEEE 11073 stack library

From Wikidb

Jump to: navigation, search

This is the library that implements the IEEE 11073-20601 stack, and provides ways to adapt the stack to any transport protocol (Bluetooth, USB, TCP/IP etc.)


Core Stack

The core stack is written in C, it is transport-agnostic and, to some extent, platform-agnostic. It implements MDER encoding for ASN.1, PHD types, DIM, Agent and Manager.

The API for lower-level componentes (like PHD, DIM) is public, so an application might choose to use only a lower portion of the stack, if desired.


The stack accepts device specializations, in the form of compile-time plug-ins. There are some specializations implemented already in stack, and the application may implement more of them.

Transport plug-in interface

The adaptation between core stack (e.g. a Manager) and a given transport protocol is made by a transport plug-in. The transport layer brings the majority of platform dependencies into an application, but the plug-in architecture ensures that stack is insulated from them.

The stack imposes a particular (and very simple) interface for those plug-ins, and the application has a high degree of freedom on how to implement the plug-in.

Threads are allowed, even using one thread per connection (which means that more than one thread may call back the stack at the same time) is OK. The stack uses locks to protect itself (this brings the Pthreads dependence).

Sample transport plug-ins

The library source code contains a number of transport plug-ins. They serve as implementation examples and testing helpers; and their presence makes sure that the library is runnable "out of the box" in certain platforms.

Of particular importance are: the TCP/IP plug-in (which may be used to connect with Continua testing tools) and BlueZ HDP plug-in, which connects to BlueZ HDP implementation.

Health D-Bus Service

The healthd service exports a D-Bus service ( This application serves many objectives:


The core stack has a very light dependence on POSIX (basically on PThreads) which can is easily removed in case you need to port Antidote to a non-POSIX platform. As much as possible of the code depends only on standard library.

Each transport plug-in supplied along with the stack brings its own dependencies. All of them target a Linux platform; some of them depend on GLib, and others employ threads to monitor the transport.

A plug-in that depends on GLib expects that application runs a GLib event loop, so if the application uses another event loop (like Qt, EFL, or implements it from scratch), the plug-in can not be used. A new plug-in, specific for the event loop in question, must be written (of course, the code structure may borrow heavily from the supplied GLib or threaded plug-ins).

Specifically, the BlueZ-HDP plug-in used by healthd service has a fair number of dependencies, including very recent software:

If compiled with USB plug-in support (as it is, by default), there is the additional dependence on LibUSB 1.0.

The healthd service depends on GLib and D-Bus (dependencies already brought by the BlueZ HDP plug-in).

Personal tools