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.

Doxygen Main Article
OpenTag uses Doxygen syntax so that automated, Doxygen documentation can be generated.

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.

System Architecture Main Article
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).

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. The kernel may be the “Native” kernel, which is purpose-built and runs on the “bare-metal” of an MCU, or it may be layered on-top (or along-side) a more general-purpose RTOS. One example JP likes is ChibiOS. In either case, timing is sensitive because the cost of sloppy timing is sloppy time-slotting, and therefore greater radio on-time. Radio on-time is typically the biggest energy requirement.

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 OTplatform/.

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: OpenTag builds that are blessed by JP
• Unofficial codebases: OpenTag builds that are not blessed by JP

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:

• OTlib code must be C only
• Platform code must be C or assembly
• All code must follow the Official Style Guidelines
• All code must meet Official Performance Guidelines

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.

• Can run on “bare metal” of an MCU
• Can run as a daemon on an RT-POSIX system (or similar)
• Can be ported to an MCU-bound RTOS (ChibiOS, FreeRTOS, TinyOS, uCOS II, etc)

• Links: (Mode 2 PHY), (Mode 2 MAC)
• PN9 and FEC encoding options in HW (if available) or SW.
• Transparent CRC16 computation in HW (if available) or SW.
• Support for all defined channels and data rates
• Single and multi-frame packet support
• DASH7 Mode 2 double-sample CSMA routine
• Link-budget packet filtering
• Automated contention window generation and timeout
• Automated re-listen window entry
• Automated sleep and hold scan cycling
• Automated beacon transmission
• Upgradability to DASH7 Mode 2 Data Link Layer security features

• Links: (Mode 2 Network Layer), (Mode 2 Transport Layer)
• All basic M2NP addressing modes (unicast, broadcast, multicast, anycast)
• M2AdvP transmission (flooding) and detection
• Routing up to two-hops
• Supports upgradability to multi-hop routing algorithms
• M2DP Datastream transfer with 5-way handshake
• All M2QP transport commands
• NA2P transport dialogs (non-arbitrated two party, i.e. simple request-response)
• A2P transport dialogs (arbitrated two party, i.e. sequential query)
• Upgradability to an A3P scheme (not currently in DASH7 spec)
• AIND, RAIND, RIGD collision avoidance mechanisms

• Link: (Mode 2 Session Layer)
• Configurable at compile-time (typical depth = 4)
• Allows dialogs to be scheduled in the future
• Allows dialogs to create follow-up dialogs

• Link: (Mode 2 Datastream Handshaking
• Large, point-to-point data transfer (TCP-like)
• Cryptographic authentication
• Anything else that needs 3/4/5-way handshaking

• Full support for required DASH7 filesystem features
• root-user-guest permissions model
• Read/write and create/delete files
• 16 bit virtual addressing (platform independent)
• 16 bit word size
• Upgradable to 32 bit virtual addressing
• Unique, high-performance software Flash wear leveling algorithm

• Link: (Mode 2 Application Layer Protocols)
• Current: File Access, Logger (Echo), ALP-API
• Future: Authentication, ISO 21451-7 sensor protocol, DASHForth
• ALP format is a subset of NFC NDEF format
• ALP framework is extensible

• Low-level C functions (experts only)
• C API for server-side programming
• ALP-API for client side messaging
• Future: DASHForth meta-messaging

• Platform framework is largely abstracted, so porting is typically quick
• Simple, NDEF-based wireline protocol for console terminals (MPipe)
• Confirmed support of CC430, Cortex M3 (ARM), and POSIX