A Wireless Ad Hoc Network Communication Platform and Data Transmission Strategies for Multi-Bus Instruments

Abstract

As automatic test technology advances, the number of programmable instruments in a single test system increases. Traditional wired communication methods have a limited range and involve complex cable layouts. Single-function wireless converters provide a viable alternative, but they have limitations. These include complicated configuration, issues with multi-system collaboration, and data blocking. This paper proposes a wireless ad hoc network platform for multi-bus instruments based on a low-cost ESP-12H WiFi module. The platform supports GPIB, RS232, RS485, and CAN bus interface instrument access. It features easy configuration, ad hoc networking, and self-repairing capabilities. A relay multi-hop network with a tree topology expands capacity and coverage. Additionally, a dynamic window-receiving mode and an improved multi-priority queue ensure data transmission integrity. The experimental results show that the platform’s networking time is less than 10 s, and the coverage range reaches 50 m in complex indoor environments. It also shows good stability when running for a long time. However, due to hardware and software design limitations, the actual upload speeds fall short of the theoretical values. For example, RS232 and RS485 are about 10% slower than the theoretical values, and GPIB is about 80% slower. Further optimization is required in the future.

1. Introduction

With the development of measurement science, automatic test systems are widely used in various fields. Most automated measurement systems use instruments that are compatible with VISA (Virtual Instrument Software Architecture). These instruments connect to a host computer through standard wired buses such as USB (Universal Serial Bus), GPIB (General-Purpose Instrumentation Bus), LAN (Local Area Network), RS232, RS485, or Ethernet, and execute commands from the host [1,2,3,4,5,6]. Wired measurements limit the flexibility of reconfiguring multi-instrument systems. This prevents the implementation of wide-area flexible measurement systems. Consequently, the wireless upgrading of automatic test systems has garnered significant attention [7,8,9].

Several instrument manufacturers have introduced proprietary solutions. For example, Agilent’s E5810B gateway connects to a wireless router via a LAN port. It enables the remote control of instruments with GPIB, RS232, and USB interfaces [10]. However, the gateway still requires a wired connection to the router. In 2014, Tektronix launched a wireless lab instrument management tool. It uses USB-WIFI converters for the remote control of instruments via special software [11]. However, this solution is limited to Tektronix and Keithley USB test equipment and is not universally applicable. The authors of [12,13] developed a low-cost, Bluetooth-based wireless converter for instruments. It is a cheaper alternative to commercial solutions. This converter supports RS232, GPIB, USB, and LAN buses. However, the converter is limited by traditional Bluetooth technology. It can only support up to seven sub-devices at the same time. Also, its range is limited to 10 to 50 m, especially indoors with two obstacles. To improve wireless test systems, refs. [14,15] introduced a four-port USB gateway. It uses a low-cost Raspberry Pi Zero W single-board computer (SBC). This solution improves scalability, coverage, and accessibility, and it supports fewer interface types than the E5810B gateway. However, it offers a significant advantage: you can download the entire measurement process to the gateway and run it on the instrument.

In summary, WiFi is better than Bluetooth for wireless test systems. It has a wider range and supports multiple devices. Under IEEE 802.11, there are two types of wireless network configurations: ad-hoc and infrastructure [16]. Traditional infrastructure wireless networks often rely on existing network infrastructure. They require separate configurations for each node. This limits the flexibility of using various public instruments to build test systems. In contrast, a wireless ad hoc network is a temporary, multi-hop system comprising mobile nodes with wireless transceivers. It can quickly establish a communication network without fixed infrastructure.

In this paper, a wireless ad hoc network communication platform is constructed based on a commercial Wi-Fi SoC (System-on-Chip) module. The platform solves the problem of the complex configuration process when the test system is set up. Based on the ESP-WIFI-MESH scheme supported by the Wi-Fi module, a multi-level tree topology is created to enhance the platform’s capacity and coverage. Additionally, a self-repairing capability is developed to prevent disruptions caused by node failures. This improves the robustness of the platform. As the number of nodes increases, data transmission issues emerge, which will be analyzed and addressed in detail in Section 4. The optimized data transmission strategy addresses common issues such as buffer overflow and queue blockage, improving the reliability and stability of data transmission.

The rest of the paper is organized as follows: Section 2 introduces the architecture and networking methods of the ad hoc network communication platform. Section 3 provides an in-depth description of the hardware design and control mode of the bus protocol converter. In Section 4, we analyze and address data transmission issues. Section 5 presents the overall performance test of the platform. Section 6 concludes the paper and suggests directions for improvement in future research.

2. Design of Ad Hoc Network Communication Platform

To address the requirements of multi-node network communication, in this section, we first examine the platform structure and its ad hoc network methodology. Additionally, we formulate the self-repair process for when some nodes are damaged.

2.1. Platform Structure and Ad Hoc Network Method

Traditional infrastructure wireless networks employ a point-to-multipoint structure, with a central access point (AP) connecting all other nodes. In contrast, ad hoc networks allow nodes to connect to neighboring nodes without requiring direct connections to the AP. However, this less structured design requires algorithms to ensure efficient communication. ESP-WIFI-MESH, a network protocol based on ad hoc configuration, is supported by the Wi-Fi module of this platform. In ESP-WIFI-MESH, each node is responsible for relaying data to the connected nodes, creating a multi-hop relay network [17]. This approach overcomes the limitations of root node distance and capacity [18,19]. Each node autonomously builds the network, forming a multi-level tree topology, as shown in Figure 1.

The specific networking process of each node is shown in Figure 2 and begins when a new node is enabled. First, the node checks for the existence of the corresponding networking platform. If the networking platform already exists, the network strength between the new node and the existing nodes is checked. The new node connects as a child node to the existing node that has the strongest network strength. Otherwise, the node is defined as a pending node. When there are multiple pending nodes, the signal strength between each one and the AP is measured. The pending node with the highest signal strength is taken as the root node, and the other nodes are configured as the child nodes. All nodes form a tree topology, establishing wireless connections in levels based on network strength. The plug-and-play AP connects to the computer via a USB port to facilitate remote control. When the communication network is established, all nodes send heartbeat packets to the computer to confirm the connection. Each node stores a link table of its subordinate nodes. The root node’s link table includes all nodes in the network. This allows for directed data transmission across the entire network. Whenever the network structure changes, such as a node joining or leaving, the link table is updated synchronously.

2.2. Self-Repairing Capability

Given the variety of public instruments in the laboratory, it is necessary to integrate them into distinct test systems based on specific requirements. To avoid confusion, the node’s network name, port number, and ID number are configured to map the instruments in different test systems. Specifically, the network name determines which access point (AP) the node connects to, corresponding to different control computers. The port number distinguishes multiple sub-test systems controlled by the same computer. Within each sub-test system, every node is assigned a unique ID number to avoid communication collisions.

The relay multi-hop network helps transmit data. However, if relay nodes fail, it can cause platform failure and interrupt data transmission. Therefore, this paper proposes a self-repair mechanism. If the computer fails to receive heartbeat packets from all nodes, it will assume the root node is corrupted. The platform then nominates a new root node for reconstruction based on signal strength. Similarly, if a node’s heartbeat packet is lost, the link table can be used to infer the damage to the upper node. The affected child nodes will re-establish connections with other normal nodes.

3. Bus Protocol Converters

To ensure the communication platform’s compatibility with various communication interfaces, a range of protocol converters were designed. The converter design involves hardware structure and software control logic.

3.1. Converter Hardware Structure

Four specialized wireless communication, converters were developed for GPIB, RS232, RS485, and CAN bus protocols. All the converters adopt a similar design, which is composed of a WiFi module, a processor module, an interface logic module, a power module, a dial switch module, and a communication interface module. The ESP-12H WiFi module, developed by AI-Thinker (Shenzhen, China), is used in all converters. Priced at just CNY 10, it offers excellent performance and low price. The core of this module is the ESP32-S2F WiFi SoC chip from Espressif (Shanghai, China). The chip supports the ESP-WIFI-MESH protocol. It supports up to 1000 nodes in tree topology and offers advantages such as easy deployment, self-organization, and self-repair. The ESP32-S2F also has an LX7 processor for secondary development. In the RS232, RS485, and CAN converter designs, the built-in LX7 processor is used to realize data packaging, transmission, and parsing. In contrast, the GPIB converter uses an additional STM32F103RCT6 processor. The processor module pre-stores the network information for the platform’s ad hoc network. This includes the network name; port number; ID number; and communication interface parameters like baud rate, parity bit, and stop bit. The dial switch module allows for the convenient configuration of the aforementioned parameters. The interface logic module primarily adapts to the electrical specifications of various communication buses. For example, the GPIB converter uses the NAT9914, SN75160, and SN75162 chips for protocol management and interface driving. Figure 3 shows the appearance and internal structure of the GPIB converter.

3.2. Converter Control Logic

Each of the four converters includes three basic functions: ad hoc network construction, command issuance, and data uploading. The corresponding control logic is shown in Figure 4. When the converter is powered on, it first establishes a tree topology network following the method described in Section 2.1. Each node keeps its own link table and uploads heartbeat packets. Packets transmitted in the platform follow a standard format: ’Type + ID + Data’. During command issuance, the root node first verifies if the ID in the data packet matches its own. If it does, the root node sends the parsed commands to the connected instrument. If not, the packet is forwarded step by step to the destination node according to the link table. For data uploading, each node first requests a data upload window from its connected relay node. It then packages the data into standard packets, which are transmitted sequentially by the relay node.

4. Data Transmission Strategy

To ensure the reliability of data transmission in the communication platform, this study investigates the data transmission strategy. It identifies the main problems and proposes corresponding measures.

4.1. Issues in Data Transmission

In network communication, the main challenges in data transmission occur during the data upload stage. On the one hand, large data packets can cause a data buffer overflow in the processor, increasing the risk of data loss. On the other hand, when multiple nodes upload heartbeat packets and instrumentation packets simultaneously, they can lead to data congestion. Specifically, the heartbeat packet checks the link’s integrity. The instrumentation packet contains all kinds of data returned by the instrumentation. To address the above problems, this paper proposes an optimized data transmission strategy to improve data transmission reliability.

4.2. Approaches to Optimize Large Data Packet Transmission

This paper proposes a dynamic window receiving mode to address the issue of large packet transmission. As shown in Figure 5, when a child node needs to upload data, it initially requests a data upload window from the relay node. Based on the remaining buffer capacity, the relay node allocates the size of the data window and provides feedback to the child node. The child node then splits the data packets and continues requesting subsequent data windows until the transmission is complete.

4.3. Approaches to Optimize Data Packet Conflicts

To solve the problem of data blocking, various queuing mechanisms are commonly used, including First In First Out (FIFO), Priority Queue (PQ), Custom Queue (CQ), and Weighted Fair Queue (WFQ) [20,21]. FIFO is the simplest mechanism, processing packets in the order they arrive [22]. However, it does not prioritize packets, which can increase jitter and delay, making it unsuitable for low-latency data. The system in classic PQ categorizes packets and places them in different priority queues. Low-priority queues are served only if all queues of higher priority are empty [23]. This can cause low-priority packets to experience infinite delay, which is known as starvation [24]. By guaranteeing minimum service rates for each queue, CQ excels over PQ and prevents starvation. However, CQ lacks a high-priority queue that is always serviced first, meaning that it cannot guarantee low-latency service for any packets. WFQ assigns a weight to each queue, which controls the service rate received by each queue. However, WFQ’s scheduling is completely automated and cannot be tuned. To overcome these limitations, this paper proposes an enhanced multi-priority queuing mechanism called the PC mechanism.

In the PC mechanism, the queuing priority can be expressed as follows:

$$P=10D+M+X$$

(1)

P stands for the queuing priority, with smaller values indicating higher priority. D denotes packet priority, where values 1 and 2 correspond to the heartbeat and instrumentation packets, respectively. M signifies instrument priority, which has 10 levels, determined by the importance of the instrument in the test system. X represents the interface priority, with values from 1 to 4 assigned to RS232, GPIB, CAN, and RS485 based on interface usage and transfer rate.

As illustrated in Figure 6, the buffer queues in the PC mechanism are categorized into regular and starvation queues, with service rates of 75% and 25%, respectively. When the starved queue is empty, the buffer only serves the normal queue. The regular queue is further divided into high-, medium-, and low-priority sub-queues. When the high-priority queue is empty, the service rates for the medium- and low-priority queues are 70% and 30%, respectively. Within the sub-queue, data transmission follows the PQ mechanism. When packets in the regular queue surpass the starvation threshold, they are moved to the starvation queue, which utilizes the FIFO mechanism. This setup reduces the probability of congestion in the low-priority queue due to the lack of service. Note that the service rate distribution and starvation threshold can be adjusted. They depend on the actual application requirements.

4.4. Validation of Optimized Data Transmission Strategy

4.4.1. Validation of the Dynamic Window Receiving Mode

To verify the dynamic window receiving mode, we conducted simulations using MATLAB 2018. These simulations analyzed packet loss and transmission rates at various speeds, testing both the normal and dynamic window receiving modes. Each simulation involved 1000 packets, with each packet size following a Poisson distribution with a mean of 2 kbits. The detailed simulation parameters are listed in

Table 1. MATLAB simulation parameters.

Name	Size
Packet generation interval	1 s
Buffer size	5 kbit
Buffer processing rate	1.5 kbps/1.6 kbps/1.7 kbps/1.8 kbps/1.9 kbps
Link transmission rate	1 Mbps

.

Figure 7a shows that packet loss occurs in the normal reception mode, and the lower the processing rate, the higher the packet loss rate. In contrast, the dynamic window receiving mode does not experience packet loss. However, as shown in Figure 7b, this mode reduces the data transfer rate. This is due to the extra time spent requesting data windows and splitting packets. This is acceptable in most non-high-speed testing scenarios where data transmission integrity is prioritized.

4.4.2. Validation of the PC Mechanism

To verify the effectiveness of the PC mechanism in preventing data blocking, it was compared with the PQ mechanism using OPNET 14.5 simulation software [25]. All nodes upload their data to the computer through the root node, which has the highest probability of data blocking. We analyzed the root node’s packet loss rate and transmission delay under different queuing mechanisms. The network topology used for simulation is shown in Figure 8, including a server node, a root node, multi-hub nodes, and multi-priority (prio) nodes. The server node is the data transmission destination, and the root node actively forwards data packets from all nodes to the server. The hub node acts as a relay, forwarding packets from child nodes and generating its own medium-priority packets. The prio nodes, which are ordinary child nodes, are divided into three levels, each producing packets with high, medium, or low priority. During the simulation, the buffer queue processing rate at the root node was set to 1 Mbps. The capacity of all sub-queues was 5 Mbit, and the starvation threshold was set at 3 s. Additional simulation parameters are detailed in

Table 2. OPNET simulation parameters.

Name	Interval	Size
prio_h	1 s	40 kbit
prio_m	1 s	30 kbit
prio_l	0.5 s	20 kbit
hub	1 s	30 kbit

. The simulation duration was 100 s.

The simulation results of the data throughput of the root node under different queuing mechanisms are shown in Figure 9. In the PQ mechanism, the arrival curves and processing curves of high- and medium-priority packets almost overlap. This shows that these packets are served promptly. However, the arrival curve for low-priority packets always exceeds the processing curve, indicating a delay in data transmission. Even after 75 s, this results in data loss. This trend is also evident in the average delay statistics shown in Figure 10c. In contrast, the packet arrival and processing curves of the three priorities of the PQ mechanism are almost consistent. In the average delay test, the PQ mechanism shows a lower average delay than the PC mechanism, particularly for low-priority sub-queues. The PC mechanism’s low-priority queue exhibits significantly higher delays than the high- and medium-priority queues, as shown in Figure 10. This phenomenon is primarily caused by the rates of service and starvation thresholds.

5. Platform Performance Test

To evaluate the effectiveness of the communication platform, various experiments were designed to assess key performance metrics. These metrics included the networking time, self-repairing capability, coverage, upload rate, and data transmission stability.

5.1. Networking Performance

To assess the networking time of the communication platform, a test platform was established, as depicted in Figure 11. Computers and converters were arranged in sequence with a one-meter interval between each. Nodes 1 to 4 were the GPIB converter, RS232 converter, RS485 converter, and CAN converter. The root node was selected based on signal strength. Since node 1 had the strongest signal due to its proximity to the computer, it was identified as the root node. The other nodes were connected in turn, resulting in a straight-line network structure with one-to-one connections. During the test, all nodes were powered on simultaneously, and the connection time for each node was recorded based on when the computer received their heartbeat packets. The results of twenty repeated trials are shown in Figure 12a, indicating that the average time for a node to access the network is approximately 10 s. Notably, the root node’s access time is slightly longer than the others. This is because it uploads the heartbeat packet after storing the link table of all child nodes.

