Next Article in Journal
A Novel Virtual Reality-Based Simulator for Maxillofacial Reconstruction Surgery: Development and Validation Study
Previous Article in Journal
Study on the Effects and Mechanisms of Action of Biological Enzymes on the Quality of Summer Rock Tea Extract
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Software-Defined Radio-Based Internet of Things Communication Systems: An Application for the DASH7 Alliance Protocol †

1
IDLab—Faculty of Applied Engineering, University of Antwerp—imec, Sint-Pietersvliet 7, 2000 Antwerp, Belgium
2
European Space Agency—European Space Research and Technology Centre (ESA—ESTEC), Keplerlaan 1, 2201 AZ Noordwijk, The Netherlands
*
Author to whom correspondence should be addressed.
This article is a revised and expanded version of a paper entitled Implementation of a Multi-Channel DASH7 IoT Communication System for Packet Investigation and Validation, which was presented at the 14th Annual GNU Radio Conference, Knoxville, TN, USA, 16–20 September 2024.
Appl. Sci. 2025, 15(1), 333; https://doi.org/10.3390/app15010333
Submission received: 14 November 2024 / Revised: 18 December 2024 / Accepted: 25 December 2024 / Published: 31 December 2024
(This article belongs to the Section Electrical, Electronics and Communications Engineering)

Abstract

:
Software-Defined Radio (SDR) technology has been a very popular and powerful prototyping device for decades. It finds applications in both fundamental research or application-oriented tasks. Additionally, the continuing rise of the Internet of Things (IoT) necessitates the validation, processing, and decoding of a large number of received signals. This is where SDRs can be a valuable instrument. In this work, we present an open-source software system using GNU Radio and SDRs, which improves the comprehension of the physical layer aspects of Internet of Things communication systems. Our implementation is generic and application-agnostic. Therefore, it can serve as a learning and investigation instrument for any IoT communication system. Within this work, we implement the open-source DASH7 Alliance Protocol (D7AP). The developed software tool can simulate synthetic DASH7 signals, process recorded data sets, and decode the received DASH7 packets in real time using an SDR front-end. The software is accompanied by three data sets collected in controlled, indoor, and suburban environments. The experimental results revealed that the total packet losses of the data sets were 0%, 2.33%, and 16.67%, respectively. Simultaneously, the three data sets were received by a dedicated DASH7 gateway with total packet losses of 0%, 3.83%, and 7.92%, respectively.

1. Introduction

The Internet of Things (IoT) is a concept that has evolved in the last decade to provide internet connectivity to objects that we use in everyday life. The versatility of these objects knows no limits. They can be generic devices such as bicycles, motors, home appliances, tools of any kind, and devices such as temperature, humidity, air quality, or inertial measurement unit sensors. These objects are also usually equipped with extra hardware that constitutes mainly a processing unit and a transceiver for digital communications. Consequently, this hardware enables objects to communicate with one another or to send information to the internet [1]. The IoT concept aims to provide an extra layer of intelligence to these objects by enabling remote access. Furthermore, it allows interaction among several objects to achieve a high operational efficiency [2,3]. Accordingly, the IoT concept has attracted the attention of many industries where automation plays a key role. Applications can be found in home and industrial automation, medical aids, energy management, automotive, smart cities, etc.
Moreover, Low-Power Wide-Area Networks (LPWANs) have emerged to provide the communication means that have enabled the IoT concept. Most LPWAN technologies can, in principle, provide the required internet connectivity to millions or even billions of objects. This communication revolution can be attributed to the LPWAN’s capability to establish long-range communication links that go up to several kilometers while using low-power transceivers [4]. Moreover, due to the low production cost, LPWAN transceivers are massively deployed in large-scale environments, i.e., on the scale of cities or even countries.
During the last decades, Software-Defined Radio (SDR) technology has also become a very popular and powerful prototyping tool [5,6]. Before the introduction of SDR technology, researchers and manufacturers relied only on custom-made expensive hardware and simulation tools. Although simulation tools can be very powerful in describing any physical behavior, they cannot include all the physical variables that are associated with complex engineering problems. On the other hand, SDR technology can provide a physical prototype that can be subjected to testing scrutiny. A noticeable trend in recent years is that SDR technology is used as a final product for many communication system technologies due to the decreasing production costs.
In this paper, we make use of SDR technology to design the physical layer for LPWAN communication systems. The design steps are generic and can be deployed with any LPWAN standard. However, we adopted the DASH7 Alliance Protocol (D7A) [7]. This communication standard was selected to represent IoT communication systems because its specification is freely available [8], and an open-source software stack is ready to use [9]. The proposed SDR implementation of the DASH7 standard was validated using simulation and experimental analyses. Furthermore, we provided raw DASH7 signals that were recorded using the SDR front-end in indoor and suburban environments to test our implementation; these data sets were correctly labeled, and the accurate positions of every transmitted signal were reported, which can be used in various applications, including localization.
In the following section, several LPWAN technologies will be presented, and a brief introduction to SDR technology will be provided. The DASH7 Alliance Protocol and our SDR implementation are presented in Section 4 and Section 5. In Section 6, we present simulation and experimental results that consolidate our implementation capabilities, followed by the discussion of the achieved results in Section 7. Subsequently, conclusions are drawn in Section 8. Finally, several technical appendices are presented to serve as tutorial material to understand common coding and decoding techniques used in telecommunication systems.

2. LPWAN Technologies

Several LPWAN technologies have been introduced over the years. In the following sections, a brief description of several established technologies is provided. Furthermore, an overview of their key characteristics is depicted in Table 1.

2.1. LoRaWAN

As a small start-up company, Cycleo introduced the LoRa (Long-Range) communication network in 2009 [10]. Three years later, the company was acquired by the Semtech corporation [11]. Since then, LoRa Wide-Area Networks (LoRaWANs) have been deployed all over the world to provide long-range and low-power communication for IoT networks [12].
The LoRaWAN physical layer is closed-source and proprietary. It utilizes Chirped Spread Spectrum (CSS) modulation in the unlicensed Sub-1 GHz frequency bands [13]. The operational bandwidth can be either 125, 250, or 500 kHz. Moreover, the allowed data rate varies from 300 bits per second (bps) to 50 kbps [14,15]. Accordingly, the characteristics of a LoRa signal, i.e., the carrier frequency, the bandwidth of the signal, and the modulation technique, allow LoRa networks to establish communication links up to 15 km in rural areas [2]. Besides that, LoRa sub-GHz has an extension, namely LoRa 2.4 GHz, which was announced in 2020. This LPWAN technology has the benefit of using the widely used unlicensed 2.4 GHz Industrial, Scientific, and Medical (ISM) band and, therefore, is not subject to duty cycle restrictions. The technology is based on the same CSS technique, but the bandwidths, spreading factors, and, therefore, data rates are expanded. Nevertheless, the advertised communication ranges seem to be higher compared to any other technology that is operating in this band [12].

2.2. Sigfox

In 2010, the French start-up Sigfox introduced the Sigfox technology, which can serve as an IoT communication network [10]. The Sigfox physical layer is also closed-source and proprietary. It utilizes Binary Phase Shift-Keying (BPSK) modulation in the unlicensed Sub-1 GHz frequency bands [10]. Sigfox exploits the Ultra Narrowband (UNB) technology with an uplink of 100 Hz bandwidth. Therefore, Sigfox signals encounter very low noise levels. Consequently, Sigfox gateways have a high receiving sensitivity, and the transceivers consume minimal power. Accordingly, a Sigfox gateway is presumed to handle up to a million connected objects with a coverage of 50 km in rural areas [2]. To achieve this low power consumption and long communication range, Sigfox networks limit the transmission throughput to 100 bps.

2.3. NB-IoT

Narrowband Internet of Things (NB-IoT) technology was introduced by 3GPP to provide LPWAN services [14]. The NB-IoT standard utilizes mobile network features (e.g., user identity confidentiality, authentication, and integrity). It is designed to achieve excellent coexistence performance between Global System for Mobile Communication (GSM) and Long-Term Evolution (LTE) technologies [16]. NB-IoT requires 180 kHz minimum system bandwidth for both downlink and uplink. Therefore, a GSM operator can replace one GSM carrier of 200 kHz to NB-IoT. An LTE operator can deploy NB-IoT inside an LTE carrier by reallocating one of the Physical Resource Blocks (PRBs) of 180 kHz to NB-IoT.
NB-IoT utilizes BPSK and Quadrature Phase Shift-Keying (QPSK) modulations at a frequency band of 700 MHz, 800 MHz, and 900 MHz. Consequently, NB-IoT can provide a communication link in rural areas up to 10 km [10].

2.4. DASH7

DASH7 is an open-source standard for wireless communication. It provides ultra-low-power and mid-range communication connectivity that is suitable for IoT applications. A DASH7 network can establish a communication link up to 5 km. Therefore, DASH7 is technically not an LPWAN technology. It is worth noting that some review papers classify the DASH7 standard as an LPWAN technology [17].
According to the DASH7 Alliance Protocol (D7AP) specification, the DASH7 physical layer utilizes Gaussian Frequency-Shift Keying (GFSK) modulation in the unlicensed Sub-1 GHz frequency bands. Moreover, DASH7 signals can be categorized into three channel classes with different parameters. The Lo-Rate class has an operational bandwidth of 25 kHz and a data rate of 9.6 kbps, the Normal class with an operational bandwidth of 200 kHz and a data rate of 55.555 kbps, and finally the Hi-Rate class which has an operational bandwidth of 200 kHz and a data rate of 166.667 kbps [5,7,18]. Consequently, the DASH7 physical layer characteristics, i.e., the carrier frequency, the signals’ operational bandwidth, and the minimal transmission power, are similar to the aforementioned LPWAN technologies.

3. SDR Technology

SDR technology allows software modules to run on a generic hardware platform used to implement radio functions. By combining an SDR front-end with a software platform, the user can exploit SDR technology to rapidly prototype communication systems, including physical layer design, recording and playback of signals, signal intelligence, algorithm validation, and more. In the following section, we provide a brief introduction to the main aspects of SDR technology. Furthermore, IoT technologies can benefit from SDR technology. Flexible SDR-based IoT gateways can be deployed while reducing overall costs. The reason that SDRs are a good candidate to serve as a platform within the IoT is due to the usage of straightforward modulation techniques, the deployment of low-bandwidth applications and low-data-rate signals.

