13.3.3.1. u-blox F9P 칩셋 간 UART2 포트 직접 크로스토크(Cross-talk) 결선을 통한 RTCM3 이동형 기준 데이터 송출 하드웨어 설정

이동형 베이스(Moving Base) 기반의 듀얼 안테나(Dual Antenna) GPS 시스템, 일명 GPS for Yaw 나침반 대체 기술을 구현하기 위해서는, 소프트웨어적인 설정 이전에 두 개의 고성능 GNSS 수신기 사이를 가로지르는 물리적인 하드웨어 브릿지가 필수적이다.

현대 산업용 드론의 측위 표준이라 할 수 있는 u-blox ZED-F9P 칩셋은 이러한 이동형 베이스 기하학을 하드웨어 레벨에서 지원하도록 설계되었다. 본 절에서는 드론 기체 내부에 탑재된 두 개의 F9P 모듈(Base와 Rover) 간에 지연 시간(Latency)이 거의 체감되지 않는 밀리초( $\text{ms}$ ) 단위의 극저지연 통신망을 구축하기 위해, UART2 포트를 직결(Cross-talk)하는 전기적 결선 방법 및 설정 패러다임을 기술한다.

1. 듀얼 F9P 아키텍처: Base와 Rover의 역할 분담

하나의 비행기(혹은 차량) 지붕 위에 두 개의 수신기가 $50\text{ cm}$ 간격을 두고 얹혀 있다고 상상해 보자. 두 수신기가 완전히 동등한 자격으로 작동하면 안 된다. 철저한 주종(Master-Slave) 관계가 성립되어야 한다.

Moving Base (Master): 전방(Nose) 혹은 후방(Tail)에 지정된 1번 수신기로서, 위성 신호를 받아들여 자신만의 RTCM 3.3 보정 메시지(주로 1077, 1087, 1097, 1127 등의 고해상도 Observation 메시지와, 이동체 특화 메시지인 4072.0 Reference Station Update)를 끊임없이 쏟아내는 공장 역할을 한다.
Rover (Slave): 반대편에 지정된 2번 수신기로서, Base로부터 전달된 RTCM 데이터를 자신의 위성 관측치와 합성하여 두 안테나 사이의 $50\text{ cm}$ 3D 상대 벡터(Relative Vector)를 도출해 내는 연산 엔진이다.

2. UART2 포트 기반 하드웨어 크로스토크(Cross-talk) 결선법

가장 직관적이고 오류가 없는 통신망은 ’전류가 흐르는 구리선’을 직접 연결하는 것이다. u-blox F9P 칩셋은 외부 통신(비행제어기와의 MAVLink/UBX 통신)을 위한 UART1 (또는 USB/I2C) 메인 포트 외에, 오직 백도어(Back-door) 용도로 활용할 수 있는 보조 포트인 UART2 를 내장하고 있다.

엔지니어는 비행 제어기(FC)를 거치지 않고, 두 F9P 모듈의 UART2 핀을 크로스 오버(Crossover) 방식으로 직접 납땜하거나 커넥터로 체결해야 한다.

2.1 전기적 결선 다이어그램(Wiring Diagram)

graph LR
    subgraph Moving Base (F9P 1)
        B_UART1_TX[UART1 TX]
        B_UART1_RX[UART1 RX]
        B_UART2_TX[UART2 TX]
        B_UART2_RX[UART2 RX]
        B_GND[GND]
    end

    subgraph Rover (F9P 2)
        R_UART1_TX[UART1 TX]
        R_UART1_RX[UART1 RX]
        R_UART2_TX[UART2 TX]
        R_UART2_RX[UART2 RX]
        R_GND[GND]
    end
    
    subgraph Pixhawk (Flight Controller)
        FC_GPS1[GPS 1 Port]
        FC_GPS2[GPS 2 Port]
    end

    B_UART1_TX -->|UBX Protocol| FC_GPS1
    B_UART1_RX --- FC_GPS1
    
    R_UART1_TX -->|UBX Protocol| FC_GPS2
    R_UART1_RX --- FC_GPS2

    %% The Critical Cross-talk wiring
    B_UART2_TX ==[RTCM3 @ 460800 baud]==> R_UART2_RX
    B_UART2_RX -.- R_UART2_TX 
    B_GND ---- R_GND

    %% Note for floating pin
    classDef highlight fill:#f9f,stroke:#333,stroke-width:2px;
    class B_UART2_TX highlight;

