RTK không nhận CORS: Kiểm tra NTRIP, RTCM, Mountpoint

09/04/2026

RTK không nhận CORS chưa đồng nghĩa receiver gặp lỗi GNSS; trước hết cần xác định corrections đang dừng ở Internet, phiên NTRIP, mountpoint hay luồng RTCM. Với đội trắc địa đang chạy tiến độ ngoài hiện trường, cách kiểm tra hiệu quả là đi theo trạng thái kết nối và thông lượng dữ liệu: caster có truy cập được không, đăng nhập có thành công không, mountpoint có trả stream và RTCM có thực sự chảy vào máy hay không. Khi tách đúng lớp lỗi, việc xử lý sẽ nhanh hơn và tránh mất thời gian chỉnh GNSS khi nguyên nhân vẫn nằm ở kết nối.

Xác định RTK đang mất kết nối CORS ở bước nào?

Muốn khoanh đúng lỗi khi RTK không nhận CORS, hãy kiểm tra theo chuỗi NTRIP từ kết nối mạng → đăng nhập → mountpoint → dòng RTCM → nghiệm RTK; trạng thái cuối cùng rover đạt được chính là mốc xác định bước lỗi gần nhất.

Dấu hiệu quan sátBước đang lỗiKiểm tra tiếp theo
Không kết nối được casterMạng/transportSIM, APN, sóng, địa chỉ server và port
Caster phản hồi nhưng báo 401/login failedXác thựcUsername, password, hạn tài khoản
Đăng nhập được nhưng không có danh sách mountpointSource table/casterPort, trạng thái caster, sourcetable
Chọn mountpoint và Connected nhưng byte/RTCM không tăngMountpoint/streamTên mountpoint, stream có hoạt động, GGA có được gửi
RTCM tăng nhưng nghiệm vẫn SingleCorrection chưa được rover sử dụng đúngSatellite lock, GGA, định dạng RTCM tương thích
RTCM tăng nhưng nghiệm giữ FloatChất lượng nghiệm RTKCorrection age, vệ tinh/DOP, baseline, che khuất và multipath

Điểm phân biệt quan trọng là “Connected” chưa chứng minh rover đã nhận correction: byte/RTCM phải tăng; ngược lại, RTCM đã tới mà chưa FIX thì nên chuyển kiểm tra chất lượng GNSS và môi trường thay vì tiếp tục sửa Internet hoặc tài khoản.

Kiểm tra Internet và SIM trước khi sửa cấu hình NTRIP

Khi RTK không nhận CORS, chưa nên đổi Server, Port hay Mountpoint ngay: trước hết phải xác nhận thiết bị thực sự có đường truyền Internet hoạt động, vì NTRIP chỉ có thể kết nối sau khi lớp SIM–mạng–data đã thông.

  1. Kiểm tra SIM và đăng ký mạng. Xác nhận SIM được nhận, không bị khóa PIN, còn dịch vụ data và modem đã đăng ký vào mạng di động. Với modem hỗ trợ AT command, AT+CPIN? = READY kiểm tra trạng thái SIM; trạng thái đăng ký mạng phải cho thấy đã registered.
  2. Kiểm tra data session, không chỉ cột sóng. Có sóng hoặc đăng ký mạng chưa đồng nghĩa có Internet. Receiver/controller cần có kết nối data hoạt động và được cấp IP; APN sai có thể tạo tình huống “có sóng nhưng không vào mạng”.
  3. Xác nhận Internet bằng tác vụ độc lập với NTRIP. Trên đúng controller hoặc đường truyền mà NTRIP sử dụng, thử mở một trang web hoặc kiểm tra trạng thái Online/Connected. Nếu Internet chưa hoạt động, sửa NTRIP lúc này chỉ làm tăng số biến cần chẩn đoán.
  4. Dùng đổi SIM/đường truyền như phép thử cách ly. Nếu cùng receiver hoạt động với SIM hoặc hotspot khác, nghi ngờ chuyển về SIM, APN hoặc đường mạng ban đầu; nếu lỗi vẫn tái hiện, mới ưu tiên kiểm tra NTRIP, receiver hoặc dịch vụ CORS. Đây là cách khoanh vùng nguyên nhân, không phải bằng chứng tuyệt đối rằng nhà mạng hay thiết bị bị lỗi.

Kiểm tra NTRIP: Server, Port, tài khoản và mật khẩu