3.1. SDR Architecture

Nowadays, various Commercial-Off-The-Shelf (COTS) SDRs are available for use. These SDRs vary in terms of cost and operational modes, i.e., transmitting, receiving or duplex modes, operating bandwidth, frequency bands, and the amount of coherent RF channels. Table 2 provides a brief comparison among several commercial SDR front-end units. In the following sections, the reception and transmission operations that are handled by the SDR front-end are briefly introduced.

3.1.1. SDR Transmission Mode

During the transmission process, the baseband in-phase and quadrature (I/Q) samples are synthesized by the host computer and fed to the onboard FPGA of the SDR at a specified sampling rate. The FPGA interpolates the data to a higher sampling rate using a digital up-conversion (DUC) process. Thereafter, it converts the signal to the analog domain with a digital-to-analog converter (DAC). The signal will be mixed with a specified carrier frequency signal that is generated by a local oscillator (LO). After this stage, the signal is amplified and ready to be transmitted [19].

3.1.2. SDR Receiving Mode

The first stage in the reception process is the down-conversion of the received signal by mixing the incoming signal with an LO. In this way, the received signal is converted from the Radio Frequency (RF) domain to the Intermediate Frequency (IF) domain. The IF signal is then represented by I/Q components. Afterwards, the intermediate I/Q components will be sampled by an analog-to-digital converter (ADC). The digitized I/Q data follow parallel paths through a digital down-conversion (DDC) process which mixes, filters, and decimates the input signal to a user-specified sampling rate. The down-converted samples will then be sent to the host computer. Both transmitting and receiving operations are depicted in Figure 1.

3.2. GNU Radio

GNU Radio is a set of free and open-source tools aiming to implement SDR systems and provides ready-to-use signal processing blocks [20]. It can be used with COTS SDRs or in a simulation mode. It can be used to write applications, to receive data out of digital streams, or to push data into digital streams, which can be transmitted using specific hardware. GNU Radio contains a variety of blocks such as filters, channel coders, synchronisation elements, equalizers, demodulators, decoders, and many other elements that are typically found in software radio systems. These elements are readily available as software blocks. More importantly, it includes a method of connecting these blocks and then manages how data are passed from one block to another. Adding extra DSP functions can be achieved with the use of embedded Python blocks. These blocks allow the implementation of custom Python code.
Since GNU Radio 3.10 is software, it can only handle discrete data. Usually, I/Q baseband samples are the input data type for receivers and the output data type for transmitters. SDRs are then used to shift the signal to the desired center frequency. However, within GNU Radio, any data type can be passed from one block to another, e.g., bits, bytes, vectors, integers, and real or complex numbers. When creating new applications in GNU Radio, they are primarily based on Python. Nonetheless, the performance-critical signal processing path is implemented in C++ using processor floating-point extensions. Thus, the developers can implement real-time, high-throughput radio systems in an easy-to-use environment.

3.3. In-Phase and Quadrature Data

The use of in-phase and quadrature (I/Q) data is a key concept when working with SDRs. I/Q data are a mathematical complex representation of the transmitted (or received) baseband signal. In this way, I/Q data describe the variations in the amplitude and phase of a signal. An I/Q signal can be represented as two orthogonal signals which form a new waveform. The creation of this new waveform is achieved by using a quadrature modulator; see Figure 2. The two real data signals at the transmitter end can be written as follows:
i ( t ) = I t ( t ) cos ( 2 π f o t )
q ( t ) = Q t ( t ) sin ( 2 π f o t )
Combining the two components leads to the following:
y ( t ) = I t ( t ) cos ( 2 π f o t ) + Q t ( t ) sin ( 2 π f o t ) .
At the receiver end, the in-phase and quadrature components can be recovered as follows by applying the product-to-sum identities:
I r ( t ) = I t ( t ) cos ( 2 π f o t ) + Q t ( t ) sin ( 2 π f o t ) 2 cos ( 2 π f o t ) = I t ( t ) term 1 + I t ( t ) cos ( 4 π f o t ) term 2 + Q t ( t ) sin ( 4 π f o t ) term 3
Q r ( t ) = I t ( t ) cos ( 2 π f o t ) + Q t ( t ) sin ( 2 π f o t ) 2 sin ( 2 π f o t ) = Q t ( t ) term 1 Q t ( t ) cos ( 4 π f o t ) term 2 + I t ( t ) sin ( 4 π f o t ) term 3
By using a low-pass filter (LPF), the high-frequency components, i.e., term two and term three in Equations (4) and (5), are removed, and the in-phase component i(t) and quadrature component q(t) can be recovered at the receiver.

4. DASH7 Communication System

Before explaining the implementation of our communication system, we first look into several important DASH7 system parameters of the physical layer to obtain a deeper understanding. These parameters are described in the following sections and are defined by the DASH7 Alliance [21].

4.1. Air Interface

4.1.1. RF Channels

As mentioned earlier, the DASH7 communication standard operates in the unlicensed sub-GHz frequency spectrum. The RF band that is available to use depends on the geographical region from where devices are operated. DASH7 supports the 433 MHz, 868 MHz, and 915 MHz bands. These bands with their specific channel indexes and frequencies are found in Table 3.

4.1.2. Channel Classes

To avoid signal collisions, the DASH7 protocol divides the specific spectrum band into several channels. Therefore, the DASH7 protocol defines three channel classes that represent the data rates that can be used. These are the Lo-Rate, Normal-Rate, and Hi-Rate data rates. Each channel class defines a certain symbol rate, modulation index, frequency deviation, and occupied bandwidth [21]. These parameters as displayed in Table 4.
Each channel is defined by an index specifying its start frequency relative to the start of the DASH7 operating frequency band. The center frequency expressed in Megahertz (MHz) of each channel can be calculated as follows:
f c c h a n n e l = Start ( b ) + 0.025 d + Channel Spacing ( c ) 2 ,
where b and d are the start frequency of the band and the channel index, as shown in Table 3, while c is the channel spacing of the selected channel class, which can be found in Table 4.

4.1.3. DASH7 Modulation Scheme

The DASH7 protocol adopts the widely used Frequency-Shift Keying (FSK) modulation scheme with a Gaussian pulse shape filter for the transmitted samples (hence, this modulation is referred to as GFSK). Accordingly, the transmitted waveform can be presented as follows:
s ( t ) = A e j Φ ( t ) ,
where A is the transmitted signal’s amplitude and Φ ( t ) is the angular phase which can be expressed as follows:
Φ ( t ) = 2 π h 0 t α ( τ ) d τ .
α ( t ) for an FSK signal is as follows:
α ( t ) = i = 0 L a ( i ) q ( t i T s ) ,
where a is 1 or −1 and represents the transmitted bit value. L is the number of transmitted bits, and q ( t i T s ) is the shape filter response of the transmitted signal (i.e., for GFSK, the q ( t ) is a Gaussian filter response). Finally, h is the modulation index, and can be expressed as follows:
h = 2 Δ f R b ,
where Δ f is the peak frequency deviation and R b is the data rate.
In general, GFSK has a higher spectral efficiency compared to FSK. The Gaussian pulse shaping filter smooths the symbol transitions and, therefore, is more bandwidth-efficient because it reduces the amount of sidelobes. In this way, it also reduces Inter-Channel Interference (ICI). The effect of FSK- and GFSK-modulated signals can be seen in a two-dimensional and three-dimensional view in Figure 3 and Figure 4, respectively. The energy is much more spread in the frequency domain when no pulse shaping is applied, whereas the energy is more concentrated when a Gaussian pulse shaping step is implemented.
The spread of a Gaussian-shaped symbol is defined by the bandwidth-to-symbol time product (BT), which, in essence, defines the curvature and amplitude of a symbol in the time domain. This is the product of the duration of a symbol and its spectral width. Its value lies between 0.1 and 1. If the BT has a small value, then the symbol is smeared in the time domain, and therefore, less bandwidth is required. However, it increases the chance of ISI occurring. When the BT product is high, the shape of the curve is closer to a rectangular shape in the time domain. This indicates that there is a lower chance of ISI, but it requires a much higher bandwidth. Therefore, a good trade-off needs to be found. For the executed measurements, a BT of 0.5 is used.

4.1.4. Gaussian Minimum-Shift Keying

When using the Hi-Rate channel class, there is a slight difference compared to the other channel classes. The modulation scheme changes from GFSK to Gaussian Minimum-Shift Keying (GMSK). This is a form of Continuous-Phase Frequency-Shift Keying (CPFSK) [22]. This means that the phase continuity between alternating symbols is maintained. To be more precise, there are no phase discontinuities between symbols observed because the frequency or tone changes happen at the carrier zero crossing points. This is because the frequency difference between the logical 0 and the logical 1 of GMSK is equal to half the data rate. The modulation index for the Hi-Rate channel class is 0.5. This is the smallest value achievable while maintaining orthogonality. In general, GMSK has a higher spectral efficiency than GFSK.

4.2. Packet Structure

Every DASH7 packet is preceded by a power ramp-up and succeeded by a power ramp-down, which is used to meet the band stop channel requirements. The power ramp-up is the time that is needed before the first symbol transmission. This means that the carrier frequency is ramped from idle power to transmit power and settles to a stable state. The reverse operation occurs when ramping down. If this ramp-down is too fast, a part of the encoded frame might be affected, and therefore, the packet can become unrecoverable. Typically, these ramps have a period of 8 symbols but can go up to 32 symbols.
When looking into the Data Link Layer of DASH7, we see two types of frames defined: background frames and foreground frames. Background frames have a static payload size of six bytes. These frames are used to send broadcast messages, which are applied for ad-hoc group synchronisation. Foreground frames can have a length of up to 256 bytes and are used for data requests or contain data.
The preamble is an unencoded static structure of alternating binary symbols starting with ‘1’ and can have a variable length of up to 64 bits. This is used to settle the receiver by calibrating its data rate circuits. The DASH7 specification defines a typical preamble length of 32 bits for the Lo-Rate and Normal-Rate classes while recommending 48 bits for the Hi-Rate channel class [23].
The sync word is an unencoded structure of 16 binary symbols used to identify the start of the payload. The physical layer supports two sync word classes which depend on the type of frame that is used. Background frames use Sync Word Class 0, while foreground frames use Sync Word Class 1. A second categorisation that makes up a specific sync word is the applied type of encoding. It can be seen from Table 5 that only Coding Scheme 0 (CS0) and Coding Scheme 2 (CS2) are used. In future releases, this can be extended with two additional coding schemes.
Finally, the payload field, which can have a length between 5 and 256 bytes, contains at least a length byte, a subnet byte, a control byte (CTRL), the packet data, and two Cyclic Redundancy Check (CRC16) bytes. The CRC operation is applied only to the payload before the encoding process. Its operation is extensively explained in Appendix A. Furthermore, the payload is the only encoded part of the packet. This encoding step is achieved with a PN9 code or a combination of a PN9 code and 1 2 -Forward Error Correction Code (FEC), which are described in Appendix B and Appendix C. Figure 5 shows the general composition of a DASH7 packet.