TX-to-RX 결선: Moving Base의 UART2_TX (송신) 핀을 Rover의 UART2_RX (수신) 핀에 직접 연결한다. 이 얇은 전선 한 가닥을 통해 초당 수십 킬로바이트의 RTCM 데이터가 $460800\text{ bps}$ 나 $115200\text{ bps}$ 의 고속으로 쏟아진다.
단방향 통신 허용: 통상적으로 Rover가 Base에게 할 말은 없으므로 역방향(R_UART2_TX -> B_UART2_RX) 결선은 생략해도 무방하다. 단, 그라운드(GND) 핀은 반드시 상호 체결하여 전위차(Ground Loop)로 인한 통신 노이즈를 억제해야 한다.
비행제어기 (FC) 바이패스: 위 설계에서 가장 아름다운 점은 그 무거운 RTCM 바이너리 스트림이 Pixhawk의 메인 CPU를 단 1바이트도 더럽히지(Interrupt) 않는다는 것이다. FC는 각자의 UART1 포트를 통해 완전히 요리된 깔끔한 결과물(UBX-NAV-RELPOSNED 등)만을 편안하게 취식한다.

3. 포트 통신 병목 및 U-Center 하드웨어 레지스터 튜닝

물리적 선을 꽂는다고 만사가 해결되지 않는다. u-blox 칩셋 내부에 내장된 펌웨어 환경설정 툴인 u-center (또는 QGC의 GPS 패스스루)를 이용하여 UART2 포트의 역할을 강제로 규정(Configuration)해 주어야 한다.

3.1 보드레이트 (Baudrate)의 선택

듀얼 안테나 차량용 GPS 콤파스 시스템의 권장 업데이트 주기는 $5\text{Hz}$ 이상이다.
초당 5번씩 수많은 위성 띠의 RTCM 원시 데이터를 뱉어내기 위해선 $9600$ 이나 $38400\text{ bps}$ 같은 구시대의 보드레이트로는 ’버퍼 오버런(Buffer Overrun)’과 지연시간(Age of restriction) 에러를 피할 수 없다.
따라서 CFG-UART2-BAUDRATE 레지스터 값을 과감하게 $460800\text{ bps}$ 로 끌어올리는 것이 기체 역학적 지연 스파이크를 줄이는 핵심이다.

3.2 입출력 프로토콜 전용화 (Protocol Masking)

노이즈 개입을 막기 위해 UART2를 오직 특수한 목적으로만 사용하도록 입출력 파이프를 강제 폐쇄해야 한다.

Moving Base (UART2): CFG-UART2INPROT-NONE 으로 모든 수신을 거부하고, CFG-UART2OUTPROT-RTCM3X 만 활성화하여 오직 RTCM 송출 전용 입으로만 세팅한다.
Rover (UART2): CFG-UART2OUTPROT-NONE 으로 모든 송신을 막아버리고, CFG-UART2INPROT-RTCM3X 만 활성화하여 RTCM 데이터 흡수 전용 귀로 세팅한다.

이러한 물리적 UART 직결과 칩셋 레벨의 프로토콜 마스킹이 결합될 때 비로소 $1\text{ms}$ 의 딜레이조차 용납하지 않는 극한의 이동형 베이스 통신 링크가 완성된다. 이는 거친 돌풍과 진동이 난무하는 상공에서 드론이 자기장을 무시한 채 완벽한 헤딩(Yaw) 벡터를 직조해 낼 수 있는 가장 원단적인(Fundamental) 하드웨어적 토대이다.