Indigresso Wiki

Open Source Stuff for DASH7

User Tools

Site Tools


OpenTag APIs

OpenTag uses a client-server architecture and a messaging API for communicating between devices (or between processes on a single device). Lower-level developers are also able to use a C API for intra-process control.

Primary APIs

As mentioned, OpenTag contains two main APIs: Messaging and C API. In addition, it is possible to work directly with the OpenTag code if you know what you are doing. These are “primary” APIs because they are built into OpenTag and they map directly to OpenTag OTAPI functions.

Messaging API (ALP API)

ALP API Main Article
API Quickstart Main Article
The ALP API (Application Layer Protocol Application Programming Interface) uses several OpenTag ALPs to represent C API function calls. Presently there are 4 ALPs used for the Messaging API, and more can be added as necessary. Each ALP can accommodate 128 functions, which for practical purposes is much more than enough. ALPs are communicated over a message pipe. The pipe is usually a HW interface between two devices, but a normal FIFO (POSIX-style interprocess pipe) is just the same.

The quickstart guide is available as some glue to hold all of the components together in a descriptive way. If you have not used NDEF or OpenTag APIs before, you probably want to read it.

Some Notes on Using ALPs

  • ALPs are mostly communicated over the Message Pipe.
  • For internal interprocess-comm, any Queue can also be used for ALPs.
  • Over the message pipe, ALPs use NDEF
  • Internally, ALPs use a leaner data format that is a subset of NDEF
  • OTcom is a program that can run on a PC and communicate ALPs via the NDEF MPipe. It is possible to build other programs that do the same thing.


The C API is also known as OTAPI, and the ALP API messages actually just map directly to OTAPI functions (so they are the same API, one is just done through a message pipe and the other through a C function interface).

Secondary APIs

Secondary APIs do not map directly to OpenTag machine-code functions. There is some extra layer in between the secondary API and OTAPI. Secondary APIs might be proprietary in nature or part of the “official” codebase. Proprietary APIs can map to compiled-C or anything else. Official secondary API's will always include some type of interpreter, because official API's that map directly to compiled-C will always be added as new OTAPI routines, and thus they will be accessible via primary APIs.

Abstracted APIs

OpenTag APIs are very low-level to the point that they are not really abstracted at all. OpenTag is intended to run on very resource-constrained embedded devices, so the decision was made to create a low-level API that can easily fit onto these kinds of devices and also can provide the “lowest common denominator” feature-set.

Application-Specific Feature Wrapping

Abstracted APIs are application-specific in nature, because they wrap-together low-level calls (OTAPI calls) in unique ways. Users are free to build wrapper APIs (i.e. abstraction layers) that call multiple OTAPI functions in a single user call. These can be stored on the server (if resources allow) or on the client (if resources do not allow).

Client-Side vs. Server-Side Absraction

Abstracted APIs can be stored either on the server or on the client. The benefit of building client-side abstracted APIs is that they are likely to be interoperable with any OpenTag device that supports ALP. The benefit of building server-side abstracted APIs is that they require less communication between client and server. The OpenTag codebase may contain some server-side abstracted APIs, stored in the OTlibext part of the codebase.


An official secondary API. Reserved for Future Use (RFU)

Wiring API

An official secondary API. Reserved for Future Use (RFU)

Proprietary APIs

None known at this time. When some are built, they will be listed in a table below.

opentag/api/main.txt · Last modified: 2012/03/30 14:55 by jpnorair