5. DASH7 Communication System Implementation

In this section, we present the implementation of our communication system using SDR technology. To represent the communication system more conveniently, we divide it into a transmitting and a receiving process. Subsequently, we create separate sections. The details of both methods will be thoroughly explained in the following sections.

5.1. The Transmitting Process

This process constitutes three steps: a data formatting process, a symbols to waveform conversion, and a modulation step. These operations will be discussed in the following sections.

5.1.1. Data Formatting

This process foresees the correct format for the packet as specified by the communication protocol [21]. The DASH7 protocol specifies that the packet starts with a preamble followed by a sync word and, finally, the payload containing the actual data message. Furthermore, the payload begins with one byte that specifies the length of the payload and ends with two CRC16 bytes, which are used as a bit error check. Finally, the payload data needs to be whitened using a PN9-code. The CRC and the PN9 calculations are presented in Appendix A and Appendix C, respectively. Optionally, a 1 2 -FEC can be applied before the PN9 coding operation, but this depends on the used coding scheme. A summarized operation of the FEC process can be found in Appendix B.
Figure 6 shows the GNU Radio implementation of the DASH7 data formatting step. The Parameter blocks contain all the required variables to create a synthetic DASH7 packet. The bytes in our implementation are represented as decimal numbers. For instance, the decimal number 170 represents a byte of the preamble data, i.e., “0b10101010”. Accordingly, you can add the decimal number 170 for every eight bits of preamble data. On the other hand, the two bytes of the sync word represent the value depending on a specific Sync Word Class and selected Coding Scheme, as shown in Table 5. Sync Word Class 0 is used for background frames, while Sync Word Class 1 is only used for foreground frames, which are defined at the Data Link Layer. As for the payload, in our implementation, we created the CRC16_and_PN9 function, which is a custom Python Module block. This function is applied in the Coded_Packet parameter block. The main task of this function is to add the length byte of the payload at the beginning and the two CRC16 bytes at the end of the payload. Afterwards, encode the entire payload with the PN9 code. Therefore, the total length of the coded packet is always the length of the payload plus three bytes.
The data formatting box in Figure 6 exploits three Vector sources and a Multiplexer block. The vector sources are dedicated to the preamble, the sync word, and the payload data. Subsequently, the Binary to symbols box converts each bit into a series of bytes and creates symbols by mapping these values. The 0 b is represented by −1, and the 1 b is represented by 1. The Throttle block is added to control the throughput of the data flow. In this case, we transmit a Lo-Rate DASH7 signal with a symbol rate of 9.6 kbps. The Virtual Sink block, in the flowgraph, is used for organizational purposes. Note that the Virtual Sink needs to be linked with a Virtual Source so that the data flows between the sink and the source. The complete transmitted packet is presented in Figure 7. The figure clearly shows the preamble data followed by the sync word and the whitened payload.

5.1.2. Symbols to Waveform Conversion

In the previous section, the complete DASH7 packet is formatted and converted to symbols. In this section, the symbols (see a ( i ) in Equation (9)) will be converted to a waveform. Consequently, every symbol will have a transmission time. Therefore, a single symbol will be represented by multiple samples. In our presentation, the symbols take the values of [−1,1] and are converted directly from the binary data [0,1]. However, the samples represent the digital waveform that will be transmitted. Therefore, the sample rate will always be larger than the symbol rate.
The process of converting an individual symbol into multiple samples is called upsampling, and the factor that controls this conversion is called the samples per symbol (SPS) factor. Consequently, a larger SPS value will improve the modulation process but at the same time will require a higher sample rate; e.g., the Lo-Rate DASH7 signals’ bit rate is 9.6 kbps if the SPS is set to 100, and this will lead to a sample rate of 960 kbps. After selecting the proper SPS, the pulse shape of the waveform should be specified. When the samples are represented by uniform values, the waveform of these samples will have a rectangular pulse shape. Nevertheless, the rectangular pulse shape is not commonly used in wireless communications due to its large side lobes in the frequency domain. In our application, the pulse shape of the signals will have a Gaussian filter response because DASH7 signals exploit GFSK modulation.
In GNU Radio, we utilize the Interpolating FIR Filter block to simultaneously perform the upsampling and shape filter processes. This filter creates a Finite Impulse Response (FIR) filter that performs the convolution in the time domain between the payload symbols and the filter taps, which happens after upsampling the bits by the SPS factor in the interpolation process. Consequently, if the taps are set to ones, then the output waveform will have a rectangular pulse shape. However, we deployed a Gaussian shape filter defined by the variable Gaussian_Shape_Filter. This variable exploits the GNU Radio firdes.gaussian(gain, SPS, beta, ntaps) function. The gain and SPS parameters are self-explanatory at this point, while beta is a Gaussian filter parameter ranging between 0 and 1. The parameter beta represents the product between the 3 dB bandwidth of the Gaussian filter and the symbol duration, i.e., BT, where B is the bandwidth and T is the symbol duration. For instance, if beta equals 0.25, then the Gaussian pulse shape spreads over four symbols. Thus, a smaller beta causes a higher Inter-Symbol Interference (ISI) but a compact spectrum. Finally, the ntaps variable specifies the amount of FIR taps. The choice of the number of taps (ntaps) is a trade-off between the filter performance and computational cost. A long tap line will ensure a compact signal bandwidth and good phase and amplitude responses for the signal of interest. A more expanded description regarding FIR filter design can be found in [24]. In our implementation, the ntaps parameter is equal to the SPS parameter because we usually deploy a high SPS factor. The implementation can be seen in Figure 8. We apply an Automatic Gain Control (AGC) block to the output of the Interpolating FIR filter block to obtain a more normalized signal after the pulses are amplified and shaped.
The generated waveform is depicted in Figure 9. This signal is obtained by upsampling, pulse shaping, and gain control of the mapped symbols. This baseband waveform can now be modulated.

5.1.3. Baseband Modulation

To implement the GFSK modulation in the digital domain, the integration in Equation (8) will be substituted by a summation of calculations as follows:
0 t α ( τ ) d τ k = 0 n α ( k T ) T ,
where T is the sampling interval, i.e., the reciprocal of the sampling rate. If we consider the following:
β ( n T ) = k = 0 n α ( k T ) T ,
then
β ( n T ) β ( ( n 1 ) T ) = k = 0 n α ( k T ) k = 0 n 1 α ( k T ) = α ( k T ) T
leads to
β ( n T ) = β ( n T T ) + α ( n T ) T .
The Z-transform of Equation (14) can be expressed as follows:
β ( z ) = β ( z ) z 1 + α ( z ) T ,
which leads to the transfer function,
β ( z ) α ( z ) = T 1 1 z 1 .
Equation (16) is the single-pole difference equation of an Infinite Impulse Response (IIR) filter, which can be implemented in a straightforward manner in GNU Radio.
Figure 10 shows the FSK modulation flowgraph. First, the signal is multiplied by the 2 π factor and the modulation index. Afterwards, the integration process will be conducted using the IIR filter. The Feedforward and the Feedback Taps control the behavior of the IIR filter. For the single-pole IIR filter, the feedback taps need to be (1, −1), as shown in Equation (16). However, the Feedforward Taps can vary based on the deployed integrator type. Several integration types can be performed: (1) rectangular integration, where the area under the curve is assumed to be flat; (2) trapezoidal integration, where the area under the curve is assumed to be triangular; and (3) the Simpson’s rule integration, where the area under the curve is assumed to be an arc [25]. To implement this rectangular integration, we use taps that are equal to 1. For trapezoidal integration, the taps will change to 1 2 and 1 2 . Finally, for Simpson’s rule integration, it becomes more complex, and the taps will be set to 1 3 , 4 3 , and 1 3 .
H R ( z ) = T 1 1 z 1
H T ( z ) = T 2 1 + z 1 1 z 1
H S ( z ) = T 3 1 + 4 z 1 + z 2 1 z 2
The Feedback Taps should be (1, −1) for the rectangular and trapezoidal integration. However, for the Simpson rule, this will be (1, 0, −1). In general, if the SPS factor is high, the rectangular integration will suffice. The baseband-modulated signal is sent to the SDR front-end. On that front-end, the signal will be sent through a DAC and eventually mixed to the needed RF frequency, followed by an amplification stage. Figure 10 depicts the implementation of the rectangular integration in GNU Radio, which generates a modulated baseband signal. The output of this flowgraph in the frequency domain is shown in Figure 11. In the plot, there are two distinct peaks noticeable at 4.8 kHz and 4.8 kHz, which are the “space” and “mark” tones used by the Lo-Rate DASH7 channel class.
The upsampling process and shape filter process in GNU Radio are achieved with an interpolating FIR filtering.

5.2. The Receiving Process

The receiving process is, in essence, the opposite operation of the transmission process. It comprises four steps: reception, demodulation, time synchronisation, and decoding.

5.2.1. Reception

The reception of a signal while using an SDR happens when the user tunes the local oscillator to or close to the frequency of interest. For FSK modulation, the center frequency of the SDR front-end needs to be tuned to the same center frequency of the FSK waveform. Accordingly, any deviation in the frequency between the front-end and the received modulated signal will result in a detection error and can cause a high bit error rate (BER).
In our implementation, the frequency of the received DASH7 signal is assumed to be known by the receiver (in general, in every communication system, this should be the case). Therefore, if the signal is received with an IF frequency, the signal has to be shifted to the center frequency of the receiving bandwidth. This can be achieved in GNU Radio by multiplying the received signal with a sinusoidal signal, which has a frequency equal to the IF frequency. Figure 12 presents the flowgraph of the digital mixer operation. The signal source provides a complex single-tone signal with a frequency equal to the IF frequency.

