Blogs

When the ublox 6 series modules were released, I noted that the 6T and 6P modules provided access to the raw carrier phase measurements, and I started thinking about how to use this capability.  My connections through my university research appointment weren't strong enough to get ublox to sample a dev kit to me (they generally don't sample them at all).  Jordi and Chris from 3DRobotics.com were kind enough to use their customer relationship with ublox to get a sample 6T module and provided it to me mounted on the standard DIYDrones ublox LEA-6 module.  So mine looks just like the one above, except it has a 6T module instead of a 6H.

My prime curiosity was how good the carrier phase measurements from this module were.  The datasheet indicates that carrier phase measurements are available, but gives no specs about their accuracy.  So I had no idea if they would be of value.  Well, with a module in hand, some measurements made, and post-processing completed, I can tell you that there is tremendous potential here, but a lot of work before this is something ready for everyday use.

OK, what is carrier phase and why do I care?

A carrier phase measurement is a measurement of the phase of the arriving carrier wave signal from the gps satellite.  Think of it this way - as the radio signal from the GPS satellite travels from the satellite to your receiver it completes some fractional number of cycles of oscillation.  That means that the distance from the satellite receiver to you is some fractional number of wavelengths - say 100 million and 1/2 wavelengths.  The carrier phase measurement gives you the fractional value of 1/2 wavelength, or 180 degrees of phase.  That in itself is almost useless.  Fortunately the gps module gives us something a little better than that.  What it reports is the phase change (or the number of wavelengths of distance change) between the satellite and the receiver from one measurement epoch to the next.  So what we really have is a measurement of the change in distance between the satellite and the receiver over a known period of time.  And so theoretically, given that we know something about the location and velocity of all the satellites we should be able to use this information to calculate the (3D) velocity of the receiver.  Just one more thought on this topic - we could do the same thing with pseudo-range or Doppler measurements, which the receiver also makes, but carrier phase measurements have the potential to be orders of magnitude more accurate.

Nice, but what about position?

Well, the technique that I will describe below has some applicability to making very accurate position measurements, but lets just say it is really hard and is the kind of thing that only happens (still a relatively small number of) military gps with very large price tags.  I'll say some more about this later.  For now, we will just be looking at making velocity measurements.

OK, but what will we do with a great velocity measurement?

Well, imagine how much better position hold could work in a copter if the autopilot knew its 3D velocity vector to an accuracy of 5 millimeters per second.  Yeah, time for a double-take.  I said millimeters per second.  My initial test yielded a velocity resolution of 1 millimeter per second and an accuracy of better than 5 millimeters per second at a 5 Hz update rate.

There are lots of other things we can do with a better velocity estimate, like better acceleration modelling in the AHRS system, etc.

Let's see the data.

OK.  I have run two tests so far.  The first turned out fantastic.  The second had some difficulties, but still shows immense promise.  Below is a plot of the velocity estimate error during the first test.  This represents a bit over 5 minutes of data with samples at 5 Hz.

OK - let me describe a few things in this plot.  First, note that there are 5 `spikes' where the error is above 0.1 m/s.  These are 5 samples where the receiver did not have carrier phase lock on at least 4 satellites, and you need 4 satellites to get a valid solution.  For individual samples like this you can generally re-use the last velocity estimate.  There are also around 10 samples where the error is on the order of 4 or 5 cm/s.  These are samples where the receiver only had 4 satellites with carrier phase lock.  The accuracy gets better when the receiver has more satellites with carrier phase lock.

You may be wondering what my "truth data" was.  Well, it was simply that the module was just sitting on the ground in my back yard, so the truth was 0 velocity in the Earth centered Earth fixed (ECEF, WGS84 for example) frame.  This is not at all cheating as the velocity relative to the ground is irrelevant - we are still making a velocity estimate based on measurements of the velocity between the satellites and the receiver, and the satellites are all moving at roughly 14,000 km/hour in various directions.  The relative velocities between the satellites and the receiver are on the order of thousands of kilometers per hour, and from this we are able to deduce motion on the millimeter per second scale.

Unfortunately maintaining carrier phase lock is not as easy as tracking a satellite.  On the second test in similar conditions I only got carrier phase lock on 4+ satellites about 75% of the time, leaving many periods of several seconds with no valid measurements available.  On the second test the reduced accuracy of the velocity measurement was more apparent with accuracy on the order of 0.1 m/s with 4 satellites and 0.02 m/s with 5 satellites.  Even so, 0.02 m/s is a very impressive number.

How did you do it?

I did all this with data recorded using ublox UCenter and post processing using MATLab.  There is no reason that C code cannot be developed to do this in real time, although it probably requires too much processing power to add to an 8 bit autpilot.  Fortunately 32 bit hobbyist autopilots are becoming reality.  My method was really a reflection on my lack of time for this sort of project at present.  So, here is what I did: