Back in 2014 I wrote a post on RTK-GPS using Navspark NS-RAW boards. Back then I promised to write a follow-up once I have done some testing. I didn’t quite think it would take so long but the reason behind the delay is that I never quite got it working as well as I expected and tried various things over the years which took time, and I lost interest couple of times in between.

A couple of people have asked me how it worked, so finally I decided that enough is enough and I’ll just describe how far I got.

TLDR version: NS-RAW in seems to perform significantly worse than the u-blox of the same era. Even if it had performed at a similar level, single frequency GNSS in general just seems to be unsuitable for reliable ground based robot navigation. It might work at some times of the day where the satellite visibility and geometry happens to be just right and you are testing in a large open field, have good antennas etc. but for most realistic cases it will not be reliably usable.

Setup

Navspark has this to say about the required conditions to be met for a stable RTK FIX:

NS-HP or NS-HP-GL are single frequency RTK receivers. For reliable consistent single-frequency RTK operation, they require 12 or more usable satellite signals above 15 degree elevation angle with SNR no less than 38dB/Hz.

NS-RAW is single-constellation so I’m limited to only GPS. Looking at the GNSS radar tells me 5-9 GPS satellites would be visible from my location at different times of the day (with 15 degree elevation). So 12 satellites would be impossible here. Other sources say that you need 7 satellites min. to get a RTK FIX solution (and min. 5 to hold it). That would have been a bit more realistic requirement, and besides, an earlier u-blox LEA-6T test got a FIX solution just fine so I decided to go on with the test.

Here’s what my test ground looks like:

The plot has 20m high forest in the N & NE directions. Other sides have better visibility but all the sides have at least one row of 20-30m trees + some sporadic buildings and trees all over the place.

BS1 is the original base station that was described in the previous post on the topic. It uses Satmar FME marine active GPS antenna. I have added a 15cm wide ground plane below it (a paint can lid). The location of BS1 is somewhat unfortunate since it is basically surrounded by some trees from all the sides. When I originally chose the location for the base station I didn’t have good access to the roof of the main building so I chose a spot that was furthest away from the house, so that it wouldn’t block satellites from that side. Here’s the picture of the location:

BS2 is the new base station at the top of the roof. It’s about 8m higher than BS1 and hence has better satellite visibility. Tri-Band GPS/Galileo, Beidou, GLONASS Active Antenna is used. It looks like this:

“Rover” is me walking around with a laptop and NS-RAW with an antenna setup identical to BS1.
Everything is connected over WIFI.

Best case – localization between two base stations

Using BS2 as base station and BS1 as rover in the Kinetic mode should give us a good idea of what is the best that can be achieved with this hardware on my plot. Even though BS2 doesn’t have good sky visibility it’s better than a real rover will ever have since it’s located on a pole that is a couple of meters higher than the rover will ever be, and has less sky blocked by the house than a rover normally would.

I finally got RTK working rather well in this scenario and it has FIX most of the time. The location stays in a ~5 cm^2 area for the 8h session:

I was cheating a bit though – for localizing static points I use Integer Ambiquity Res mode FIX and hold. This mode takes past measurements more into account when calculating the current location than Instantaneous or Continuous would, which makes position mode stable but would also make it return the wrong position for longer if the rover was actually moving. I also used demo5 ver. of RTKLIB by rtklibexplorer which got more FIX solutions than the mainline RTKLIB.

Driveway test

Next I walked up and down the driveway as a rover a couple of times to see if I can get comparable results to my u-blox test at the same location in 2013.

The results were not bad but worse than the earlier u-blox LEA-6T test:

There were lots of slips, large residuals and ambiguity validation failures in the RTKLIB logs. Most of these errors are said to be commonly caused by not having clear enough view of the sky and the consequent multipath errors.
This seem likely since the rover certainly didn’t have a great view of the sky from 2 sides and things seemed to get worse with stronger winds (when trees had leaves and these were moving a lot).

With that said, the driveway basically has the best visibility in my yard that a real rover could ever have, so this is the most optimistic-realistic scenario. Even though the common satellite count is really low and we seem to be in FLOAT mode half of the time, the points are reasonably close (~20-30cm) and it would be usable for real navigation if this precision were repeatable 24/7 all year round. This test was done in January so no leaves on the trees which probably reduced errors a bit and made it even more of a best-case scenario.

Rover circle

Now for a more realistic test – walking in a circle with 20m diameter in the middle of the yard in mid-summer when trees have leaves.

This looks rather bad, only 2.1% of the points have FIX solution. The FLOAT solution was reasonably precise for 3 circles and then suddenly wandered through the circle. We see that most of these points have a lower confidence than FLOAT points on the actual circle so we could filter those out on that basis, but we also see a single FIX solution point in that path which is a couple of meters away from the actual location.
This test was done with integer ambiquity res. set to continuous.

 

What next?

I have put the navigation project on hold for now. I expect L5 capable chips to be much more common in the next 2 years which along with new Galileo satellite launches should considerably improve the precision of navigation at my location (NE Europe). L5 should be much less prone to multipath problems that seemed one of the main things throwing my rover signal off. Broadcom 47755 is the first mass consumer L1/L5 chip and others will surely follow.

Finally here’s a list of relatively cheap alternatives to NS-RAW that are available right now and would be rather interesting to try in similar situation but not interesting enough for me to actually buy the test hardware:

• My original tests in 2013 seemed to get much better results with LEA-6T so u-blox LEA-8T that is available for ~75$ per module might give better results. You would also be able to try out various hacks and configuration tweaks described in the awesome rtklibexplorer blog.
• Navspark NS-HP series (NS-HP-GL, NS-HP-BD) might also give somewhat better results than NS-RAW since these have multi-constellation support. Having the ability to use Glonass satellites in addition to GPS would almost double the average number of visible satellites in my location. These chips also do RTK on board so you don’t have to have a separate computer for running RTKLIB which will save you both weight and power. They also claim significant improvements in environments like mine in the newer firmware versions.
• u-blox M8P based boards might also be interesting, these are multi constellation (GPS, BD, Glonass) L1 chips that do RTK calculations on board so you only have to provide a communication link. Such boards are for example Tiny RTK from Drotek (~215€) or the one from CSG (~239€).
• Drone operators seem to like Emlid Reach. Under the hood it’s a combo of u-blox M8T + Intel Edison for processing and RTKLIB with much friendlier frontends than bare RTKLIB has. It seems that some of their customers are happy with the results and others seem to almost never get a FIX solution.

After having read lots of forums of users trying to use these cheap single frequency RTK solutions, my conclusion so far is that it seems to require intimate knowledge of almost endless GNSS related stuff, a very good sky visibility, living in a place where satellite geometry is just right for large part of the time, good antennas and specific weather conditions. In short it doesn’t seem to be feasible for generic rover navigation that requires constant precision in the dm range in all corners of the yard.