5.2.2. Demodulation

At the receiver, and after tuning the LO at the carrier frequency of the received signal, the received digital baseband signal can be expressed as
x ( k ) = A r e i Φ ( k ) ,
where A r is the received signal’s amplitude. The demodulation process of the received signal can be illustrated as follows:
  • Extracting the phase Φ ( k ) of the baseband signal using a Complex to Arg block:
    Φ ( k ) = 2 π h k = 0 n α ( k ) + ϕ e ,
    where k is the digitized time index, and ϕ e is a constant arbitrary phase due to the phase difference between the transmitter and the receiver.
  • Taking the derivative of Φ ( k )
    d Φ ( k ) d k = 2 π h α ( k ) α ( k 1 ) ,
    where h is the modulation index and is equal to the following:
    h = Δ f T .
    In order to further decode the packet, the following are required:
  • Time synchronisation and bit decimation must be performed.
  • Payload detection based on the sync word bits.
  • To decode the payload data, further data de-whitening and the optional FEC decoding are required.
The software implementation of points one and two are shown in Figure 13. The implementation of subsequent points are implemented in Figure 14 and will be discussed. Points 3, 4, and 5 will be discussed in the upcoming sections.

5.2.3. Time Synchronisation

The demodulated data samples are passed through a digital filter that minimizes the effects of noise and the effects of Inter-Symbol Interference (ISI). The ISI can be caused when the filtered received pulses overlap. The best filter to maximize the signal-to-noise ratio (SNR) while minimizing the ISI is a matched filter (MF). A matched filter has a frequency response whose magnitude matches the magnitude of the frequency response of the transmitter’s shape filter. Accordingly, for DASH7 signals, a Gaussian matched filter is deployed similar to the Gaussian shape filter which is implemented at the transmitter.
Afterwards, the output of the shape filter is sampled periodically at the symbol rate which is achieved by downsampling the data by the factor SPS, at the precise sampling time instants t m = m T s y m b o l + τ , where T s y m b o l is the symbol interval and τ is a nominal time delay or timing offset that accounts for the propagation time of the signal from the transmitter to the receiver [26]. Note that in DASH7, the symbol interval is the same as the bit interval. To perform this periodic sampling, we require a symbol clock at the receiver to select the correct symbol from several received samples. The process of extracting such a clock signal at the receiver is usually called symbol synchronisation or timing recovery. Timing recovery is one of the most critical functions performed at the receiver of an asynchronous digital communication system. It is important to emphasize that the receiver must know both the transmitted symbol rate (1/ T s y m b o l ) and the time instant to extract the symbol from multiple received samples within each symbol interval T s y m b o l .
A clock signal can be extracted from the received data signal. Many techniques can be used at the receiver to achieve self-synchronisation. However, in this paper, we adopted the Mueller and Müller symbol synchronisation method [27]. The details of this method are out of this paper’s scope.
The time recovery process is the first stage after demodulating the received samples, as shown in Figure 14. In GNU Radio, the Symbol Sync block provides several symbol synchronisation methods, including the Mueller and Müller method; every symbol synchronisation method has its specific parameters. Furthermore, the Symbol Sync allows the definition of any type of match filter when using the Polyphase Filterbank (PF). The input of the Symbol Sync are samples with a sample rate equal to 1 / T . On the other hand, the output of the Symbol Sync are symbols with a symbol rate of 1 / T s y m b o l .

5.2.4. Decoding

The first stage after the symbol synchronisation is the binary conversion process. The Binary Slicer block in Figure 14 converts every negative symbol value to a 0 b and the rest to 1 b. After converting the symbols to bits, the correlation process will start between the received bits and both the preamble and the sync word. The Correlate Access Code-Tag block provides a tag that indicates the location of the preamble and the sync word in the data stream. The tags will be exploited by the DASH7_demod_py_bb block. The py_bb in the block name indicates that the block is implemented using Python code, and it receives and delivers binary data. The DASH7_demod_py_bb block decodes the received packet. These are the bits after the sync word tag with PN9 sequences. After the decoding process, the block deploys a CRC16 to validate the correct reception of the received packet.
The output of the decoding process is shown in the GNU Radio Console, which states the number of the packet, the packet length, the calculated CRC check, and the message in decimal and hexadecimal form, as can be seen in Figure 15. Note that the payload size of a DASH7 packet is longer due to extra obligatory fields of the other layers.

6. Experimental Setup

The correct operation of the created software system was achieved by executing several experiments. Therefore, we collected three data sets. The first data set was obtained through a cabled setup. Consequently, we recorded a data set in an office environment followed by a third data set recorded from a suburban environment.
The cabled setup served as an optimal condition data set. Within this data set, three Lo-Rate channels were recorded, namely channel 0, 93, and 186. A total of 10 data transmissions were sent on each channel. Furthermore, we recorded two wireless data sets: one at an indoor location and one in a suburban setting. The indoor experiment was conducted at 10 locations, while the suburban experiment contained 21 predetermined locations. Each data set was tested on the aforementioned Lo-Rate channels. For each location of both wireless data sets, we transmitted 60 packets in total. Additionally, we logged the timestamp, channel, payload, RSSI, and EIRP from each packet on separate DASH7 gateways.
The measurement setup included six B-L072Z-LRWAN1 STM32 LoRaWAN Discovery Boards. Three development boards acted as DASH7 nodes or transmitters, which operated at different Lo-Rate channels. At the receiving end, three boards were configured as dedicated DASH7 gateways, where the incoming packets were demodulated and logged. The boards were programmed with the use of the Sub-IoT-Stack, which contained a full and open-source software stack of the DASH7 Alliance Protocol [9]. The nodes used the push communication model and transmit DASH7 messages, i.e., foreground frames, with a configurable payload, channel, gain, and encoding scheme.
Furthermore, we used an Ettus Research USRP B210 SDR to record the received data simultaneously from the DASH7 nodes. Note that lower-cost SDRs such as the ADALM-PLUTO, for example, can be used for the same purpose of data recording. This is feasible as long as the specific frequency band and sample rate are covered by the device. We set the center frequency ( F c ) to 866.5 MHz, which lay in the middle of the operating range of the 868 MHz ISM band. By setting the sample rate to 7.68 MHz, we covered the entire bandwidth where DASH7 operated. In this way, demodulation of the received signal became more convenient. An overview of the complete measurement setup is shown in Figure 16.
The hardware setup deviated slightly for the cabled measurements compared to the wireless setups. We connected the DASH7 node, the dedicated channel gateway, and the SDR through coaxial cables, which is shown in Figure 17. The DASH7 node was equipped with a 40 dB attenuator and RF splitter to guide the signal equally to the SDR and the dedicated DASH7 gateway.
The recorded data were fed and processed by the created GNU Radio flowgraphs. For the data recording and multi-channel implementation, we used GNU Radio version 3.10.1.1 installed on a Linux machine. The flowgraphs were created using readily available blocks and Python snippets. This made the conversion to older or newer GNU Radio versions more straightforward. The recorded data sets used the Signal Metadata Format (SigMF). This format describes the recorded digital signals with metadata in a JSON format, which makes it easier to validate and interpret the data during post-processing.
The software and flowgraphs used, which are extensively discussed in previous sections, accompanied by the recorded data sets and specifications, are published on Zenodo [28]. For a more concise summary of the work, we refer to [29].

Measurement Environments

The indoor environment consisted of several office rooms, meeting rooms, and hallways. It generally contained several materials, such as metal structures, wooden doors, wooden walls, and glass. The offices were filled with desks, cupboards, office chairs, and plants. The hallways consisted of glass and concrete walls, whereas the floor of the entire office was carpeted. The staircase contained stone and reinforced concrete and was accessible via wooden doors. Figure 18 depicts the indoor measurement environment. The 10 TX locations are shown as green indicators on the map while the receiving setup, i.e., the SDR and DASH7 gateways, are positioned at the red RX indicator. The receiving setup was placed entirely indoors.
Figure 19 shows the map of the suburban measurement environment. The DASH7 gateways and SDR are positioned at the red pointer, while the TX locations are shown in green. Many of these locations had LOS, while others did not. In the suburban environment, a lot of vegetation was found, such as trees and plants. Nine points had LOS, while twelve locations had non-line-of-sight (NLOS) to the receiving point. This NLOS was created by metal fences, vegetation such as trees and bushes, small hills, and buildings. Furthermore, a private marina and shipyard also obstructed the LOS. Finally, the suburban region and receiving location were separated by a busy waterway. In Figure 19, location 21 is shown in blue. This location was the furthest measurement point while having complete NLOS. Subsequently, no packets were received, as can be seen in Table 6.

7. Results and Discussion

