u-blox ZED-F9P를 RTK 이동국(Rover)으로 쓰면서 NTRIP 서버에 접속하면 마운트포인트가 여러 개 뜨는 경우가 있습니다. 이름도 VRS, RTK, SINGLE, 지역명, 기준국 코드 등으로 제각각이라, 처음 설정할 때는 어떤 스트림을 골라야 할지 헷갈리기 쉽습니다.
가장 가까워 보이는 걸 고르면 될 것 같지만, 실제로는 거리만으로 정하면 안 됩니다. 먼저 확인할 것은 네 가지입니다.
- 어떤 보정 방식의 스트림인지
- ZED-F9P가 처리할 수 있는 RTCM 메시지가 들어오는지
- 필요한 GNSS 위성군이 포함되어 있는지
- VRS라면 이동국 위치정보가 정상적으로 전달되는지
이 순서로 보면 마운트포인트 선택이 훨씬 단순해집니다.
먼저 NTRIP과 RTCM을 구분하자
NTRIP과 RTCM은 같은 것이 아닙니다. NTRIP(Networked Transport of RTCM via Internet Protocol)은 인터넷으로 GNSS 보정정보를 전달하는 방식이고, RTCM은 그 안에 실려 오는 보정 데이터의 형식입니다. 통로가 NTRIP이고, 통로로 흘러 들어오는 내용물이 RTCM이라고 생각하면 쉽습니다.
u-blox도 NTRIP을 GNSS 보정 데이터를 인터넷으로 스트리밍하는 프로토콜로 설명하고, RTCM 외의 다른 보정 데이터 형식도 실을 수 있다고 안내합니다. 그래서 NTRIP 서버에 접속됐다고 해서 RTK가 정상 동작한다고 볼 수는 없습니다. 실제로 어떤 보정 메시지를 받고 있는지까지 확인해야 합니다.
ZED-F9P가 RTK Fix를 하려면 무엇이 필요할까?
ZED-F9P는 멀티밴드·멀티 GNSS를 지원하는 고정밀 GNSS 모듈로, GPS, GLONASS, Galileo, BeiDou를 동시에 사용할 수 있고 RTK 이동국으로도 쓸 수 있습니다.
u-blox의 ZED-F9P Integration Manual에 따르면, 이동국이 정수 모호정수를 결정하려면 크게 두 가지 정보가 필요합니다.
- 기준국 위치정보
- 기준국 GNSS 관측정보
기준국 위치에는 보통 RTCM 1005 또는 1006, 위성 관측정보에는 MSM4 또는 MSM7 계열 메시지가 쓰입니다. 위성 시스템별 대표 메시지는 아래와 같습니다.
| GPS | RTCM 1074 / 1077 |
| GLONASS | RTCM 1084 / 1087 |
| Galileo | RTCM 1094 / 1097 |
| BeiDou | RTCM 1124 / 1127 |
ZED-F9P는 이런 RTCM 메시지를 받아 RTK 해를 계산합니다. 다만 지원하는 메시지는 하드웨어와 펌웨어 버전에 따라 다를 수 있으니, 사용 중인 모델의 데이터시트도 같이 확인하는 것이 좋습니다.
결국 중요한 것은 RTCM 데이터가 들어오느냐가 아닙니다. 내가 쓰는 GNSS 구성에 맞는 기준국 위치정보와 관측정보가 제대로 들어오느냐입니다.
마운트포인트 목록에서 먼저 볼 항목
NTRIP 캐스터는 보통 Source Table을 제공하고, 여기에 스트림별 정보가 들어 있습니다. 주로 보는 항목은 다음과 같습니다.
| Mountpoint | 접속할 보정 스트림 이름 |
| Format | 데이터 형식 |
| Format Details | 세부 메시지 구성 |
| Carrier | 반송파 정보 |
| Nav-System | 지원 GNSS |
| Latitude / Longitude | 기준국 또는 스트림의 대략적인 위치 |
| NMEA | GGA 등 위치정보 전송 필요 여부 |
| Solution | 보정 방식 관련 정보 |
NTRIP Source Table 표준도 스트림마다 format, carrier, nav-system, latitude, longitude, nmea 등을 제공하도록 정의하고 있습니다. 이름만 보고 고르기보다 Source Table의 실제 속성을 먼저 보는 편이 안전합니다.
VRS, SINGLE 같은 이름만 믿으면 안 되는 이유
마운트포인트 이름에는 VRS, SINGLE, 지역명 등이 붙는 경우가 많습니다. 보통 SINGLE 형태는 특정 물리 기준국의 보정정보를 주고, VRS는 여러 기준국 네트워크로 이동국 근처에 가상의 기준점을 만드는 방식입니다. ZED-F9P는 물리 기준국의 RTCM 보정정보도, VRS 서비스의 보정정보도 사용할 수 있습니다.
다만 이름 규칙은 서비스 제공자마다 다를 수 있습니다. "VRS면 무조건 선택", "SINGLE이면 피하기", "특정 문자열이 들어가면 더 정확함" 같은 식으로 판단하면 안 됩니다. 어떤 방식의 서비스인지, 어떤 RTCM 메시지를 주는지는 해당 서비스의 설명과 Source Table로 확인하는 것이 정확합니다.
VRS를 쓸 때 GGA가 중요한 이유
VRS는 이동국 근처에 가상 기준점을 만들어야 해서, 현재 이동국의 위치를 알아야 합니다. 이 위치정보를 NTRIP 캐스터에 보낼 때 흔히 쓰는 것이 NMEA GGA 메시지입니다. ZED-F9P Integration Manual은 가상 기준국 서비스를 쓸 때 Rover가 NMEA GGA를 캐스터로 보내야 하고, 그러지 않으면 보정정보를 받지 못할 수 있다고 명시합니다.
그렇다고 GGA를 무조건 1초 간격으로 보내야 한다고 단정할 필요는 없습니다. 필요한 전송 주기와 방식은 NTRIP 서비스와 클라이언트 설정에 따라 달라질 수 있습니다. u-center 2의 NTRIP Client도 수신기의 UBX-NAV-PVT나 표준 NMEA GGA로 위치정보를 서비스에 전달하도록 되어 있습니다.
VRS 접속이 안 되거나 보정정보가 들어오지 않는다면 이렇게 확인해 보세요.
- GGA 또는 위치정보가 정상적으로 만들어지는지
- NTRIP Client가 그 위치정보를 캐스터에 전달하고 있는지
- Source Table의 NMEA 항목이 위치정보 전송을 요구하는지
가장 가까운 기준국이 항상 정답일까?
Single-base RTK에서는 기준국과 이동국 사이의 거리가 중요합니다. 거리가 멀어질수록 두 지점이 겪는 전리층·대류권 오차의 차이가 커질 수 있기 때문입니다. 하지만 마운트포인트를 고를 때 거리 하나만 봐서도 안 됩니다. 더 가까운 스트림이라도 필요한 RTCM 메시지가 부족하거나 쓰려는 위성군과 맞지 않으면 ZED-F9P의 장점을 제대로 살리지 못합니다.
반대로 VRS나 Network RTK는 이동국 위치를 기반으로 보정정보를 만들기 때문에, 물리 기준국 하나와의 직선거리만으로 판단하기 어렵습니다. 앞선 Single RTK 글에서 살펴봤듯이, Single-base RTK의 운용 거리도 하나의 절대적인 숫자로 정해지는 것이 아니라 요구 정확도와 관측환경에 따라 판단해야 합니다.
Fix가 안 될 때는 RTCM이 실제로 들어오는지 확인하자
NTRIP 연결창에 Connected가 떠도 실제 보정 데이터가 제대로 들어오는지는 따로 확인해야 합니다. u-center에서 UBX-RXM-RTCM 메시지를 보면 수신 중인 RTCM 메시지와 CRC 상태 등을 확인할 수 있습니다. 특히 기준국 위치정보인 RTCM 1005나 이에 대응하는 메시지가 들어오는지가 중요합니다.
점검할 항목은 다음과 같습니다.
NTRIP 연결. 캐스터 주소, 포트, 사용자 이름과 비밀번호, 마운트포인트를 확인합니다.
RTCM 데이터 수신. 메시지가 끊기지 않고 들어오는지, CRC 오류는 없는지, 기준국 위치 메시지가 있는지 봅니다.
GNSS 관측 메시지. GPS, GLONASS, Galileo, BeiDou 관측정보가 각각 들어오는지 확인하고, 쓰려는 위성군과 실제 스트림 구성이 맞는지 봅니다.
보정정보의 시간. 오래된 보정정보는 쓸 수 없습니다. ZED-F9P Integration Manual에 따르면 기본 설정에서는 RTCM 보정정보가 일정 시간 이상 오래되면 그 보정을 버리고 일반 GNSS/DGNSS 상태로 돌아갈 수 있습니다. 모바일 통신이 불안정한 곳이라면 마운트포인트 자체보다 데이터 지연과 끊김이 문제일 수 있습니다.
Connected인데 계속 Float라면
접속은 정상인데 Float가 계속된다면, 마운트포인트만 계속 바꾸는 것은 좋은 해결 방법이 아닙니다. ZED-F9P 공식 매뉴얼은 RTK 수렴시간이 아래 요소들의 영향을 받는다고 설명합니다.
- 기준국과 이동국의 거리
- 멀티패스
- 기준국의 위성 가시성
- 이동국의 위성 가시성
그래서 다음 순서로 확인하는 편이 효율적입니다.
- RTCM 메시지가 정상적으로 들어오는지
- 기준국 위치 메시지와 MSM 관측 메시지가 있는지
- VRS라면 GGA가 제대로 전달되는지
- Correction Age나 데이터 지연은 어떤지
- 위성 수와 신호 품질
- 하늘 가림과 멀티패스
- 기준국까지의 거리, 또는 Network RTK 서비스 상태
여기까지 이상이 없다면 마운트포인트가 아니라 관측환경이나 신호 품질이 원인일 가능성도 봐야 합니다.
ZED-F9P용 마운트포인트 선택 순서
여러 마운트포인트가 보일 때는 저는 아래 순서로 정리하는 방식이 가장 이해하기 쉽다고 봅니다.
1단계, 보정 방식. Single-base인지 VRS/Network 방식인지 확인합니다.
2단계, RTCM 형식. 사용 중인 ZED-F9P의 하드웨어와 펌웨어가 처리할 수 있는 스트림인지 봅니다.
3단계, 위성 시스템. GPS뿐 아니라 GLONASS, Galileo, BeiDou 중 쓰려는 위성군의 관측정보가 포함되는지 확인합니다.
4단계, 기준국 위치 메시지. RTCM 1005/1006 등 필요한 기준국 정보가 들어오는지 봅니다.
5단계, VRS라면 GGA. 캐스터가 Rover 위치정보를 제대로 받고 있는지 확인합니다.
6단계, 거리와 서비스 범위. Single-base라면 기준국까지의 거리와 서비스 제공자의 권장 범위를 확인합니다.
7단계, 실제 수신상태. u-center에서 RTCM 상태와 Fix/Float 전환을 확인합니다.
이렇게 하면 마운트포인트 이름만 보고 시행착오를 되풀이하는 일이 많이 줄어듭니다.
정리
ZED-F9P에서 NTRIP 마운트포인트를 고를 때는 가장 가까운 스트림을 고르는 것만으로는 부족합니다. 핵심은 보정 방식, RTCM 메시지, GNSS 위성군, Rover 위치정보 이 네 가지입니다.
RTK 상태가 좋지 않다면 연결 여부보다 어떤 RTCM 메시지가 얼마나 안정적으로 들어오는지부터 확인하세요. ZED-F9P는 정상적인 보정 데이터와 충분한 위성 관측조건이 갖춰지면 Float를 거쳐 RTK Fixed로 넘어갑니다. 마운트포인트 이름보다 그 스트림이 실제로 어떤 데이터를 제공하는지 확인하는 것이 올바른 출발점입니다.
참고자료
- u-blox, ZED-F9P Integration Manual
- u-blox, ZED-F9P Module
- u-blox, u-center 2 User Guide – NTRIP
- u-blox, What is NTRIP?
- BKG / RTCM-NTRIP, NTRIP Source Table Documentation
#u-blox F9P #RTK #NTRIP #VRS #측량 #GPS 설정 #이동국 #GNSS #마운트포인트 #RTCM
'GNSS·측량' 카테고리의 다른 글
| 스마트폰 GPS와 측량용 GNSS는 왜 정확도가 다를까? 미터급과 센티미터급의 차이 (0) | 2026.04.24 |
|---|---|
| RTK가 Float에서 Fix로 안 넘어갈 때: 원인 6가지와 점검 순서 (0) | 2026.04.24 |
| Single RTK는 왜 거리가 멀어질수록 불리할까? 베이스라인과 기준국 운용 기준 (0) | 2026.04.23 |
| GNSS 멀티패스는 왜 생길까? 도심지 측량에서 초크링 안테나가 하는 역할 (0) | 2026.04.19 |