# Research on Secure Debugging Interaction of Sensor Nodes Based on Visible Light Communication
## 6 Evaluation
### Transmission Rate under Different Debugging Cases  
In downlink, we conduct a series of experiments about updating code blocks from five different functions shown in Table 2. These blocks are stored as binary files. The timing and LS Ctrl function relative to controlling sensor node. Bubble sort, Dijkstra, and Horspool are all sort algorithms. As shown in Figure 7, we compressed each of the five code blocks with traditional Huffman and our method, and Table 2 gives the compression rate and time of the five blocks with our compression method. After using our compression method, the code block size is reduced at least 8%, especially in Timing Fun with 16% reduction. From Figure 7, the average compression rate of our method has reached 86.8%. The reason is that the difference of operands of instructions makes binary codes appear irregular, and using Huffman is difficult to compress these irregular codes. In addition, Huffman needs to maintain a dictionary in the sensor node and occupy the precious RAM of the node. And if the sensor node does not have a corresponding dictionary, an additional dictionary will be transmitted by downlink, which reduces the transmission efficiency. The transmission rate of ODH-PIM is given in Figure 8a. We compared ODH-PIM with DH-PIM. In order to neatly compares, these two methods are used to transmit origin code without compression. In most cases of transmitting code blocks, our method is better than DH-PIM. Especially in the Timing Fun case, ODH-PIM is 25.8% faster than DH-PIM because ODH-PIM can effectively reduce a symbol's length. In the Bubble Sort Fun case, we found that ODH-PIM needs more slots when a large number of consecutive zero existing in binary codes, and the transmission rate of ODH-PIM remains about 3.9% below DH-PIM. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Function Name** & **Brief** & **Size (Bit)** & **Compression Rate** & **Compression Time (s)** \\ \hline Timing Fun & Control timer & 904 & 84.62\% & 0.47 \\ Bubble Sort Fun & Data sorting & 232 & 78.84\% & 0.21 \\ Dijkstra Fun & Find the shortest path & 1744 & 90.94\% & 0.76 \\ LS Ctrl Fun & Control light sensor & 1848 & 87.87\% & 0.84 \\ Horspool Fun & Character match & 1184 & 92.14\% & 0.56 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Compression information. In the uplink, we test OOK, DH-PIM, and modified DH-PIM by transmitting feedback data in five different debugging cases. It is obviously that the amount of transmitted data using DH-PIM cannot exceed using OOK under same slots. As shown in Figure 8b, the transmission rate of OOK is faster than DH-PIM. The modified DH-PIM has a slightly higher transmission rate than DH-PIM, and its BER is significantly lower than that of DH-PIM. Figure 9 shows the debugging completion time, which consist of downlink/uplink transmission, compression and local rebuilding time. We complete VLC-based debugging interaction under outdoor and indoor environments with different ambient light intensity. The whole procedure of debugging interactions includes: (1) The node sends the message \"Update: xx fun\" to the smartphone; (2) the smartphone firstly compresses the code block of the corresponding function (the size of code blocks is shown in Table 2), and then transmits the compressed data to the sensor node; (3) the sensor node decompresses the received data and locally rebuilds the program image. As shown in Figure 9, the most time-consuming process is the transmission of the debugging codes. In contrast, the code block's compression occupies a small time period due to the computing power of smartphone. The debugging completion time in the indoor environment is 15% less than the time in the outdoor environment on average. Ambient light impacts uplink/downlink transmission and increases frame errors. To deal with frame errors requires extra retransmitting frame and prolong uplink/downlink transmission in outdoor environment. Moreover, the rebuilding time is relative to the size of the debugging code.