We validated the proper working of the created software by using a cabled setup. The transmitted signals were attenuated by 40 dB. This attenuated signal was split, causing an additional 3 dB attenuation. In this way, the signal was distributed to the dedicated DASH7 gateway and the SDR simultaneously. For 10 measurements per channel, we observed mean received signal strengths between 21 dB and 22 dB. Subsequently, no packet loss was registered at the gateway and from the recorded data. This implies that our created software works as expected. When investigating the wireless indoor experiments, we observed very good results, although, at some points, partial packet loss was found. We have to note that 90% of the TX locations were NLOS and transmitters were placed at challenging locations throughout the office environment.
Subsequently, we see that the results of the indoor experiments are better compared to the suburban data set. The reason for this higher packet loss in the suburban environment is due to multipath effects, NLOS scenarios, and changes in distance between the transmitting locations and receiver setup. We also believe that we reached the limit of the maximum distance from where DASH7 can operate. It was found that the dedicated DASH7 gateways occasionally had a hard time detecting and decoding the packets properly. We also observed that packet loss occurred more often when the mean RSS was equal to or lower than 80 dB; however, this was not always the case. We believe this was due to the received signal being close to or even below the noise floor.
For the suburban data set, we found that packets were received even at a distance of 1180 m, which is within the expectations of the technology. Locations 1 and 2 were NLOS points. The obstruction was formed by buildings at the receiving end. Locations 3 to 7 were effectively LOS locations; however, on channel 0, a low level of packet loss was found. We noticed that there were other signals transmitting at or around the same frequency during experiments. This can explain why the packet loss was substantially higher in general at channel 0. Location 8 was an NLOS location with low packet loss. Location 9 was an LOS location, but a small packet loss was observed in the software. Locations 10 to 14 lay behind the marina and were further obstructed by vegetation and metal fences, which again caused quite some packet loss. Location 15 was an (N)LOS location, and partial obstruction from buildings, vegetation, and metal fences was observed. Although channel 0 and channel 186 performed well, channel 93 experienced low packet loss. Locations 16, 18, and 20 were NLOS locations, but at a long distance. At these locations, a partial packet loss was observed, which was due to buildings and vegetation obstructing the view. Locations 17, 18, 20, and 21 were measured on an embankment, whereas locations 17 and 19 were LOS locations that did not experience packet loss. Locations 18 and 20 were the second- and third-furthest locations while being NLOS locations. Also, here, we observed severe packet loss. Location 21 was a worst-case location with no line of sight while located at the furthest measurement point. A summary of the obtained results of the indoor and suburban experiments can be found in Table 6 and Table 7, respectively. We believe that the majority of the packet loss is attributable to NLOS measurement points and not necessarily distance. In many cases, when packet loss was observed, the loss was equally significant or even worse when we put the recorded data through the created software. Figure 20 shows the relation between distance and mean RSS for each channel measured at the suburban environment. We note that the RSS fluctuates heavily, independent of the distance. However, the majority of the NLOS happens at 75 dB or lower.
Figure 21 shows the relationship between packet loss and distance per channel for the suburban environment when the data were processed through the created software. Figure 22 shows the same relationship with the exception that it shows the packet loss at the dedicated DASH7 gateways. Note that the packet loss is generally lower compared to Figure 21. It is noteworthy that the majority of packet loss occurs when there is NLOS.
Eventually, we found that there was less packet loss at the DASH7 gateways compared to the post-processed data in GNU Radio of the indoor data set. The findings for the suburban data set are slightly different. At certain locations and channels, the software processing outperformed the DASH7 gateways. But in other cases, it performed equally or worse. There are diverse factors that can explain the cause of it. Firstly, multipath, difference in noise floor, and other signals such as LoRa were randomly seen within the data set, which affected the transmitted signals and, therefore, can explain the packet loss. Also, at channel 0, other signals were observed occasionally. Another reason why the gateway outperformed the SDR recordings was due to sensitivity. It is found that the receiver sensitivity of the B-L072Z-LRWAN1 board was 137 dBm. The sensitivity of the applied SDR was not advertised and depended on multiple factors. However, we believe that the sensitivity of the SDR was worse, taking into account the large bandwidth compared to a dedicated, small bandwidth device.
Another explanation for the increased data loss is time variances between the packets within one recording. We observed that these dynamic time variances between consecutive packets were between 1 ms and 2 ms. This caused phase shifts in comparison to the locked frequency and phase of the local oscillator, which caused the intermediate frequency to be affected by each received packet. We observed that more or even other packets were decoded successfully by changing the phase offset of the local oscillator.
Another observation within the recordings was a recurring static frequency deviation of about 1.5 kHz that needed to be adjusted at the first mixing stage in the receiver flowgraph. This is a Center Frequency Offset (CFO), which is caused by the frequency deviation of the Temperature Compensated Crystal Oscillator (TCXO) of the B-L072Z-LRWAN1 boards (STMicroelectronics, Geneva, Switzerland), which operates at 32 MHz. This TCXO provides a clock signal to the SX1276 transceiver chip (Semtech, Camarillo, CA, USA) and is used by the DASH7 transmitters and gateways. According to the datasheet, these crystals have a deviation of two parts per million (ppm) [30].

8. Conclusions

In this work, we have presented a communication system based on the DASH7 Alliance Protocol by utilizing GNU Radio and Software-Defined Radios. The complete communication system works in simulation, which makes the software suitable as a learning, analysis, and validation tool for DASH7 packets. Furthermore, the demodulation system was deployed and examined in a cabled setup and in an indoor and suburban environment. The obtained data sets are open-source and can be accessed on Zenodo. The cabled setup and indoor experiments showed that the software performed sufficiently, while the suburban experiment showed severe packet loss, which was also observed while using the dedicated DASH7 gateways. This was due to the nature of field experiments and was caused by multipath effects and varying (N)LOS conditions. Nevertheless, certain optimizations can be performed to decrease the packet loss within the software.
In future work, we envision several software optimizations. Currently, a lot of parameters are defined statically, which restricts the abilities of the software. To make the system more robust, we can implement certain DASH7-specific parameters dynamically. These parameters involve correlation with a varying length of the preamble, varying Sync Word Classes and channel classes. When taking these parameters into account, other system parameters need to be changed dynamically as well, for example, filter and gain blocks. Lastly, it is needed to implement the 1 2 -FEC technique.
On the level of digital signal processing, we find a few shortcomings in the current implementation. Firstly, an automatic Center Frequency Offset compensation block needs to be created. Secondly, the mixing stage of the demodulator should be improved to a self-centering technique. In this way, the signal is automatically centered at baseband level, which implies that it does not matter which specific channel a signal is received on. Thirdly, a phase offset measuring step and phase compensation step need to be added while maintaining the mixing stage. Furthermore, the Normal-Rate and Hi-Rate channel classes need to be implemented and validated. Penultimately, the dynamical detection of the used Sync Word Class and coding scheme for a certain packet should be implemented. Finally, the implementation of loading a configuration file containing several DASH7 specification-specific parameters can make the system more dynamic and less error-prone.

Author Contributions

Conceptualization, N.B.; Methodology, D.J. and N.B; Software, D.J. and N.B.; Investigation, D.J.; Data curation, D.J.; Writing—original draft, D.J.; Supervision, N.B., R.B. and M.W. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

The data set presented and used in this study is openly available at https://doi.org/10.5281/zenodo.10961310 (accessed on 10 September 2024).

Conflicts of Interest

The authors declare no conflicts of interest.

Appendix A. DASH7 CRC16 Validation

A cyclic redundancy check (CRC) is an error-detecting code commonly used in digital networks and storage devices to detect accidental changes to raw data. Blocks of data entering these systems receive a short check value attached, which is based on the remainder of a polynomial division of their contents. On retrieval, the calculation is repeated. When the check values do not match, corrective action can be taken against data corruption. A frame is always terminated by a 16-bit CRC field. Only when the CRC calculation of a received frame matches the supplied value will it be sent to the Data Link Layer, which continues processing the frame. The calculation of the field includes all previous bytes of the frame. For DASH7, the CRC16/CCITT_FALSE polynomial is used. This is expressed as x 16 + x 12 + x 5 + x 0 (0x1021 or 10001000000100001B) with an initial value of 0xFFFF. Using this algorithm correctly, the value 0x29B1 will result from the computation of the nine-character ASCII reference string “123456789” (note: the numbers of the reference string are ASCII-encoded, not binary). To compute an n-bit binary CRC, line the bits representing the input in a row, and position the (n + 1)-bit pattern representing the CRC’s divisor (called a “polynomial”) underneath the left-hand end of the row.
To make the operation straightforward, we encode a one-byte message with a 3-bit CRC, which uses the polynomial x 3 + x + 1 . The polynomial is written in binary as the coefficients; a third-order polynomial has four coefficients ( 1 x 3 + 0 x 2 + 1 x + 1 ). In this case, the coefficients are 1, 0, 1, and 1. The result of the calculation is 3 bits long.
We start with the message to be encoded: 11001100. This is first padded with zeros corresponding to the bit length (n) of the CRC (add 0 0 0 at the end of the message), and an initial value of n bits is added at the beginning of the message (add 1 1 1 at the beginning of the message). The first calculation for computing a 3-bit CRC is as follows:
111 11001100 000
101 1 divisor (4 bits) = x 3 + x + 1
010 01001100 000 ← result
The algorithm acts on the bits directly above the divisor in each step. The result for that iteration is the bitwise XOR of the polynomial divisor with the bits above it. The bits not above the divisor are simply copied directly below for that step. The divisor is then shifted one bit to the right, and the process is repeated until the divisor reaches the right-hand end of the input row. The entire calculation is written out below.
111111001100000
1011
201001001100000
1011
300010001100000
1011
400000111100000
1011
500000010000000
1011
600000000110000
1011
700000000011100
1011
800000000001010
1011
900000000000001
Since the leftmost divisor bit zeroed every input bit it touched, when this process ends, the only bits in the input row that can be nonzero are the n bits at the right-hand end of the row. These n bits are the remainder of the division step, and will also be the value of the CRC function. The validity of a received message can easily be verified by performing the above calculation again, this time with the check value added instead of zeros. The remainder should be equal to zero if there are no detectable errors.
111111001100001
1011
201001001100001
1011
300010001100001
1011
400000111100001
1011
500000010000001
1011
600000000110001
1011
700000000011101
1011
800000000001011
1011
900000000000000
As you may notice at step three in the previous example, when the next bit of the message is zero, the divisor skips it and goes to the bit after it. This skipping operation will continue until the divisor reaches one bit.

Appendix B. Forward Error Correction

