GPS RTCM data not recognized by F9P chip/u-center

[greinet]

Hello,

I`m trying to receive to use a Pixhawk together with a simpleRTK2B board and an online NTRIP service. My plan is to receive the NTRIP data on a companion computer and send the RTCM data via MAVSDK to the Pixhawk. The Pixhawk should then send the data automatically to the simpleRTK2B’s F9P chip and thereby create an RTK fix.

My current setup is using the NTRIP client from MAVProxy and I convert the rtcm data as described here.

from ntrip import NtripClient
import sys
import asyncio
from mavsdk import System
from mavsdk.rtk import RtcmData
from pyrtcm import RTCMReader

async def send_to_px4(raw_rtcm_data):
    msg = RTCMReader.parse(raw_rtcm_data)
    print(msg.identity)
   
    drone = System(mavsdk_server_address='localhost', port=50051)
    await drone.connect()
    await drone.rtk.send_rtcm_data(RtcmData(str(raw_rtcm_data)))

if __name__ == '__main__':
    n = NtripClient( user="username",
                     port=2101,
                     caster="casterip",
                     mountpoint="mountpoint",
                     lat=48,
                     lon=12,
                     height=0,
                    );

    for raw_rtcm_data in n.readLoop():
        asyncio.run(send_to_px4(raw_rtcm_data))

I changed this line in the NTRIP client to yield return the data instead of printing it.

    def readLoop(self):
        while True:
            data = self.read()
            if data is None:
                continue
            else:
                yield data

The RTCM data is received by the Pixhawk and forwarded to the simpleRTK which I can see by connecting to the simpleRTK via u-center, however the data can`t be parsed and is labeled as unknown.

Now it could be that I somehow misconfigured the simpleRTK board, but to find that out I was trying to follow the RTCM data and see if it gets mixed up somewhere.
My first step was to look at the gps_inject_data message using QGroundControl`s MAVLink Console. When viewing the data there, I was not able to find any relation between the data I sent to the PixHawk and the data printed out there.

The data i sent started with 211, 0, … and I found no match somewhere in the array.

Now my question is if I am parsing the data correctly and if the way I check the data is even correct. I would also be interested what the “flags” parameter in the message means exactly as this was the only thing changing at some times.

Please let me know if you need any further data or description of what I tried so far as I might have forgotten something.

Greetings,
Andy

[Pauli_J]

Did you manage it to get to work, I have similar issues, the rtk fix just doesn’t happen. send_rtcm_data is not complaining anything, data goes to PX4 but nothing happens

[JulianOes]

I wonder if RtcmData(str(raw_rtcm_data)) is the right approach. Shouldn’t it be bytes instead of str?

[Marc_Schneebeli]

Hello
This problem seems to persist. I send the correct RTCM data (as string, as it is suggested here
Data I send start with [211, 0, 123, 67, …
Data I observe at the mavlink console with

nsh> listener gps_inject_data

appear somehow random and hence the the gps fix_type remains at 3 and never reaches 6. With QGroundControl in contrast, it works perfectly.

Any suggestions on how to use the

await drone.rtk.send_rtcm_data(rtk.RtcmData(str(rtcm_correction_data)))

function properly?
Thanks
Marc

[Marc_Schneebeli]

Maybe it helps if some more information is provided:

MAVSKD Version is 2.8.1
I use some test data to send to the drone:

rtcm_correction_data = bytes([0x7f, 0x0, 0x0, 0x0, 0x0])

I send the data with:

await drone.rtk.send_rtcm_data(rtk.RtcmData(str(rtcm_correction_data,‘latin-1’)))

At the console, I enter the command

pxh> listener gps_inject_data

and get the data that arrived at the drone: [127, 0, 0, …, 0], as it should be.
However, for larger numbers it behaves differently, i.e., for

rtcm_correction_data = bytes([0x80, 0x0, 0x0, 0x0, 0x0])

The data arriving at the drone is [194, 128, 0, 0, …, 0] instead of [128, 0, 0, …, 0]
So obviously I still haven’t found out how this rtk correction data is being handled and how I have to provide it. Any hint is appreciated, thanks.

[JulianOes]

This doesn’t work currently but will be fixed with v3 which will come out shortly.

Also see: Change RTK to base64 · Issue #2314 · mavlink/MAVSDK · GitHub

[Marc_Schneebeli]

Thank you. I was able to make it work by compiling mavsdk server myself, adapting some proto files and referencing mavsdk python to the new server binary. Looking forward to v3.

[JulianOes]

Right, sorry for the pain.

[ndr222]

Hello @JulianOes!! I have a similar problem. I’m trying to inject RTCM corrections to Holybro F9P from Pixhawk, that is receiving them by ROS2 and UXRCE agent-client via TELEM2 port (ROS2 in running on a Jetson). Currently, I can see gps_inject_data as uorb topics in px4 shell (listener gps_inject_data) and they seem valid, but inspecting gps status show that no RCTM correction are received. So I guess the corrections are entering the PX4 environment but are not forwarded to the GPS module.

I configured GPS_1_CONFIG to GPS1 (where F9P is connected), SER_GPS1_BAUD is Auto (but 115200 has the same result), GPS_UBX_MODE is Default. In u-center I configure UART1 port of F9P with: Protocol in=UBX+NMEA+RTCM3, Protocol out=UBX, Baudrate = 115200.

I have noticed:

• if enabling parameter SEP_PORT1_CFG then gps cannot comunicate (gps status in px4 shell shows: no gps running)
• in MAVLink Inspector i can see GPS_RAW_INT updating (even with no signal since i’m indoor) but I don’t see GPS_RTCM_DATA
• in u-center I can see some UBX data updating (e.g. UBX-NAV_PVT) but no fix (I know I’m indoor, but i’m sending correction through ROS2 reading from a binary file recorded outdoor) and no RTCM

I can’t really understand what I’m doing wrong, also I’ve tried with different parameters and also using TELEM1 (Pixhawk side) and UART2 (F9P side) to connect the GPS module, but still no luck.

Any help would be appreciated, thanks!

[JulianOes]

@ndr222

SEP_PORT1_CFG

Yes, that would probably interfere with the same serial port.

Here is where the injection should happen:

src/drivers/gps/gps.cpp

What PX4 version is this? And maybe you can share a log of it?

[ndr222]

Thanks for your reply! I’m using PX4 1.15.

Looking at the gps.cpp was a great hint. The issue was that i was sending the correction messages using the device_id of the GPS, but then i found out these line of the gps.cpp:

// Prevent injection of data from self
			if (msg.device_id != get_device_id()) {
				/* Write the message to the gps device. Note that the message could be fragmented.
				* But as we don't write anywhere else to the device during operation, we don't
				* need to assemble the message first.
				*/
				injectData(msg.data, msg.len);

				++_last_rate_rtcm_injection_count;
				_last_rtcm_injection_time = hrt_absolute_time();
			}

and I understood. Thanks for your time, hope this help someone else!

[JulianOes]

Aha, so what device ID did you have to use? I wasn’t aware of this.