uBlox accuracy

[William Premerlani]

Team,

Up until recently, I have been using an EM406 GPS exclusively in my flights with the UDB and MatrixPilot.

Recently, I tested a uBlox, and was surprised at the results.

At the same flying field where I verified an EM406 has an accuracy of 1 meter for all 3 dimensions, including altitude, my uBlox is much worse than that, with an accuracy of about 10 meters for longitude and latitude, and an accuracy of 40 meters for altitude.

One of the tests that I run after every flight is to see what happens to reported altitude for a few minutes after landing. The EM406 is rock-solid, reporting the same altitude with a maximum variation of 1 meter, indefinitely.

The uBlox, on the other hand, showed a variation in altitude from 106 meters to 160 meters for a few minutes after a long flight, with 9 satellites in view, all the while it was sitting on the ground at 113 meters.

So, has anyone else done any comparisons between EM406 and uBlox?

I know that there were a few studies a few months ago that concluded the accuracy of the EM406 and uBlox depended on a lot of things, but that overall, they are comparable.

So, I am very disappointed in the uBlox, especially with all the hype it has gotten.

Any comments?

Best regards,

Bill

[ben levitt]

My main comment is that I'm excited that the UDB4 is now flyable! :)

But it sure does sound like the uBlox is working poorly. Bill, have
you ever tested the EM406 upside down and sideways? I know one of the
alleged benefits of the helical antenna on the uBlox is that it's
supposed to perform well in all orientations..

Maybe after your next flight with the 406, you could try holding the
plane in other orientations for a minute each? If the 406 works fine
upside down too, then I'm in favor of moving us back to that model as
our primary GPS.

Thanks for the test flights! I wish I could fly mine too.

Ben

[John McClelland]

Hi Bill

 

The uBlox accuracies sound more like the EM406 without differential GPS (WAAS which I think you have near the airport).  Is it possible the uBlox has this disabled?

 

John

[William Premerlani]

John,

When I run the uBlox directly from my computer, it shows that WAAS is enabled, so I don't think that is the problem.

Best regards,

Bill

[Skymonkey]

Another setting that has strong influence on position accuracy
especially including "dither" when stationary is the type of platform
setting you have your system set to. uBlox has 8 different application
types and states that

"Dynamic platforms designed for high acceleration systems (e.g.
airborne <2g) may result in a
greater standard deviation in the reported position."

Looking at the uBlox 5 protocol spec, the one labeled "Pedestrian"
might work well for you. Pedestrian isn't what you might expect to
apply to a UAV but their criteria for this is:

"Applications with low accelerations and low speed, as a pedestrian
would move. Assuming
low accelerations. MAX Altitude [m]: 9000, MAX Velocity [m/s]: 30, MAX
Vertical Velocity
[m/s]: 20"

On Jul 30, 1:15 pm, "John McClelland" <mcclelland.j...@gmail.com>
wrote:

[William Premerlani]

Hi Ben,

I have not tested the EM406 upside down and sideways, I will add that to my list of things to do, but I am not sure when I will get around to it. Lately I have gotten sidetracked with a lot of these sorts of things, which have diverted me from what I really want to do, which is to go flying. So, my plan for the rest of the summer is to put these sorts of things on the back burner, and go have some fun. If anyone else wants to do an in-depth comparison of the EM406 with the uBlox, I would be very grateful.

From what I know about radio, there is a tradeoff between the sensitivity and directionality of an antenna. You cannot design for both. You make sensitive antenna by tuning it to a specific direction. If you design it to work equally well in all directions, you must sacrifice sensitivity.

So, if you design an antenna to work in any orientation, it would have to sacrifice sensitivity, which would translate into degraded accuracy.

Any comments from the radio experts out there? I know that we have a couple of them in our group.

Best regards,

Bill

[William Premerlani]

Hi Skymonkey,

Good point about the platform setting.

It was my understanding that the team who programmed the MatrixPilot to uBlox interface did some testing in this area, and picked the "best" setting, but I am not sure what that was. It was also my understanding the MatrixPilot selects the settings during initialization, so that you do not need to manually set them, but I have not checked on that yet.

The latest versions of MatrixPilot have "dead-reckoning" as an option, which discounts the value of GPS transient response by using the accelerometers and gyros as the primary source of high frequency location signals.

In that case, there is a higher premium on accuracy. So, what we should be doing with the uBlox is picking the platform setting that gives us the best average accuracy.

Best regards,

Bill

[Netfoot]

On Fri, Jul 30, 2010 at 5:31 PM, William Premerlani <wprem...@gmail.com> wrote:

From what I know about radio, there is a tradeoff between the sensitivity and directionality of an antenna. You cannot design for both. You make sensitive antenna by tuning it to a specific direction. If you design it to work equally well in all directions, you must sacrifice sensitivity.

