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