Before the data whitening step in DASH7, an optional Forward Error Correction (FEC) step can be applied. FEC is a channel encoding step that adds redundancy bits to the transmitted data using a predetermined algorithm, making the data more robust against bit errors. In the case of DASH7, the encoding process includes two stages.
The first stage includes a 1/2 rate non-recursive convolutional encoding process with a constraint length (L) of 4. The 1/2 base coding rate indicates that each input bit will be encoded into two output bits. The encoder itself consists of three shift registers where an XOR operation is applied twice in a specific manner, eventually gaining two output bits.
The second stage applies a 32-bit interleaving process executed on every 2-bit symbol. This interleave/deinterleave process scrambles and separates adjacent symbols, thus lowering the impact of bursty errors that mostly span multiple bits and can be induced by interference or time-varying signal strengths. In this way, the process increases the robustness against these errors [31]. In order to have a properly working interleaving process, a convolutional code trellis terminator is also appended to the unencoded data. This sequence is 0x0B0B for even-length byte inputs and 0x0B0B0B for odd-length byte inputs. In the DASH7 protocol, a 4x4 matrix interleaver is used.
The bits coming from the convolutional coder are written into the rows of the matrix interleaver while the bits that will be sent are read from the columns of the matrix in a certain order. The interleaving operation is applied per 2-bit symbols. This means that the data are scrambled per 32 aligned bits. Note that FEC is only applied when using Coding Scheme 2 of DASH7, where the data are firstly FEC-encoded and afterwards PN9-encoded. Figure A1 depicts the operation of the encoder stage and interleaving stage. The following example is based on [32], whereas Figure A2 and Figure A3 show the filled buffers of the interleaver. The output bytes are highlighted in bold.
Input [4 B]0x030x010x020x03
Appended CRC [6 B]0x030x010x020x030x7E0x2D
Appended Trellis terminator [8 B]0x030x010x020x030x7E0x2D0x0B0x0B
FEC encoder output [16 B]000E8C037C0DF00EB5A93D1BBCD18CD1
Interleaver output [16 B]C83C002084CF3331D5B97B0A443337EE
Figure A1. Implementation of the FEC operation in DASH7 starting with a convolutional encoder with configuration (n,k,m) = (2,1,3), where n is the number of output bits, k is the number of input bits, and m is the number of shift register stages supplemented with the 4 × 4 matrix interleaver.
Figure A1. Implementation of the FEC operation in DASH7 starting with a convolutional encoder with configuration (n,k,m) = (2,1,3), where n is the number of output bits, k is the number of input bits, and m is the number of shift register stages supplemented with the 4 × 4 matrix interleaver.
Applsci 15 00333 g0a1
Figure A2. Buffer 1 and 2.
Figure A2. Buffer 1 and 2.
Applsci 15 00333 g0a2
Figure A3. Buffer 3 and 4.
Figure A3. Buffer 3 and 4.
Applsci 15 00333 g0a3

Appendix C. PN9 Coding

The 9-bit pseudo-random number (“PN9”) generator is shown at the top of Figure A4. The generator is described by the polynomial x 9 + x 5 + x 0 . The PN9 generates all the values between 1 through 511 (inclusively) in a pseudo-random order as it is clocked. The latches are all set to ones at the start of a whitening operation.
Figure A4. PN9 coding circuit.
Figure A4. PN9 coding circuit.
Applsci 15 00333 g0a4
Figure A5 illustrates the operation of the PN9 generator as it is clocked. The generator starts with a value of all ones “111111111”. Bit 0 (the LSB) and bit 5 are XOR’d to produce 0 that is shifted into the MSB on the next clock. This results in the next value of the generator being “011111111”. Again, bits 0 and 5 are XOR’d to give the next value of the MSB (again, 0) to produce the next value of the generator “001111111”, and the process continues through all 511 states of the generator.
Figure A5. Operation of the PN9 generator.
Figure A5. Operation of the PN9 generator.
Applsci 15 00333 g0a5
The lower set of latches in Figure A4 contains the current byte of the data to be whitened. Recall that the preamble and sync words are not whitened, so the first byte of data to be whitened is either the packet length byte (in variable packet mode) or the first byte of user data.
When the first byte of data is ready, it is XOR’d with the eight LSBs of the initial value of the PN9 generator, which are all ones. So, the PN9 generator is “111111111”, and the data are XOR’d with the eight LSBs of this, which is “11111111”. This whitened data are then transmitted over the air. Next, the second byte of data is shifted into the data latches (eight shifts, one per bit), while the PN9 generator is also clocked eight times (once per bit). This means that the second byte of user data is not XOR’d with the next PN9 value but instead by the value eight later in the PN9 sequence. Thus, the PN9 generator contains “111111111” when the first byte is processed, while the PN9 generator state during the second byte of data is not “011111111” (the next PN9 value), but instead “111100001” (the ninth PN9 value).
  • Suppose the (unwhitened) data sequence to be transmitted starts out as follows (these would be the bytes, for example, if a packet with a packet length byte of ten were transmitted, and the data were 0x00, 0x01,...): /0000 1010/0000 0000/0000 0001/0000 0010/... Remember that the values to XOR with the data are the eight LSBs of the PN9 sequence if every eighth value is used:
  • 1,1,1,1,1,1,1,1,1 *** Eight LSBs are 1111 1111
  • 0,1,1,1,1,1,1,1,1
  • 0,0,1,1,1,1,1,1,1
  • 0,0,0,1,1,1,1,1,1
  • 0,0,0,0,1,1,1,1,1
  • 1,0,0,0,0,1,1,1,1
  • 1,1,0,0,0,0,1,1,1
  • 1,1,1,0,0,0,0,1,1
  • 1,1,1,1,0,0,0,0,1 *** Eight LSBs are 1110 0001
  • 0,1,1,1,1,0,0,0,0
  • 1,0,1,1,1,1,0,0,0
  • 1,1,0,1,1,1,1,0,0
  • 1,1,1,0,1,1,1,1,0
  • 0,1,1,1,0,1,1,1,1
  • 0,0,1,1,1,0,1,1,1
  • 0,0,0,1,1,1,0,1,1
  • 0,0,0,0,1,1,1,0,1 *** Eight LSBs are 0001 1101
  • 1,0,0,0,0,1,1,1,0
  • 0,1,0,0,0,0,1,1,1
  • 1,0,1,0,0,0,0,1,1
  • 1,1,0,1,0,0,0,0,1
  • 0,1,1,0,1,0,0,0,0
  • 0,0,1,1,0,1,0,0,0
  • 1,0,0,1,1,0,1,0,0
  • 1,1,0,0,1,1,0,1,0 *** Eight LSBs are 10011010
  • 0,1,1,0,0,1,1,0,1
  • So, the values to XOR with the data are as follows:
  • / 1111 1111/1110 0001/0001 1101/1001 1010/
  • Taking the exclusive-OR of these two sequences gives the data to be transmitted:
  • Data: /0000 1010/0000 0000/0000 0001/0000 0010 ...
  • PN9: /1111 1111/1110 0001/0001 1101/1001 1010/...
  • Result:/1111 0101/1110 0001/0001 1100/1001 1000 /...
  • When received, the resultant data are XOR’d with the same PN9-derived sequence, resulting in the originally transmitted data.
  • Received: /1111 0101/1110 0001/0001 1100/1001 1000 /...
  • PN9: /1111 1111/1110 0001/0001 1101/1001 1010/...
  • Data: /0000 1010/0000 0000/0000 0001/0000 0010/...