So, if you design an antenna to work in any orientation, it would have to sacrifice sensitivity, which would translate into degraded accuracy.

It is true, that higher antenna gain is achieved at the cost of a narrower 'beam' or 'lobe' of directionality.  But the shape of the 'lobe' is dependent upon antenna design.  While high gain designs can be used, the beam-width narrows to the point where the antenna must be made to track the bird.  The Quadrifilar Helix antenna (as per uBlox) is a popular choice for satellite work because it is directional, but with a wide beam-width or 'lobe'.  This gives a useful amount of gain while covering a large area of the sky without the need for aiming the antenna.  With GPS applications, you can't readily aim the antenna anyhow, since you are listening to more than one bird simultaneously, and can't aim at multiple places at once. 

The Quadrifilar Helix also delivers the benefits of circular polarization.

[William Premerlani]

On Fri, Jul 30, 2010 at 6:25 PM, Netfoot <net...@gmail.com> wrote:

The Quadrifilar Helix antenna (as per uBlox) is a popular choice for satellite work because it is directional, but with a wide beam-width or 'lobe'.  This gives a useful amount of gain while covering a large area of the sky without the need for aiming the antenna. 

Hi Netfoot,

Thanks for the info.

Based on what you said, it would seem to me that the Quadrifilar Helix would not work well pointed at the horizon, and would not work at all upside down. It sounds like it would have a broad maximum in its gain in the "up direction", dwindling to a low value at the horizon. In other words, it works best if you keep the antenna pointed straight up.

Do you happen to have a plot of gain versus direction, or give us a link to that information?

Best regards,

Bill

[Netfoot]

On Fri, Jul 30, 2010 at 7:24 PM, William Premerlani <wprem...@gmail.com> wrote:

Based on what you said, it would seem to me that the Quadrifilar Helix would not work well pointed at the horizon, and would not work at all upside down. It sounds like it would have a broad maximum in its gain in the "up direction", dwindling to a low value at the horizon. In other words, it works best if you keep the antenna pointed straight up.

That is essentially correct. Generally, the beam is very wide.

Obviously it varies between specific designs, but the QFH tends to have a very wide lobe, sometimes even to the point where it is wider than it is tall.  Hence, less gain straight up than at an angle to one side.  in such cases, the fact that the slant-range of satellites straight up is less than those nearer the horizon compensates for the fact that the straight up gain is sometimes lower.  

Do you happen to have a plot of gain versus direction, or give us a link to that information?

I've got a number of beautiful polar plots here, in paper texts, but this page has a couple of typical plots.

Oh, BTW, don't confuse the QFH for the Axial-Mode Helix (or just plain Helix) which is quite different.

[William Premerlani]

Hi Netfoot,

Thanks for the link to the polar plot for the QFH.

Do you have a link for a similar plot for the antenna used in the EM406?

Best regards,

Bill

[Netfoot]

On Sat, Jul 31, 2010 at 9:03 AM, William Premerlani <wprem...@gmail.com> wrote:

Do you have a link for a similar plot for the antenna used in the EM406?

Funnily enough, I have not been able to find any published plots for patch antennas, either in general, or for the EM406 in particular.  By contrast, here is the PDF datasheet for the Sarantel SL1206 antenna (uBlox-5).  Being the suspicious type, I assume the lack of published plots for patch antennas means the patterns are pretty poor!  If any other subscriber can provide directions to a plot for a patch antenna, I'd be very interested.

[Lew Payne]

From what I'm seeing, and from what's stated for the reference design,
it's apples and oranges. The QHA radiation pattern plotted at that
URL assumes a *dish* feed. At first, before I was fully awake, I was
going to simply comment here and say that according to the orientation
shown on the diagram, the QHA antenna seems to not work very well at
receiving signals emanating from *below* the antenna. But then I read
carefully, and realized the front-to-back ration is created due to it
being mounted in a *dish*. So... please don't deduce *anything* from
this polar plot as far as how the Sarantel antenna might radiate.

Lew Payne, KA6RBJ

On Jul 30, 7:39 pm, Netfoot <netf...@gmail.com> wrote:
> I've got a number of beautiful polar plots here, in paper texts, but this

> page <http://www.qsl.net/va3rr/qha/qha.html> has a couple of typical plots.

[Lew Payne]

I have some more info for you, as it turns out.

I'm using this UBX-G5010 (Ublox 5) based GPS (with QFH antenna) in
another design...

http://www.falcom.de/products/gps-modules/fsa03/

Specs for the Sarantel QFH antenna are as follows:

Antenna: quadrifiliar helix
frequency: 1575.42 MHz
gain: -3.5 dBic
efficiency: 23 % total spherical
efficiency: 45 % upper spherical
beamwidth: 120 degrees
VSWR < 2.0 : 1

