RTK gps on a budget (Quectel LC29HEA)

This evening it finally stopped raining outside, so I was able to do a test setup:

Unfortunately the RTK-float/fix did not work for me. To check, I got an RTK fix at the same position before and after with the QGNSS.exe within a few seconds. When connected first to Arducopter then Arduplane on a Mateksys h743 wlite, a 3D fix could be achieved, but no RTK-float or fix. The settings of the LC29HEA were made with the Ini-Script to exclude errors. GPS settings were set to NMEA. I hope to have more time on Friday or Saturday to look into this.


I had no issues with Mission Planner RTCM3 passthrough (except at baud rates lower than 460800 - MAVLink is a pretty poor conduit for RTCM3, but it does work!).

By way of comparison, a raw RTCM3 stream should actually be passable at 9600 baud and virtually error free at 19200 or higher. But cramming it into MAVLink along with all the other telemetry and then reassembling it from segments takes a lot of valuable time.

Yuri, another dumb question. I have been playing with MP on my main i5 laptop, but would prefer to run it on its own laptop. I have an older i3 with Windows 10. Would this work? Are there any limitations in these laptops on highest baud rate for the USB? Is there a way to verify that 460800 would work on my laptop? Or is the 460800 between the H743 and LC29HEA? I ordered the other ebay LC29HEA and a helical antenna and hopefully can make it work.

Serial comms work on anything north of a potato.

For Sale on Ebay:

Ublox NEO-F9P RTK High Precision Centimeter Level RTK Module GPS L1 & L5 Bands | eBay


That’s over double the price of the module in question and basically the same price as Sparkfun’s and ArduSimple’s hardware (with better quality workmanship and better performing Zed-F9P modules). The quality is questionable at best - probably assembled in a toaster oven - look at the crooked SMD placement. Not really on topic and, in my opinion, not even worth considering.

1 Like

I’ve got 2 LC29HEA boards on the way from SuperBuy in China for $37 USD delivered each!!

Great. Keep us posted on how they perform, please…

Hi Rolf,

I am just curious, in the Ardu world UBLOX GPS setups, is the nTrip data sent to the GPS’s on the same serial port that they output the RTK corrected GPS fixes on?


Yes, of course, the GPS is connected to the flight controller via just one serial interface.


Thanks, I was just questioning since the pic Denis sent of another alternate GPS unit shows separate ‘pinned’ uarts to handle them separately which I believe that current LC29HEA’s boards can not do…

I had time to try the LC29HEA again today. Unfortunately, unlike Yury, my LC29HEA will not switch to float or fix mode, even though the NTRIP data is displayed by the mission planner.

To rule out a trivial parameter error in Arduplane, I connected a U-Blox F9P to the same flight controller and the same serial output as a cross-check.

( By the way: I noticed that MP could only establish a connection to the NTRIP server after EGNOS correction data had been received on the F9P. With an older version of MP, a normal 3D fix was sufficient. A bit mystical, but I didn’t want to look into it today)

After a while, it was possible to get an RTKFIX by the F9P on the windowsill. On instinct, I connected the LC29HEA as a second GPS. And now, after a while, the MP even showed an RTKFIX for the LC29HEA (which was not possible when I had connected it as the only GPS).

Here is a photo of the wild experimental setup at the kitchen window, ice crusher and asperagus cooker aren’t absolutely necessary :smile:

I logged and compared the data for a while: I disconnected the NTRIP data source at 16:57:00 to see the behavior afterwards.

For some time, both GPS had an RTKFIX. I am not surprised that this does not happen at the same time, as as far as I know the F9P is aligned to L1/L2 and the LC29HEA to L1/L5. In addition, the location is so unfavorable that half of the firmament is covered by the house. I should certainly do this outside with a clear view.

Here are the differences in the lateral and height determinations:

Unfortunately, unlike the F9P, the LC29HEA does not provide climb rates in the current settings (the GPS climb rates are more accurate than those of a barometer).

Now for the timing. F9P:



Pretty sure the only thing you’ve potentially proved there is that the F9P has a little better sensitivity than the Quectel module. Testing indoors is almost never worthwhile other than MAYBE to confirm the wiring is correct.

1 Like

That’s right, that’s why I did it. But I still have to find out why I can’t get the LC29HEA ALONE to RTK float or FIX.


Because it’s inside…

That is certainly not the case, because I had just RTKFIX inside today when the F9P was also connected. I have at least FLOAT inside when the GPS is connected to the QGNSS.exe and had it outside a few days ago with good visibility with the same result: No RTKFIX or FLOAT outside via MissionPlanner, via QGNSS in a few seconds.

But you are creating a correlation vs causation error by testing with poor reception. I don’t think you can conclusively say anything about RTK status whether connected as the sole module or in tandem with another.

I just installed the Quectel module on my bigger Copter and achieved RTK Float within a few seconds of connecting NTRIP data via Mission Planner. And it’s now RTK Fixed, while the Here3+ remains at RTK Float.

I think we’re talking past each other. When it’s not raining here, I’ll report from outside :wink:

Fair enough. Short test flight shows the LC29HEA outperforming the Here3+ (lower HDOP and longer periods of RTK Fixed operation) with no discernible phase lag as shown in the logs shared several weeks ago.

Use the config I provided, pass RTCM3 over MAVLink, and be sure the LC29HEA is operating at 460800.

This is a Cube Orange and Copter 4.5.3.

1 Like

Log file from a brief flight where the LC29HEA was the only GPS source. Still working through a minor amount of fine tuning on this Copter, but I think this is proof positive there’s nothing stopping us from using the LC29HEA as an RTK GPS for ArduPilot. 5Hz updates are reliable enough, and typical RTCM3 streaming over MAVLink works reliably with the settings I provided.

I expect performance will fall somewhere between the uBLox Neo-M8P and Zed-F9P series. I don’t have time to perform that analysis this week. It appears that this module can be used for fixed base and moving baseline operation as well, but I’ll leave that for another day (or another user).

I had no significant delay in obtaining RTK Float or RTK Fixed status once NTRIP data was available over the telemetry link (915MHz SiK telemetry at 115200 - this is the primary bottleneck for RTCM3, BTW). I noticed no correlation between fix states when another module was connected to the autopilot. They each behaved normally, and as expected.