RTKFix works fine for others, but not for me. Why?

It’s difficult to explain, but

https://ardupilot.org/rover/docs/common-gps-for-yaw.html
RTKFix does not work even if you refer to this.
Ntrip’s servers are also running well.

I am using F9PX1.
The board status LED is
GPS1 says “Blinking: Correction data has been received but not fixed.”
For those connected to GPS2, “Light off: Fix is in progress.”
is.
Even if you replace this board, the status LED will still be a sign that GPS1 is not fixed and GPS2 is fixed.

I’ve been stuck on this task for several months already.
Do you have any ideas for a solution?



What I have done so far to solve the problem.
Initializing two F9P boards
Wiring processing of two F9P boards
Connect two F9P boards to u-center and initialize them
Confirmed that the two F9P boards and GPS antennas will be RTKFixed using NTRIP at u-center.
Mission Planner parameter changes
(See the image above for the changed location)
Connect two F9P boards to Pixhawk CUBE Orange’s GPS1 and GPS2
I connected Pixhawk CUBE Orange to the PC and connected to the NTRIP server.

But it won’t be RTKFix.
What else should I adjust to get RTKFix?

@Eosbandi may know:

Does Mission Planner forward RTCM3 over USB?

And, does Mission Planner (and/or MavLink) handle/forward MSM7 messages or only MSM4?

Does Mission Planner forward RTCM3 over USB?
No, it is transferred using the Wireless Telemetry Unit 2.4GHz Transmitter/Receiver Set for Pixhawk2.
SERIAL1_Protocol is 2
SERIAL1_BAUD is 38.

does Mission Planner (and/or MavLink) handle/forward MSM7 messages or only MSM4?
This is MSM7.

Sorry, I thought you were using a USB connection for testing, and I’m asking a developer to share some insight.

And yes, I can see that it’s MSM7 (with even larger packet sizes), hence my other question to the dev…

But since you shared some more config info:

MP shows 57600 baud, and your autopilot is set to 38400. Neither of those rates have the bandwidth for the large RTCM3 packet sizes. 460800 is usually recommended, though 115200 might get it done. The low bandwidth might be the root cause of your issue.

Thank you for your advice.
Now, about 20 minutes have passed since I changed SERIAL1_BAUD to 460.
GPS: remains as 3D dgps.

You can’t just arbitrarily change baud rates. I’m not familiar with that radio link, but it sounds poorly configured, and I’m surprised it works at all after you changed that parameter so drastically. You should read the manual for it and properly configure it to its max practical rate on BOTH endpoints.

1 Like

The recommendation for SERIAL1_BAUD is 38400, so return SERIAL1_BAUD to 38.
Even if I try changing the baud rate, there is no change.
I’m stuck again.

38400 is not enough for RTCM injection AFAIK.

The instructions for the telemetry module I’m using include
SERIAL1_BAUD is written as 38400.

It seems that other people are also connecting with 38400 and doing RTKFix.
If 38400 is not enough, how many should I use?

230400 is the baud rate that uBlox uses. But if other people have got that model working at 38400 then use that.

In the explanation on this person’s web page, it is stated that SERIAL1_BAUD is 38 for the same telemetry device as me, and this person writes that he came with RTKFix, so I think SERIAL1_BAUD should be 38.

Sorry, but just because someone makes a claim on YouTube, it doesn’t change the math. Your 1127 message alone is possibly taking up half the available bandwidth, and you still have to package RTCM3 inside Mavlink2 AND carry all the telemetry messages on that link. I don’t see how that’s remotely possible at 38k baud.

I’m sorry, but I can’t translate that manual into a language I speak/read, but I do see a spec of 250kbps in the chart, and even the examples show 57600 in Mission Planner (which is still too low, but it’s a step in the right direction). Perhaps the baud rate can be increased.