The above specs leave a lot to be desired, as far as substituting for
a polar graph. Start with a sphere. Slice it in half, horizontally.
Fan out the upper half so that it's twice as big as the lower half.
Trim the fat off the points located at 90 degrees and 270 degrees, so
that the "fan out" mostly takes place in the 120 degrees of "top" that
lies between those two points. You now have your graph.

Gain is terrible (compared to anything directional), but better than
the losses associated with running a really long length of coax (I'd
suggest Andrews Heliax) to the actual satellite itself.

-Lew Payne

[murmur]

Bill, I don't know any hard evidence to cite to back up this comment,
It's just my personal impression after having watched the behavior of
several consumer GPS receivers: I think many of them artificially
"lock" the position outputs when it is detected that a ("doppler")
speed is below some threshold that's coded into the receiver software.
This seems like a smart thing to do until you realize that for the
mean position output to be accurate, position must be allowed to vary
according to the time-varying error sources that affect it, even if
the receiver isn't moving relative to the earth.

By locking the position output when some fading-memory average (i.e. a
low-pass filter) of doppler-based speed measurement falls below some
value, the receiver is essentially making the decision that even
though the position output is "wrong" to some degree, it's going to
stick with that position until speed comes up above the threshold
again. This decision gives the impression of solid "accuracy" in the
sense that the position doesn't move when the receiver *truly* isn't
moving, but in reality it just keeps the same errors in the position
output until the receiver moves again.

If this supposition is right, then it means that the apparent
differences between the EM406 and the uBlox when the receivers aren't
moving don't really indicate anything that matters for use of these
receivers in aircraft.

I'm not quite sure where to go to find out if my impressions are
correct. Obviously this gets into some internal GPS receiver
algorithms that manufacturers undoubtedly aren't all that anxious to
discuss, probably for both good reasons and not-so-good ones.

Dave

[William Premerlani]

Hi Lew,

Thank you very much for the information, especially your comments about the dish feed.

Glad to have you on board!

Best regards,

Bill

[William Premerlani]

Dave,

Thank you very much for the information.

I am heading out to the flying field to do some comparison testing of the uBlox and the EM406 by riding around on a bicycle.

Best regards,

Bill

[murmur]

I did a little more looking for evidence on this "locking" of the
position output when speed is below some threshold, and this kind of
thing is, in fact, implemented in both SiRF III and uBlox receiver
modules. SiRF calls it "static navigation" and it's a cessation of
updates to the position outputs when speed is below a configurable
threshold that defaults to 1.2 m/s (for three 1Hz passes). uBlox calls
it "static hold" and I haven't found what the default speed threshold
is. Here's the uBlox protocol specification for their v5 engines:

http://www.u-blox.com/images/downloads/Product_Docs/u-blox5_Protocol_Specifications%28GPS.G5-X-07036%29.pdf

Hopefully you'll find that when the receivers are moving, accuracy of
the uBlox comes up to a similar level to the EM-406.

Dave

[Lew Payne]

Dave - You are correct, most GPS firmware is designed to "average" the
multiple readings (each of which has its own error covariance) into
something coherent for the application at hand (typically, pedestrian
or vehicular navigation). In addition, most units feature a
"hysteresis/dynamics" reduction circuit which effectively "locks" the
"averaged" reading when at a stand-still. My quotes are intentional -
I'm substituting words for lengthy explanations, at the expense of
semantics.

I'd like to take this opportunity to point out a few things (pet-
peeves, per-se). There's a difference between a GPS chip (let's take
the MediaTek MT3329) and what is sold/distributed by the OEM (LeadTek
LR9023, in the case of the MT3329). The OEM generally has control of
the integration firmware, which makes the GPS chip useful for a
particular purpose. The integration firmware is what normally trips
up the DIY community... and people assume a particular chip is
unsuitable, when most of the time it's actually the integrated
firmware that's unsuitable (for a particular application).

In the case of the MT3329 (with which I have a great deal of
experience), there are two OEM's that turn the chip into a useful
board solution. In the case of the second OEM (not LeadTek), they can
actually enable/disable features of their firmware, and provide a
somewhat customized (from stock masks) solution at little, if any,
added cost. For example, the "custom to DIYdrones" firmware is
anything but custom to them. Any customer can ask for those "stock"
modifications (binary and endian). In addition, some have different
"averaging" algorithms and "lock/hold" methodologies, and given a
certain volume, you can pick-n-choose your customization. Such is the
case with the OpenPilot MT3329 board solution. I believe they've had
the "lock" algorithm removed, among other things.

