On 5/21/19 11:42 AM, kinsell wrote:
On 5/20/19 9:06 PM, Dave Leonard wrote:
Check the discussion he
On Monday, May 20, 2019 at 8:34:07 PM UTC-6, Dave Leonard wrote:
Maybe has to do with waiting to get the current almanac to know how
many leap seconds to apply to received GPS time to get to UTC time
used for the logs? Waiting for the whole message can take over 10
Yes, but the number of leap seconds to apply changes so infrequently
that it's silly to wait for that information to be downloaded at each
GPS engines are free to store almanac and ephemeris data and shorten the
initialization time considerably, many of them do.Â* I would say that the
Ublox behavior of waiting 10 minutes plus after achieving a 3D lock to
do corrections to the time is out of the ordinary.
So we have the perfect storm of a slow gps engine, pilots who don't
think they need to wait for the gps to lock up before takeoff, and OLC
doing stringent checking on the quality of the data.Â* Of those three, I
would say OLC is the least at fault in all this.
As a side note, I've used Ublox engines for Stratux boxes, was quite
happy with them. They seemed sensitive, quick to lock up, and certainly
were dirt cheap. Maybe they do cache the almanac data, but have some
bug in them that explains the big delay in getting the time right.