13.1.3.1.1. Preamble(0xD3), Reserved, Length, Data Message, 24-bit CRC(Qualcomm 알고리즘) 구조

13.1.3.1.1. Preamble(0xD3), Reserved, Length, Data Message, 24-bit CRC(Qualcomm 알고리즘) 구조

RTCM v3 프로토콜은 물리적 계층(Physical Layer) 상에서 데이터를 전송할 때 발생할 수 있는 노이즈나 데이터 유실에 대응하기 위해 견고한 전송 프레임(Transmission Frame) 아키텍처를 도입하였다. 이 아키텍처는 시작을 알리는 Preamble부터 마지막 무결성을 검증하는 CRC(Cyclic Redundancy Check)까지 직렬화된 데이터 파이프라인으로 구성된다.

본 절에서는 각 필드의 공학적 설계 목적과 PX4-Autopilot 및 GNSS 수신기 사이의 직렬 통신(UART, USB 등) 환경에서 이들이 어떻게 처리되는지를 구체적으로 다룬다.

1. Preamble (0xD3) 및 동기화 무결성

RTCM 3.x 프레임의 가장 첫 바이트는 영문자로 ’매직 넘버(Magic Number)’라 불리는 Preamble 필드이다. 그 값은 항상 0xD3 (이진수 11010011) 로 고정되어 있다.

1.1 프레임 동기화(Frame Synchronization) 역할

RS-232, RS-422, UART와 같이 비동기식(Asynchronous) 직렬 통신을 수행할 때, 펌웨어 부팅 초기 혹은 일시적인 전원 불안정으로 인해 드론의 비행 제어기(FC)가 수신 버퍼의 바이트 정렬을 잃을 수 있다. 이때 PX4 드라이버의 파서는 스트림에서 0xD3를 찾을 때까지 들어오는 모든 쓰레기 데이터(Garbage Data)를 버린다.

그러나 우연히 페이로드 내부의 데이터 값이 0xD3와 동일할 수도 있으므로, 드라이버는 0xD3를 발견한 후 지정된 Length 만큼 건너뛰어 마지막 3바이트의 CRC 연산을 수행한다. 만약 CRC가 통과(Pass)하면 그때서야 동기화가 완전히 회복되었다고 간주한다. 이를 “Trial and Error” 기반의 동기화 획득 알고리즘이라 한다.

2. Reserved (6-bit) 및 Length (10-bit) 필드

Preamble 다음에는 16비트(2바이트)를 서로 쪼개어 사용하는 Reserved 영역과 Length 영역이 등장한다.

  • Reserved (6-bit): 향후 프로토콜 확장을 위해 남겨둔 예약 필드이다. RTCM v3.3 표준에 이르기까지 이 값은 항상 000000 비트열을 유지해야 한다. PX4 소스코드 디코더에서는 이 값이 0이 아닐 경우 비정상적인 프레임으로 간주하고 폐기 단계를 거칩니다.
  • Length (10-bit): 이어지는 Data Message (페이로드)의 전체 길이를 바이트 단위로 나타낸다.

2.1 10-bit Length가 가지는 시스템적 한계치

10비트로 표현할 수 있는 최대 양의 정수는 2^{10} - 1 = 1023 이다. 즉, 하나의 RTCM 프레임이 가질 수 있는 최대 페이로드 사이즈는 1023 바이트로 물리적으로 제한되어 있다.
현대 다중 위성 체계(GPS, GLONASS, Galileo, BeiDou 등)가 상용화되면서 한 번의 에포크(Epoch, 통상 1Hz ~ 10Hz)에 30개 이상의 위성 관측 데이터(MSM 패킷)를 전송해야 할 경우가 발생하는데, 이 데이터의 크기가 1023바이트를 초과하면 RTCM 규격상 하나의 메시지에 담을 수 없다. 따라서 이를 해결하기 위해 여러 개의 MSM 프레임으로 파편화(Fragmentation)하여 송수신해야 하며, QGroundControl과 PX4-Autopilot의 MAVLink(GPS_RTCM_DATA) 연동 로직은 이러한 시퀀스 분할을 완벽하게 지원하도록 구현되어 있다.

