I have used both the C-RTK 2 and 9PS modules. Both use the u-blox F9P receiver, so both have the same RTK precision/accuracy.
With RTK, you’ll get extremely similar results than with PPK. PPK is really just RTK, but post-processed. There are some benefits to PPK, there are so many options you can configure in software such as RTKlib (PPK open-source software). Here are two PPK vs RTK comparaisons
- PPK vs RTK: A look at RTKLIB for post-processing solutions – rtklibexplorer (using older M8N receiver)
- Comparing real-time precise (RTK) solutions for the u-blox F9P – rtklibexplorer (Using F9P receiver)
I guess one main advantage of PPK is that you can not only filter forwards, but you can filter backwards. With RTK, in real-time, the receiver only knows where it was, and not where it will be. So the RTK algorithm can use the fact that it knows where it precisely was last timestep to help know where it currently is. But sometimes the signal might degrade, and the receiver will lose the RTK Fix and downgrade to RTK float. Eventually, it can regain RTK Fix. But with PPK, you can filter forwards and backwards, meaning that if there are moments of uncertainty in the positioning, it can use past and future precise positioning to get a better precision on those uncertain moments.
Another advantage of PPK over RTK is if you have to fly far, RTK might drop if the drone looses comms with the ground station. With PPK, even if the drone is not wandering around because it doesn’t have RTK, the RAW logs will provide precise positioning.
I think Ardupilot supports logging RAW UBX messages (messages sent from u-blox receivers), although I have never done so. Maybe @tridge would know. According to this merged pull request, you can also record triggered events, like taking pictures. But I’m not sure what the setup would be. So it’s possible you don’t need a RAW logger just for PPK.
I’ve had a couple gripes about the C-RTK 2, although it might not be an issue for you.
- The UAVCAN node inside the C-RTK 2 (which transcribes the UART output of the F9P to CAN for Ardupilot) should send 2 types of altitudes to Ardupilot (EGM96 and WGS84 altitudes), but it only sends one type of altitude twice (WGS84) while Ardupilot defaults to using EGM96. The drone will still fly well, and the logs from the C-RTK 2 will give you good PPK data, but for my application, where I needed to fly a drone relative to a target drone, the altitudes were messed up. My post: Vertical Datum used by C-RTK 2 GPS
I don’t know if they’ve fixed this yet or not. - I found another issue with their CAN node that I haven’t reported yet. The velocity outputted by the CAN node is delayed by 200 ms compared to the position output. It’s not a major issue if you fly slowly, but in my work case where I fly at 80-120 km/h, it caused significant state estimation issues.
Hope this help with your decision making!