[Rtk] Data above 180 bytes length not working

[Katawann]

Hi,

I tested the new RTK plugin and it works like a charm ! Thank you @julianoes for the job.

In my working setup I have something like this:
Ntrip caster <---> Internet <---> Linux Ubuntu 20.04 <---> C++ app with MAVSDK and Ntrip Client <---> USB <---> Pixhawk 4

I noticed that if I send a data with length of 4*180 bytes (accepted by the plugin) it will never turn to RTK position, but sending 180 bytes works fine. Not sure to understand the logic around the fragment ID. Maybe the plugin should only accept 180 bytes maximum or is there a logic I missed ?

[JonasVautherin]

The maximum length of the mavlink payload is 255 bytes. Not sure what happens if you write 4*180=720 bytes into the message (that would happen here: https://github.com/mavlink/MAVSDK/blob/main/src/mavsdk/plugins/rtk/rtk_impl.cpp#L60), but I guess if it doesn't crash, maybe it's just ignoring whatever is exceeding.

My feeling is that the rtk plugin should check the length of the data and return an error if it's bigger than 180 (which is what is specified here: https://mavlink.io/en/messages/common.html#GPS_RTCM_DATA

[julianoes]

Thanks for the issue. I'll have a look.

[Katawann]

From my understanding, MAVProxy ntrip module is sending N packets of 180 bytes according to the size of the RTCM data https://github.com/ArduPilot/MAVProxy/blob/65acf3a9cef818ea819ac0ccac3c5a9577bd1d06/MAVProxy/modules/mavproxy_ntrip.py#L115

[JonasVautherin]

Oh, I misread the code, sorry 🙈. The specs read:

RTCM message (may be fragmented)

And the code is apparently trying to split the data in multiple messages. So that's something to debug indeed 👍.

To me it feels like this line is wrong, as it always sends rtcm_data.data.c_str(), and it should instead take the right part of it for each message.

[julianoes]

Oops, that's indeed wrong.

[Katawann]

Awesome thank you good job. I'll test it and come back here if I still see an issue