3. Data Message (Payload) 본문 구조

Length 필드에 의해 명시된 크기만큼 위치하는 데이터 가변 영역이다.
이 본문의 첫 번째 파트는 항상 12-bit의 Message Type Number (메시지 식별자) 로 시작한다.

  • 예: Type 1004 (L1/L2 RTK 관측치), Type 1005 (기준국 안테나 기준점(ARP) 위치), Type 1077 (MSM7 GPS 신호 데이터)
  • QGroundControl은 MAVLink를 거쳐 이 바이너리 블록 전체를 건드리지 않고 그대로 gps_inject_data uORB 토픽으로 전달하며, 기체 내 u-blox 혹은 Septentrio 등 GNSS 펌웨어가 이 Type에 따라 자신의 로컬 EKF(Extended Kalman Filter) 보정치로 융합 적용한다.

4. 24-bit CRC (Qualcomm 알고리즘) 구조 및 무결성 검증

프레임의 가장 마지막 3바이트(24비트)에는 무선 채널의 잡음에 의한 데이터 변형을 탐지하기 위한 해시 검증 수단으로 CRC(Cyclic Redundancy Check)가 위치한다. RTCM은 모바일 칩 제조사인 퀄컴(Qualcomm)이 제안한 24-bit 다항식을 채택했다.

4.1 CRC-24Q 다항식과 수학적 특성

이 알고리즘에 사용되는 생성 다항식(Generator Polynomial)은 다음과 같다.
P(x) = x^{24} + x^{23} + x^{18} + x^{17} + x^{14} + x^{11} + x^{10} + x^7 + x^6 + x^5 + x^4 + x^3 + x + 1
이 다항식은 이진 코드 기반 다항식 나눗셈을 수행하여 잔여값을 산출한다. 24비트 CRC는 패킷 당 1023 바이트 길이 내에서 거의 모든 버스트 에러(Burst Error)와 다중 비트 전송 에러를 높은 확률로 검출해낼 수 있는 우수한 해밍 거리(Hamming Distance) 특성을 지니기 때문에, 항공 우주 시스템과 같은 생명 중시형(Safety-critical) 로보틱스 분야에 적합하게 채용되었다.

4.2 시스템 내부 구현 (Look-up Table)

MCU 자원이 극도로 제한되었던 임베디드 장비(예: STM32F4 기반의 구형 Pixhawk 1)에서 다항식 나눗셈을 비트 단위로 루프 컷(Loop cut)하여 진행하는 것은 심각한 CPU 점유를 유발한다. 따라서 PX4 소스코드 트리(src/drivers/gps/rtcm.cpp)나 GNSS 드라이버는 256개의 uint32_t 룩업 테이블(Look-up Table)을 메모리의 Flash 영역에 하드코딩(Hard-coding)하여 바이트 단위로 XOR 고속 연산을 처리하는 기법을 표준으로 활용한다.

graph TD
    A[RTCM 수신 패킷: Preamble ~ Payload] --> B{Byte Iterator}
    B -->|1 Byte 단위| C[Lookup Array Index 매핑]
    C --> D[이전 CRC 값과 bitwise XOR]
    D --> E{마지막 바이트?}
    E -->|No| B
    E -->|Yes| F[최종 연산된 24-bit CRC 값]
    F --> G{수신된 CRC 꼬리와 비교}
    G -->|Match| H([Data Accept = 무결성 확보])
    G -->|Mismatch| I([Data Drop = 손상])

GNSS RTK 기술에서 오염된 보정 데이터가 네비게이션 필터(EKF2)로 유입될 경우, 드론의 위치가 순간적으로 수 미터(m) 이상 튀어오르는 발산(Divergence) 현상을 야기할 수 있으므로 이 24비트 CRC 검증 과정은 절대 생략할 수 없는 핵심 펌웨어 안전 장치(Failsafe) 중 하나이다.