[Space] Fwd: KML from G1 data

[tedward]

What GPS chipset are you guys using?

If you're using UBLOX, I wrote a little python tool that can speak its
binary protocol and switch it to "airborne" filtering mode, which would
avoid this kind of problem.

http://github.com/deleted/ublox

Cheers,
twd

On Fri, Jun 11, 2010 at 1:49 PM, Erik Ebert <eebert at gmail.com> wrote:

> More information from Ken, our club's GPS guru.
>
> I suspect that the weird stairstep ascent and descent you can see in
> the Google Earth plot of the data is caused by the filtering issue
> that Ken describes for "high altitude and/or high dynamic flights".
> That's a typical symptom.
>
>
> My guess is that what is going on is when the GPS is in 'ground mode'
> and it sees a large change in altitude it assumes it must be a
> multipath artifact and tries to smooth it out.  But when the altitude
> change exceeds some threshold or goes on for long enough it decides
> the altitude change must have been real and it resets the baseline to
> the new value.
>
>  -- Erik
>
>
> ---------- Forwarded message ----------
> From: Ken Biba <ken at bibafamily.com>
> Date: Thu, Jun 10, 2010 at 10:09 AM
> Subject: Re: [Space] KML from G1 data
> To: Erik Ebert <eebert at gmail.com>
>
>
> Love to help.
>
> There are really two problems with GPS chipsets:
>
> 1.  Some have a legacy limitation on speed and altitude - and I
> suspect the Garmin had that problem.   There are legacy restrictions
> on GPS from the old days (now expired) so the these devices would not
> work to build missle guidance systems.    Now, since most of these
> devices are built in China anyway - that is a pretty silly
> restriction.   And further, they were often incompetently implemented
> ... the restrictions were basically preventing a device from reporting
> faster than the speed of sound AND above 60K'.     Sadly .. some folks
> implemented OR rather than AND.   Confusion reigns.
>
> 2.  A second problem, and somewhat distinct - is the filtering used in
> the GPS microprocessor.    All of these devices use some kind of
> filtering to improve their performance in changing environments.
> Most are optimized for the GPS reception environment in urban canyons
> on the ground (car and foot navigation) and make assumptions when
> filtering consistent with that model.  Some - have multiple filters
> supporting different movement models - the uBlox and the Trimble are
> in the latter camp.
>
> I think Garmin no longer makes its own chipsets and uses SiRFStar
> chipsets ... which would explain all of the above behaviour.
>
> The only chipsets that really should be used on high altitude and/or
> high dynamic flights are uBlox or Trimble Lassen.     Trimble is
> chipset used in Big Red Bee GPS.   Both need to be correctly
> programmed (in non NMEA mode) to use the right movement filter.
> Actually - that was the problem I think you had - BigRedBee had a
> manufacturing glitch and forgot to properly program the GPS chip.
>
> Parrot is good ... so is GPSFlight ... frankly for their application,
> I have 1W GPSFlight devices left over from the 100K project that
> should work well.
>
> K
> _______________________________________________
> Space mailing list
> Space at lists.noisebridge.net
> https://www.noisebridge.net/mailman/listinfo/space
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.noisebridge.net/pipermail/space/attachments/20100611/bc33d97d/attachment.html>