I am using the Reach RTK GPS connected to my Pixhawk as a secondary GPS. (Its not used for navigation just for reference.) With Copter 3.4, I could send the UBlox formatted corrections to the Reach via the MAVLINK telemetry from the base station and they were routed correctly to the Reach. With Copter 3.5 RC8, the corrections don’t seem to be routed correctly since the Copter’s Reach never registers that the corrections arrived. It did work as expected with RTCM3 formatted messages in both 3.4 and 3.5. I’d like to continue to use the UBlox formatted messages since they provide quicker RTK fixes and contain other useful information for the RTK algorithms.

I know there was a lot of work done on the GPS code for Copter 3.5. Were there any changes that would’ve affected the routing of the UBlox formatted messages? (They get encapsulated in the MAVLINK msg_gps_rtcm_data_dynamic messsage.) One difference in the UBlox vs. RTCM3 messages is that the UBlox messages are larger and have to be broken up into multiple MAVLINK messages.

It appears that smaller UBlox messages get forwarded to the Copter’s RTK GPS, but once many more satellites start getting tracked, the messages get larger and do not get forwarded to the GPS. It is likely due to logic within the firmware related to combining multiple message fragments into one to forward to the GPS. Like I mentioned, this appears to be a regression in the 3.5 RC8 firmware as compared to 3.4.6 since the only thing I changed was the firmware version on the copter.

RTCM3 formatted messages work fine with even 13 satellites or more with both 3.5 and 3.4.6.

How are you sending the corrections? You mention msg_gps_rtcm_data_dynamic however that isn’t a standard message in common so I’m unsure how you are sending it.

3.5 does use http://mavlink.org/messages/common#GPS_RTCM_DATA however you do have to implement the fragmenting rules described there which Mission Planner and MAVProxy both do, but I’m really lost on what message you are trying to use for this.

@WickedShell, I’m using the gps_rtcm_data message. (The dynamic version was an extended class to make the array size variable based on the message size. The original generated class forced the payload to 180 even if all 180 bytes weren’t used. I’m doing this in Java BTW.)

I’ll review the fragmenting rules to ensure that I’m doing it correctly. My implementation works for 3.4.6, but I didn’t see much different in the https://github.com/ArduPilot/ardupilot/blame/master/libraries/AP_GPS/AP_GPS.cpp#L957 that joins the fragments together so I’m rechecking my implementation. It didn’t work in Mission Planner either, but I’m not sure if Mission Planner forwards the UBlox formatted messages as opposed to the RTCM3 messages. (I didn’t test MP with 3.4.6 and UBlox messages.)

@OXINARF, Do I need to create a fork in my repository to create a branch for the pull request? (I haven’t done this on github before.)

Also, it looks like the 4 record limit on fragments can be too low when you include GPS, GLONASS, SBAS and Galileo satellites. I have to filter or remove constellations to get under the 4 record limit.

What messages are you trying to use? The buffer was setup to allow transporting RTCM data correctly, and there just aren’t enough bits in the flags field to allow more then 4 fragments. (Blame the fact that the message was created without any thought on how to handle fragmenting, and the fragmentation protocol was developed by ArduPilot to attempt to cope with that).

@rrr6399 you can fit up to 22 measurements in with that message, the RTCM stuff was designed to handle the probable range of RTCM messages, so if you can move to those instead you should be fine, but anything else it could be to large.

You could fall back to just the old injection method which doesn’t have fragmenting or reassembling, but you end up racing against the GPS driver or any data loss so that won’t be a reliable solution in that case…

I was getting faster and more reliable fixes with the UBlox messages. There have been some fixes (like higher resolution timestamps and such) with the RTCM3 messages so its possible I may get decent results now. It would be nice in the future to accommodate the size of the UBlox messages in the future for all constellations since it provides more information for the RTK algorithms and removes a translation step.

The down side is RTCM is what the industry uses and has standardized upon, and you can’t keep increasing the message size for corrections. IE RTCM already supports L1/L2 multiple constellations quite nicely, and does inject through the current path.

I’m not set against a larger message per say, but it means larger buffers on the autopilot, and the message is more and more likely to be lost in transport over the radios most commonly used. I suspect looking at the proven solutions that can already handle all these input types is better long term then just trying to handle everything in a single message.

I’ll test it out and see. I’d rather use RTCM3 since there is less custom configuration work and the bandwidth is less, but in the past I had a very difficult time getting fixes with RTCM3 messages on the Reach. That was back in January though so the landscape may be different now. (UBlox had the doppler shift info and didn’t truncate measurements as much. RTKExplorer recommended the UBlox messages and they did work better.)