Daylight Losing Time: GPS Synchronizing VL?

Well, it's time to set clocks back...and I noticed something
interesting today.

My VolksLogger's clock seems to run 15 seconds ahead of other GPS
units...and the US Atomic clock (which appears to be synchronized with
GPS time -- or vice verse -- per the readout from a Garmin GPS90).

I say the VL seems ahead...and this is based on seeing the minute
readout roll over ahead of the other GPS units...since the VL display
doesn't show seconds.

Normally, this isn't a real concern, but I've been using the VL to do
some performance flight testing on a power plane...and I noticed that
the events I recorded didn't match up with the trace on the VL.

Has anybody else seen this type of "synchronization" error?

-Pete
#309

At 05:23 02 November 2008, 309 wrote:
Well, it's time to set clocks back...and I noticed something
interesting today.

My VolksLogger's clock seems to run 15 seconds ahead of other GPS
units...and the US Atomic clock (which appears to be synchronized with
GPS time -- or vice verse -- per the readout from a Garmin GPS90).

I say the VL seems ahead...and this is based on seeing the minute
readout roll over ahead of the other GPS units...since the VL display
doesn't show seconds.

Normally, this isn't a real concern, but I've been using the VL to do
some performance flight testing on a power plane...and I noticed that
the events I recorded didn't match up with the trace on the VL.

Has anybody else seen this type of "synchronization" error?

-Pete
#309

The probably explanation is that the difference you are seeing is 14
seconds and there have been 14 leap seconds since GPS started up.

Leap Seconds are introduced because the earth does not rotate in exactly
24 hours and GPS relies on exact time.

Satellites transmit the leap-second correction in ephemeris data which is
broadcast every 12.5 minutes, so if your VL had had sight of the sky until
the next correction came in, it would show correct time.

Read http://www.u-blox.com/customersuppor...apSeconds.html
for a manufacturer's explanation.

Had your VL been without power for a long period? I would have expected
the RTC in the VL to keep a record of the current correction under normal
circumstances.
-

Tim Newport-Peace >
Skype: specialist_systems
http://www.spsys.demon.co.uk/icom.htm

FR should record all events in UTC, which is different form GPS-time, as
UTC has leap seconds and GPS-time does not.

UTC and GPS-time were identical at UTC midnight the night from 5th of
Jan 1980 to 6th of Jan 1980.

Leap Seconds inserted into the UTC Time Scale

Date MJD Date MJD Date MJD Date MJD
2005-12-31 53735 1998-12-31 51178 1989-12-31 47891 1979-12-31 44238
1997-06-30 50629 1987-12-31 47160 1978-12-31 43873
1995-12-31 50082 1985-06-30 46246 1977-12-31 43508
1994-06-30 49533 1983-06-30 45515 1976-12-31 43143
1993-06-30 49168 1982-06-30 45150 1975-12-31 42777
1992-06-30 48803 1981-06-30 44785 1974-12-31 42412
1990-12-31 48256 1973-12-31 42047
1972-12-31 41682
1972-06-30 41498

Well...the VL gets run about twice a month...and had been up for a bit
of time before flight or comparison with the Garmin. And I try to
give it time to obtain an almanac (hoping this will update ephemeris
data) before flying.

This seems odd, based on the explanations above, the Garmin appears to
be displaying UTC, since it lines up well with the Atomic clock and
the Naval Observatory...so it has the 14 seconds added (?), or are
they subtracted...or is time relative??? (pun intended).

Is the VL then displaying GPS time (ahead of UTC)?

....or am I using the wrong sign convention -- leap seconds inserted
into UTC make it BEHIND GPS time?

Here I thought I'd found a way to make my 1-26 14 seconds faster...

-Pete

P.S.: This is making me wish I had IRIG time in my recording
stream...if only to confuse matters more.

On Nov 2, 5:23*am, 309 wrote:
Well, it's time to set clocks back...and I noticed something
interesting today.

My VolksLogger's clock seems to run 15 seconds ahead of other GPS
units

I say the VL seems ahead...and this is based on seeing the minute
readout roll over ahead of the other GPS units...since the VL display
doesn't show seconds.

It will show seconds, though, on the IGC file. What would be useful
would be to borrow another IGC-approved recorder and run the two
recorders together on a flight or a drive in a car. Make some
manouevres that can be identified post-flight (or press the Pilot
Event buttons at the same time) and compare the times in the IGC
files.

As others have said, your 15 seconds is very close to the 14 leap
seconds that have been added to UTC since January 2000 when the US GPS
system first came on line. Internal GPS system time is still UTC as
in January 2000 and GPS units normally automatically make the 14
second correction so the difference is not (normally) noticed by
users.

It would be interesting to hear the result of a comparative test with
another GPS recorder.

BTW, the Russian GLObal NAvigation Satellite System (GLONASS) system,
their equivalent of the US GPS, corrects its internal system time to
UTC every time a leap second is added by international agreement,
normally at midnight on 31 December. But that means that GLONASS has
to be taken off line while all its electronic clocks are re-set.
Question, does anyone know how long this system reset takes? It would
be embarrassing if you were half way down a bad-weather GLONASS
approach at the time.


Ian Strachan
Lasham Gliding Centre

