[Space] Fwd: KML from G1 data
brian.choate at gmail.com
Fri Jun 11 15:18:40 PDT 2010
The data that we have been talking about is from a G1 phone.
The GPS we are using with the radio equipment actually has software for
configuring those settings. I need to construct a programming cable for
On 06/11/2010 02:44 PM, tedward wrote:
> 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.
> On Fri, Jun 11, 2010 at 1:49 PM, Erik Ebert <eebert at gmail.com
> <mailto: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 <mailto: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 <mailto: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.
> Space mailing list
> Space at lists.noisebridge.net <mailto:Space at lists.noisebridge.net>
> Space mailing list
> Space at lists.noisebridge.net
More information about the Space