Khi RTK không nhận CORS, hãy kiểm tra NTRIP theo đúng thứ tự kết nối: Host/Port → xác thực → dữ liệu correction; trạng thái dừng ở bước nào sẽ giúp khoanh vùng lỗi nhanh hơn thay vì đổi đồng loạt mọi thông số.

  1. Kiểm tra Server và Port. Nếu rover không thiết lập được TCP và không có phản hồi HTTP, ưu tiên kiểm tra Host/IP, kết nối Internet và cổng NTRIP. Timeout hoặc “Cannot connect” thuộc nhóm lỗi đường truyền, chưa phải lỗi tài khoản.
  2. Kiểm tra Username và Password. Nếu TCP đã kết nối nhưng caster trả 401 Unauthorized hoặc 403 Forbidden, đường mạng đã hoạt động; cần kiểm tra lại NTRIP credentials, khoảng trắng khi nhập và trạng thái tài khoản. Đây là điểm phân biệt quan trọng: đổi Server/Port thường không giải quyết lỗi xác thực.
  3. Nếu đã đăng nhập nhưng vẫn không có correction, đừng tiếp tục tập trung vào mật khẩu. HTTP 200 OK nhưng không có RTCM chuyển chẩn đoán sang mountpoint, yêu cầu gửi NMEA GGA hoặc trạng thái nguồn correction.

Vì vậy, “Connected” không đồng nghĩa NTRIP đã hoạt động hoàn chỉnh: chỉ khi rover bắt đầu nhận stream RTCM mới nên chuyển sang kiểm tra khả năng đạt FLOAT/FIX.

Kiểm tra Mountpoint và xác nhận Rover thực sự nhận RTCM

Khi RTK không nhận CORS, đừng dùng trạng thái “Connected” làm bằng chứng correction đã vào rover; hãy xác nhận theo chuỗi Mountpoint đúng → RTCM thực sự truyền → rover giải mã correction, rồi mới đánh giá nghiệm FIX.

  1. Xác nhận đúng Mountpoint. Đối chiếu tên stream với dịch vụ CORS và định dạng rover hỗ trợ; ví dụ Reach hỗ trợ RTCM3 từ MSM4 trở lên. Với VRS hoặc dịch vụ chọn trạm theo vị trí, phải bật gửi NMEA GGA, nếu không caster có thể không cấp correction dù kết nối NTRIP đã hình thành.
  2. Kiểm tra RTCM có thực sự chạy. Sau Connect, quan sát bộ đếm dữ liệu/RTCM hoặc chỉ báo correction của phần mềm. “Connected” chỉ xác nhận phiên NTRIP; nếu dữ liệu không tăng, ưu tiên kiểm tra lại mountpoint, quyền truy cập và yêu cầu GGA thay vì chờ FIX.
  3. Tách lỗi truyền correction khỏi lỗi tạo nghiệm. Khi dữ liệu RTCM đang tới nhưng rover vẫn Float, kiểm tra tiếp khả năng tương thích RTCM/MSM và điều kiện quan sát vệ tinh; Emlid cũng yêu cầu mountpoint cung cấp RTCM3 và tầm nhìn bầu trời phù hợp.

FIX là kết quả cuối, không phải phép thử duy nhất cho Mountpoint. Khi xử lý RTK không nhận CORS, hãy chứng minh dòng RTCM trước rồi mới chẩn đoán chất lượng nghiệm.

RTCM đã chạy nhưng RTK vẫn không Fix thì kiểm tra gì?

Nếu RTCM vẫn cập nhật và Correction Age duy trì thấp nhưng rover vẫn Float, nên chuyển chẩn đoán từ “mất CORS” sang chất lượng thu GNSS, multipath và khả năng rover thực sự sử dụng dòng correction.

  • Xem Correction Age trước: byte có chạy chưa đủ chứng minh correction đang hữu dụng. Nếu Age tăng liên tục hoặc RTCM ngừng cập nhật, quay lại kiểm tra NTRIP, SIM và mountpoint.
  • Kiểm tra sky view, số vệ tinh và DOP: vật che khuất hoặc hình học vệ tinh kém có thể giữ nghiệm ở Float dù correction đến đều.
  • Loại trừ multipath: đưa rover ra vị trí thoáng, xa mái tôn, kính, hàng rào kim loại hoặc mặt nước. Nếu rover Fix tại vị trí mới, ưu tiên xử lý môi trường đo thay vì CORS.
  • Kiểm tra RTCM/mountpoint: xác nhận receiver hỗ trợ các message RTCM đang phát, các chòm sao cần thiết được bật và mountpoint phù hợp với rover.
  • Chỉ nghi phần cứng sau cùng: nếu cùng rover vẫn Float ở vị trí thoáng, correction ổn định và nhiều mountpoint phù hợp, mới chuyển sang anten, cáp, firmware hoặc receiver.