References

  1. Zanella, A.; Bui, N.; Castellani, A.; Vangelista, L.; Zorzi, M. Internet of Things for Smart Cities. IEEE Internet Things J. 2014, 1, 22–32. [Google Scholar] [CrossRef]
  2. Centenaro, M.; Vangelista, L.; Zanella, A.; Zorzi, M. Long-range Communications in Unlicensed Bands: The Rising Stars in the IoT and Smart City Scenarios. IEEE Wirel. Commun. 2016, 23, 60–67. [Google Scholar] [CrossRef]
  3. Bni Lam, N.H. Angle of Arrival Estimation for Low Power and Long Range Communication Networks. Ph.D. Thesis, University of Antwerp, Faculty of Applied Engineering, Antwerp, Belgium, 2021. Available online: https://repository.uantwerpen.be/docstore/d:irua:6256 (accessed on 24 December 2024).
  4. BniLam, N.; Janssens, R.; Steckel, J.; Weyn, M. AoA Estimates for LPWAN Technologies: Indoor Experimental Analysis. In Proceedings of the 2021 15th European Conference on Antennas and Propagation (EuCAP), Düsseldorf, Germany, 22–26 March 2021; pp. 1–5. [Google Scholar] [CrossRef]
  5. BniLam, N.; Steckel, J.; Weyn, M. Synchronization of Multiple Independent Subarray Antennas: An Application for Angle of Arrival Estimation. IEEE Trans. Antennas Propag. 2019, 67, 1223–1232. [Google Scholar] [CrossRef]
  6. BniLam, N.; Joosens, D.; Steckel, J.; Weyn, M. Low Cost AoA Unit for IoT Applications. In Proceedings of the 2019 13th European Conference on Antennas and Propagation (EuCAP), Krakow, Poland, 31 March–5 April 2019; pp. 1–5. [Google Scholar]
  7. BniLam, N.; Ergeerts, G.; Subotic, D.; Steckel, J.; Weyn, M. Adaptive probabilistic model using angle of arrival estimation for IoT indoor localization. In Proceedings of the 2017 International Conference on Indoor Positioning and Indoor Navigation (IPIN), Sapporo, Japan, 18–21 September 2017; pp. 1–7. [Google Scholar] [CrossRef]
  8. DASH7 Alliance. Available online: http://www.dash7-alliance.org (accessed on 10 September 2024).
  9. Sub-IoT. Available online: https://sub-iot.github.io/Sub-IoT-Stack (accessed on 10 September 2024).
  10. Mekki, K.; Bajic, E.; Chaxel, F.; Meyer, F. A Comparative Study of LPWAN Technologies for Large-scale IoT Deployment. ICT Express 2019, 5, 1–7. [Google Scholar] [CrossRef]
  11. Semtech. Available online: https://www.semtech.com (accessed on 10 September 2024).
  12. Janssen, T.; BniLam, N.; Aernouts, M.; Berkvens, R.; Weyn, M. LoRa 2.4 GHz communication link and range. Sensors 2020, 20, 4366. [Google Scholar] [CrossRef] [PubMed]
  13. BniLam, N.; Nasser, S.; Weyn, M. Angle of Arrival Estimation System for LoRa Technology based on Phase Detectors. In Proceedings of the 2022 16th European Conference on Antennas and Propagation (EuCAP), Madrid, Spain, 27 March–1 April 2022; pp. 1–5. [Google Scholar] [CrossRef]
  14. Adefemi Alimi, K.O.; Ouahada, K.; Abu-Mahfouz, A.M.; Rimer, S. A Survey on the Security of Low Power Wide Area Networks: Threats, Challenges, and Potential Solutions. Sensors 2020, 20, 5800. [Google Scholar] [CrossRef] [PubMed]
  15. BniLam, N.; Joosens, D.; Aernouts, M.; Steckel, J.; Weyn, M. LoRay: AoA Estimation System for Long Range Communication Networks. IEEE Trans. Wirel. Commun. 2021, 20, 2005–2018. [Google Scholar] [CrossRef]
  16. Wang, Y.P.E.; Lin, X.; Adhikary, A.; Grovlen, A.; Sui, Y.; Blankenship, Y.; Bergman, J.; Razaghi, H.S. A Primer on 3GPP Narrowband Internet of Things. IEEE Commun. Mag. 2017, 55, 117–123. [Google Scholar] [CrossRef]
  17. Bembe, M.; Abu-Mahfouz, A.; Masonta, M.; Ngqondi, T. A survey on low-power wide area networks for IoT applications. Telecommun. Syst. 2019, 71, 249–274. [Google Scholar] [CrossRef]
  18. Bnilam, N.; Joosens, D.; Berkvens, R.; Steckel, J.; Weyn, M. AoA-Based Localization System Using a Single IoT Gateway: An Application for Smart Pedestrian Crossing. IEEE Access 2021, 9, 13532–13541. [Google Scholar] [CrossRef]
  19. Price, N.D.; Zawodniok, M.J.; Guardiola, I.G. Transceivers as a Resource: Scheduling Time and Bandwidth in Software-Defined Radio. IEEE Access 2020, 8, 132603–132613. [Google Scholar] [CrossRef]
  20. GNU Radio. Available online: https://www.gnuradio.org/ (accessed on 10 September 2024).
  21. DASH7 Alliance. DASH7 Alliance Protocol Specification v1.2. Available online: https://www.dash7-alliance.org/download-specification/ (accessed on 10 September 2024).
  22. Norair, J. Introduction to DASH7 Technologies, 1st ed.; 2009; Available online: https://www.rfidjournal.com/wp-content/uploads/2019/07/269.pdf (accessed on 24 December 2024).
  23. Singh, R.K.; Puluckul, P.P.; Berkvens, R.; Weyn, M. Energy Consumption Analysis of LPWAN Technologies and Lifetime Estimation for IoT Application. Sensors 2020, 20, 4794. [Google Scholar] [CrossRef] [PubMed]
  24. Sklar, B. Digital Communications: Fundamentals & Applications, 2nd ed.; Prentice Hall: Upper Saddle River, NJ, USA, 2001. [Google Scholar]
  25. Lyons, R. Understanding Digital Signal Processing, 3rd ed.; Prentice Hall: Upper Saddle River, NJ, USA, 2011. [Google Scholar]
  26. Proakis, J.; Salehi, M. Digital Communications, 5th ed.; McGraw-Hill: New York, NY, USA, 2008. [Google Scholar]
  27. Mueller, K.; Muller, M. Timing Recovery in Digital Synchronous Data Receivers. IEEE Trans. Commun. 1976, 24, 516–531. [Google Scholar] [CrossRef]
  28. Joosens, D.; BniLam, N.; Weyn, M.; Berkvens, R. SDR-Based IoT Communication Systems: An Application for the DASH7 Alliance Protocol. Dataset Zenodo. 2024. Available online: https://zenodo.org/records/10961311 (accessed on 10 September 2024).
  29. Joosens, D.; BniLam, N.; Berkvens, R.; Weyn, M. Implementation of a Multi-Channel DASH7 IoT Communication System for Packet Investigation and Validation. In Proceedings of the GNU Radio Conference 2024, Knoxville, TN, USA, 16–20 September 2024. [Google Scholar]
  30. Semtech. SX1276/77/78/79–137 MHz to 1020 MHz Low Power Long Range Transceiver; Semtech: Camarillo, CA, USA, 2020; Available online: https://semtech.my.salesforce.com/sfc/p/#E0000000JelG/a/2R0000001Rbr/6EfVZUorrpoKFfvaF_Fkpgp5kzjiNyiAbqcpqh9qSjE (accessed on 10 September 2024).
  31. Weyn, M.; Ergeerts, G.; Wante, L.; Vercauteren, C.; Hellinckx, P. Survey of the DASH7 Alliance Protocol for 433 MHz Wireless Sensor Communication. Int. J. Distrib. Sens. Netw. 2013, 9, 870430. [Google Scholar] [CrossRef]
  32. Hoel, R. Design Note DN504: FEC Implementation; Texas Instruments: Dallas, TX, USA, 2007; Rev. SWRA113A; Available online: http://www.ti.com/lit/an/swra113a/swra113a.pdf (accessed on 10 September 2024).