Another thing to consider (pet-peeve) is the fact that GPS units have
latency, especially when used in something like a funjet going 100
knots. In order to compute a vector, the GPS has to necessarily
average several inputs. As with all averaging, this produces
latency. In addition, the unit has to continually average the
multiple readings it receives (each of which has its own margin of
error), in order to form a cohesive relative reading. This, too,
produces latency. So far, both examples show what I like to term as
"internal" latency. In addition, there's external latency... at 9600
baud, by the time the output string is parsed and processed by the
AHRS/IMU, the reading is quite stale (especially for a fast-moving
plane). That reading is used to correct the gyros and accelerometers
in some cases, adding further to ongoing inaccuracy (e.g., going from
a turn to a straight path). There are ways to correct for GPS
latency, and some if it requires that the "averaging" algorithm be
known, so that its delays can be modeled and accounted for under
varying navigation conditions (straight, curved, and at varying
speeds).

I have some papers in my technical blog, which go into this. The blog
isn't pretty... it's just there so that I can keep track of things,
and comment on what I'm reading so that I'll remember what I liked
about a particular paper. As I age, it's becoming increasingly
difficult to keep track of these things. You're welcome to peruse it,
if you want to find out more about latency and compensation
algorithms...

http://lewpayne.blogspot.com

Some commercial GPS units (designed for aviation) can output a point-
source solution (where do you think I am right now, ignoring vector
math) along with an estimate of latency (which is perfect - since you
no longer need to model the unit). Most little units, like the MT3329
and uBlox, don't do that. I would be happy with a point-source
solution alone, since latency could be modeled.

Lew Payne

[William Premerlani]

Hi Lew,

Thanks a bunch for the information, I really appreciate it. It all makes sense.

Regarding the GPS latency, there is a "dead reckoning" option available in MicroPilot. If you select it, the position of the plane is computed primarily from the accelerometers, with GPS serving merely as drift compensation. With dead-reckoning, the latency in reporting actual position is 0.025 seconds, and that is how often waypoints are computed.

Regarding the FunJet, Rick Kuebler has achieved waypoint control of his FunJet at 150 miles an hour, and also accomplished a fully autonomous flight, from takeoff to landing, under control of MatrixPilot running on the UDB.

Here is a link, in case you haven't seen his posting:

http://www.diydrones.com/profiles/blogs/gt200kmh-funjet-the-fastest

Best regards,

Bill

[William Premerlani]

Team,

By the way, there was a typo in my last posting.

I meant to say "MatrxiPilot", not MicroPilot.

Best regards,

Bill

[Lew Payne]

Bill - I'm glad to hear MatrixPilot takes GPS latency into account.
Not doing so can create a problem that's hard to diagnose - since it
only tends to show up at faster speeds. Also, thanks for the warm
welcome... I've actually been here for months, chiming in only when I
felt I had something concise to contribute. I enjoy helping in any
way I can. Forcing myself back into embedded system and circuit
design (which I last did commercially back in 1985) is how I plan on
trying to exercise my brain synapses.

Regards,
Lew Payne

[Riccardo Kuebler]

Hi,

now I understand why those strange "cathedrals" appears in GE, at the end of each flight. It seems that Ublox is enough accurate (at least from what I expect from such a GPS device) during the flight, but when it stops after landing, altitude goes up and down like a crazy, say tens or even more that 100 meters.

Anyway, what I noticed with Ublox is that it can be very accurate in any position. I have severals flight logs doing aerobatics, and the plane position is always showed without strange deviations, like I had with another GPS logger. Is this a sign of good GPS signal ? I guess it is.

Another considerations is that I fly between high mountains, so no low horizon (and satellites) view. I watched this with a cellular phone software that shows satallites position and it showed to me that I can loose satellites under 20-40° from horizon.

I still have a good HDOP (in the last flight, in UDB values, between 5 and 13 and satellites between 6 and 8). This was with a Funjet that banks when turning (manual or autonomous) at 45°-90° and pitch at same angles.

Ublox has a Sarantel 1206 aerial that seems to have a beam width of 135° and seems to have some receiving capabilities even from bottom (inverted flight).

I don't have the specs of the EM406 but I read somewhere that those patch aerials have 25-30° beam width.

I don't have UDB format telemetry from my previous flights with the EM406. I did those flights with an Arcus (powered glider). It did not bank a lot, in autonomous flight, but I had big problems when changing altitude (plane pitching at ~20°). GPS bad signal when banking / pitching ?

The strange, but not so much, is that when doing autonomous inverted flight, sometimes it was going right, sometimes it was going bananas. There are some factors that changed between those flight, like snow, clouds etc.

Another test is when I was using Ardustation to record video of the moving plane (Arcus EM406). When inverted, Ardustation was not following well the plane position.

With Acromaster and Ublox it was working better.

You can have a look at this in the two videos :

- Arcus

- Acromaster (at the end of video Ardustation stuck)

Best regards,

Ric

2010/8/2 Lew Payne <lew....@gmail.com>