In the test platform depicted in Figure 11, we turned off the power of nodes 1, 2, and 3 in turn to simulate node failure and verify the self-repair ability of the platform. The time taken from powering down a child node to when the computer received a heartbeat packet from its subordinate was recorded. The results of 20 repeated experiments are illustrated in Figure 12b. Notably, the system required a longer repair time of approximately 10 s when the root node failed, compared to about 4.5 s for child node failures. This increased time is attributed to the necessity of electing a new root node and re-establishing the ad hoc network.

To test the communication platform’s coverage in a complex environment, as shown in Figure 13, we chose a laboratory with typical obstacles, like glass and concrete walls. The results are presented in

Table 3. Single-node connection’s coverage test results.

Distance/m	Indoor No Obstacle	One Glass Wall	One Concrete Wall	Two Concrete Walls
5	100%	100%	100%	/
10	100%	100%	100%	0%
50	100%	/	0%	0%

In this table, the slash ‘/’ indicates the lack of corresponding experimental conditions.

. If the platform has one root node and one child node, effective communication is hindered if they are either 10 m apart with two cement walls or 50 m apart with one cement wall. However, accessing a relay node can establish reliable communication in all test scenarios, as shown in

Table 4. Relay-node connection’s coverage test results.

Distance/m	Indoor No Obstacle	One Glass Wall	One Concrete Wall	Two Concrete Walls
5	100%	100%	100%	/
10	100%	100%	100%	100%
50	100%	/	100%	100%

In this table, the slash ‘/’ indicates the lack of corresponding experimental conditions.

. This shows that relay nodes increase coverage and prevent connection issues from obstacles.

5.2. Upload Rate

To evaluate the data upload rates of various wireless bus protocol converters, a testbed was constructed, as depicted in Figure 14. The test setup included a Keysight 3458A instrument connected to a GPIB converter. The RS232, RS485, and CAN converters were linked to computer 1 via a USB converter. The host computer software on computer 1 simulated data transmission from the instrument. Each converter was tested individually, establishing wireless communication directly with computer 2.

Figure 15 shows the test results. The X-axis is the baud rate set by the converter. The Y-axis is the data upload rates captured by Wireshark on computer 2. Due to limitations in the internal chips of the USB-RS232 and USB-RS485 converters, the maximum testable baud rate was 1 Mbps. Figure 15 shows that the RS232 and RS485 converters had upload rates that closely matched their theoretical baud rates. The CAN converter’s software on the host computer can only send 8-bit data frames at 1-millisecond intervals, which limits the maximum sending rate to 8 kbps. The measured data upload rate of the CAN converter is consistent with this rate. The upload rate of the GPIB converter is approximately 200 kbps, which is lower than its theoretical maximum. This is mainly due to the processor’s frequent manipulation of the NAT9914’s registers.

5.3. Stability of Data Transmission

5.3.1. Practicality of Data Transmission

To verify the practicality of data transmission, it was compared to the traditional wired method. Due to the complexity of the GPIB transmission protocol, we chose the wireless GPIB converter and GPIB-USB-HS cable from National Instruments (Austin, TX, USA) for comparison testing. We used the Keysight 33220A Waveform Generator (Santa Rosa, CA, USA) to create a sine waveform with an amplitude of 100 mVpp and a frequency of 10 Hz. the Keysight 3458A Digital Multimeter (Santa Rosa, CA, USA) collected data at a frequency of 1000 Hz. The waveform data obtained by the GPIB converter are shown in Figure 16. The 3458A was set to acquire 100 points with a single trigger, resulting in a complete cycle of waveform data. The figure shows that the waveform is uniform, smooth, and complete. The data quality is comparable to that of the wired method, validating the reliability of data transmission. However, when triggered several times to acquire multi-cycle data, the time to obtain valid data is significantly higher than with the wired method. This is due to the insufficient hardware design of the GPIB converter and the limitations of the data transmission rate, which need further improvement.

5.3.2. The Targeted Testing of Data Transmission Problems

For this test, three testbeds were set up, as shown in Figure 17, to evaluate the optimized data transmission strategy under the conditions of large data packets, conflicts between heartbeat and instrument packets, and multi-node synchronous communication conflicts.

The root node in the testbed shown in Figure 17a was the RS232 converter, which had a 512-byte buffer. Computer 2 sent a 1000-byte packet to simulate the buffer overflow. The statistical analysis of 100 repeated tests showed that computer 1 consistently received the entire 1000 bytes of data. This shows that the dynamic window receiving mode proposed in this paper works. It ensures the integrity of large data packet transmissions.