Figure 1. Functional block diagram of a direct conversion or zero-IF-based SDR architecture. Note that the parallel lines indicate that this process is repeated; i.e., one flow is dedicated to the in-phase data stream and one flow to the quadrature data stream.
Figure 1. Functional block diagram of a direct conversion or zero-IF-based SDR architecture. Note that the parallel lines indicate that this process is repeated; i.e., one flow is dedicated to the in-phase data stream and one flow to the quadrature data stream.
Applsci 15 00333 g001
Figure 2. Concept of an in-phase and quadrature modulator and demodulator.
Figure 2. Concept of an in-phase and quadrature modulator and demodulator.
Applsci 15 00333 g002
Figure 3. Two−dimensional spectrogram of ten modulated DASH7 packets seen over a time span of 1.4 s and a bandwidth of 200 kHz.
Figure 3. Two−dimensional spectrogram of ten modulated DASH7 packets seen over a time span of 1.4 s and a bandwidth of 200 kHz.
Applsci 15 00333 g003
Figure 4. Three−dimensional spectrogram of ten modulated DASH7 packets seen over 1.4 s and a bandwidth of 200 kHz.
Figure 4. Three−dimensional spectrogram of ten modulated DASH7 packets seen over 1.4 s and a bandwidth of 200 kHz.
Applsci 15 00333 g004aApplsci 15 00333 g004b
Figure 5. DASH7 packet structure.
Figure 5. DASH7 packet structure.
Applsci 15 00333 g005
Figure 6. Packet to symbols conversion flowgraph. The data formatting box exploits three vector sources and a multiplexer block. The respective parameters control the values of the vector sources. The second blue-framed box implements the mapping of the bytes to real values. The byte’s parallel values are converted into a series of symbols, where the 0 b is represented by −1 and the 1 b is represented by 1. The mapped packet is presented in Figure 7.
Figure 6. Packet to symbols conversion flowgraph. The data formatting box exploits three vector sources and a multiplexer block. The respective parameters control the values of the vector sources. The second blue-framed box implements the mapping of the bytes to real values. The byte’s parallel values are converted into a series of symbols, where the 0 b is represented by −1 and the 1 b is represented by 1. The mapped packet is presented in Figure 7.
Applsci 15 00333 g006
Figure 7. DASH7-mappedpacket structure as seen in the time domain. The figure shows the preamble followed by the sync word and the whitened payload, respectively.
Figure 7. DASH7-mappedpacket structure as seen in the time domain. The figure shows the preamble followed by the sync word and the whitened payload, respectively.
Applsci 15 00333 g007
Figure 8. The upsampling process and shape filter process in GNU Radio, which is achieved with an interpolating FIR filtering.
Figure 8. The upsampling process and shape filter process in GNU Radio, which is achieved with an interpolating FIR filtering.
Applsci 15 00333 g008
Figure 9. The upsampled and pulse-shaped waveform as seen in the time domain.
Figure 9. The upsampled and pulse-shaped waveform as seen in the time domain.
Applsci 15 00333 g009
Figure 10. Flowgraph of the GFSK modulation. The FSK modulation mainly consists of an IIR filter with configurable taps that act as an integrator and a phase to complex value block.
Figure 10. Flowgraph of the GFSK modulation. The FSK modulation mainly consists of an IIR filter with configurable taps that act as an integrator and a phase to complex value block.
Applsci 15 00333 g010
Figure 11. Frequency response of a baseband-modulated DASH7 signal.
Figure 11. Frequency response of a baseband-modulated DASH7 signal.
Applsci 15 00333 g011
Figure 12. Fixed-frequency demodulator using recorded data while tuned to channel 0 using the Lo-Rate channel class.
Figure 12. Fixed-frequency demodulator using recorded data while tuned to channel 0 using the Lo-Rate channel class.
Applsci 15 00333 g012
Figure 13. Demodulation process. The phase is extracted from the data signal and consecutively accumulated while high-frequency noise is filtered out.
Figure 13. Demodulation process. The phase is extracted from the data signal and consecutively accumulated while high-frequency noise is filtered out.
Applsci 15 00333 g013
Figure 14. Final GNU Radio flowgraph, where the demodulated samples are time-synchronized and put through a matched filter. After this step, a tag is added when a correlation is found to a predefined preamble and sync word sequence. Finally, the message is PN9-decoded, a CRC check is applied, and the output will be printed to the console window.
Figure 14. Final GNU Radio flowgraph, where the demodulated samples are time-synchronized and put through a matched filter. After this step, a tag is added when a correlation is found to a predefined preamble and sync word sequence. Finally, the message is PN9-decoded, a CRC check is applied, and the output will be printed to the console window.
Applsci 15 00333 g014
Figure 15. Decoded output of a DASH7 packet with a length of 25 bytes as seen in the console window of GNU Radio. The packet has a payload of three bytes [0x00, 0xAB, 0xCD] followed by two CRC bytes.
Figure 15. Decoded output of a DASH7 packet with a length of 25 bytes as seen in the console window of GNU Radio. The packet has a payload of three bytes [0x00, 0xAB, 0xCD] followed by two CRC bytes.
Applsci 15 00333 g015
Figure 16. Indoor and suburban measurement setup consisting of three DASH7 nodes and three DASH7 gateways which send and receive on different Lo-Rate channels. The setup was extended with an Ettus Research (Austin, TX, USA) USRP B210 SDR, which received the transmissions of the DASH7 nodes and stored these transmissions as raw I/Q data. These captured data were investigated during post-processing analysis.
Figure 16. Indoor and suburban measurement setup consisting of three DASH7 nodes and three DASH7 gateways which send and receive on different Lo-Rate channels. The setup was extended with an Ettus Research (Austin, TX, USA) USRP B210 SDR, which received the transmissions of the DASH7 nodes and stored these transmissions as raw I/Q data. These captured data were investigated during post-processing analysis.
Applsci 15 00333 g016
Figure 17. A cabled measurement setup consists of a DASH7 gateway, a DASH7 node having a 40 dB attenuator and a Software-Defined Radio, which are connected through coaxial cables.
Figure 17. A cabled measurement setup consists of a DASH7 gateway, a DASH7 node having a 40 dB attenuator and a Software-Defined Radio, which are connected through coaxial cables.
Applsci 15 00333 g017
Figure 18. Map of the indoor measurement environment. The 10 TX locations are shown as green pins while the receiving setup, i.e., the SDR and DASH7 gateways, are positioned at the red RX pin. The office spans an area of 64 by 24 m.
Figure 18. Map of the indoor measurement environment. The 10 TX locations are shown as green pins while the receiving setup, i.e., the SDR and DASH7 gateways, are positioned at the red RX pin. The office spans an area of 64 by 24 m.
Applsci 15 00333 g018
Figure 19. Map of the suburban measurement environment. The 21 TX locations are shown as green pins while the receiving setup, i.e., the SDR and DASH7 gateways, are positioned at the red RX pin The blue marker indicates measurement point 21.
Figure 19. Map of the suburban measurement environment. The 21 TX locations are shown as green pins while the receiving setup, i.e., the SDR and DASH7 gateways, are positioned at the red RX pin The blue marker indicates measurement point 21.
Applsci 15 00333 g019
Figure 20. Overview of the relation between RSSI and distance for each received channel measured at the suburban environment. The “N” stands for NLOS locations.
Figure 20. Overview of the relation between RSSI and distance for each received channel measured at the suburban environment. The “N” stands for NLOS locations.
Applsci 15 00333 g020
Figure 21. An overview of the relationship between distance and packet loss based on measurements from the suburban environment. The data for each received channel were captured by the SDR. The “N” stands for NLOS locations.
Figure 21. An overview of the relationship between distance and packet loss based on measurements from the suburban environment. The data for each received channel were captured by the SDR. The “N” stands for NLOS locations.
Applsci 15 00333 g021
Figure 22. An overview of the relationship between distance and packet loss based on measurements from the suburban environment. The data for each received channel were captured by dedicated DASH7 gateways. The “N” stands for NLOS locations.
Figure 22. An overview of the relationship between distance and packet loss based on measurements from the suburban environment. The data for each received channel were captured by dedicated DASH7 gateways. The “N” stands for NLOS locations.
Applsci 15 00333 g022
Table 1. An overview of the physical layer characteristics of LPWAN technologies.
Table 1. An overview of the physical layer characteristics of LPWAN technologies.
Operating
Frequency
(MHz)
Bandwidth
(kHz)
Range
(km)
Data Rate
(kbps)
LoRaWAN433/868 (EU)125/250/5005 (urban)0.3–50
Sub-1 GHz915 (US) 20 (rural)
LoRaWAN2400203/4060.5 (urban)0.595–253.91
2.4 GHz 812/162510 (rural)
Sigfox868 (EU)0.1 (UL)10 (urban)0.1 (UL)
915 (US)0.1 (DL)40 (rural)0.6 (DL)
NB-IoTLicensed1801 (urban)150 (UL)
LTE bands 10 (rural)127 (DL)
D7AP433/868 (EU)25/2001–2 (urban)9.6/55.6
915 (US) 5 (rural)166.7
Table 2. Non-exhaustive list of common SDRs that can be used for the reception of LPWAN protocols.
Table 2. Non-exhaustive list of common SDRs that can be used for the reception of LPWAN protocols.
SDRFrequency
(MHz)
ADC/DAC
Resolution
Max. RF
Bandwidth
RF
Channels
Price
RTL-SDR Blog V324–17668-bit3.2 MHz1 RXlow
Great Scott Gadgets
HackRF one
1–60008-bit20 MHz1 TX/RXmedium
Analog Devices
ADALM-PLUTO
325–380012-bit20 MHz1 TX–1 RXmedium
Nuand
bladeRF 2.0 xA4
70–600012-bit56 MHz2 TX–2 RXmedium
Ettus Research
USRP B200mini
70–600012-bit56 MHz1 TX–1 RXmedium
Ettus Research
USRP B200
70–600012-bit56 MHz1 TX–1 RXmedium
Ettus Research
USRP B210
70–600012-bit56 MHz2 TX–2 RXhigh
Deepwave Digital
AIR7201-B
300–600014–16 bit100 MHz2 TX–2 RXvery high
Table 3. DASH7 channel bands. The stars in the table indicate the following: * Worldwide coverage with local regulatory limitations; ** EN 300 220 (Europe) with local regulatory limitations; *** FCC part 15 in the United States of America.
Table 3. DASH7 channel bands. The stars in the table indicate the following: * Worldwide coverage with local regulatory limitations; ** EN 300 220 (Europe) with local regulatory limitations; *** FCC part 15 in the United States of America.
RF BandLo-Rate (d)Normal and
Hi-Rate (d)
Start (b)End
433 MHz *0, 1, …, 680, 8, 16, …, 56433.06 MHz434.785 MHz
868 MHz **0, 1, …, 2790, 8, 16, …, 216,
229, 239,
257, 270
863 MHz870 MHz
915 MHz ***0, 1, …, 10390, 8, 16, …, 1032902 MHz928 MHz
Table 4. DASH7 channel classes.
Table 4. DASH7 channel classes.
ClassSymbol RateModulation IndexFrequency Deviation ( Δ f ) Channel Spacing (c)
Lo-Rate9.6 kbps1±4.8 kHz0.025 MHz
Normal55.555 kbps1.8±50 kHz0.2 MHz
Hi-Rate166.667 kbps0.5±41.667 kHz0.2 MHz
Table 5. DASH7 sync word classes and the possible applied Coding Schemes (CSs). Currently, only CS0 and CS2 are used. CS1 and CS3 are reserved for future use.
Table 5. DASH7 sync word classes and the possible applied Coding Schemes (CSs). Currently, only CS0 and CS2 are used. CS1 and CS3 are reserved for future use.
Sync Word ClassCoding Scheme
CS0CS1CS2CS3
00xE6D0RFU0xF498RFU
10x0B67RFU0x192FRFU
Table 6. Comparison of the packet loss found at each DASH7 gateway (GW) and packet loss in software (SDR) per location for three DASH7 Lo-Rate channels collected during the suburban experiment. Furthermore, the logged mean received signal strengths (GW mean RSS) at each DASH7 gateway and the gateway-to-node distance are shown.
Table 6. Comparison of the packet loss found at each DASH7 gateway (GW) and packet loss in software (SDR) per location for three DASH7 Lo-Rate channels collected during the suburban experiment. Furthermore, the logged mean received signal strengths (GW mean RSS) at each DASH7 gateway and the gateway-to-node distance are shown.
CH 0CH 93CH 186
LocationGW Mean RSSGW Packet lossGRC Packet lossGW Mean RSSGW Packet lossGRC Packet lossGW Mean RSSGW Packet lossGRC Packet lossDistance(N)LOS
(dB)(%)(%)(dB)(%)(%)(dB)(%)(%)(m)
1−91.313550−93.16510−89.30060806NLOS
2−94.643030−83.65075−94.350100631NLOS
3−71.4750−76.8000−77.2000565LOS
4−78.7450−67.0000−70.5000556LOS
5−70.3555−67.8000−76.7000558LOS
6−68.5500−68.7500−69.6000590LOS
7−61.3000−67.6500−77.8000572LOS
8−85.281010−81.2005−90.941515643NLOS
9−66.8000−64.3500−73.55015663LOS
10−89.5350−75.40040−81.3755725NLOS
11−88.18450−84.0050−74.9505789NLOS
12−77.671010−76.8000−83.80010833NLOS
13−93.643080−88.821535−89.21510889NLOS
14−81.90510−88.5500−82.30015973NLOS
15−83.2000−94.132530−85.7000997LOS
16−91.296555−87.80015−87.424025944NLOS
17−70.6500−67.7000−66.60001070LOS
18−88.11530−85.25010−90.055501240NLOS
19−67.4500−63.9500−64.8500940LOS
20−93.0040100//15−90.7560751180NLOS
21/100100/100100/1001001260NLOS
Table 7. Mean received signal strength and packet loss per location for three DASH7 Lo-Rate channels collected during the indoor experiment.
Table 7. Mean received signal strength and packet loss per location for three DASH7 Lo-Rate channels collected during the indoor experiment.
CH 0CH 93CH 186
LocationGW Mean RSSGW Packet LossSDR Packet LossGW Mean RSSGW Packet LossSDR Packet LossGW Mean RSSGW Packet LossSDR Packet loss(N)LOS
(dB)(%)(%)(dB)(%)(%)(dB)(%)(%)
1−27.4500−22.3500−31.2000LOS
2−32.1500−36.591520−40.6005NLOS
3−58.7000−60.3500−51.5500NLOS
4−92.573025−80.9500−90.391010NLOS
5−83.7950−78.4500−89.2005NLOS
6−76.8000−76.1000−97.60505NLOS
7−67.8500−60.8000−62.5000NLOS
8−60.2600−64.7900−64.9500NLOS
9−61.8450−66.5000−66.8000NLOS
10−58.9500−40.7000−45.0000NLOS
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Joosens, D.; BniLam, N.; Berkvens, R.; Weyn, M. Software-Defined Radio-Based Internet of Things Communication Systems: An Application for the DASH7 Alliance Protocol. Appl. Sci. 2025, 15, 333. https://doi.org/10.3390/app15010333

AMA Style

Joosens D, BniLam N, Berkvens R, Weyn M. Software-Defined Radio-Based Internet of Things Communication Systems: An Application for the DASH7 Alliance Protocol. Applied Sciences. 2025; 15(1):333. https://doi.org/10.3390/app15010333

Chicago/Turabian Style

Joosens, Dennis, Noori BniLam, Rafael Berkvens, and Maarten Weyn. 2025. "Software-Defined Radio-Based Internet of Things Communication Systems: An Application for the DASH7 Alliance Protocol" Applied Sciences 15, no. 1: 333. https://doi.org/10.3390/app15010333

APA Style

Joosens, D., BniLam, N., Berkvens, R., & Weyn, M. (2025). Software-Defined Radio-Based Internet of Things Communication Systems: An Application for the DASH7 Alliance Protocol. Applied Sciences, 15(1), 333. https://doi.org/10.3390/app15010333

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop