## 5 DASH7 Communication System Implementation
### The Transmitting Process
#### 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  
Figure 5: DASH7 packet structure.  
\begin{table}
\begin{tabular}{l c c c c} \hline \hline \multirow{2}{*}{**Sync Word Class**} & \multicolumn{4}{c}{**Coding Scheme**} \\ \cline{2-5}  & **CS0** & **CS1** & **CS2** & **CS3** \\ \hline
**0** & 0 xE6D0 & RFU & 0 xF498 & RFU \\ \hline
**1** & 0x0B67 & RFU & 0x192F & RFU \\ \hline \hline \end{tabular}
\end{table}
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.  
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 Appendices A and C, respectively. Optionally, a \(\frac{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., \"0b101010\". 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.  
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.