Design and Implementation of Controller Area Network-Based Monitoring and Control System with Arduino UNO and Logic Analyzer ^†

Abstract

We developed and evaluated a monitoring and control system based on the controller area network (CAN) bus with a microprocessor of Arduino UNOs and a logic analyzer as auxiliary tools. We implemented a CAN bus communication system using Arduino UNO to control servo movements and collected data from ultrasonic sensors, infrared (IR) sensors, or DHT11 sensors that measure temperature and humidity. The CAN node received the data to control the servo motor and to display the information on the liquid crystal display. While the IR sensor detects an object, the ultrasonic measurement is stopped, and the servo is set to the home position at 0°. The CAN bus communication operated effectively, enabling real-time control of the servo motor following the command from sensor data.

1. Introduction

The controller area network (CAN) bus, a robust communication protocol widely used in industrial automation and automotive systems, is known for its efficient real-time data exchange, high reliability, and resistance to electromagnetic interference [1,2,3,4,5,6,7,8]. The innovative system is implemented with an Arduino UNO microprocessor (Arduino S.r.l., Turin, Italy) [9] as a modular and decentralized master–slave architecture that integrates an MCP2515 breakout board as a CAN control transceiver [10], playing a critical role in ensuring seamless communication between the nodes. The control node, as a master, supervises and coordinates the network while the planned (linked as a slave) nodes are equipped with specific hardware components and execute tasks such as data acquisition and mechatronic control.

The system comprises two transmitter nodes that send information on distance, temperature, and humidity data under the CAN protocol. It consists of a temperature and humidity sensor for environmental recognition [11], an ultrasonic sensor for distance detection [12], a liquid crystal display (LCD) for real-time data visualization [13], a servo motor to provide mechanical feedback [14], and LEDs for status indication. The MCP2515 modules, interfaced with microcontrollers, facilitate CAN protocol-based message frames and prevent data collisions during transmission, ensuring high reliability and low latency. All transferred data are detected by a Zeroplus PC-based logic analyzer (LA) (Zeroplus Technology Corp., New Taipei City, Taiwan.) [15]. The CAN bus shows advantages in monitoring and control systems, particularly in scenarios demanding high scalability and fault tolerance. Experimental results in this study validated the system’s capability to handle real-time communication with minimal latency, high accuracy in measurement, and robust operation under various environmental conditions. The superiority of the CAN bus was verified in applications where synchronized and decentralized control is required, such as in robotics, industrial automation, and smart environments. The modular architecture and CAN-based bus communication are validated to be useful in developing adaptable and scalable monitoring and control solutions. Further enhancements in dynamic network configurations and load management are necessary to maximize the CAN bus performance.

2. Experimental Setup on CAN Bus Training System

2.1. Monitoring and Control Integrity on CAN Specifications

The monitoring and control configuration of the CAN bus training system is shown in Figure 1. The system comprises an XDS-series (OWON Technology, Zhangzhou, China) decoding oscilloscope, a USBCAN II device plus GCAN software (Guangzhou ZHIYUAN Electronics Co., Ltd. (ZLG), Guangzhou, China), and a PC-based LA. The CAN dynamic protocol waveforms were acquired and decoded in hexadecimal format using an XDS-series oscilloscope and/or a USBCAN device with adaptable software. LA plays an important role in bus protocol analysis, in which it debugs and verifies the operation of the digital system, as well as monitors timing violations and transient events on protocols. The implementation of a device under testing (DUT), according to the CAN bus communication protocol, enables real-time control of a servo motor based on command data from an ultrasonic detector, an IR sensor [16], and a DHT11 humidity (Aosong Electronics Co., Ltd. (ASair), Guangzhou, China) and temperature sensor. However, before the DUT experiment, the ZDS2000 signal board (ZGL Corp., Guangzhou, China.) was used as a standard signal source for the calibration of the CAN bus training system.

2.2. CAN Protocol and Message Frames

The CAN 2.0 system was built following the communication regulation and ISO11898-1/16845/CiA601 protocol. Due to all testing items for real-time control being normal UDTs without limitation, the design cost is reduced with the excellent network feature. Furthermore, correlation between multiple digital signals simultaneously is found, so the system procedure violation is detected in massive protocol data by using the CAN protocol acquired by LA (Figure 2a). CAN, a broadcast system, has a mechanism of error detection to avoid faults during signal transmission on bus lines. There are five error-proofing mechanisms with cyclic redundancy check (CRC), frame check, ACK errors, monitoring, and bit stuffing on CAN 2.0 data frame (Figure 2b) [5]. While one or more errors occur, these delivered messages are interrupted as a fault frame. Furthermore, any node resends a message using a CAN frame arbitration on a bus or into an idle mode. During idle mode, it has at least 11 successively received bit times (“1” or –0 volts CAN_High to CAN_Low). Other multiple μ-controllers as nodes tend to start their message frames. A “data frame” is considered the same as a CAN frame: using more than one frame to send a long message in the arbitration mechanism. In this case, a multi-packet protocol is applied via a USBCAN-II device, and displays the protocol format after using GCAN analysis software (PLC-400/510/511, Guangzhou ZHIYUAN Electronics Co., Ltd. (ZLG), Guangzhou, China), as shown in Figure 1. The CAN 2.0 system is widely applied to vehicle electronic components due to its high reliability.