At 03:39 03 November 2008, 309 wrote:
Well...the VL gets run about twice a month...and had been up for a bit
of time before flight or comparison with the Garmin. And I try to
give it time to obtain an almanac (hoping this will update ephemeris
data) before flying.

This seems odd, based on the explanations above, the Garmin appears to
be displaying UTC, since it lines up well with the Atomic clock and
the Naval Observatory...so it has the 14 seconds added (?), or are
they subtracted...or is time relative??? (pun intended).

Is the VL then displaying GPS time (ahead of UTC)?

....or am I using the wrong sign convention -- leap seconds inserted
into UTC make it BEHIND GPS time?

Here I thought I'd found a way to make my 1-26 14 seconds faster...

Or is that Slower?

-Pete

UTC=GPS+Leap Seconds.

For a UTC (=GMT) reference try http://wwp.greenwichmeantime.com/

The Volkslogger uses 'GPS Time' in the GPS Engine, but adds Leap Seconds
before recording the time.

Try using the VL's Pilot Event Marker to mark the trace at a minute
change as shown on the above site, download the trace and see what time is
recorded for the PEV.
-
Tim Newport-Peace >
Skype: specialist_systems
http://www.spsys.demon.co.uk/icom.htm

On Nov 3, 1:30*am, Tim Newport-Peace
wrote:

UTC=GPS+Leap Seconds.

For a UTC (=GMT) reference try *http://wwp.greenwichmeantime.com/

The Volkslogger uses 'GPS Time' in the GPS Engine, but adds Leap Seconds
before recording the time.


Thanks...I'll try the "event marker" experiment next chance I get.

FYI, my watch (synchronized to the Garmin GPS unit) matches pretty
damn closely to the grenwichmeantime.com link (and the US atomic clock
and the US Naval Observatory clock...) and this is ~14 seconds BEHIND
the reading of the VL. Using the equation above, Leap seconds would
be negative (i.e., the clock with the leap second correction - GMT-
reads an earlier time than one without leap seconds).

So at the same moment in time, the readings are as below:
Garmin = 00:01:15 = watch = GMT = US Atomic = USNO (???)
VL = 00:01:30

Yes, I see the seconds in the IGC file...I'm using that for performing
airspeed system calibrations.

I'll try to see how the event marker synch's with GMT vs. VL vs.
Watch...

Now here's a different question: does anybody know how to take an IGC
file (or SeeYou treatment of it) and derive north-south and east-west
velocities? This would be useful in determining the pitot-static
errors by flying a constant bank angle circle: Plot north-south/east
west velocities and you get a circle -- the center gives you the wind
and the radius is the true airspeed. If you want more info on that,
say so and I'll try to find the references online. For now, I've been
using the GPS-Horseshoe Heading technique...which uses more gas, but
gives a good opportunity to measure cruise performance...for a tug or
other power plane.

-Pete

At 08:21 04 November 2008, 309 wrote:
On Nov 3, 1:30=A0am, Tim Newport-Peace
wrote:

UTC=3DGPS+Leap Seconds.

For a UTC (=3DGMT) reference try =A0http://wwp.greenwichmeantime.com/

The Volkslogger uses 'GPS Time' in the GPS Engine, but adds Leap
Seconds
before recording the time.


Thanks...I'll try the "event marker" experiment next chance I get.

FYI, my watch (synchronized to the Garmin GPS unit) matches pretty
damn closely to the grenwichmeantime.com link (and the US atomic clock
and the US Naval Observatory clock...) and this is ~14 seconds BEHIND
the reading of the VL. Using the equation above, Leap seconds would
be negative (i.e., the clock with the leap second correction - GMT-
reads an earlier time than one without leap seconds).

So at the same moment in time, the readings are as below:
Garmin =3D 00:01:15 =3D watch =3D GMT =3D US Atomic =3D USNO (???)
VL =3D 00:01:30

Yes, I see the seconds in the IGC file...I'm using that for performing
airspeed system calibrations.

I'll try to see how the event marker synch's with GMT vs. VL vs.
Watch...

The point to remember is that when you add in a Leap Second, it makes the
minute one second longer and delays the start of the next minute. This
will result in UTC being slower by one second for each Leap Second added.




Now here's a different question: does anybody know how to take an IGC
file (or SeeYou treatment of it) and derive north-south and east-west
velocities? This would be useful in determining the pitot-static
errors by flying a constant bank angle circle: Plot north-south/east
west velocities and you get a circle -- the center gives you the wind
and the radius is the true airspeed. If you want more info on that,
say so and I'll try to find the references online. For now, I've been
using the GPS-Horseshoe Heading technique...which uses more gas, but
gives a good opportunity to measure cruise performance...for a tug or
other power plane.

-Pete

This is probably better in a new thread, however...

The B-record in the IGC file (records starting with the letter B) contain
Time (6 bytes), Latitude (8 bytes), Longitude (Longitude (9 bytes) and a
Fix Valid flag.

Ignore records where the fix valid flag is "V" only use records where
the fix valid flag is "A".

You can now extract the Time, Latitude and Longitude differences between
two records and calculate the N-S and E-W speed in degrees/second.

If you want to translate degrees into metres, it is too complex to explain
in a newsgroup but look at Ed Williams' Aviation Formulary at
http://williams.best.vwh.net/avform.htm
-
Tim Newport-Peace >
Skype: specialist_systems
http://www.spsys.demon.co.uk/icom.htm