Điểm phân luồng quan trọng là trạng thái correction: RTCM đều + Age thấp → kiểm tra khả năng giải nghiệm; Age tăng/ngừng → quay lại đường truyền CORS.

Khoanh vùng lỗi ở CORS, đường truyền hay riêng một máy Rover

Khi RTK không nhận CORS, đừng kết luận từ một lần đổi SIM hoặc đổi mountpoint; hãy giữ nguyên hai biến và chỉ thay một biến mỗi lần để xem lỗi “đi theo” CORS, đường truyền hay một Rover cụ thể.

Phép đối chứngKết quả lặp lạiKhoanh vùng ưu tiên
Nhiều Rover + nhiều SIM, cùng caster/mountpointTất cả cùng lỗi; đổi caster/mountpoint thì hoạt độngCORS/NTRIP: server, port, tài khoản, mountpoint
Cùng Rover + cùng CORS, đổi SIM hoặc Wi-FiChỉ một SIM/mạng lỗi; Wi-Fi hoạt độngĐường truyền: coverage, data plan, APN hoặc modem
Nhiều Rover cùng SIM/CORS/vị tríChỉ một Rover luôn lỗiRover: profile NTRIP, firmware, modem, cổng dữ liệu, anten/cáp

Điểm phân biệt quan trọng là lỗi có bám theo biến được thay hay không: một lần đổi SIM rồi Fix chỉ là tín hiệu, vì chất lượng mạng hoặc caster có thể đồng thời thay đổi. Ngược lại, mẫu lỗi lặp lại qua nhiều tổ hợp mới đủ mạnh để thu hẹp nguyên nhân.

Nếu lỗi chỉ xuất hiện ở một Rover nhưng máy đó Fix qua Wi-Fi, chưa nên kết luận receiver hỏng; ưu tiên kiểm tra SIM–APN–modem nội bộ trước.

Khi nào nên dừng tự xử lý và chuyển máy cho kỹ thuật viên?

Nên dừng tự xử lý khi lỗi RTK không nhận CORS vẫn bám theo chính rover sau khi đã loại trừ cấu hình NTRIP, mountpoint, tài khoản và đường truyền; lúc đó khả năng lỗi đã chuyển từ “thiết lập” sang tầng thiết bị cần chẩn đoán chuyên sâu.

  • Chuyển kỹ thuật nếu thiết bị đối chứng vẫn hoạt động: cùng vị trí và nguồn CORS, rover khác nhận correction/Fixed bình thường nhưng máy lỗi vẫn Disconnected, Single hoặc không nhận RTCM. Khi đổi SIM/hotspot và kiểm tra lại caster–port–mountpoint không làm kết quả thay đổi, modem, firmware hoặc cổng dữ liệu trở thành nhóm cần kiểm tra.
  • Chuyển kỹ thuật nếu lỗi tái diễn sau reset/hiệu chuẩn: vòng lặp mất NTRIP hoặc Fix → Float → Single vẫn xuất hiện trong điều kiện mạng ổn định; IMU, cảm biến nghiêng hoặc anten tiếp tục báo lỗi sau cấu hình và hiệu chuẩn đúng quy trình.
  • Chưa nên kết luận máy hỏng nếu thiết bị đối chứng cũng mất correction: đây là ngoại lệ quan trọng, vì lỗi đồng thời trên nhiều rover có thể nằm ở CORS, mountpoint hoặc mạng thay vì phần cứng.

Quy tắc thực địa: lỗi bám theo một máy sau các phép thử đối chứng → ghi log và chuyển kỹ thuật; lỗi xuất hiện trên nhiều máy → kiểm tra mạng/CORS trước.

Mốc phân nhánh quan trọng là luồng RTCM: nếu byte counter vẫn bằng 0 hoặc corrections bị gián đoạn, hãy tiếp tục kiểm tra Internet, tài khoản NTRIP, mountpoint và GGA theo yêu cầu của caster. Khi RTCM đã truyền ổn định nhưng receiver vẫn giữ trạng thái Single hoặc Float, lỗi nên được chuyển sang nhánh GNSS/RTK thay vì tiếp tục chỉnh NTRIP. Lúc đó, ưu tiên kiểm tra điều kiện thu vệ tinh, khoảng cách tới base/CORS, cấu hình datum/epoch và khả năng hỗ trợ stream RTCM của receiver.

Để lại một bình luận

Trở lại đầu trang