3. Results and Discussion

3.1. Calibration Procedure

For calibration, two CAN protocol sources were used: a protocol simulator made by Zeroplus Technology Corp., New Taipei City, Taiwan, and a ZDS2000_DEMO board from ZGL Corp., Guangzhou, China. The function of the CAN protocol simulator is to output the bus signal through a command (CMD) in a dual inline package (DIP) switch mode on SW4 setting, and clock (CLK) and data wiring with pins connected, as shown in Figure 3. When the DIP SW1 is switched to OFF (PIN 1), the signals are transmitted continuously, and the rest of PINs, 2–8, are kept ON. While signals are sent, a segment of the CAN protocol frame at PIN 1–3 of DIP SW4 is switched to OFF and broadcast after pressing SW3 once. Simultaneously, the D1 LED displays the action of the signal sending. Usually, the series data frame is decoded with LA for calibration. The LAP-educator 10003 of LA software (Zeroplus Technology Corp., New Taipei City, Taiwan) quickly decodes the CAN signals that contain supported protocol analysis in packet format, i.e., the signals sending the CAN start of frame (SOF), arbitration identifier, remote transmission request (RTR), identifier extension (IDE), data length code (DLC), data (0–8 bytes), CRC, ACK slot, end of frame (EOF) and so on, as shown in Figure 4.

USBCAN-II Pro is used to check the CAN frame data (Figure 5). After being properly connected to the laptop USB interface with the CAN system, a compatible software, GCAN, is adopted for calibration and data analysis based on the configuration of baud rate and the start of data collection [17]. The USBCAN-II Pro enables effective data collection and analysis, contributing significantly to the CAN system development. There are several functions to identify the five methods of error checking. The demo board ZDS2000_DEMO uses CAN standard signals for the calibration and double-checking of the instrument and/or the software on the laptop (Figure 6). Decoding results from the XDS oscilloscope [18] and the GCAN have the same data fields (Figure 7). They show the “Arbitration Field-11 identifier: 00x200, Control-DLC: 3, and Data-3 bytes: 5A 4C 47” from the ZDS2000_DEMO board that sends the important fields of CAN standardized message frames. The signal consistency is maintained throughout the process.

3.2. UDT Prototype Design and Circuit Layout

To understand the CAN bus system, the communication and control process is presented in Figure 8. The figure displays the fully assembled CAN bus system with all connections and components. The prototype system consists of two Arduino UNO boards connected to various components on a breadboard, such as an LCD screen in the center with connecting wires, and labelled "CAN BUS SPI." There are electronic components on the breadboard, including an ultrasonic sensor, a humidity and temperature sensor, IR sensor, and LEDs.

The electronic circuits incorporate several key components. The layout enables the integration of multiple sensors and actuators with two Arduino UNOs. The electronic circuits offer flexibility and effective data communication via the CAN bus network and enable the measurement and interaction with various environmental variables.

3.3. Logic Signal Analysis

The PC-based LA is used to monitor and troubleshoot communication protocols, including CAN bus. It captures and analyzes digital signals, providing valuable insights into the timing, sequence, and content of data transmitted through the CAN system. LA enables scanning errors for debugging, verifying data integrity, and assessing system performance. This LA tool is indispensable in ensuring that the CAN system functions in complex, real-time environments. The signal analysis results (Figure 2a) indicate that ID 257 represents data for distance, while ID 258 represents data for temperature and humidity. Packet 7, with ID 257, contains 2 bytes of distance data (44) but resulted in a NACK due to a CRC mismatch, indicating potential transmission issues. In contrast, Packet 8, with ID 258, successfully transmits 2 bytes of temperature and humidity data (20 and 70) with a verified CRC (2705) and received an ACK, confirming receipt. Ensuring reliable data integrity for both IDs might require examining the physical bus, terminal resistors, and system configuration. LA provides a visual representation of frame signals, including the transmission time, device addresses, and data contents to debug after connecting the LA probes to the I²C lines (SDA and SCL) to capture data as the Arduino UNO sending commands (pulse width modulation (PWM) communication) through wires to the communicated components such as LCD, ultrasonic sensor, and servo motor. Figure 9 depicts that I²C lines are analyzed to ensure proper data transmission between Arduino UNO and the LCD via SPI interface.