As depicted in Figure 17b, two RS232 converters were used to establish the communication network, with converter 1 as the root node and converter 2 as the child node. In ten minutes, computer 2 sent 60,000 data packets of 50 bytes each to converter 2 at 10-millisecond intervals. Both converters sent heartbeat packets every 3 s, for a total of 400 uploads. The test results indicate that computer 1 received all data packets without any errors or corruption. This means that the PC mechanism in this paper can effectively reduce collisions between heartbeat and instrument packets.

Figure 17c shows a small tree topology network. It comprised one GPIB module, four RS232 modules, one RS485 module, and one CAN module. The GPIB converter, as the root node, was connected to the Keysight 33220A Waveform Generator. The other six converters were connected to computers using USB converters. Computer 1, serving as the host computer, issued the SCPI query command ‘*IDN?’ to the GPIB converter. Meanwhile, the computer connected to the RS485 converter manually transmitted 20 KB data packets to it at irregular intervals. The computers connecting to the other converters were set to the timing transmission mode, sending a data packet of 10 bytes per second. The test lasted five minutes in total. Statistics on the actual data packets sent and received by each converter are shown in

Table 5. The simulated blocking test results.

Networking Module	Baud Rate	Sent Count	Received Count	Packet Loss Rate
GPIB	115,200	301	301	0%
RS232(1)	115,200	301	301	0%
RS232(2)	9600	299	299	0%
RS232(3)	921,600	299	299	0%
RS232(4)	460,800	298	298	0%
RS485	115,200	20	20	0%
CAN	115,200	296	296	0%

. The table shows that, in a synchronous transmission of multiple nodes, the data success rate is 100%. This proves that the PC mechanism is reliable.

5.3.3. Long-Term Stability Testing

Given the need for the automatic test system to operate for extended periods, it is essential to test the long-term stability and reliability of the communication platform. As shown in Figure 18, computer 1 served as the host and communicated with eight converter modules through networking. These modules encompassed all types of interface converters. Some converters were connected to typical instruments, such as the Keysight 3458A Digital Multimeter, Fluke 8508A Digital Multimeter (Washington, DC, USA), Keysight 33220A Waveform Generator, and ASL F200 Precision Thermometer (WIKA, Lawrenceville, GA, USA). To better simulate the actual application scenarios, the host randomly extracted commands from the command library at varying intervals. Since all the instruments operated in the response mode, the long-term communication quality of the platform was assessed by counting the number of complete data packets returned by each node. The test results, presented in

Table 6. The long-term stability test’s experimental results.

Networking Module	Sent Count	Received Count
GPIB 1 (3458A)	15,364	15,364
GPIB 2 (8508A)	15,282	15,282
GPIB 2 (33220A)	17,379	17,379
RS232 1	40,466	40,466
RS232 2 (F200)	17,286	17,286
RS232 3	40,383	40,383
RS232 4	20,182	20,182
RS485	40,451	40,451
CAN	4050	4050

, show no communication failures during 12 h of continuous testing. This demonstrates the platform’s reliability.

6. Conclusions

In this study, we developed four types of converters based on the low-cost commercial ESP-12H WiFi module, supporting GPIB, RS232, RS485, and CAN bus protocols. The configuration process can be simplified by selecting pre-stored networking information and interface parameters through dip switches. With the help of the ESP-WIFI-MESH protocol, a multi-bus instrument network platform with tree topology and multi-hop relay properties was constructed. In the networking performance experiments, the platform’s network setup and self-repair time were within 10 s. Its coverage range was about 50 m in indoor environments with complex obstacles. This shows that it has a robust network and good coverage. This study proposes an improved data transmission strategy to enhance data transmission reliability. This strategy employs a dynamic windowing model to reduce the loss of large packets and a PC mechanism to optimize data priority allocation. The inclusion of a starvation prevention mechanism prevents blocking caused by inadequate service provision. The experimental results demonstrate that the optimized data transmission strategy significantly improves data reliability. During the upload speed test, the RS232 and RS485 converters were slightly below their theoretical maximum upload speeds. The GPIB and CAN converters did not reach their theoretical values due to hardware and test platform limitations. Future work should focus on optimizing the software and hardware of the current converters and developing an improved test plan. Furthermore, it is necessary to expand support for additional interface types, including USB and LAN.