Dữ liệu sửa sai RTK là luồng thông điệp RTCM 3.x được gửi từ Base hoặc mạng CORS tới Rover để hỗ trợ tính vị trí chính xác theo thời gian thực. Điểm dễ nhầm là RTCM và NTRIP không cùng một chức năng: RTCM quy định cấu trúc, loại và ý nghĩa của dữ liệu GNSS, còn NTRIP đảm nhiệm việc vận chuyển luồng dữ liệu đó qua Internet. Phân biệt đúng hai lớp này giúp đội khảo sát xác định nhanh lỗi nằm ở nguồn hiệu chỉnh, định dạng dữ liệu, kết nối hay thiết bị Rover khi công việc ngoài hiện trường bị gián đoạn.
Dữ liệu sửa sai RTK (correction data RTK) không phải tọa độ đã hiệu chỉnh sẵn của Rover, mà là thông tin tham chiếu từ Base/CORS để Rover kết hợp với quan sát GNSS của chính mình và tự giải nghiệm vị trí thời gian thực.
Trong RTK cổ điển, stream RTCM thường mang tọa độ đã biết của trạm tham chiếu cùng các quan sát như pseudorange và carrier phase. Rover so sánh các quan sát này với phép đo đồng thời của chính nó, tạo sai phân để giảm các sai số chung và giải integer ambiguity; khi nghiệm nguyên được xác lập, trạng thái mới chuyển từ Float sang Fixed và đạt mức chính xác centimet trong điều kiện phù hợp.
Điểm thực dụng là “đang nhận correction” không đồng nghĩa “đã có tọa độ chính xác”: dữ liệu tham chiếu chỉ cung cấp đầu vào cho RTK engine; Rover vẫn phải ghép được quan sát chung và hoàn tất ambiguity resolution. Với Network RTK, dữ liệu có thể là quan sát VRS hoặc mô hình MAC/FKP thay vì observables của một Base vật lý, nhưng nguyên tắc vẫn là cung cấp tham chiếu cho phép Rover tự tính nghiệm.
Vì vậy, trên công trường không nên xác nhận chất lượng đo chỉ bằng trạng thái kết nối NTRIP/RTCM; cần kiểm tra Rover thực sự đạt Fixed và duy trì được nghiệm ổn định trước khi ghi điểm hoặc stake out.
Dữ liệu sửa sai RTK được tạo bằng cách lấy quan sát GNSS tại trạm có tọa độ đã biết để ước lượng sai số; Base cục bộ tạo correction từ một điểm, còn CORS/Network RTK mô hình hóa sai số từ nhiều trạm trước khi cung cấp correction phù hợp vị trí Rover.
Ở Base đơn, trạm tham chiếu thu code/carrier phase, kiểm tra chất lượng và áp dụng các hiệu chỉnh anten, phần cứng; correction sau đó phản ánh điều kiện sai số tại chính vị trí Base. Vì các sai số khí quyển không còn tương đồng khi khoảng cách Base–Rover tăng, hiệu quả của mô hình một trạm phụ thuộc đáng kể vào baseline.
CORS/Network RTK thay đổi điểm mấu chốt này: nhiều trạm được giải đồng thời để ước lượng biến thiên ionosphere, troposphere và các sai số chung theo không gian. Từ cùng mô hình mạng, hệ thống có thể tạo VRS gần Rover, gửi tham số vùng FKP, hoặc dữ liệu MAC để Rover tự nội suy. Vì vậy, khác biệt thực chất không chỉ là “một Base hay nhiều Base”, mà là correction một điểm so với mô hình sai số theo vùng.
Network RTK không loại bỏ mọi nguồn lỗi và chỉ có ý nghĩa trong vùng mạng được mô hình hóa. Cuối chuỗi, correction được đóng gói theo RTCM và truyền tới Rover; phương thức truyền không phải chính correction: Base có thể dùng radio, còn CORS thường dùng IP/NTRIP.
RTCM là tiêu chuẩn quy định cấu trúc và ý nghĩa của các thông điệp GNSS dùng trong dữ liệu sửa sai RTK; nó chuẩn hóa “rover nhận dữ liệu gì”, nhưng không quy định dữ liệu phải đi qua radio, 4G hay NTRIP. RTCM hiện liệt kê 10403.4, Version 3 + Amendment 1, ngày 1/11/2024 cho dịch vụ Differential GNSS.
Ở lớp dữ liệu, RTCM 3.x tổ chức thông tin thành các Message Type: chẳng hạn tọa độ trạm tham chiếu, quan sát GNSS đa tần/đa hệ qua MSM, ephemeris hoặc dữ liệu SSR. Nhờ cùng định dạng, base hoặc mạng CORS có thể tạo correction data RTK mà rover tương thích có thể giải mã; còn thuật toán xử lý ambiguity và tính tọa độ cuối cùng vẫn nằm trong rover.
Điểm thực tế dễ bị nhầm là RTCM và NTRIP không phải hai phương án cạnh tranh. RTCM xác định payload; NTRIP là giao thức ứng dụng dùng để truyền luồng GNSS qua Internet, trong khi cùng dữ liệu RTCM cũng có thể được gửi trực tiếp bằng radio. RTCM công bố NTRIP riêng dưới tiêu chuẩn 10410.1, cho thấy hai chức năng được tách thành hai lớp.
Khi RTK không FIX ổn định, kiểm tra “có kết nối NTRIP hay radio hay không” chưa đủ. Cần kiểm tra thêm phiên bản RTCM và các Message Type mà rover thực sự hỗ trợ: đường truyền vẫn hoạt động nhưng dữ liệu không tương thích thì rover vẫn không có đúng đầu vào để giải RTK.
NTRIP đưa RTCM từ nguồn hiệu chỉnh đến rover qua Caster: rover kết nối Internet, chọn đúng mountpoint, yêu cầu luồng đó và liên tục nhận correction data RTK để bộ máy định vị xử lý.
Trong thực địa, hãy kiểm tra mountpoint, RTCM tương thích, datum và yêu cầu GGA trước khi quy lỗi mất Fixed cho máy thu.
Rover không cộng correction data RTK trực tiếp vào tọa độ; nó ghép correction từ base với quan sát carrier-phase/pseudorange cùng thời điểm, khử các sai số chung rồi giải vị trí cùng ambiguity để đi từ Float sang Fixed.
Cụ thể, rover buffer quan sát GNSS của mình, time-match với epoch correction nhận được và chỉ sử dụng các vệ tinh chung giữa rover–base. Từ hai bộ quan sát này, bộ xử lý tạo single-difference hoặc double-difference để giảm mạnh ảnh hưởng của đồng hồ vệ tinh, đồng hồ máy thu và các sai số tương quan khác; sau đó EKF hoặc least-squares ước tính đồng thời vị trí và ambiguity carrier-phase.
Điểm quyết định không phải chỉ là “đã nhận RTCM”, mà là rover có giải được ambiguity thành số nguyên hay không. Khi ambiguity vẫn được giữ dưới dạng số thực, nghiệm là Float; khi thuật toán integer ambiguity resolution tìm được nghiệm nguyên và vượt kiểm định thống kê, rover chuyển sang Fixed, cho phép khai thác độ chính xác centimet của carrier-phase.
Correction hợp lệ là điều kiện cần nhưng chưa đủ để Fixed: mất khóa, multipath, hình học vệ tinh kém hoặc quan sát không đồng bộ vẫn có thể giữ rover ở Float. Với đội khảo sát hiện trường, trạng thái Fixed ổn định mới cho thấy toàn bộ chuỗi correction → differencing → ambiguity resolution đang hoạt động thành công.
Dữ liệu sửa sai RTK không còn đủ để giữ nghiệm Fixed khi một trong ba điều kiện bị phá vỡ: correction đến rover không còn đúng và liên tục, base không cung cấp tham chiếu đáng tin cậy, hoặc rover không còn quan sát vệ tinh đủ tốt để giải ambiguity.
Điểm phân biệt hữu ích là không chẩn đoán từ trạng thái “receiving corrections” riêng lẻ: nếu đổi sang vùng trời thoáng mà Fix trở lại, ưu tiên kiểm tra môi trường rover; nếu cùng vị trí nhưng đổi base/mountpoint lại ổn định, ưu tiên kiểm tra nguồn correction, định dạng và đường truyền.
Muốn một hệ thống RTK hoạt động ổn định, cần nhìn toàn bộ chuỗi từ Base/CORS, luồng RTCM, kênh truyền đến Rover thay vì xem “dữ liệu sửa sai” như một thành phần duy nhất. RTCM quyết định Rover nhận được thông tin gì; NTRIP chỉ đưa luồng đó qua mạng tới đúng client và mountpoint. Khi RTK chậm Fix, mất Fix hoặc ngừng nhận hiệu chỉnh, đội khảo sát nên kiểm tra theo đúng từng lớp chức năng để khoanh vùng nguyên nhân trước khi thay đổi cấu hình hoặc thiết bị.
Liên hệ
Zalo
Báo giá
Vị trí