Without divulging too much information that might be copyrighted, here is a series of tables describing the Mode 2 Physical Layer (PHY).
Each DASH7 channel is specified by a 1-byte (8 bit) Channel ID field. The frequency of the channel is set by the Channel Frequency Specifier, which is the lower 4 bits of the Channel ID. Bits 5:4 specify the modulation and datarate. Bits 7:6 specify the type of encoding used on the PHY data.
|Channel ID Bitfield|
The DASH7 channel frequency is specified by 4 bits. The center block is 7, and each block is 108.48 kHz plus or minus the one next to it. Each low speed DASH7 Channel is 216.96 kHz wide (2 blocks), and each DASH7 high speed channel is 433.92 kHz wide (4 blocks). A DASH7 implementation can mix any combination of channels, although it is usually best-practice not to have overlapping channels.
|Channel Frequency Specifier|
|Specifier||Modulation Type||Symbol Rate||Maximum Bandwidth|
|1||FSK / GFSK||55.55 kHz||216.96 kHz|
|2||FSK / GFSK||200.0 kHz||433.92 kHz|
|Specifier||Encoding Type||Data Rate Multiplier|
|2||FEC + PN9||1/2|
The DASH7 Modulation is binary FSK, however there are some filtering requirements as well. In most implementations, binary GFSK filtering with Bandwidth-Time (BT) of 0.7 (or lower) is used to implement the filtered FSK per spectrum requirements. Chips like the CC430 and SX1231 have GFSK BT of 0.5, which easily meets spectrum requirements. Other filtering techniques are also acceptable, as long as they meet the channel stopband requirements. Chips with clean oscillators may only need a GFSK BT of 1.0, chips with continuous-wave FSK may need no pulse-shaping at all, and chips with raised-cosine filters also tend to be perfectly acceptable. The requirement is simply that a generic FSK receiver shall demodulate the filtered transmission with nominal attenuation.
|Type||2-FSK (typically, GFSK with BT 0.5)|
|Frequency Deviation||± 50 kHz Carrier|
|Symbol 0 (LOW)||- 50 kHz Carrier|
|Symbol 1 (HIGH)||+ 50 kHz|
|Symbol rate||55.55 kS/s or 200 kS/s|
All messages are encoded with a PN9 scheme. Optionally, an FEC scheme can also be used. In the case where FEC is used, the data is encoded with PN9 first and FEC second (or decoded with FEC first and PN9 second).
The PN9 Scheme is the same one that's done in hardware on the ST SPIRIT1, TI CC11xx, and CC430 series of chips, as well as on some chips from other companies as well. However, not all PN9 is the same. Make sure the chip you are looking at is compatible with the SPIRIT1 PN9 Scheme. If not, the PN9 can be done in software without a big performance hit (it is pretty fast). The code block in OpenTag's m2_encode.c file shows how to do it in software.
The FEC scheme is a 1/2 rate convolutional code, k=4, with a 4×4 interleaver on the backend for the purpose of compensating for bursty noise. The FEC scheme is compatible with the HW codec on the ST SPIRIT1 and TI CC11xx family of chips (The CC430, however, does not have the convolutional code in HW).
FEC in DASH7 uses only a constraint length (k) of 4, so it doesn't deliver a particularly high encoding gain (about 4 dB) at the detection limit (SNR = ~10 dB). However, like all convolutional codes, the encoding gain is non-linear, so there's an impressive reduction in packet loss away from the detection limit. In other words, the FEC scheme is very data efficient and pairs well with the FSK modulation used by DASH7. Block code methods are not as optimal for random/AGWN error correction, and especially not for the DASH7 FSK modulation which has a decoding limit 3dB above BPSK and QPSK schemes. At this higher SNR limit, the convolutional code can perform better.
FEC is optional, and in software it is not really fast – make sure to test your platform before assuming that it will work. In OpenTag, the encode_M2.c contains code for doing the FEC in software, but it could use some optimization. Here is a table of known FEC support. For later versions of OpenTag, I have some ideas to optimize the decoder to be much faster.
|Chip||Type||FEC TX support||FEC RX support||Limit Gain||Comments|
|ST SPIRIT1||RF TRX||HW (reference)||HW (reference)||5 dB||Soft-decision decoder in HW|
|TI CC430||RF SoC||SW (confirmed)||SW (untested)||est 3.5 dB||Too slow for real-time decoding|
|TI CC11xx||RF TRX||HW (confirmed)||HW (confirmed)||est 5 dB||Soft-decision decoder in HW|
|ST STM32L||MCU||SW (confirmed)||SW (confirmed)||est 3.5 dB||SW decoder tested at 32 MHz|
|ST STM32F||MCU||SW (confirmed)||SW (confirmed)||est 3.5 dB||SW decoder tested at 32 MHz|
Some frames may support an internal block coding scheme. The block code is computed at a layer beneath the binary coding and appended to the end of the frame data. The specified code is an adaptive Reed Solomon code on a byte field (2^m = 256), using nominal rate (k/n) = 0.8.
|Preamble||Sync Word||Frame Data||Frame Parity Block|
|32 - 128 bits||16 bits||K bytes||N-K (P) bytes|
Encoding derivation: P = 4 + (ceiling(K/16) * 2)
Decoding derivation: K = floor((N + 13) / 18)
At the PHY layer, a type of CCA (Clear Channel Assessment) is specified as a means to guard the channel from errant transmission. The Data Link Layer and Transport Layers expand on the channel access methodology. In DASH7, the CCA is gated by a variable set in the system (ECCA = CCA Energy Threshold). If the detected energy in the channel, via RSSI measurement or something similar, is above the ECCA value then the CCA fails. The resolution of the CCA measurement must be 6 dBm or better.
DASH7 packets contain at least a preamble, sync word, packet data. The symbols in each of these components are of the same period (either 55.555 or 200.00 kS/s). The preamble is specified as 101010… notable as having the '1' symbol first. Implementation on transceivers without preamble quality detectors can use “10101010” as an addition to the front of the sync word in order to reduce false-positives.
|Preamble (Base, Normal)||32||32||64||Symbols|
|Preamble (Hi-Rate, Blink)||48||48||128||Symbols|
|Power Ramp-up Period||0||8||32||Symbols|
|Power Ramp-down Period||0||8||32||Symbols|
There are two classes of Sync Words that are used for different circumstances. The class utilization is defined in upper layers. The sync words are all related, as inversions or transpositions of each other, therefore they all have the same correlation properties. The words were chosen to have high correlation in the presence of a preamble.
|Class||Non-FEC Type||FEC Type|