Several years ago, I shared a blog post about creating an RTK base station and transmitting data via an NTRIP caster, which worked flawlessly at the time. However, after some time, people encountered an issue with Mission Planner’s connection to Centipède, the NTRIP caster in my demo. In this blog post, I will detail my journey to fix this problem and bring back the seamless functionality of my setup.
The investigation
To start, I needed to identify the culprit behind the issue—was it Mission Planner, Centipède, or perhaps both?
To gather clues, I looked on reports on discuss and noticed reports suggesting that it had worked with previous Mission Planner releases, implying that a change in Mission Planner might be the source of the problem.
Upon exploring Mission Planner’s GitHub repository, I located the NTRIP connection code in ExtLibs/Comms/CommsNTRIP.cs. Examining the commit history, I discovered that a few months after my initial post, the NTRIP connection protocol had transitioned from V1 to V2. To gain a better understanding of these protocols, I researched and found explanations on the differences between NTRIP V1 and V2 formats at this link.
According to the information I gathered, NTRIP V1 should return:
ICY 200 OK<cr><lf>
While NTRIP V2 should return:
HTTP/1.1 200 OK<cr><lf>
I then attempted to connect Mission Planner to Centipède (http://caster.centipede.fr:2101/TCY22, the nearest caster to my location) and observed that the caster responded correctly with V2 protocol, but data retrieval remained elusive.
This led me to question whether Mission Planner was at fault.
Upon further investigation, I tested the connection with rtk2go, a free NTRIP caster (http://email:none@rtk2go.com:2101/JFSM), and it worked seamlessly. This confirmed that Mission Planner’s NTRIP implementation was not the issue. (replace @ in your email with -at- to make it works)
The conclusion: Centipède was the likely culprit. To validate this hypothesis, I decided to test Centipède with another Ground Control Station (GCS), Mavproxy, which includes an NTRIP module.
Surprisingly, it worked well with Centipède. However, a closer look at the code (https://github.com/ArduPilot/MAVProxy/blob/master/MAVProxy/modules/lib/ntrip.py#L272) revealed that Mavproxy utilized NTRIP V1 protocol by default.
So V2 protocol doesn’t work but V1 does ?
So, while V1 worked, V2 did not. It appeared that Centipède, which relied on the RTKLib backend (https://www.rtklib.com/), was the root cause. Further examination of the RTKLib codebase revealed an issue (Does RTKlib support NTRIP protocol version 2.0 ? · Issue #592 · tomojitakasu/RTKLIB · GitHub), indicating that NTRIP V2 was not supported by RTKLib. Consequently, Centipède and possibly other systems relying on RTKLib as their backend were affected.
How to fix the issue then ?
The ideal solution would be to implement NTRIP V2 support in RTKLib, but this would require C black magic. On the other hand, we can enable back V1 support on Mission Planner even if I am no a C# developper.
Modifying Mission Planner
Since I wasn’t familiar with modifying Mission Planner, I referred to the wiki for guidance (Building Mission Planner with Visual Studio — Dev documentation).
Unfortunately, I encountered outdated instructions.
Fortunately, the Mission Planner GitHub repository had more up-to-date information in its Readme (GitHub - ArduPilot/MissionPlanner: Mission Planner Ground Control Station for ArduPilot (c# .net)).
I proceeded to create a simple pull request (PR) to add a checkbox in the NTRIP connection settings, allowing users to select NTRIP V1 Protocol instead of V2 . So C# master would be able to make an automatic failover logic. However, as I mentioned earlier, it wasn’t straightforward since a caster like Centipède responded with HTTP/1.1 200 OK<cr><lf> —the correct answer for V2 connections.
As the wiki instructions were outdated, I took the opportunity to update them to benefit others (dev: update Mission Planner building instructions by khancyr · Pull Request #5418 · ArduPilot/ardupilot_wiki · GitHub).
Lastly, due to slow building times for the wiki, I submitted another PR (dev: update Mission Planner building instructions by khancyr · Pull Request #5418 · ArduPilot/ardupilot_wiki · GitHub) to enhance the building process’s speed.
Results :
In summary, my efforts led to the following outcomes:
- A simple checkbox in Mission Planner for selecting NTRIP V1 Protocol.
- Working Centipède NTRIP Caster and any using NTRIP V1.
- Updated wiki instructions for others facing similar challenges.
With these changes, I hope to make it easier for developers to address similar issues in the future and maintain the smooth operation of RTK-based systems like mine.