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.
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.
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.
The DASH7 Mode 2 MAC is simple. It does only a few things.
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)|
Scan for background packets. Cancelled immediately if Carrier Sense / Energy Detect fails.
Scan for foreground packets. Cancelled on Scan Timeout.
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.
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.