Realtime DGPS with ublox and GPSTk lib processing, relative <1m?

I've read through a few discussions on this forum about poor man's DGPS and getting relative accuracy down to the ~1m range.  It seems no one's having much luck even with identical GPS units.  I'm wondering if anyone has manged this and what are your thoughts on what I'm currently building.


I'm laying out a PCB for a ublox LEA-6T (that's the one that outputs raw data and carrier phase) to interface to a MCU and a 433MHz radio.  That's the mobile unit.  My base station is then a single board computer with it's own LEA-6T, radio, and software running GPSTk post-processing software.  The mobile board will then radio the raw data (subframes 1 and 2 and psuedo range and carrier info) to my base station.  Base station code then chooses a set of sattellites that work well for both units and calculates position of both units using the same satallites and same ephemeris data.  (calculated position could then be radioed back to mobile unit)


The units are genearlly pretty close to each other (spatially) so the only error here should be that inherent to the ublox measuring psuedorange--no constellation, algorithm, iono/troposphere, ephemeris differences.


Has anybody tried this?  Do you think I can get a relative accuracy of ~1m?



Thanks for any thoughts guys and gals!


Views: 33614

Reply to This

Replies to This Discussion

Hi Anthony,
Iam looking for a solution for my Octocoptor for arial photography and film precise position and lock....I have a flight controller ARM processor also I can add additional processor like Gumstix....ready to buy a good antenna like navXperince 3G+ C...request to provide me a solution and cost...


I am also very interested in this subject but i am lacking the mathematic and programming abilities to pull something off like you did.

I think it might be possible to reduce the error if you swap some steps.

My postulate: acc/x/y/z are read more frequently than gps coordinates so doing mathematics with even small errors can sum up more quickly on acc values. Perhaps it could reduce the error by doing it the other way around:

1.Sum up the acc in bodyframe to get the velocity in bodyframe with growing error.

2.Get gps coordinates and calculate the real velocity in earth frame.

3.Transform gps earth frame vel to bodyframe acc vel and correct the ongoing acc(bodyframe) summation. After this take the corrected acc values back to earthframe and do the navigation.

Cheers Kraut Rob

are there still people following this thread?

i am setting up my RTK system using 2 ublox receivers and 2 ublox active patch antenna and RTKLIB,,, sometimes i get FIX solution for short period of time but mostly FLOAT SOLUTION. Also, when i get a new FIX the position changes there is no precise point in every FIX.

can you help me sort things out.

thank you very much

PS. here are my config files for ucenter and rtklib


If you just want to try one thing I'd change the Integer Ambiguity Res parameter (RTKNavi options - Setting2) to Continuous instead of Fix and Hold.  This will be more forgiving of a bad fix.

What I'd really do is take a step back though.  The Ublox receivers need a very good receiving environment to supply "fixed-integer" quality phase data.  I would test in an ideal environment first, get that working, and then try under less than perfect conditions to see if things will work for your particular application.

A very good receiving environment means an open field with no obstructions down to ~10 degrees above the horizon.  No buildings or large signs near by - especially metal.

Assuming you can run RTKLIB on a portable computer and have a car I would place the two antennas on the car roof, orientated in the same way, and measure the distance between them.  Say you get 81.5 cm.  Drive out to an excellent receiving area like a road between farm fields and do some testing there.  Set RTKNAVI up in Moving-Base mode and let it run.  You can, of course, be parked.  When the integers are correctly fixed the baseline will be 81.5 cm +/- 1 cm or better.  You'll also get a highly accurate heading and a pitch value that's pretty good.

Do this multiple times.  It's all just for getting used to what the hardware/software will do under ideal conditions.  Are the correct integers determined reliably?  Do they stay correctly fixed?  You can try changing some parameters.  You can even drive around (be careful) and see if the integers remain fixed.

There are many parameters which can be changed.  For testing in an ideal environment I would drop the elevation mask to 10 degrees or so.  The more satellites the better.  I haven't parsed through the RTKLIB code, but there are methods to essentially instantaneously fix the integers for L1 only data when 9+ satellites are available.  When fewer are available a fixed integer solution could take several minutes even under near ideal conditions.  One last parameter I'd change for testing purposes is to go with a 1 hertz update rate.  The receivers can output raw data at a faster rate, but the quality may suffer a bit.

I didn't check all your settings so I'm not sure if any others should be changed, but hopefully the above makes sense.  I mostly use RTKLIB in post processing mode, but have tested RTKNAVI multiple times as stated above with generally good results.

John has some good suggestions there... Doing post-processing rather than realtime give the advantage that the data can be computed in the reverse direction, and thus may be able to extend a fix 'back' for sections of 'poor' data.

I'd also suggest that you 'time tag' the data when you are collecting it. This enables you to replay data as if collecting it again, so you can tweak settings and see where/if they make a difference.

The antenna quality is going to have the biggest affect on the data. You might get better performance extending the ground plane around each. Don't know if decent antennas are easy to get in the Philippines.

If you are OK with posting raw data somewhere (dropbox or the like) I can see if I can run it through RTK-Lib and commercial applications to plot the difference.

Good luck, Simon.

yes John has a good point.

In my location i can get 8-11 satellites in view in average. will that be sufficient?

And Simon, about the ground plane is there a formula that i can use to be able to calculate for the ground plane size, or the bigger the better?

this is the same antenna i am using.

Im already uploading a raw file, just waiting to finish and ill give you the link later.


Here is the Link for my raw observation, UBX format.

still, i cannot get a solid FIX solution. :(

Hi all,
Here is a file explain what I have down and the problem I have meet.Can
you give me some advice? Thank you very much!

Hi, I can suggest you to try DGPS using differential code correction. You can use your own base or grab NTRIP stream from a local GNSS reference. Then, you wireless send RTCM 2.3 correction to any new generation u-blox/NVS receiver.

We did it. We send RTCM 2.3 correction to a GNSS inside football players shinguard. Accuracy is submetric.


That's awesome accuracy. Where is your antenna? in the shinguard? ceramic patch?

Hi Noland. Yes, we use a tuned ceramic patch inside the shinguard and we wireless send real time corrections. Code corrections are very stable also in dynamic. Accuracy decreases with the distance from the reference (better <10km, best <1km).

Reply to Discussion


© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service