# Development of a Power and Communication Bus Using HIL and Computational Intelligence
## 4 Auto Addressing Method
### Test Description  
The first research stand was constructed by using one master and four clients. This small application was used to set up many options, such as signal flow, measure strategy, software on clients and master, objective functions in MATLAB and so forth. After the first test, specifically where changing setup or software on clients was very fast, the authors decided to expand the research stand. Twenty prototype boards were ordered, in the case of an unpredicted problem only 15 boards were used to build the test setup. With five boards, everything works correctly using Rpi as the MQTT server and AP. With this setup, the authors adjusted all parameters to optimize communication between nodes, where 2 Mbps was achieved. All parameters of communication were adjusted using well-known laboratory equipment and engineering knowledge.  
The next step was to build up a research stand for 15 boards and find parameters of auto-addressing, which finally was even more difficult than the authors expected. Unfortunately, the stability of AP on Rpi was unsatisfactory when all 15 nodes sent the report after the test (exactly at the same time). The report contains 1500 measured parameters. The behaviour was diagnosed by MQTT.fx--external tool. It necessitated the use of additional AP, where the Mikrotik RouterBoard was selected, then all frames could be received by the computer with the MQTT.fx and MATLAB environment installed in it. The last issue the authors had to tackle was the MQTT library written in Java for the MATLAB environment because it lacked speed to process all frames from MQTT. The standard solution is to increase Quality Of Service (QOS) in MQTT frames. The disadvantage of this solution is, however, the extended time of sending each measurement. Therefore, in the case of planned 500 k-1 mln tests, another solution was selected. A two-thread script was written in Python, and ran on Rpi. One thread handled receiving and decoding MQTT frames from the JSON format, the other one analysed data, and after the finished test, it collected all data into one frame which was then sent to Matlab. This configuration made the research stand and data flow concept more complicated, but significantly reduced the time of a single measurement, and guaranteed almost 100% data correctness. The only programmed delay (Figure 6, p. 4) was to synchronize all nodes.  
\begin{table}
\begin{tabular}{l l l l l l l} \hline \hline  & **Master** & **Client1** & **Client2** &... &
\begin{tabular}{l} **Client** \\ **n\(-\)1** \\ \end{tabular} & **Client n** \\ \hline R0 & 1 & 0 & 0 &... & 0 & 0 \\ \hline R1 & 1 & 1 & 0 &... & 0 & 0 \\ \hline R2 & 1 & 1 & 1 &... & 0 & 0 \\ \hline � & � & � & � & � & � & � \\ \hline Rn\(-\)1 & 1 & 1 & 1 &... & 1 & 0 \\ \hline Rn & 1 & 1 & 1 &... & 1 & 1 \\ \hline \hline \end{tabular}
\end{table}
Table 4: The 3 rd strategy.  
The authors prepared a special program in the MATLAB environment, which received input data of 15 variables, where artificial algorithms (AA) try to find optimal values and many static values, such as strictly hardware dependent parameters, or the component cost of LC terminators. The communication between all components of the stand is shown in Figure 6. The MATLAB environment code is responsible for building up MQTT frames. All frames are sent to boards and Rpi. Client boards after receiving frames with an individual configuration (Figure 6 frame 3) are set to wait for a trigger from the master. To avoid any problems with synchronization, the software waits 200 ms (Figure 6 p. 4) before the data publish the start of the test frame (Figure 6 frame 5). After the test, the boards publish the measured data, which are collected by Rpi to one frame (Figure 6 frame 9), which is published by Rpi, and subscribed by the MATLAB environment (Figure 6 frame 10).