This is an old revision of the document!
OpenTag is a DASH7 Mode 2 software stack, written in C, that is designed with the intent of running on microcontrollers (or radio SoC's). Therefore, OpenTag must be a very tight, compact package, but with proper configuration it can also run in any POSIX environment. It is also worth noting that OpenTag can provide all functionality required for any type of DASH7 Mode 2 device, not just a “tag.”
Current and future versions of OpenTag are open sourced under the OpenTag License, which is an outgrowth of the BSD License we designed for standards-based embedded projects (such as OpenTag). OpenTag code & app distributions are available from various places on the internet, and the Archive Page hopes to track all of them.
API Main Article
If you are a systems developer interested in treating OpenTag like a black-box and going straight to the API, you can skip most of the other documentation and focus on the APIs. You may also want to look at available platforms, boards, and the system architecture section below. There is also an API quickstart guide that is especially helpful for new users starting to work in a client-server system.
OpenTag is defined as a client-server model with a distributed dataset. A device that runs OpenTag (typically a microcontroller) is a server, and servers communicate with other servers via DASH7. Servers communicate with clients via one of the OpenTag API's or ALP's. Clients are typically POSIX devices like PC's, smartphones, higher-function embedded devices, etc. A device that contains a server and a connection to a client is known as a “Gateway.” Devices that contain only a server are known as “Subcontrollers” or “Endpoints,” depending on configuration and featureset.
OpenTag is organized as a root directory (known as OTroot or OT root) and a group of subdirectories. Each main subdirectory should contain code (or further subdirectories) related to specific purposes. As well, these subdirectories provide a good organization method for making chapters in the OT users' guide (which is integrated into the wiki).
|apps||Applications and demos (project folders)||Typically not||Opmode Demo, Ping Pong Demo, Query Demo, …|
|board||Configuration headers for supported boards||No||EM430RF, Chronos, Jupiter, IKR001, etc|
|otkernel||Scheduler and System Calls||Yes||GULP, BigGULP, HICCULP|
|otlib||Core library interfaces and code modules||Yes||No options (flat code)|
|otlibext||Official otlib extensions & patches||Typically Yes||Application protocols, stub-functions, applets, etc.|
|otplatform||Drivers, utilities, and kernel subroutines||No||CC430, MSP430, STM32F, STM32L, etc|
|otradio||DASH7 Mode 2 Radio Driver||No||CC430, SPIRIT1, SX1231, etc|
|otstack||DASH7 Mode 2 Stack for OpenTag||Yes||No options (flat code)|
|otulip||Ethernet/IP networking for OpenTag||Partial|
OpenTag comes with a set of applications that developers can compile with OpenTag (one at a time) for demonstration, evaluation, or even potentially productization. Each one of these applications is stored in a subdirectory of the
/Apps directory (each application may have sub-applications or variants). If you are an application developer looking to spin-out a quick demo, this is a good place to look first.
OpenTag is entended mainly for embedded targets, and it supports many “boards” (i.e. circuit boards containing at least a processing element, memory, and a radio). Boards are organized by platform (typically microcontroller families). Each Board platform may be supported by many different board configuration files.
OpenTag has a real-time kernel that dispatches tasks when events demand them. There are two kernel options: GULP (Global-interrupt Ultra Low Power) and HICCULP (Hardware Integrated Context Control with Ultra Low Power).
Most of the DASH7 code itself is implemented in OTlib, a fully platform-independent C library that OpenTag relies on heavily. Also, the API's are implemented in OTlib.
Any extensions to OTlib are stored here. Some examples are security support, advanced routing algorithms, sensor support, or application layer protocols. In all these cases, the library extensions should be backed by some kind of standard that is recognized by the DASH7 Alliance. Proprietary extensions should stay in the app code.
OpenTag defines a standard platform header in
OTlib/OT_platform.h and a standard low-level filesystem header in
OTlib/veelite_core.h, but different devices will implement them differently. The implementation of the platform and drivers are stored in
OTplatform/. Each platform (i.e. MCU family) has its own folder inside
OpenTag defines a standard radio header in
OTlib/radio.h which is bound to be implemented differently by different radios. Therefore, each supported radio device gets a folder inside
OTradio/ where the drivers and support files are stored.
If you define you board configuration file correctly, define your application configuration files correctly, and you setup your project (e.g. makefile) to compile the appropriate source code, everything will build and run. There is always going to be some manual effort, because automated configuration tools just don't work well with the huge variety of platforms and radios that OpenTag can support.
OpenTag is an open source project, so contributions to the source will inevitably be made by the community. There are two types of OpenTag codebases:
Official codebases will be hosted in the main source distribution (sourceforge). Unofficial codebases may be interoperable with official codebases, and they may be made available to the community, just not on sourceforge alongside the official codebases. In order for a codebase to be made official, JP needs to review it and “bless” it as official. JP will bless codebases that meet the Official OpenTag Coding Guidelines, summarized below:
OpenTag (per DASH7 Mode 2) is a monolithic system that encompasses OSI-layers 1-6 and part of 7 as well (the application layer). Because OpenTag is small, targeted at microcontrollers, and open source, there is no practical deficiency in keeping things monolithic: there is no sense in implementing different layers of an embedded WSN technology on anything but an RF transceiver and an MCU (or an RF SoC). In fact, this design strategy enables OpenTag to be much more optimized than are other, typical solutions for active RFID and WSN.