The LA measuring results show that the I²C signals are stable with a frequency of 100 kHz. The PWM duty cycle on the servo motor correctly controls its movement as expected from the ultrasonic sensor input. LA ensures that data are transmitted without errors, enhancing system reliability. Performance evaluation of CAN bus communication is scored based on the following performance metrics: message integrity, data transmission speed, error handling, and signal integrity. The CAN communication is successfully established between the two nodes of Arduino UNO microprocessors, with each node sending and receiving data reliably. Therefore, the results of the tests are as follows.

• Message integrity

The data frames sent by Node 1 were received intact by Node 2. A few minor errors (CRC errors) were observed during some test cases, which were handled by the CAN protocol’s automatic retransmission feature. These errors were rare and did not affect overall system performance. The test results were as follows.

• -

  Message ID: 0 × 001

  -

  Data length: 8 bytes

  -

  Error rate: 0.02% (minor CRC errors)

  -

  Transmission time: 150 μs per message

  -

  Status: No loss of data

The results indicated that the CAN bus transmitted and received data with high reliability under normal operating conditions.

• Data transmission speed

The system used a 500 Kbps data rate, which is a typical speed for automotive applications. The transmission speed was measured to be consistent with the expected values, with messages being delivered within the expected time frame. The test results were as follows.

• -

  Transmission speed: 500 Kbps (measured using an oscilloscope)

  -

  Message latency: 0.3 ms per message

  -

  System latency: 1.2 ms from sending to receiving data

These results confirmed that the CAN bus handled high-speed communication effectively, making it suitable for real-time embedded systems.

• Error handling

The CAN protocol includes robust error-handling mechanisms such as CRC, ACK, and error flags. During testing, the error detection system operated efficiently, with the CAN bus automatically re-transmitting messages that encountered errors, ensuring that no data were lost due to transmission issues. The test results were as follows.

• -

  Detected errors: 5 errors over 1000 transmitted messages

  -

  Automatic retransmissions: 5 retransmissions (successful)

  -

  Error type: CRC error and bit stuffing error

The system’s error correction mechanisms demonstrated their effectiveness in maintaining data integrity, even under conditions where minor transmission errors occurred.

• Signal integrity

Signal integrity on the CAN bus was monitored using an oscilloscope to ensure that the differential voltage levels (CAN_H and CAN_L) were maintained according to the specifications. The system performed well with no significant degradation in signal quality over the communication line, even with several meters of twisted pair cable. The test results were as follows.

• -

  CAN_H and CAN_L Voltage: 2.5V differential (within standard range)

  -

  Signal degradation: None observed

  -

  Data bit duration: Consistent with expected values (1 bit = 2 μs at 500 Kbps)

The testing confirmed that the CAN bus was highly reliable in maintaining proper signal levels over long distances, which is crucial in automotive and industrial applications.

There are several troublesome cases in the bus caused by wires: (1) In CAN bus wires, there was a broken wire; (2) CAN wires in reverse connection; (3) CAN wires in short circuit. If CAN_H/L wires have such troubles, the LA device stops and waits for triggering automatically, and fails the operation of the CAN frame as shown in Figure 10. Otherwise, a CAN is interrupted for the data transition of message frames.

A further study is necessary to stop data acquisition on bitwise operations and message frames by using a USBCAN device programming via LabVIEW or MATLAB software. However, by incorporating the logic analyzer system, the digital communication between components and controllers can be analyzed. The tool provides additional validation of network system performance, making debugging easier and improving the accuracy of the implementation in an excellent project development.

4. Conclusions

The CAN bus system enables reliable real-time communication between ultrasonic, IR, and humidity/temperature sensors and controls a servo motor. An LCD presents information and the received data. The CAN system’s performance aligns with the theoretical expectations of the protocol frames. The message transmission times, latency, and error rates are within the expected range for a standard 500 Kbps (maximum up to 1 Mbps) on the CAN bus network. The robustness of the CAN bus, particularly in handling errors, and its suitability for use in environments where real-time, fault-tolerant communication is critical, are demonstrated. Signal integrity is well maintained throughout testing, with the differential voltage levels between CAN_H and CAN_L remaining stable and within specifications. Even with several meters of twisted pair cable, the nodes are connected. There is no noticeable signal degradation, demonstrating the reliability of the CAN bus for medium-distance communication.