The integration of civilian UAV systems presents a significant communication challenge beyond the fundamental flight control (FC) link. Various onboard avionics, such as payload controllers and high-precision navigation receivers, require dedicated data links with their ground-based counterparts. A prime example is the use of Real-Time Kinematic (RTK) or Differential GPS (DGPS) techniques, where a ground-based reference station must transmit correction data to the airborne rover receiver to achieve centimeter-level positioning accuracy. Similarly, mission payloads (e.g., cameras, sensors) need to exchange status information and control commands with their dedicated ground control terminals. Effectively managing the simultaneous, reliable transmission of these multiple data streams between air and ground is therefore a critical subsystem integration problem.
Existing solutions predominantly follow two paths. The first method employs multiple independent data link radio pairs or a single multi-channel radio, dedicating a physical channel to each data stream. While straightforward, this approach increases the system’s size, weight, power consumption (SWaP), and cost, while also raising concerns about electromagnetic compatibility (EMC). The second, more common method utilizes the Flight Controller (FC) and Ground Control Station (GCS) software to act as data routers, multiplexing and de-multiplexing all streams over a single wireless data link. Although this method saves hardware, it imposes a significant software burden on the FC’s processor. Given that the FC is primarily tasked with complex, real-time navigation and control algorithms, its processing resources are often limited. This can lead to reduced data transmission efficiency, increased latency, and, under high data loads, critical communication bottlenecks that jeopardize civilian UAV flight safety.
Observing that most civilian UAV avionics communicate via serial interfaces (UART, RS-232, RS-422) and that the air-ground communication exhibits a star-topology network characteristic, this paper presents the design of a dedicated Serial Port Switch. This device offloads the data routing task from the FC, creating a robust, efficient, and transparent data exchange network. The system is realized through a custom Data Link Layer protocol and a multi-threaded communication firmware built on the RT-Thread real-time operating system (RTOS). Furthermore, leveraging the RTOS’s priority-based thread scheduling, we implement a Strict Priority (SP) queue scheduling mechanism at the critical wireless link output. This ensures that high-priority data (e.g., critical flight telemetry or safety commands) is never blocked by lower-priority, high-volume traffic (e.g., video telemetry), thereby significantly enhancing the overall reliability of the civilian UAV‘s communication infrastructure.
1. System Network Architecture and Operational Principle
The core of the system is a pair of identical Serial Port Switches, one deployed on the civilian UAV airframe (airborne unit) and the other within the ground control system (ground unit). Each switch connects to local serial devices, forming a logical bridge over a single wireless data link. The network topology is illustrated conceptually in the system diagram. Each switch features two distinct port types: one Node Port and multiple Device Ports. The Node Port is connected to the data transceiver (radio modem), which handles the time-division multiplexing of all data streams across the wireless channel. The Device Ports are connected to the various avionics and ground equipment (e.g., FC, RTK base station, payload controller).
The operational principle is inspired by Ethernet switches in computer networks. A standard Ethernet switch operates at the OSI Data Link Layer, forwarding frames based on Media Access Control (MAC) addresses and a port mapping table. In a civilian UAV device network, however, the switch receives raw application-layer data frames from connected devices, which contain no inherent network addressing information. To enable routing, our system software assigns a unique Port Address to each Device Port. When a data frame arrives at a Device Port, the switch’s firmware encapsulates it within a proprietary Data Link Layer protocol packet. This encapsulation adds crucial header information, including the source Port Address, destination Port Address (determined from configuration), and a priority field. This packet is then forwarded internally to the Node Port for wireless transmission.
On the receiving switch (e.g., ground unit receiving from the air), the process is reversed. The Node Port receives the protocol packet, validates it, strips off the link-layer encapsulation based on the packet’s header, and delivers the original application data frame to the Device Port specified by the destination address. This creates a virtual, transparent connection (virtual wire) between devices on opposite ends of the wireless link. When multiple data packets from different Device Ports contend for access to the single Node Port transmitter, they are scheduled for output based on their assigned priority, ensuring an orderly and deterministic multiplexing scheme.
2. System Requirements and Hardware Design
Analyzing typical civilian UAV integration needs, we identify three primary data links: the Flight Control Data Link, the Differential Correction Data Link (e.g., for RTK), and the Payload Data Link. To accommodate these and provide expansion capability, the Serial Port Switch is designed with five physical ports: one Node Port and four Device Ports.
The hardware architecture centers on a powerful microcontroller unit (MCU). The STM32F405RGT6 from STMicroelectronics was selected, featuring an ARM Cortex-M4 core running at 168 MHz. Its key advantages include six UART peripherals (sufficient for five ports plus debugging), 1 MB of Flash memory, and 192 KB of RAM. The ample RAM is crucial for providing large data buffers to absorb traffic bursts without loss. Each UART is interfaced to the physical world via level-translation chips: MAX3232 for RS-232 compatibility and MAX3490 for robust differential RS-422 communication. This dual-standard support allows the switch to connect to a wide variety of civilian UAV equipment. The hardware also includes status LEDs for each port to indicate data activity and a stable switching power supply. A block diagram of the hardware interface is shown below.
| Component | Model/Specification | Primary Function |
|---|---|---|
| Microcontroller (MCU) | STM32F405RGT6 (Cortex-M4 @168MHz) | Central processor for protocol handling, routing, and scheduling. |
| UART Peripherals | 6x USART (within MCU) | Hardware serial communication channels. |
| RS-232 Transceiver | MAX3232 | Converts UART TTL levels to RS-232 voltages. |
| RS-422 Transceiver | MAX3490 | Converts UART TTL levels to differential RS-422 signals. |
| Memory | 192 KB SRAM, 1 MB Flash | Runtime data buffers and firmware storage. |
| Port LEDs | 5x Bi-color LEDs | Visual indication of transmit/receive activity per port. |
3. System Software Design
3.1 Data Link Layer Protocol Design
The foundation for multi-channel data exchange is a lean and efficient Data Link Layer protocol. Drawing inspiration from the IEEE 802.3 Ethernet frame format but tailored for the constrained, point-to-point nature of a civilian UAV serial network, we defined the following packet structure.
| Field Name | Length (Bytes) | Description |
|---|---|---|
| Frame Start Delimiter | 4 | Unique pattern (e.g., 0xAA, 0x55, 0xAA, 0x55) marking packet start. Differentiates Data Packets from Command Packets. |
| Packet Length (L) | 1 | Total length of the packet from this field through the Data Field (1 to 255 bytes). |
| Packet Sequence Number | 1 | Sequence number for reassembling long application frames split across multiple link packets. |
| Destination Port Address | 1 | Address of the target Device Port on the receiving switch. |
| Source Port Address | 1 | Address of the originating Device Port on the transmitting switch. |
| Priority | 1 | Numerical priority value (lower number = higher priority) for output scheduling. |
| Data Field | 0 to 244 | Payload: Raw application data or configuration command. |
| CRC-16 | 2 | Cyclic Redundancy Check for data integrity, computed from Length to Data Field. |
Key design rationales include:
- Frame Size: Unlike Ethernet’s 1500-byte MTU, our maximum packet data field is 244 bytes, suitable for most civilian UAV serial protocols. Larger application frames are fragmented, with the Sequence Number ensuring correct reassembly, preventing one long frame from monopolizing the link.
- Explicit Priority: The dedicated Priority field enables the Strict Priority scheduling algorithm at the Node Port, a critical feature for civilian UAV safety.
- Command and Control: The protocol supports command packets, allowing remote configuration of switch parameters (e.g., baud rates, port priorities) via the network itself, enhancing flexibility.
3.2 Multi-threaded Communication Firmware Design
Managing five full-duplex UARTs concurrently with protocol processing and routing demands an efficient concurrency model. Traditional super-loop firmware architectures struggle with this complexity, often leading to missed data or high latency. We addressed this by porting the RT-Thread real-time operating system to the STM32 MCU. RT-Thread provides a preemptive, multi-threaded environment essential for this task.
Low-Level Driver: To minimize CPU overhead during data reception, we implemented a UART driver using DMA (Direct Memory Access) combined with an “Idle Line” detection interrupt. When data arrives, the DMA controller automatically stores it into a dedicated ring buffer without CPU intervention. The UART hardware generates an interrupt only when the line becomes idle (indicating a natural pause or end of a frame), at which point the driver calculates the received data length and releases a semaphore to signal the upper-layer thread. For transmission, data is placed into a buffer, and the DMA is programmed to send it, freeing the CPU immediately. This is far more efficient than per-byte interrupt methods and is vital for handling the data rates common in civilian UAV systems.
High-Level Application Threads: The application firmware is structured around threads for each port. Each Device Port has a Receive-Process Thread and a Transmit Thread. The Node Port has one Receive-Process Thread and multiple Transmit Threads (for priority queuing, detailed in section 3.3).
The execution flow for a Device Port’s Receive-Process Thread is as follows:
- Wait on the semaphore from the low-level UART driver (blocks thread until data arrives).
- Read the raw application data frame from the DMA ring buffer.
- Perform Transparent Transmission processing: read the configured destination address for this port, encapsulate the raw data into a Link Layer Packet (adding header and CRC).
- Forward the complete packet to the Node Port’s transmission queue using an RT-Thread message queue.
The Node Port’s Receive-Process Thread has a different role:
- Wait for a complete Link Layer Packet from the wireless radio via its UART/DMA.
- Validate the packet (CRC check).
- Extract the Destination Port Address from the packet header.
- Forward the packet’s payload (the original application data) to the Transmit Thread of the corresponding destination Device Port via another message queue.
Device Port Transmit Threads remain dormant until they receive a message in their queue. When a message arrives, they wake up, retrieve the application data, and initiate a DMA transfer to send it out the physical UART. These threads are assigned higher priority than their corresponding receive threads to ensure timely data egress and prevent queue overflow.
3.3 Priority Queue Scheduling via Thread Priority
The Node Port is a shared resource with a finite transmission bandwidth, determined by the configured radio baud rate. When multiple packets from different Device Ports arrive simultaneously, they must be queued for sequential transmission. Without management, a burst of low-priority data (e.g., high-frequency sensor readings) could block time-critical high-priority data (e.g., emergency stop command), creating a dangerous scenario for a civilian UAV.
We implement a Strict Priority (SP) scheduling algorithm to guarantee bandwidth for critical links. A classical software implementation would involve a multi-level queue data structure and a dedicated scheduler function that polls these queues. However, we realized that the preemptive, priority-based thread scheduler of RT-Thread could be leveraged to implement this behavior elegantly and reliably.
Implementation Method: Instead of one Node Port Transmit Thread, we create four, labeled Tx_Prio_0 to Tx_Prio_3, where a lower index corresponds to a higher priority. Each thread is associated with its own message queue (buffer). The threads are assigned static priorities in the RTOS kernel that match their logical priority level, and these priorities are set higher than all other application threads. Each thread waits on its own message queue.
Scheduling Mechanism: When a Device Port thread forwards a packet to the Node Port, it posts the packet into the message queue corresponding to the packet’s Priority field. This action makes the respective Tx_Prio_N thread ready to run. The RTOS kernel’s scheduler then selects the highest-priority ready thread to execute. For example, if Tx_Prio_0 (highest) and Tx_Prio_2 are both ready, the kernel will always schedule Tx_Prio_0 first. This thread will then send its packet via DMA.
Critical Section Management: A potential issue with full preemption is that a higher-priority transmit thread could preempt a lower-priority one mid-transmission, corrupting the serial output. To prevent this, we protect the actual UART transmit function with a mutex semaphore. A transmit thread must acquire this mutex before starting the DMA transfer and releases it only after the transfer is initiated (or completed, depending on implementation). This ensures atomic access to the physical UART, while the scheduling of which thread gets the mutex next is still governed by thread priority.
The resulting behavior is mathematically equivalent to the SP algorithm. The system guarantees that all packets in queue $Q_{high}$ are transmitted before any packet in queue $Q_{low}$, given that $Priority(Q_{high}) > Priority(Q_{low})$. The service discipline for packets of equal priority is typically First-In-First-Out (FIFO), governed by the message queue. The use of the RTOS kernel as the scheduler eliminates the need for custom queue management code, reduces complexity, and enhances reliability for civilian UAV operations.
The relationship between thread priority ($\pi$), packet arrival, and transmission can be modeled. Let $B$ be the wireless link bandwidth in bytes/second. The transmission time for a packet $i$ of length $L_i$ bytes is:
$$T_{tx,i} = \frac{L_i}{B}$$
For a packet arriving at time $t_a$ with priority $p$, its total delay $D_p$ until transmission completes is the sum of the transmission times of all higher-priority packets already queued plus any in-progress lower-priority packet that must complete (due to the mutex), and its own transmission time:
$$D_p(t_a) = \sum_{j \in H(t_a)} T_{tx,j} + I_{lp}(t_a) + T_{tx,i}$$
where $H(t_a)$ is the set of higher-priority packets already in the system’s queues at time $t_a$, and $I_{lp}(t_a)$ is the remaining transmission time of a lower-priority packet currently holding the transmit mutex at $t_a$. This model shows that high-priority packets experience bounded delay, independent of the load on lower-priority channels.
4. System Testing and Performance Analysis
The system was rigorously tested to validate functionality and performance. To isolate the switch’s performance from wireless channel errors, initial tests connected the Node Ports of two switches directly via a wired serial link at 115,200 bps. Virtual serial devices were simulated using terminal software.
Test 1: Basic Channel Integrity. Each of the four data channels was tested independently with bidirectional traffic at various baud rates (9,600 to 115,200 bps) and data rates (1 to 100 Hz). All channels demonstrated lossless, low-latency transmission in isolation, confirming correct protocol encapsulation/decapsulation and transparent operation.
Test 2: Multi-Channel Congestion & Priority Scheduling. This critical test evaluated the system under congested conditions. All four Device Ports were configured with unique priorities: Port 1 (Highest), Port 2, Port 3, Port 4 (Lowest). A constant data stream of 50-byte frames was injected into each port simultaneously at increasing frequencies (from 50 Hz to 100 Hz per port). The aggregate input data rate $R_{in}$ is given by:
$$R_{in} = N_{ports} \times L_{frame} \times F_{rate}$$
where $N_{ports}=4$, $L_{frame}=50$ bytes. At $F_{rate}=60$ Hz, $R_{in} = 4 \times 50 \times 60 = 12,000$ B/s. The Node Port output rate $R_{out}$ at 115,200 bps, assuming 8-N-1 framing (10 bits per byte), is:
$$R_{out} = \frac{115,200 \text{ bps}}{10 \text{ bits/byte}} = 11,520 \text{ B/s}$$
When $R_{in} \leq R_{out}$, the system can sustain the load. When $R_{in} > R_{out}$, congestion occurs, and the scheduling algorithm dictates which data is dropped. The test measured the Data Transfer Integrity Ratio $I_{port}$ for each port over a 10-minute period:
$$I_{port} = \frac{\text{Bytes Received}}{\text{Bytes Sent}} \times 100\%$$
The results, summarized in the table below, clearly demonstrate the effectiveness of the priority scheduling.
| Injection Frequency (Hz) | Aggregate Input Rate (B/s) | Port 1 (Prio 0) Integrity | Port 2 (Prio 1) Integrity | Port 3 (Prio 2) Integrity | Port 4 (Prio 3) Integrity | Observation |
|---|---|---|---|---|---|---|
| 50 | 10,000 | ~100% | ~100% | ~100% | ~100% | No congestion ($R_{in} < R_{out}$). |
| 60 | 12,000 | ~100% | ~100% | ~99.8% | ~99.5% | Mild congestion. Slight losses due to buffer management, not priority. |
| 70 | 14,000 | 100% | 100% | 67.8% | 0% | Severe congestion ($R_{in} >> R_{out}$). SP algorithm protects Ports 1 & 2 perfectly. Port 3 gets partial service. Port 4 is starved. |
| 80 | 16,000 | 100% | 100% | 41.5% | 0% | Increased load further reduces Port 3 service. High-priority ports unaffected. |
| 90 | 18,000 | 100% | 100% | 32.1% | 0% | Trend continues, validating SP behavior. |
| 100 | 20,000 | 100% | 100% | 28.5% | 0% | High-priority channel integrity remains guaranteed under extreme overload. |
The data shows that the system successfully implements the Strict Priority policy. The highest-priority channels (Port 1 and 2) maintained 100% integrity even when the aggregate input exceeded the link capacity by over 70%. This is a crucial outcome for civilian UAV safety, ensuring that flight-critical commands and telemetry are never blocked by non-critical data floods.
5. Conclusion
This paper presented the design, implementation, and validation of a dedicated Serial Port Switch system to address the multi-channel data exchange problem in civilian UAV integration. By applying network switching concepts to the serial device domain, the system offloads the data routing burden from the flight controller, leading to a more robust and efficient architecture. The custom Data Link Layer protocol enables transparent, address-based routing of data between air and ground equipment. The firmware, built on the RT-Thread RTOS, utilizes an efficient multi-threaded model with DMA-driven UARTs to handle concurrent data streams with high efficiency and low latency.
A key innovation is the implementation of a Strict Priority (SP) output queue scheduling algorithm by leveraging the RTOS’s native thread priority mechanism. This method provides a simple, reliable way to guarantee bandwidth for high-priority data streams, a non-negotiable requirement for civilian UAV operational safety. Experimental results confirm that the system maintains full data integrity for critical channels even under severe network congestion, while gracefully degrading service for lower-priority traffic according to the SP policy.
The proposed system simplifies civilian UAV avionics integration, reduces system SWaP and cost compared to multiple radios, and enhances overall communication reliability. It represents a practical and significant step towards more modular, scalable, and safe data link architectures for the expanding domain of civilian UAV applications.