Indigresso Wiki

Open Source Stuff for DASH7

User Tools

Site Tools


DASH7 Mode 2 in a Nutshell (Feature Summary)

DASH7 Mode 2 has a large featureset, but many of the features are optional, so it is possible to implement really small, low-cost DASH7 Mode 2 devices as well as more complex devices. Mode 2 uses a consistent set of configuration files to enable negotiation of featuresets and hence interoperability among different devices of the thousands (maybe millions) of feature permutations allowed by the standard.

High Level Feature Descriptions

If you were to encounter JP in a cafe and ask him to tell you about DASH7 Mode 2 over 30 minutes, it would probably come out like this.

Data Rates & Such

Turbo Data Rate: 100/200 kbps Normal Data Rate: 27.7/55.5 kbps

Turbo Data rate uses a GFSK (or filtered FSK) modulation with 0.5 index. It is a narrowband modulation so it is subject to all sorts of bad things like inter-symbol interference, multipath, and stuff like that, but it offers high-rate throughput. The 100 kbps method uses an optional 1/2 rate convolutional coding scheme (FEC), but this combats some of the downsides of the narrowband modulation.

Normal Data rate uses a GFSK (or filtered FSK) modulation with 1.8 index. It is a wideband modulation, so it has the opposite issues of narrowband. That is, good performance around interference but low data rate. The 27.7 kbps method uses the same optional 1/2 rate convolutional coding scheme (FEC) as used by narrowband. Normal rate + FEC can offer crazy-good performance in seriously RF unfriendly environments.


DASH7 Mode 2 can support a bunch of simultaneous channel options. It can support up to eight (8) concurrent Normal Data Rate channels, four (4) concurrent Turbo Data Rate channels, or some combination of both.

DASH7 Mode 2 does not do FHSS (Frequency Hopping Spread Spectrum). This is also known as fast-frequency hopping, but no matter the name, DASH7 Mode 2 doesn't do it. During the design we determined that DASH7 packets are characteristically short enough that FHSS would offer very little benefit, in contrast with technologies like Bluetooth that have to maintain very long datastreams. However, DASH7 does support adaptive channel hopping between packets. The channel hopping algorithms are not part of the standard (they are part of the application level), but the standard supports a framework for managing such channel hopping at the Transport Layer. In many types of applications, channel hopping may not be necessary at all.

MAC basics

The DASH7 Mode 2 MAC is simple. It does only a few things.

  • Detect errors in frames using CRC16.
  • Low-level frame filtering – there is a “subnet” field, which enables numerical filtering, and a TX EIRP field that enables filtering based on the normalized, estimated range of communication.
  • The standard type of frame is called a “Foreground Frame.” It includes some fields that allow addressing and other options that get pushed up to the network layer.
  • “Background Frames” are hyper-simple frames that can be flooded onto a channel for group synchronization (see that topic below).
  • Manage the Channel Scan Cycling routine
  • Manage the Beacon Cycling routine
  • Controlling Request-Response-Request windows

Channel Scan Cycling

This is a big part of DASH7 Mode 2. The scan cycle contains the parameters in the table below. In practice, a scan loop contains a string of multiple scan periods, each scan executing after the last one until the loop completes and the first scan repeats. Mode 2 devices will scan channels in the cycling unless they are turned-off or unless some communication is happening. In other words, Channel Scan Cycling is a Idle Time Process.

Parameter What it means
Channel ID A number identifying the channel that is being scanned
Scan Type Foreground or Background Scan
Scan Timeout An amount of time to keep the radio active, listening for a frame (ignored by background scan)
Next Scan An amount of time after initiating the scan to begin the next scan (should be larger than scan timeout)
Backgound Scan

Scan for background packets. Cancelled immediately if Carrier Sense / Energy Detect fails.

Foreground Scan

Scan for foreground packets. Cancelled on Scan Timeout.

Beacon Cycling

Beacon cycling is for sending automated beacons. It is very similar to Scan Cycling, except that beacons are transmitted on each cycle. Beacon Cycling is an Idle Time Process that happens parallel to Channel Scan Cycling. In most implementations the Channel Scan has priority (but priority of Scan vs. Beacon is not part of the spec, it is implementation dependent). In other words, if a Scan event happens at the same time as a Beacon event, the scan process will execute first.

Parameter What it means
Channel ID A number identifying the channel to be used for the beacon
Control Flags Some data that defines addressing parameters, per the spec
File Template A File ID or a File Series ID (a handle to a batch of Files), an offset value into the file where the beacon data starts, and a data limit for the beacon
Next Beacon An amount of time after initiating the beacon to begin the next beacon

In order to fully understand the File Template, see sections on the Mode 2 Filesystem, and related topics. Basically, you can keep a few files for your application, write to them (or have automated processes write to them), and have the automatic beacon cycle use the file data. So building a beaconing application with DASH7 Mode 2 is dead simple: just write the data you want to beacon to some files you choose, and DASH7 (or OpenTag) will do the rest. Update the files whenever you have new data.

Controlling Request-Response-Request Windows

In formal terms, the DASH7 dialog consists of a Request, a Response (the contention period), and optionally a follow-up request. There are some complexities in maintaining order in the channel. In a nutshell, DASH7 Mode 2 employs a CSMA algorithm to prevent collisions. DASH7 Mode 2 also has some features for implementing time-slots in the Response contention period to prevent collision from a request that yields responses from many devices. However, time-slotting like this is done in the Transport Layer. Doing slotting in the transport layer makes some IEEE 802.15.4 people red in the face (some Croatian guys come to mind), but the fact is that all sorts of IEEE 802 stuff use enhanced flow/congestion control in the transport layer. Plus, this strategy allows us to better stratify solution offerings, so we can enable ultra low cost products that only need to do simple things, yet they still have a common MAC with more complex products.

Addressing, Routing, Multihop (the Network Layer)

Managing Queries (the Transport Layer)

Handshaking and Sending Datastreams (also the Transport Layer)

Ordering Dialogs (the Session Layer)

The Filesystem

Built-in Application Protocols

User Application Protocols

The Configuration Files

Network Configuration

Device Parameters

Channel Configuration

Real Time Scheduler

Scan & Beacon Series

Hold Scan Series

Sleep Scan Series

Beacon Transmit Series

Feature Lists

Protocol List

ISFSB File ID List

GFB File List

Location Data File

Sensor Configuration File

Authentication Keys

Root Authentication Key

User Authentication Key

Mode 1 Files that Persist in Mode 2

Routing Code

User ID

HW Fault Status

Application Extension

dash7_mode_2/quickstart/features.txt · Last modified: 2011/10/06 00:21 by jpnorair