In a recent post, I compared an L1/L2 u-blox F9P receiver paired with a u-blox ANN-MB antenna against a Quectel L1/L5 LC29HEA receiver paired with a very low cost L1/L5 antenna from Waveshare ($17 + shipping). I did this to get the combined cost of receiver and antenna down to an absolute minimum. The performance of this combination was reasonably good in challenging conditions but noticeably lower quality than simultaneous results from the u-blox receiver and antenna. At the time, I did not explore how much of this reduced performance was due to the lower cost receiver and how much was due to the lower cost antenna.
After publishing the post I was contacted by a representative from Quectel. He mentioned that they have done comparison testing between the LC29HEA and the u-blox F9P and have found the results to be more similar than my results if antennas of equal quality are used in the testing. He specifically recommended the Quectel YB0017AA L1/L5 antenna as being very similar to the u-blox ANN-MB antenna in size and performance. This antenna is available on AliExpress for $22 + shipping so is only marginally more expensive than the Waveshare antenna that I used. It’s also available from Digikey for a little higher price but faster shipping. I ordered the antenna from Digikey and after it arrived, repeated the previous comparison to the u-blox hardware using the new antenna.
Here’s a photo of the three antennas, the Waveshare L1/L5 on the left, the Quectel L1/L5 in the middle, and the u-blox ANN-MB on the right. As you can see, the Quectel antenna is more similar in size and shape to the u-blox antenna.
Waveshare, Quectel, u-blox antennas
To start, I did some signal strength (C/No) comparisons between the Quectel and Waveshare antennas using the C/N0 values reported by the receivers. I expected the larger Quectel antenna to show higher C/N0 measurements but I was unable to detect a consistently measurable difference between the two.
However, when I repeated the simultaneous RTK measurement collection with the u-blox hardware and the Quectel hardware in a moderately challenging environment in my backyard with a mixture of tree cover and obstruction from the house, the Quectel results this time were noticeably closer in performance to the u-blox baseline. More detailed testing would likely bring up differences between the two, but with my single, somewhat unrigorous test, the results were close enough that I was not able to discern that one performed better than the other.
Here are the results from the Quectel receiver and antenna :
Fix rates were very similar between the two solutions at 84% for the u-blox and 88% for the Quectel. I would not consider this difference significant, especially since I suspect based on the previous comparison that the Quectel is a little more prone to false fixes.
Below is a plot of the distance between the two solutions when both were fixed. The two antennas were 34 cm apart, so the distance of each point from a circle of radius 34 cm indicates the combined error from both solutions. The number and magnitude of the errors are noticeably smaller than in a similar comparison for the previous experiment.
The large deviations in the vertical axis between the two solutions we saw in the previous comparison (shown on the left below) are not present in this comparison (shown on the right), again indicating fewer and smaller errors.
RTK solutions plotted in time (left=previous comparison, right=new comparison)
Overall, I consider both solutions quite qood considering the challenging conditions.
By the time you add the extra shipping for ordering the antenna separately from the receiver, the combined cost for receiver and antenna increases from $63 for the previous configuration to $81 for the new configuration, but given the improvement in performance, I suspect this is well worth it and is still significantly less expensive than the u-blox alternative.
Note that this and the previous comparison were made using the real-time internal RTK solutions from the receivers at a 5 Hz sample rate. For those more interested in PPK (post-processing) solutions using RTKLIB, this receiver may not be a good choice. So far, I have not been able to configure the receiver to output raw RTCM3 observations at greater than 1 Hz. 1 Hz is fine for static solutions but too slow in most cases for kinematic solutions.
Overall though, for anyone primarily interested in real-time RTK solutions for static or moving rovers, or post-processed solutions for static rovers, I would definitely suggest considering the Quectel LC29HEA module as a potential lower cost alternative to the u-blox F9P.
If you have worked with the LC29H and would like to share your thoughts and experiences, please leave a comment below.
This is a follow up to my previous post in which I describe my first experience with the Quectel LC29H receiver. In this post I will go over the details on how I configured the rover and base receivers for a real-time RTK solution. These instructions are specifically for the LC29HEA receiver boards I bought on AliExpress, but, except for the references to the UART/USB slide switches, should work on any receiver board with an LC29HEA module.
The commands to configure the receiver are all described in the LC29H Protocol Specification, although it is not completely up to date with the latest firmware. Specifically, I had to read the latest firmware notes to find that 2 Hz and 5 Hz are now options for the position output rate. The commands all consist of strings of ASCII characters, but require a checksum at the end of the command. The easiest way to send and receive these commands is by using the command console window in the Windows QGNSS app from Quectel since it will generate the checksums for you with the click of a button.
To get started, download the app, open it up, connect the receiver to your computer with a USB cable, and connect an antenna to the receiver with the SMA connector. Check that the two slide switches on the receiver board are both set down towards the “USB” label.
Then use the “Set Device Information” option in the Device tab (or the “gear” icon in the toolbar) to find and configure the receiver communication settings. Set the Model to “LC29HEA” and the baudrate to 460800 as shown below.
QGNSS device configuration window
Once this is done, open up a “Text Data” window from the “View” menu and you should see a string of NMEA text messages scrolling through the window assuming your receiver is in its default configuration. It should look something like this:
NMEA messages in QGNSS text window
Next, open up a “Command console” window from the “Tools” menu which we will use to send configuration commands to the receiver.
Rover Configuration:
The next step is to enter the commands into the command console. We will first set up the rover. I’ve listed the command I used to do this below so that they can be cut and pasted into the QGNSS console. Note that the comments are for information only and should not be copied. I’ve also included the checksum for each command which can be copied or generated by using the “Checksum” button. Be aware that some commands don’t take effect until the parameters are saved to flash or the module is rebooted.
$PQTMRESTOREPAR*13 # restore PQTM params to default and reset $PQTMCFGRCVRMODE,W,1*2A # set receiver to rover mode $PQTMSAVEPAR*5A # save PQTM params to flash # manually power cycle module $PAIR062,2,0*3C # turn off GSA messages $PAIR062,3,0*3D # turn off GSV messages $PAIR062,5,0*3B # turn off VTG messages $PQTMCFGNMEADP,W,3,6,3,2,3,2*37 # set decimal precision for NMEA $PAIR050,200*21 # set pos output interval to 200 ms $PQTMSAVEPAR*5A # save PQTM params to flash # manually power cycle module
QGNSS Command Console Window ( commands to configure rover)
Once you’ve entered all the commands into the console, you can run them by consecutively pressing the “Send” button for each command. If you have made any modifications to any of the commands you will need to press the “Checksum” button first to recalculate all of the checksums.
These instructions assume the firmware on the module is no older than LC29HEANR11A03S_RSA which has an associated date of 10/31/23. You can use the command at the end of the screenshot above to check the version of firmware on your module. If your firmware is older than this, then I believe the only change you will need to make to these instructions is that the 5 Hz option is not supported and you will need to set the PAIR050 option to 100 instead of 200 which will set the output rate to 10 Hz instead of 5 Hz.
Base Configuration:
If you are going to use a second LC29H for a local base receiver, you will need to go through a similar process to configure that module. These are the commands I used:
$PQTMRESTOREPAR*13 # restore PQTM params to default and reset $PQTMCFGRCVRMODE,W,2*29 # set receiver to base mode $PQTMSAVEPAR*5A # save PQTM params to flash # manually power cycle module $PAIR432,1*22 # output RTCM3 MSM7 messages $PAIR434,1*24 # output RTCM3 antenna position (1005) $PAIR062,0,01*0F # Enable NMEA GGA message $PQTMCFGSVIN,W,2,0,0,x,y,z*3B # set base location in XYZ coords $PQTMSAVEPAR*5A # save PQTM params to flash # manually power cycle module
Note that for the PQTMCFGSVIN command, you will need to use the XYZ coordinates of your base station and update the checksum before sending. Alternatively, the LC29H supports a survey-in capability to automatically generate an approximate base position.
Once you have sent this sequence of commands to the receiver, open up a “Binary data” window from the “View” menu and you should see the RTCM3 MSM observation messages and the 1005 base location message.
RTCM3 messages in QGNSS Binary data window
One minor issue I found is that the PAIR432 command to enable RTCM3 MSM7 messages does not seem to get saved to flash properly, so after cycling power, the module will switch to outputting MSM4 messages rather than MSM7. These contain slightly less information than the MSM7 messages but in most cases this should have negligible to no effect on the RTK solution. The MSM4 messages also require less bandwidth.
RTK Solution:
Once you are getting the correct outputs from both receivers, or a single receiver and external base correction stream, it is time to link them together to get an RTK solution. If you are using an LC29H as a local base station, you will want to connect it to an NTRIP caster to broadcast the correction stream. I describe one way of doing this with RTK2GO in this post. Once this is up and running, or you have access to NTRIP corrections from an external L1/L5 base station, the next step is to feed the base corrections to the rover using an NTRIP client. In my experiment I used an RTKLIB STRSVR stream server to do this, but for just checking out the receiver, it is simpler to use the NTRIP client tool built into QGNSS. Open this window from the “Tools” menu in QGNSS and configure it with your NTRIP address, username, password, port, and mountpoint. Once it is configured, set the “Connect to Host” button to on. If you are in an open sky view and have a ground plane under your antenna, you should see the “Quality indicator” field in the QGNSS output window switch to “Float RTK” and then to “Fixed RTK” as seen in the screenshot below. In this case, you can see from the RTK Float count field that it took 41 samples to converge from float to fix. Since the output rate is set to 5 Hz, this is about 8 seconds. The time to fix will vary depending on sky view, atmospheric conditions, and antenna quality.
So, that’s it, you should be up and running now and ready to collect some position data with centimeter-level accuracy. If you find any issues with these instructions or improvements to them, please leave a comment below.
The u-blox F9P dual-frequency RTK receiver has been my go-to choice for high precision RTK or PPK solutions ever since it first came out in 2018. Available initially on a receiver board with antenna for under $300, it offered a performance and price point far better than anything that preceded it. However, that was six years ago and although the price for the F9P receiver and antenna has come down a little to around $250 since then and they now offer a few more variations, it feels like u-blox hasn’t introduced anything dramatically new in a fairly long time.
Meanwhile, there have been a number of lower cost dual-frequency receivers introduced recently from other companies which look quite promising. I hope to take a look at a few of these eventually, but have decided to start with the LC29H from Quectel.
The F9P is an L1/L2 receiver, while the LC29H, like most of the newer receivers is an L1/L5 receiver. The L5 signals have some advantages over the L2 signals, but (like the L2C signals used by the F9P and other low-cost L1/L2 receivers) are not yet available on all satellites.
The LC29H module comes in several variants. The newest ones most generally available on receiver boards are the DA, BS, and EA variants. The specs for these are shown below. The EA variant is the one most recently available and is the only one that will output raw observations or RTK solution points at greater than 1 Hz. A 1 Hz sample rate is fine for static applications, but for dynamic rovers a higher sample rate is usually necessary. For this reason, I will focus on the LC29HEA.
Quectel LC29H specs for DA, EA, and BS variants
Probably because it’s relatively new, it is a little more difficult to find receiver boards built with the EA module. I ended up ordering two receivers from this link on AliExpress. If the link no longer works by the time you read this post, you can probably find something similar using their search option. The price for this one was $57.69 for the receiver and antenna plus $4.79 shipping to the U.S. In my case, the boards arrived in less than two weeks with no issues. I ordered the boards without the antennas since I missed the combined option when I made the order. For my initial evaluation I used what I’m guessing is a similar low-cost L1/L5 antenna from Waveshare for $17. Waveshare also sells LC29H receivers but at the current time, only with the AA, BS, and DA variants.
Quectel LC29HEA receiver with L1/L5 antenna from AliExpress
To start with, I chose to compare a real-time internal RTK solution using a pair of F9P receivers for base and rover to a real-time internal RTK solution using a pair of LC29HEA receivers. If I was trying to compare the two receivers directly, I would use the same antenna for both rovers. However, for this experiment, I wanted to compare a lower cost solution that included both a lower cost receiver and a lower cost antenna. This means that the results can not be used to draw any conclusions regarding differences between the receivers directly, only differences between the combinations of receiver and antenna. I hope to do another comparison later using a single antenna to more directly compare the receivers.
I connected the two base receivers through an antenna splitter to a Harxon geodetic GPS-500 antenna on my roof. Although this antenna is advertised as L1/L2 only, I have found it gives signal strengths in the L5 band equivalent to L1/L2 so felt it was fair to use in this comparison. I connected the F9P rover to a u-blox ANN-MB L1/L2 antenna and the LC29H rover to the low-cost L1/L5 antenna from Waveshare.
I have done most of my previous comparison tests with antennas on top of vehicles. For this test I chose something a little more challenging, and walked around my backyard, sometimes in the relative open, sometimes close to large trees, and sometimes close to the house, but never underneath dense tree foilage.
I configured the base receivers to output RTCM3 MSM7 observation messages at 1 Hz and broadcast them to the internet using the RTKLIB STRSVR stream server app and a couple of RTK2go NTRIP servers similar to what I describe in this post.
The LC29H can only be configured to output RTK positions at 1 Hz or 10 Hz, so I chose 10 Hz for the LC29H rover. [Note 5/1/24: the release notes for the latest firmware indicate that options for 2 Hz and 5 Hz have just been added] According to the datasheet, the F9P has a maximum RTK position output of 7 Hz when running with all four GNSS constellations but for this experiment I left it at 5 Hz which I find an adequate sample rate for most applications.
Using a laptop running four instances of STRSVR, I configured two of these to stream the NTRIP corrections coming from the two base receivers to go to the two rover receivers over USB cables. I used the other two to stream the real-time output of the two rovers to a couple of files. I describe a similar setup for just the F9P in this post. I used the u-blox u-center app to configure the F9P, and the Quectel QGNSS app to configure the LC29H. The LC29H configuration commands are somewhat cryptic and need to be typed into a command console in the Quectel app, so this was not as easy as configuring the F9P, but the details for doing this are reasonably well documented in the Quectel LC29H Protocol Spec.
I will share the details of exactly how I configured the LC29H base and rover modules in a separate post. The biggest issue I found here was that when running at 10 Hz, not all features can be enabled at the same time and the way the module handles this can sometimes be confusing. For example, you can not output RTCM observation messages and 10 Hz RTK real-time positions at the same time. This setup is not necessary for this experiment but can be useful if you want real-time position information but also want to postprocess the raw observations later with RTKLIB. Also, some commands would take effect immediately and others only after config parameters were saved to flash, or when the module was reset.
After all four receivers were configured, I walked around the backyard with the laptop connected to the two rovers, and the two rover antennas mounted together about 30 cm apart. When close to the house or the trees I was careful to keep the spacing between both antennas and the obstruction similar to each other.
RTKPLOT will plot two real-time NMEA position streams, so I also had an instance of this running on my laptop to plot the two solutions real-time. The screenshot below is from my laptop while I was running the experiment, showing the four stream server windows and the RTKPLOT window. The yellow/green plot lines are float/fix status for the F9P and the olive/blue plot lines are float/fix status for the LC29H. I took this screenshot before I started walking around. The antennas were static and I was periodically covering both antennas to force loss-of-lock and reconvergence of the two solutions. Both receivers recovered a fix status in a reasonable time but the F9P was generally two to three times faster.
Screenshot of my laptop while collecting data
The screenshot below shows the real-time RTK position output for the F9P collected while walking around. As you can see, most of the solution is fixed, but close to the house and close to the tree line on the right where the trees are tallest and thickest, there is more float solution. The points closest to the house are actually under the eaves of the roof. The float points in the lower middle of the image are from when I was covering and uncovering the antenna as I described above. I generated this image using the POS2KML app in RTKLIB to generate a KML file and then displayed it with Google Earth.
F9P->F9P real-time RTK solution
Here is the same image for the LC29H real-time RTK solution. Again, most of the open-sky area is fixed but a higher percent of the more challenging regions are float.
LC29H->LC29H real-time RTK solution
I don’t have a ground truth for this data so I can’t directly compare the accuracy of the two solutions. What I can do is plot the difference between the two solutions to get a general idea of the solution errors. Since the antennas are a fixed distance apart, the difference between the two solutions should be a circle with radius equal to the antenna separation distance, assuming the antennas were kept fairly close to level while the data was taken. Here’s the result of plotting the solution difference with RTKPLOT
A large percentage of the points are on the circle, in this case with radius 34 cm, but there are also a fair number of points not on the circle. Given the challenging nature of this experiment, this is somewhat expected. Float points (yellow) off of the circle are less concerning since we know the accuracy is lower for them. Fix points (green) off the circle however are more concerning and generally indicate false fixes. Plotting both solutions versus time and comparing the vertical components can help tell us where the false fixes are and which solution they occurred in. This is because the trajectory covers the same ground multiple times so we know what the valid range of altitude is. The region below circled in red indicates both solutions are fixed but differ by well over the expected accuracy of a fixed solution. Since the blue (LC29H) solution is outside the range of altitudes from the rest of the data we can determine that this is the incorrect solution in this case.
F9P solution (green/yellow) and LC29H solution (olive/blue)
Based on the results of this single experiment, it appears that the Quectel LC29H with a very low cost antenna performed reasonably well in challenging conditions and deserves further investigation. It did not perform as well as the u-blox F9P with a more expensive antenna in these conditions, however given that it cost roughly one quarter as much, I think it did quite well. In less challenging conditions such as onboard a drone where sky views are generally less obstructed, I would expect the differences to be smaller.
Performance and cost are important, but of course they are not the only factors to consider when selecting a receiver. I did find that overall the documentation is more complete for the F9P, it is both easier to configure and more configurable than the LC29H, and there are some features such as event logging that are available on the F9P but not the LC29H.
One last thing to consider is that the overall performance results are a combination of, among other things, the antenna, the front end of the receiver and the internal RTK solution. I hope to do further experiments using a common L1/L2/L5 antenna and post-processing with RTKLIB to measure the differences in each of these components separately.
Well, I think that is enough for now. I hope to follow up with some more posts as I gain a little more experience with this receiver and eventually take a look at some other very low cost L1/L5 receivers as well.
If you have worked with the LC29H and would like to share your thoughts and experiences, please leave a comment below.
rtklibexplorer