CSDB Bus Data Test Based on LabVIEW

This paper analyzes and studies the CSDB bus protocol, and introduces the two-way communication between computer and UUT based on LabVIEW7.1 software development platform through the computer's RS-232 serial port and the corresponding level conversion circuit. Among them, the software implementation that supports communication is the key.

Figure 1 CSDB bus structure

Introduction to CSDB Bus Protocol

The physical layer of the CSDB bus architecture specifies the mechanical and electrical characteristics of the bus; the data link layer defines the data frame and the timing requirements between data frames, and makes detailed provisions for the parameters of various aviation equipment connected to the bus.

Physical Layer

CSDB is a unidirectional broadcast asynchronous serial bus standard, which can form a single-source, multi-receiver transmission system. The bus data is NRZ-encoded and transmitted in full-duplex differential mode. The data format of the CSDB signal is exactly the same as the RS-232-C standard, both of which are asynchronous serial communication formats, namely: one start bit, eight data bits, one parity bit, and one stop bit. Its electrical standard is RS-422-A.

Data Link Layer

The CSDB bus is a byte-oriented transmission protocol. Bytes of a fixed length form message blocks, which are then combined into frames. Different data encapsulated in a data frame are distinguished by their respective address bytes, and different data frames are separated by synchronization message blocks. The CSDB bus data structure is shown in Figure 1.

In Figure 1, the first byte of the message block, Byte 0, is called the identifier (or address), and message blocks are distinguished by identifiers. The length of a message block is fixed at 6 bytes. CSDB uses asynchronous serial transmission, and the bit synchronization of bytes is completed through the start bit and stop bit. Therefore, clock information is not required in the encoding. Frame synchronization is achieved by identifying the hexadecimal "A5" of the 6 bytes of the synchronization message block, which identifies the starting position of each data frame.

Where: t1 = frame time = 1/maximum update rate

t2 = long message block interval (unlimited)

t3 = bus idle time (minimum 11 bits)

t4 = byte gap duration (unlimited)

CSDB bus signal test

Test Principle

To test the CSDB bus signal, the CSDB signal level is first converted to the RS-232 level that is compatible with the computer, and then according to the rules of the CSDB bus, the control information is correctly sent and the real-time feedback information is correctly received. If necessary, the useful information is sent to the test system for processing to complete the automated test of the aviation airborne equipment. The specific steps are divided into signal electrical conversion, communication synchronization, and LabVIEW implementation.

Figure 2 CSDB bus signal communication principle block diagram

Communication Configuration

(1) Electrical conversion

The CSDB bus signal directly communicates with the computer through the serial port after passing through the electrical conversion chip. When converting the electrical standard from RS-422-A to RS-232, the MAX488 full-duplex level conversion chip is used.

(2) Communication synchronization

The CSDB bus is an asynchronous serial communication. According to the basic principle of serial data transmission, the basic condition for achieving correct communication is to keep the clocks of the receiving and sending parties consistent, so as to avoid the cumulative error of the data bit width of the sending and receiving parties, resulting in the failure to correctly detect the bus data. In serial communication, information is transmitted bit by bit, and the transmission rate is expressed in baud rate. The sending and receiving of data are controlled by their own clocks. Therefore, the baud rate of the sender and the receiver should be consistent. After testing specific components, the baud rate of the CSDB data bus is 12.5Kbit/s. In order to synchronize with this, the baud rate generated by the computer should also be 12.5Kbit/s.

As shown in Figure 2, the device responsible for serial communication in the computer is the 8250 asynchronous communication adapter (UART), or its compatible components. The program controls the communication mode by reading and writing the internal registers of the 8250. The 8250 uses the reference clock input signal with a frequency of 1.8432MHz as the main data clock, and the required baud rate is obtained by setting the internal registers of the 8250. In asynchronous serial communication, in order to prevent misreading of data due to signal distortion, asynchrony, etc., the communication adapter stipulates that at least 16 clock pulses must be used to control its baud rate for each 1 bit of data read or sent. In actual applications, the baud rate clock is 1/16 or 1/(16×N) of the main clock. For the required baud rate, the divisor factor is calculated using the following formula when writing the register:

Divisor factor = (master data clock frequency / 16) / baud rate = 115200 / baud rate

After calculating the divisor factor, write the corresponding data into the baud rate setting register inside 8250, and you can get the corresponding baud rate data in the serial port. After calculation, 115200 divided by 12500 is not an integer. Therefore, due to the limitation of the computer asynchronous communication adapter 8250, the baud rate setting cannot be completely the same as 12.5Kbit/s. After calculation, when the divisor factor is 9, the corresponding baud rate is 12.8Kbit/s, which is closest to the baud rate required by the CSDB bus. Each bit occupies 78?S, and the error relative to 80?S/bit (12.5Kbit/s) is 0.25%, which is less than the maximum allowable error of the serial communication baud rate of 5%. In theory, communication synchronization can be achieved, so the communication baud rate is set to 12.8Kbit/s in the program. [page]

Bus Communication Based on LabVIEW7.1

When using LabVIEW7.1 programming to implement bus communication, users do not need to have special knowledge of GPIB, RS-232, VXI and other hardware. LabVIEW provides users with standard I/O interface functions.

The library provides various function modules such as GPIB and serial communication in Lab VIEW's Functions→All Functions→Instrument I/O, which provides a convenient implementation method for serial communication. The software flow is shown in Figure 3.

Figure 3 Serial communication software flow chart

Key issues and solutions in software design

(1) Diversified solutions for sending data frame structures

Through actual testing of different components in the system, it is found that due to different interconnection conditions, the frame structure of the control code of the corresponding components is also different. The synchronization word is followed by 1 to 4 control message blocks. In the automated test system, this communication software is required to be universal. For this reason, the control message block interface in the sending program is set to the maximum (4). When the program detects that a certain interface has data input, the data is sent. If not, it is replaced by a delay of equal length. In this way, while ensuring that all data frame cycles are the same, the different requirements of the control code of different components are met.

(2) Multiple verification of received data

In the data receiving program, LabVIEW requires setting the length of the receiving data buffer. The program can only perform subsequent processing after receiving data of this length. After the actual program is run, it is found that if the buffer length is only one frame (24×8bit), the received data may be received incorrectly. To avoid this situation, the buffer length is set to 4 to 6 times the word length of a frame. After receiving the data, it is verified according to the multiple matching principles such as synchronization words and labels, and then the data is taken out. Then the 4 to 6 groups of data are compared. If they are the same, the data is considered to be credible. If they are different, the data is considered to be unreliable.

Conclusion

When testing the CSDB bus data, the data to be sent can be easily changed through the interface, and the received data can also be displayed in real time, which is convenient for test analysis. This program is encapsulated into a sub-function module and can be applied to an aviation radio automatic test system. Based on the transceiver control of the CSDB bus, the automatic test of related products such as VIR-32 navigation receivers and VHF-22 very high frequency radios has been successfully realized.