Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

GPS Satelites - Not Synchronized

66 views
Skip to first unread message

Steve Watson

unread,
Aug 28, 2012, 12:41:25 PM8/28/12
to
More good news,

it looks like the GPS satellites are not even
synchronized, thanks :-)

what they have over there, is allegedly some
clocks reporting different times

no need for relativistic correction then

good bye

Tom Roberts

unread,
Aug 28, 2012, 1:34:26 PM8/28/12
to
On 8/28/12 8/28/12 - 11:41 AM, Steve Watson wrote:
> it looks like the GPS satellites are not even
> synchronized

I don't know how you are "looking", but this is wrong.

The GPS arranges so every satellite clock displays the time of an ECI coordinate
clock at its current location. This is after all uploaded corrections are
applied, of course.

That makes them all synchronized in the ECI frame. The system would not work
without such synchronization.


Tom Roberts

Koobee Wublee

unread,
Aug 28, 2012, 1:55:44 PM8/28/12
to
On Aug 28, 9:41 am, Steve Watson <o4s...@katamail.com> wrote:

> it looks like the GPS satellites are not even
> synchronized, thanks :-)

In a local system, you always have the following that determine local
time:

** Time = Counter that counts every tick as time flows on

** Clock = Source of time counter (atomic clocks)

Thus, time accumulates clock.

In GPS, there are satellites, receivers, and stations where stations
serve as management of the system without actual playing a direct part
in the GPS-receiver relationship. <shrug>

None of the clocks among satellites, receivers, and stations need to
be synchronized. Time also does not have to be synchronized in either
satellite-receiver or satellite-station link. However, time must be
synchronized among satellites. How well time is synchronized will
affect the accuracy of the end result. <shrug>

By acquiring the time and location of 4 satellites, all the receiver
has to do is to solve 4 equations with 4 unknowns of time, altitude,
longitude, and latitude. <shrug>

However, in the very beginning, the self-styled physicists got
involved in the development and proposed the receiver to acquire only
three satellites. Since the system only allows one to solve for only
3 unknowns (altitude, longitude, and latitude), time must be known
beforehand. In doing so, it becomes necessary to synchronize time
between satellites and receivers. This is where these clowns have
been ranting great triumph in their religion known as General
Relativity. <shrug>

Not too long afterwards, engineers being infinitely more intelligent
easily noticed that by acquiring 4 satellites and solving a system
with 4 equations and 4 unknowns, this now renders the time
synchronization between satellites and receivers totally unnecessary.
That saves a lot of money from further development. <shrug>

Thus, GPS does not validate GR at all. The self-styled physicists
with a combined intelligence not much more than an amoeba still cannot
comprehend this. They are still ranting how GPS is the biggest
triumph in the bullshit known as GR. Don’t believe Koobee Wublee?
Just ask one of these self-styled physicist. Fvking sad, no? <shrug>


kenseto

unread,
Aug 28, 2012, 4:30:23 PM8/28/12
to
No the correction is build into the GPS before launch. The GPS second is redefined to have 4.46 more periods of Cs 133 radiation. This is designed to make the GPS second contain the same amount of absolute time as the ground clock second and thus making the GPS permanently in synch with the ground clock.

>
>
>
> good bye

Steve Watson

unread,
Aug 28, 2012, 5:01:05 PM8/28/12
to
On Aug 28, 7:34 pm, Tom Roberts <tjroberts...@sbcglobal.net> wrote:
> On 8/28/12 8/28/12 - 11:41 AM, Steve Watson wrote:
>
> > it looks like the GPS satellites are not even
> > synchronized
>
> I don't know how you are "looking", but this is wrong.

with all do respect, here

http://groups.google.com/group/sci.physics.relativity/msg/8a0f80ec5045a90b

they are not "in sync" when the clocks ticks at
same rate showing different times

>
> The GPS arranges so every satellite clock displays the time of an ECI coordinate
> clock at its current location. This is after all uploaded corrections are
> applied, of course.
>
> That makes them all synchronized in the ECI frame. The system would not work
> without such synchronization.

this is not what "in sync" means

> Tom Roberts

regards

Steve Watson

unread,
Aug 28, 2012, 5:04:25 PM8/28/12
to
On Aug 28, 7:55 pm, Koobee Wublee <koobee.wub...@gmail.com> wrote:
> On Aug 28, 9:41 am, Steve Watson <o4s...@katamail.com> wrote:
>
> > it looks like the GPS satellites are not even
> > synchronized, thanks :-)
>
> In a local system, you always have the following that determine local
> time:
>
> ** Time = Counter that counts every tick as time flows on
>
> ** Clock = Source of time counter (atomic clocks)

what frequency, you don't have so fast counters
this is very pretty

>
> Thus, GPS does not validate GR at all. The self-styled physicists
> with a combined intelligence not much more than an amoeba still cannot
> comprehend this. They are still ranting how GPS is the biggest
> triumph in the bullshit known as GR. Don’t believe Koobee Wublee?
> Just ask one of these self-styled physicist. Fvking sad, no? <shrug>


thanks

Steve Watson

unread,
Aug 28, 2012, 5:07:29 PM8/28/12
to
this is rate correction, not sync, nor relativistic
correction, or is something hidden i dont know

regards

Poutnik

unread,
Aug 28, 2012, 5:15:57 PM8/28/12
to

Koobee Wublee from koobee...@gmail.com
posted Tue, 28 Aug 2012 10:55:44 -0700 (PDT)


> None of the clocks among satellites, receivers, and stations need to
> be synchronized. Time also does not have to be synchronized in either
> satellite-receiver or satellite-station link. However, time must be
> synchronized among satellites. How well time is synchronized will
> affect the accuracy of the end result. <shrug>
>
With trilateration ( determining position by given
fixed reference points ) you are right.

But Good luck than in determining exact satellite position
without satellite having correct time.

If satellites think time is 1 s less than is,
then receivers will think they are all about 4 km shifted.

--
Poutnik

Current way of spaced quoting by GoogleGroups is disaster,
if combined with no quoting by some GG users.

Steve Watson

unread,
Aug 28, 2012, 5:30:25 PM8/28/12
to
On Aug 28, 11:15 pm, Poutnik <poutnik4n...@gmail.com> wrote:
> Koobee Wublee from koobee.wub...@gmail.com
> posted Tue, 28 Aug 2012 10:55:44 -0700 (PDT)
>
> > None of the clocks among satellites, receivers, and stations need to
> > be synchronized. Time also does not have to be synchronized in either
> > satellite-receiver or satellite-station link. However, time must be
> > synchronized among satellites. How well time is synchronized will
> > affect the accuracy of the end result. <shrug>
>
> With trilateration ( determining position by given
> fixed reference points ) you are right.
>
> But Good luck than in determining exact satellite position
> without satellite having correct time.
>
> If satellites think time is 1 s less than is,
> then receivers will think they are all about 4 km shifted.
>
> --
> Poutnik

how should one of them get short of one sec
when all ticking at same rate

Poutnik

unread,
Aug 28, 2012, 5:41:31 PM8/28/12
to

Steve Watson from o4s...@katamail.com
posted Tue, 28 Aug 2012 14:30:25 -0700 (PDT)
I have addressed false claim in sense

"satellites need not to be synchronized with stations,
enough is if synchronized mutually each other."

As determining of receiver position has 3 stages:

1 - Trilateration
- Determining receiver-sat distances and receiver-sat time offset.

here is enough if sats are mutually synchronized

2 - Determining sat positions from exact time and ephemeris formulas.

Incorrect sat and therefore receiver time would lead
to incorrect sat position cca 4 km per 1s time offset )

3 - determining receiver position from trilateration
and exact sat positions for given exact time.

Steve Watson

unread,
Aug 28, 2012, 5:49:09 PM8/28/12
to
no need for corrections then

Poutnik

unread,
Aug 28, 2012, 5:58:04 PM8/28/12
to

Steve Watson from o4s...@katamail.com
posted Tue, 28 Aug 2012 14:49:09 -0700 (PDT)
Incorrect. Notice stage 2.
Clock incorrected to RT make accumulative error about 5 m per month.

even if they were not RT corrected ( they are ),
they could be continuosly synced from stations.

But, let suppose you have a wrist want slow 5 min/per day.
Lets suppose you adjust them sooften then time error is negligible.

Does that mean the are right ?

Steve Watson

unread,
Aug 28, 2012, 6:05:17 PM8/28/12
to
why should they go out of sync, they tick
at same rate

Poutnik

unread,
Aug 28, 2012, 6:09:39 PM8/28/12
to

Steve Watson from o4s...@katamail.com
posted Tue, 28 Aug 2012 15:05:17 -0700 (PDT)


>
> > Incorrect. Notice stage 2.
> > Clock incorrected to RT make accumulative error about 5 m per month.
> >
> > even if they were not RT corrected ( they are ),
> > they could be continuosly synced from stations.
> >
> > But, let suppose you have a wrist want slow 5 min/per day.
> > Lets suppose you adjust them sooften then time error is negligible.
> >
> > Does that mean the are right ?

> why should they go out of sync, they tick
> at same rate

Yes, but if not put out of proper rate on the ground,
they got out of proper rate on the orbit.

kenseto

unread,
Aug 28, 2012, 6:17:51 PM8/28/12
to
It is in synch in terms of absolute time.


Steve Watson

unread,
Aug 28, 2012, 6:19:09 PM8/28/12
to
On Aug 29, 12:09 am, Poutnik <poutnik4n...@gmail.com> wrote:
> Steve Watson from o4s...@katamail.com
> posted Tue, 28 Aug 2012 15:05:17 -0700 (PDT)
>
>
>
> > > Incorrect. Notice stage 2.
> > > Clock incorrected to RT make accumulative error about 5 m per month.
>
> > > even if they were not RT corrected ( they are ),
> > > they could be continuosly synced from stations.
>
> > > But, let suppose you have a wrist want slow 5 min/per day.
> > > Lets suppose you adjust them sooften then time error is negligible.
>
> > > Does that mean the are right ?
> > why should they go out of sync, they tick
> > at same rate
>
> Yes, but if not put out of proper rate on the ground,
> they got out of proper rate on the orbit.

a receiver dont need any local time, nor sny
specific local time rate, are you sure?

Poutnik

unread,
Aug 28, 2012, 6:23:31 PM8/28/12
to

Steve Watson from o4s...@katamail.com
posted Tue, 28 Aug 2012 15:19:09 -0700 (PDT)


> >
> > Yes, but if not put out of proper rate on the ground,
> > they got out of proper rate on the orbit.
>
> a receiver dont need any local time, nor sny
> specific local time rate, are you sure?

Receiver calculates during trilateration
atomic clock time of satellite caesium clocks.

There are 4 equations of 4 degress of freedom.
4 timestamp differences
versus 3 distances + time offset receiver-satellites

Steve Watson

unread,
Aug 28, 2012, 6:32:17 PM8/28/12
to
On Aug 29, 12:23 am, Poutnik <poutnik4n...@gmail.com> wrote:
> Steve Watson from o4s...@katamail.com
> posted Tue, 28 Aug 2012 15:19:09 -0700 (PDT)
>
>
>
> > > Yes, but if not put out of proper rate on the ground,
> > > they got out of proper rate on the orbit.
>
> > a receiver dont need any local time, nor sny
> > specific local time rate, are you sure?
>
> Receiver calculates during trilateration
> atomic clock time of satellite caesium clocks.
>
> There are 4 equations of 4 degress of freedom.
> 4 timestamp differences
> versus 3 distances + time offset receiver-satellites
>
> --
> Poutnik

i repeat, a receiver dont need any local time,
nor any specific local time rate

there is no backup battery, the receiver is
just a chip and an antenna

Poutnik

unread,
Aug 28, 2012, 6:39:42 PM8/28/12
to

Steve Watson from o4s...@katamail.com
posted Tue, 28 Aug 2012 15:32:17 -0700 (PDT)
Without local time receiver
is not able to calculate timestamp differences,
and without them distances and sat clock time.
Without sat clock time cannot calculate sat positions
and therefore neither its own position.

Poutnik

unread,
Aug 28, 2012, 6:44:20 PM8/28/12
to

Poutnik from poutni...@gmail.com
posted Wed, 29 Aug 2012 00:39:42 +0200


> > i repeat, a receiver dont need any local time,
> > nor any specific local time rate
> >
> > there is no backup battery, the receiver is
> > just a chip and an antenna
>
> Without local time receiver
> is not able to calculate timestamp differences,
> and without them distances and sat clock time.
> Without sat clock time cannot calculate sat positions
> and therefore neither its own position.

But quartz local time of the device is enough,
and local time is corrected to atomic clock
during trilateration.

Steve Watson

unread,
Aug 28, 2012, 6:50:46 PM8/28/12
to
you insist, and i repeat, the receiver is
just a chip and an antenna, no time keeping
device

Poutnik

unread,
Aug 28, 2012, 6:51:03 PM8/28/12
to

Poutnik from poutni...@gmail.com
posted Wed, 29 Aug 2012 00:44:20 +0200


>
> Poutnik from poutni...@gmail.com
> posted Wed, 29 Aug 2012 00:39:42 +0200
>
>
> > > i repeat, a receiver dont need any local time,
> > > nor any specific local time rate
> > >
> > > there is no backup battery, the receiver is
> > > just a chip and an antenna
> >
> > Without local time receiver
> > is not able to calculate timestamp differences,
> > and without them distances and sat clock time.
> > Without sat clock time cannot calculate sat positions
> > and therefore neither its own position.
>
> But quartz local time of the device is enough,
> and local time is corrected to atomic clock
> during trilateration.

You are true that you could use any time as initial local time,
and you would get corrected by triliteration,
but why not to use device time ?

Poutnik

unread,
Aug 28, 2012, 6:59:44 PM8/28/12
to

Steve Watson from o4s...@katamail.com
posted Tue, 28 Aug 2012 15:50:46 -0700 (PDT)


>
> you insist, and i repeat, the receiver is
> just a chip and an antenna, no time keeping
> device

1 - Every GPS device I am aware has got a clock.
1a - Every GPS device during GPS lock must sustain keeping local time
at least internally by chip features
to compare local timestamp and timestamp stored in GPS signal
by GPs satellite.
Otherwise it would NOT be able to calculate
neither distance to satellite
neither their position.

2 - Quad core CPU is just a chip either.

Steve Watson

unread,
Aug 28, 2012, 7:15:07 PM8/28/12
to
i can see you dont understand physics

the host application, at best would give
a time stamp based on a crystal oscillator
with stochastic large tolerance in frequency
dependent on fabrication, temperature,
interferences and many other things

are you saying that wrong local clock or
shifting to another time-zone will make
the receiver not to work?

Poutnik

unread,
Aug 29, 2012, 12:01:59 AM8/29/12
to

Steve Watson from o4s...@katamail.com
posted Tue, 28 Aug 2012 16:15:07 -0700 (PDT)


>
> On Aug 29, 12:59 am, Poutnik <poutnik4n...@gmail.com> wrote:
> > Steve Watson from o4s...@katamail.com
> > posted Tue, 28 Aug 2012 15:50:46 -0700 (PDT)
> >
> >
> >
> > > you insist, and i repeat, the receiver is
> > > just a chip and an antenna, no time keeping
> > > device
> >
> > 1 - Every GPS device I am aware has got a clock.
> > 1a - Every GPS device during GPS lock must sustain keeping local time
> > at least internally by chip features
> > to compare local timestamp and timestamp stored in GPS signal
> > by GPs satellite.
> > Otherwise it would NOT be able to calculate
> > neither distance to satellite
> > neither their position.
> >
> > 2 - Quad core CPU is just a chip either.
> >

> i can see you dont understand physics

You can see nothing but maybe mutual misunderstanding.
>
> the host application, at best would give
> a time stamp based on a crystal oscillator
> with stochastic large tolerance in frequency
> dependent on fabrication, temperature,
> interferences and many other things

Sure, this I have never disagreed.

Satellite clock time value is a byproduct
during calculation of distances
receiver - satellites.
>
> are you saying that wrong local clock or
> shifting to another time-zone will make
> the receiver not to work?

Not at all.

Poutnik

unread,
Aug 29, 2012, 12:20:40 AM8/29/12
to

Poutnik from poutni...@gmail.com
posted Wed, 29 Aug 2012 06:01:59 +0200


>
> Steve Watson from o4s...@katamail.com
> posted Tue, 28 Aug 2012 16:15:07 -0700 (PDT)

>
> > i can see you dont understand physics
>
> You can see nothing but maybe mutual misunderstanding.
> >
> > the host application, at best would give
> > a time stamp based on a crystal oscillator
> > with stochastic large tolerance in frequency
> > dependent on fabrication, temperature,
> > interferences and many other things
>
> Sure, this I have never disagreed.
>
> Satellite clock time value is a byproduct
> during calculation of distances
> receiver - satellites.
> >
> > are you saying that wrong local clock or
> > shifting to another time-zone will make
> > the receiver not to work?
>
> Not at all.

I was just trying to say that

eventual incorrect *satellite* clock values
- even if mutually synced -
would cause GPS working incorrectly,
as it would calculate wrong satellite positions.

Ground stations could send to sats corrected data,
calculating right positions from bad time.

But in such a case it is like I said, continuous correction of bad clocks
to have right value does not mean they are correct.

Martin Brown

unread,
Aug 29, 2012, 3:45:29 AM8/29/12
to
The local clock in the receiver is a practical convenience rather than
an essential component. To first order it provides a local timestamp
that can be used to get a rough solution once three satellites are
available. In practice four or more are needed and the local oscillator
drift rate is just another systematic unknown that has to be determined.

The local clock could be replaced by the repetition frame rate of the
strongest incoming signal for instance for the period of determination.
This would be Doppler shifted and require additional compensation.
>
> are you saying that wrong local clock or
> shifting to another time-zone will make
> the receiver not to work?
>

The receiver has to determine it's precise local time as a part of the
solution. It is extremely convenient to have an accurate locally
generated timestamp but it is not absolutely essential. GPS offloaded
some of the hard bits to the satellites so that the receivers would be
simple. The precise local time is not normally output from consumer
grade devices but it is determined as a part of the GPS solution.

--
Regards,
Martin Brown

Poutnik

unread,
Aug 29, 2012, 4:30:56 AM8/29/12
to

Martin Brown from |||newspam|||@nezumi.demon.co.uk
posted Wed, 29 Aug 2012 08:45:29 +0100

>
> The local clock in the receiver is a practical convenience rather than
> an essential component. To first order it provides a local timestamp
> that can be used to get a rough solution once three satellites are
> available. In practice four or more are needed and the local oscillator
> drift rate is just another systematic unknown that has to be determined.
>
> The local clock could be replaced by the repetition frame rate of the
> strongest incoming signal for instance for the period of determination.
> This would be Doppler shifted and require additional compensation.
> >
> > are you saying that wrong local clock or
> > shifting to another time-zone will make
> > the receiver not to work?
> >
>
> The receiver has to determine it's precise local time as a part of the
> solution. It is extremely convenient to have an accurate locally
> generated timestamp but it is not absolutely essential. GPS offloaded
> some of the hard bits to the satellites so that the receivers would be
> simple. The precise local time is not normally output from consumer
> grade devices but it is determined as a part of the GPS solution.

I may be wrong,
but during GPS locking process it needs
to keep rough local time running,
as it evaluates incoming signal timestamps,
compared to local time
at the different local times.

It is not just about to have ANY local time, even bad.
That would be usable if all timestamps come at the same time.

It is about to have ANY local time *running*, even bad.
And that could be running within GPS receiver chip,
evaluating

TL1 - TS1
TL2 - TS2
TL3 - TS3
TL4 - TS4

where
TSn is timestamp from signal of sat n
TLn is raw local time at receiving TSn

From above, distances to sats and their atomic clock is determined.

Tha would be usable if all timestamps come at the same time.

Tom Roberts

unread,
Aug 29, 2012, 10:24:58 AM8/29/12
to
On 8/28/12 8/28/12 4:01 PM, Steve Watson wrote:
> On Aug 28, 7:34 pm, Tom Roberts <tjroberts...@sbcglobal.net> wrote:
>> On 8/28/12 8/28/12 - 11:41 AM, Steve Watson wrote:
>>> it looks like the GPS satellites are not even
>>> synchronized
>>
>> I don't know how you are "looking", but this is wrong.
>
> with all do respect, here
> http://groups.google.com/group/sci.physics.relativity/msg/8a0f80ec5045a90b
> they are not "in sync" when the clocks ticks at
> same rate showing different times

That is correct, in itself. But the GPS satellite clocks DO display the same
time in the ECI frame (they also all tick at the same rate MEASURED IN THAT FRAME).


>> The GPS arranges so every satellite clock displays the time of an ECI coordinate
>> clock at its current location. This is after all uploaded corrections are
>> applied, of course.
>>
>> That makes them all synchronized in the ECI frame. The system would not work
>> without such synchronization.
>
> this is not what "in sync" means

Yes, it is. In particular, one must always specify in which frame the clocks are
in sync; I did so.


But there is some rubbish to clear away, in other posts of this thread.

Steve Watson said:
> no need for relativistic correction then

Not true. The relativistic corrections to the GPS are absolutely required for it
to operate within its specifications; it simply would not work without them.
Given the physical situation of the earth, no such positioning system would work
without relativistic corrections. The primary correction is to the tick rate of
the satellite clocks, but there are others which are smaller, but required to
keep the system in spec (e.g. corrections due to the gravitation of sun and
moon, and corrections due to propagation effects in the atmosphere).


kenseto said:
> the correction is build into the GPS before launch.

Yes. This is required because the GPS satellites are moving in the ECI frame,
and are at an altitude well above the geoid. The GPS design requires them to be
synchronized in the ECI frame, not in each of their own local inertial frames.
This tick-rate correction, plus periodic updates from the ground, ensures they
are all synchronized properly.


> The GPS second is
> redefined to have 4.46 more periods of Cs 133 radiation. This is designed to
> make the GPS second contain the same amount of absolute time as the ground
> clock second and thus making the GPS permanently in synch with the ground
> clock.

This is just plain wrong (kenseto has been making this mistake for over a decade
-- some people are utterly ineducable). His reference to "absolute time" is
complete fantasy.

In the GPS, the second is defined by the ISO definition. It is the satellite
CLOCKS which have their tick rate modified, in order that they tick at the
standard rate IN THE ECI FRAME. This is not a change in the meaning of 1 second,
it is merely an engineering modification to the clocks as required by their
physical situation and the requirement for synchronization in the ECI frame.

Note that the GPS includes many ground clocks, as well as satellite clocks. They
ALL are synchronized in the ECI frame, and the GPS time is maintained within 1
microsecond of UTC modulo leap seconds (it's usually much better). Note that
both UTC and the GPS time apply to earth's geoid. Note also this ECI frame is
equivalent to an inertial frame in SR, everywhere inside the GPS satellite
orbits -- in particular, time on the geoid is carried throughout the ECI frame
via the synchronization of (fictitious) ECI coordinate clocks [#].

[#] The fictitious coordinate clocks are realized by the satellite
and ground clocks.


Tom Roberts

Tom Roberts

unread,
Aug 29, 2012, 10:50:14 AM8/29/12
to
On 8/28/12 8/28/12 4:30 PM, Steve Watson wrote:
> how should one of them get short of one sec
> when all ticking at same rate

They are REAL CLOCKS, not perfect abstractions of textbooks. They all have
intrinsic drift in their tick rates, and the gravitation of sun and moon affect
each clock at different times in their orbits. More importantly, their orbits
differ from perfect circles at the design altitude, and this manifests itself as
short-term variations and long-term drift in tick rate. So a REAL system needs
to periodically update the clocks' individual times.

Note also that Kubee Wublee is wrong, and the mutual synchronization of the GPS
clocks is absolutely required for the system to operate. He is hallucinating
about some other system, with some other design, and VERY different
requirements. He is also ineducable and has repeated this mistake for many years.

BTW modern receivers use more than 4 satellites, in order to
improve the accuracy of their position fix. They perform a
multi-parameter fit, rather than simply solving 4 equations
for 4 unknowns.

In particular, the GPS is REQUIRED to keep a single system time, and to maintain
that time within 1 microsecond of UTC module leap seconds.


> a receiver dont need any local time, nor sny
> specific local time rate, are you sure?

Every GPS receivers has a local clock, but one that is vastly less accurate than
GPS time. They use this to bridge the time fixes from different satellites, to
remove certain theoretical ambiguities in the solutions for position, and for
estimating position when satellite signals are lost. This local clock need not
keep very accurate time, and in cheap receivers is only an interval clock (i.e.
it does not retain date and time).


> i repeat, the receiver is
> just a chip and an antenna, no time keeping
> device

You are wrong. See above. EVERY GPS chip has at least a local oscillator to
bridge time fixes from different satellites.


> eventual incorrect *satellite* clock values
> - even if mutually synced -
> would cause GPS working incorrectly,
> as it would calculate wrong satellite positions.

Yes. That's why the GPS ground segment uploads corrections to every satellite.
The primary corrections are of the satellite's orbit, but timing corrections are
included.


Tom Roberts

Tom Roberts

unread,
Aug 29, 2012, 11:04:40 AM8/29/12
to
On 8/29/12 8/29/12 2:45 AM, Martin Brown wrote:
> The local clock in the receiver is a practical convenience rather than an
> essential component.

This is not true. Every GPS receiver has a local clock, but one that is vastly
less accurate than GPS time. They use this to bridge the time fixes from
different satellites, to remove certain theoretical ambiguities in the solutions
for position, and for estimating position when satellite signals are lost. This
local clock need not keep very accurate time, and in cheap receivers is only an
interval clock (i.e. it does not retain date and time).


> To first order it provides a local timestamp that can be
> used to get a rough solution once three satellites are available. In practice
> four or more are needed and the local oscillator drift rate is just another
> systematic unknown that has to be determined.

Yes. But the time fixes from different satellites come at different times, and
MUST be bridged. The local oscillator is accurate enough for this. This is
essential.


> The local clock could be replaced by the repetition frame rate of the strongest
> incoming signal for instance for the period of determination.

No. That does not happen often enough. The receiver needs a local oscillator to
interpolate time between fixes from individual satellites.


> The receiver has to determine it's precise local time as a part of the solution.
> It is extremely convenient to have an accurate locally generated timestamp but
> it is not absolutely essential. GPS offloaded some of the hard bits to the
> satellites so that the receivers would be simple. The precise local time is not
> normally output from consumer grade devices but it is determined as a part of
> the GPS solution.

Yes. Indeed NIST sells/leases devices that provide highly accurate timing
signals derived from GPS satellite signals.

Actually, the really "hard bits" are in the ground segment, not
the satellites. This of course matches their computational
capacities. The ground segment uploads the results to the
satellites, which send it to the receivers. These are corrections
to individual satellite orbits and clocks; the hard bit is determining
all those corrections, and that is done on the ground.


Tom Roberts

Lord Androcles, Zeroth Earl of Medway

unread,
Aug 29, 2012, 11:48:15 AM8/29/12
to
"Tom Roberts" wrote in message news:E5-dnW3GMeI...@giganews.com...

On 8/29/12 8/29/12 2:45 AM, Martin Brown wrote:
> The local clock in the receiver is a practical convenience rather than an
> essential component.

This is not true. Every GPS receiver has a local clock, but one that is
vastly
less accurate than GPS time. They use this to bridge the time fixes from
different satellites

============================================================

Bullshit. Why would anyone need a local clock to subtract the time of one
satellite
from another?
I can set my phone to any time I choose and I can know where I am at any
time.
In the 21st century, Roberts, a phone is a GPS receiver and we've arrived,
even
if you are still in the 19th. Yesterday I used it to navigate around the
Barbican
and the Museum of London at London Wall, without a compass.
If you think that's easy turn on Google Earth Street view at
51°31'3.94"N, 0° 5'42.78"W
Martin Brown is ABSOLUTELY CORRECT.
You are a DISGUSTING ANCIENT LIAR, clueless Roberts!
-- Lord Androcles, Zeroth Earl of Medway

-- "Tom Roberts" wrote in message
news:9LqdnZVOesi...@giganews.com...
It is not me who is wrong.
Tom Roberts
===========================================================
It must be Einstein who is wrong, then.
Bwhahahahaha!
"Tom Roberts" wrote in message news:t5CdnQfQvY4...@giganews.com...
The problem is with your poor reading skills, not with the clocks. Einstein
NEVER said "they are slowed", because he knew full well that they are not
(see above).
"Thence we conclude that a balance-clock at the equator must go more slowly,
by a very small amount, than a precisely similar clock situated at one of
the poles under otherwise identical conditions." -- Einstein
--Lord Androcles, Zeroth Earl of Medway

Koobee Wublee

unread,
Aug 29, 2012, 12:48:31 PM8/29/12
to
On Aug 29, Tom Roberts wrote:

> But the GPS satellite clocks DO display the same
> time in the ECI frame (they also all tick at the same
> rate MEASURED IN THAT FRAME).

The GPS situation needs to be analyzed with an absolute time and
absolute simultaneity. After denying the absolute frame of reference,
Tom finds the ECI frame as the substitute. Relative simultaneity just
added more mysticism that at the end of the day where you still have
to use absolute simultaneity to resolve any issues. Of course, the
self-styled physicists with a combined intelligence of not much more
than an amoeba have really, really difficult time understanding that.
They really don’t know what they are doing. <shrug>

> one must always specify in which frame the clocks are
> in sync; I did so.

You don’t if simultaneity is absolute, and this is where physics is
much simpler than relative simultaneity. All experiments show
simultaneity is absolute. Only under absolute simultaneity, the
interferometers can give experimentally repeatable, coherent
interference patterns. <shrug>

> Not true. The relativistic corrections to the GPS are absolutely required for it
> to operate within its specifications; it simply would not work without them.

That is a myth. See Koobee Wublee’s recent post on this.

http://groups.google.com/group/sci.physics.relativity/msg/5847920d8e567050

> Given the physical situation of the earth, no such positioning system would work
> without relativistic corrections. The primary correction is to the tick rate of
> the satellite clocks

It is time that has to be synchronized among the satellites.
Theoretically, each satellite can have different clock with different
tick rate than the others. Synchronizing time is practically a
software solution. After all these years, Tom still cannot understand
this simple issue. Again, time is the accumulation of clock. <shrug>

> BTW modern receivers use more than 4 satellites, in order to
> improve the accuracy of their position fix. They perform a
> multi-parameter fit, rather than simply solving 4 equations
> for 4 unknowns.

This point is irrelevant in our discussions. You need to understand
the pertinent issues here before bringing up engineering
improvements. <shrug>

> In particular, the GPS is REQUIRED to keep a single system time, and to maintain
> that time within 1 microsecond of UTC module leap seconds.

It does not have to be synchronized with the UTC time.
Synchronization with the UTC time is done through software. That
piece of information is another piece of almanac data to be downloaded
into each receiver. It plays no role in the GPS calculations.
<shrug>

> Every GPS receivers has a local clock, but one that is vastly less accurate than
> GPS time.

It sounds like Tom is still confused with what time and clock are (per
Koobee Wublee’s definitions, see the link provided above). You must
understand the two definitions before any discussions can continue.
<shrug>

On a side note, each Einstein Dingleberries tends to fabricate his own
fantasy about why GPS clock synchronization is necessary. For
example, professor Andersen from Trondheim University in Norway
claimed the correction is done for the mixers. In another words,
without the relativistic corrections, it would be impossible to
demodulate the almanac information from GPS carrier frequencies.
Amazingly, he used to work in the industry as an RF engineer. Wow!
Ahahaha...

Pete Weber

unread,
Aug 29, 2012, 3:36:43 PM8/29/12
to
On Wed, 29 Aug 2012 09:50:14 -0500, Tom Roberts wrote:

> On 8/28/12 8/28/12 4:30 PM, Steve Watson wrote:
>> how should one of them get short of one sec when all ticking at same
>> rate
>
> They are REAL CLOCKS, not perfect abstractions of textbooks. They all
> have intrinsic drift in their tick rates,

Yes, but hey, they run atomic clocks. You can't
have something better than that.
_YOU_ are wrong, all digital electronics needs a
driving clock, which is not a "local time"

May be an external crystal, internal DCO, or a
direct clock signal from the host application

>
>
>> eventual incorrect *satellite* clock values - even if mutually synced -
>> would cause GPS working incorrectly,
>> as it would calculate wrong satellite positions.
>
> Yes. That's why the GPS ground segment uploads corrections to every
> satellite. The primary corrections are of the satellite's orbit, but
> timing corrections are included.

The may upload time, not corrections, this is
how corrections are done, no?

Pete Weber

Pete Weber

unread,
Aug 29, 2012, 3:36:44 PM8/29/12
to
On Wed, 29 Aug 2012 10:04:40 -0500, Tom Roberts wrote:

> On 8/29/12 8/29/12 2:45 AM, Martin Brown wrote:
>> The local clock in the receiver is a practical convenience rather than
>> an essential component.
>
> This is not true. Every GPS receiver has a local clock, but one that is
> vastly less accurate than GPS time. They use this to bridge the time
> fixes from different satellites, to remove certain theoretical
> ambiguities in the solutions for position, and for estimating position
> when satellite signals are lost.

This makes no sense, I'm afraid you confuse a
driving clock to a chip with a time keeping device.

More over, if the alleged local time is not good,
and gets corrected, why on Earth using such wrong
time from the device, and not using the corrected
one directly!

> This local clock need not keep very
> accurate time, and in cheap receivers is only an interval clock (i.e. it
> does not retain date and time).

Exactly what I said, a driving clock, say 26MHz
30% duty cycle 00100100 ... is not time

>
>
>> To first order it provides a local timestamp that can be used to get a
>> rough solution once three satellites are available. In practice four or
>> more are needed and the local oscillator drift rate is just another
>> systematic unknown that has to be determined.
>
> Yes. But the time fixes from different satellites come at different
> times, and MUST be bridged. The local oscillator is accurate enough for
> this. This is essential.

Perhaps, but this is not local time, but timers,
huge difference

>
>
>> The local clock could be replaced by the repetition frame rate of the
>> strongest incoming signal for instance for the period of determination.
>
> No. That does not happen often enough. The receiver needs a local
> oscillator to interpolate time between fixes from individual satellites.
>
>
>> The receiver has to determine it's precise local time as a part of the
>> solution.
>> It is extremely convenient to have an accurate locally generated
>> timestamp but it is not absolutely essential. GPS offloaded some of the
>> hard bits to the satellites so that the receivers would be simple. The
>> precise local time is not normally output from consumer grade devices
>> but it is determined as a part of the GPS solution.
>
> Yes. Indeed NIST sells/leases devices that provide highly accurate
> timing signals derived from GPS satellite signals.

You see, this is something completely else

>
> Actually, the really "hard bits" are in the ground segment, not the
> satellites. This of course matches their computational capacities.
The
> ground segment uploads the results to the satellites, which send
it to
> the receivers. These are corrections to individual satellite
orbits and
> clocks; the hard bit is determining all those corrections, and
that is
> done on the ground.
>
>
> Tom Roberts

So the "local time" is taken from the satellites!

Pete Weber

unread,
Aug 29, 2012, 3:44:46 PM8/29/12
to
On Wed, 29 Aug 2012 00:51:03 +0200, Poutnik wrote:

> Poutnik from poutni...@gmail.com posted Wed, 29 Aug 2012 00:44:20
> +0200
>
>
>
>> Poutnik from poutni...@gmail.com posted Wed, 29 Aug 2012 00:39:42
>> +0200
>>
>>
>> > > i repeat, a receiver dont need any local time,
>> > > nor any specific local time rate
>> > >
>> > > there is no backup battery, the receiver is just a chip and an
>> > > antenna
>> >
>> > Without local time receiver is not able to calculate timestamp
>> > differences,
>> > and without them distances and sat clock time. Without sat clock time
>> > cannot calculate sat positions and therefore neither its own
>> > position.
>>
>> But quartz local time of the device is enough,
>> and local time is corrected to atomic clock during trilateration.
>
> You are true that you could use any time as initial local time,
> and you would get corrected by triliteration,
> but why not to use device time ?

Because it would be kinda imbecility, once it
gets corrected anyway?

Poutnik

unread,
Aug 29, 2012, 5:33:53 PM8/29/12
to

Pete Weber from p4g...@gmail.com
posted Wed, 29 Aug 2012 19:36:43 +0000 (UTC)


> _YOU_ are wrong, all digital electronics needs a
> driving clock, which is not a "local time"
>
> May be an external crystal, internal DCO, or a
> direct clock signal from the host application
>

Unless it is though technically, local device time,
not geographically as e.g. local time by local noon.

Poutnik

unread,
Aug 29, 2012, 5:35:54 PM8/29/12
to

Pete Weber from p4g...@gmail.com
posted Wed, 29 Aug 2012 19:44:46 +0000 (UTC)
you need it before that, and this even imbecils understand.

Pete Weber

unread,
Aug 29, 2012, 5:51:19 PM8/29/12
to
Yes, I can see you do, using a wrong local time before that

I can't

Pete Weber

unread,
Aug 29, 2012, 5:57:21 PM8/29/12
to
On Wed, 29 Aug 2012 23:33:53 +0200, Poutnik wrote:

> Pete Weber from p4g...@gmail.com posted Wed, 29 Aug 2012 19:36:43 +0000
> (UTC)
>
>
>> _YOU_ are wrong, all digital electronics needs a driving clock, which
>> is not a "local time"
>>
>> May be an external crystal, internal DCO, or a direct clock signal from
>> the host application
>>
>>
> Unless it is though technically, local device time, not geographically
> as e.g. local time by local noon.

What is a "local device time" as different from other time.

Show it technically

Tom Roberts

unread,
Aug 29, 2012, 6:08:20 PM8/29/12
to
On 8/29/12 8/29/12 2:36 PM, Pete Weber wrote:
> On Wed, 29 Aug 2012 09:50:14 -0500, Tom Roberts wrote:
>> On 8/28/12 8/28/12 4:30 PM, Steve Watson wrote:
>>> how should one of them get short of one sec when all ticking at same
>>> rate
>> They are REAL CLOCKS, not perfect abstractions of textbooks. They all
>> have intrinsic drift in their tick rates,
>
> Yes, but hey, they run atomic clocks. You can't
> have something better than that.

Atomic clocks are not perfect; their deficiencies from perfection are large
enough to require correction.

A collection of atomic clocks _IS_ better than an atomic clock,
and the GPS ground segment uses such a collection, including
relating to the collection that defines UTC.
(Some pulsars are also better than an atomic clock...)

And as I said (and you omitted), errors in their orbit affect their timing that
needs to be corrected.


>> Every GPS receivers has a local clock, but one that is vastly less
>> accurate than GPS time. They use this to bridge the time fixes from
>> different satellites, to remove certain theoretical ambiguities in the
>> solutions for position, and for estimating position when satellite
>> signals are lost. This local clock need not keep very accurate time, and
>> in cheap receivers is only an interval clock (i.e. it does not retain
>> date and time).
>>> i repeat, the receiver is just a chip and an antenna, no time keeping
>>> device
>> You are wrong. See above. EVERY GPS chip has at least a local oscillator
>> to bridge time fixes from different satellites.
>
> all digital electronics needs a
> driving clock, which is not a "local time"

True but irrelevant.

Think about what the software inside a GPS receiver sees (simplified to just
address this point):

* Time Stamp T1 arrives from satellite #12
* some amount of time passes
* Time Stamp T2 arrives from satellite #6
* some amount of time passes
* Time Stamp T3 arrives from satellite #2
* some amount of time passes
* Time Stamp T4 arrives from satellite #21
* some amount of time passes
* Time Stamp T5 arrives from satellite #9
* some amount of time passes
* Time Stamp T6 arrives from satellite #12
...

The receiver MUST relate the unknown and essentially random arrival times of
these signals to each other, and to do that requires a local time standard (aka
clock) to quantify "some amount of time". For this example, the local time
standard need not know what time it is, and just needs to be able to measure the
time intervals between those signals moderately accurately. To resolve the
theoretical ambiguities requires it to know the date and time reasonably accurately.


>> That's why the GPS ground segment uploads corrections to every
>> satellite. The primary corrections are of the satellite's orbit, but
>> timing corrections are included.
>
> The may upload time, not corrections, this is
> how corrections are done, no?

No. They upload corrections to the orbit, and corrections to the displayed time
of the satellite clock. The design specifies the parametrized equations that
represent these corrections, and the data uploaded consist of the current best
values of the parameters.


Tom Roberts

Poutnik

unread,
Aug 29, 2012, 6:11:25 PM8/29/12
to

Pete Weber from p4g...@gmail.com
posted Wed, 29 Aug 2012 21:57:21 +0000 (UTC)
You would not understand.

kenseto

unread,
Aug 29, 2012, 6:23:39 PM8/29/12
to
The value of the ECI clock second is calculates from the ground clock second which has 9,192,631,770 periods of Cs 133 radiation. What this mean is that the ECI second has different period of Cs 133 radiation than the ground clock second. The ECI second is then used to calculate the value of the GPS second an dit turns out that the GPS second has the value of 9,192,631,774.46 periods of Cs 133 radiation. What this mean is that 9,192,631,770 periods of Cs 133 radiation on the ground clock has the same duration (absolute time) as 9,192,631,774.46 periods of Cs 133 radiation on the GPS clock.

>
> This tick-rate correction, plus periodic updates from the ground, ensures they
>
> are all synchronized properly.
>
>
>
>
>
> > The GPS second is
>
> > redefined to have 4.46 more periods of Cs 133 radiation. This is designed to
>
> > make the GPS second contain the same amount of absolute time as the ground
>
> > clock second and thus making the GPS permanently in synch with the ground
>
> > clock.
>
>
>
> This is just plain wrong (kenseto has been making this mistake for over a decade
>
> -- some people are utterly ineducable). His reference to "absolute time" is
>
> complete fantasy.

It is you who is plain wrong. You failed to understand the GPS.

Pete Weber

unread,
Aug 29, 2012, 6:39:40 PM8/29/12
to
On Wed, 29 Aug 2012 17:08:20 -0500, Tom Roberts wrote:

> On 8/29/12 8/29/12 2:36 PM, Pete Weber wrote:
>> On Wed, 29 Aug 2012 09:50:14 -0500, Tom Roberts wrote:
>>> On 8/28/12 8/28/12 4:30 PM, Steve Watson wrote:
>>>> how should one of them get short of one sec when all ticking at same
>>>> rate
>>> They are REAL CLOCKS, not perfect abstractions of textbooks. They all
>>> have intrinsic drift in their tick rates,
>>
>> Yes, but hey, they run atomic clocks. You can't have something better
>> than that.
>
> Atomic clocks are not perfect; their deficiencies from perfection are
> large enough to require correction.
>
> A collection of atomic clocks _IS_ better than an atomic clock,
> and the GPS ground segment uses such a collection, including
relating
> to the collection that defines UTC.
> (Some pulsars are also better than an atomic clock...)
>
> And as I said (and you omitted), errors in their orbit affect their
> timing that needs to be corrected.

Was not omitted, sorry, anyone knows about imperfections,
and you have +23 satellites that can autoadjust running
autonomous a periodic subroutine, which is irrelevant in
context of this discussion

>
>
>>> Every GPS receivers has a local clock, but one that is vastly less
>>> accurate than GPS time. They use this to bridge the time fixes from
>>> different satellites, to remove certain theoretical ambiguities in the
>>> solutions for position, and for estimating position when satellite
>>> signals are lost. This local clock need not keep very accurate time,
>>> and in cheap receivers is only an interval clock (i.e. it does not
>>> retain date and time).
>>>> i repeat, the receiver is just a chip and an antenna, no time keeping
>>>> device
>>> You are wrong. See above. EVERY GPS chip has at least a local
>>> oscillator to bridge time fixes from different satellites.
>>
>> all digital electronics needs a driving clock, which is not a "local
>> time"
>
> True but irrelevant.

I thought you confused a driving clock with a "local time"

>
> Think about what the software inside a GPS receiver sees (simplified to
> just address this point):
>
> * Time Stamp T1 arrives from satellite #12 * some amount of time passes
> * Time Stamp T2 arrives from satellite #6 * some amount of time passes *
> Time Stamp T3 arrives from satellite #2 * some amount of time passes *
> Time Stamp T4 arrives from satellite #21 * some amount of time passes *
> Time Stamp T5 arrives from satellite #9 * some amount of time passes *
> Time Stamp T6 arrives from satellite #12 ...

This looks like delay separated serial NMEA data strings, not the slow
stream of bits data that comes from the satellites.

The satellites transmit all at once without delays, on same channel using
CDMA coding, a spread spectrum technique

>
> The receiver MUST relate the unknown and essentially random arrival
> times of these signals to each other, and to do that requires a local
> time standard (aka clock) to quantify "some amount of time". For this
> example, the local time standard need not know what time it is, and just
> needs to be able to measure the time intervals between those signals
> moderately accurately. To resolve the theoretical ambiguities requires
> it to know the date and time reasonably accurately.

No, this is apparently an error, the receiver can just initiate a timer for
each event. Timers are not "date and time"

>
>
>>> That's why the GPS ground segment uploads corrections to every
>>> satellite. The primary corrections are of the satellite's orbit, but
>>> timing corrections are included.
>>
>> The may upload time, not corrections, this is how corrections are done,
>> no?
>
> No. They upload corrections to the orbit, and corrections to the
> displayed time of the satellite clock. The design specifies the
> parametrized equations that represent these corrections, and the data
> uploaded consist of the current best values of the parameters.

It was about corrections to the "local time" stamp

>
>
> Tom Roberts

Regards

Lord Androcles, Zeroth Earl of Medway

unread,
Aug 29, 2012, 6:43:40 PM8/29/12
to
"Tom Roberts" wrote in message news:XNudnQSHRJB...@giganews.com...
==========================================================
What a load of old bollocks!
x1^2 + y1^2 + z1^2 - (ct1)^2 = 0 (Time and position stamp)
x2^2 + y2^2 + z2^2 - (ct2)^2 = 0 (Time and position stamp)
x3^2 + y3^2 + z3^2 - (ct3)^2 = 0 (Time and position stamp)
x4^2 + y4^2 + z4^2 - (ct4)^2 = 0 (Time and position stamp)
Four simultaneous equations in four unknowns, kiddy stuff.
You couldn't program a microwave oven to run full power for 30 seconds,
Roberts.
You are an IDIOT!

Pete Weber

unread,
Aug 29, 2012, 7:03:54 PM8/29/12
to
On Wed, 29 Aug 2012 23:43:40 +0100, Lord Androcles, Zeroth Earl of Medway
wrote:

[snip crap]

> -- Lord Androcles, Zeroth Earl of Medway

looks like you try to tell something, can't see what

Martin Brown

unread,
Aug 30, 2012, 3:19:09 AM8/30/12
to
On 29/08/2012 16:04, Tom Roberts wrote:
> On 8/29/12 8/29/12 2:45 AM, Martin Brown wrote:
>> The local clock in the receiver is a practical convenience rather than an
>> essential component.
>
> This is not true. Every GPS receiver has a local clock, but one that is
> vastly less accurate than GPS time. They use this to bridge the time
> fixes from different satellites, to remove certain theoretical
> ambiguities in the solutions for position, and for estimating position
> when satellite signals are lost. This local clock need not keep very
> accurate time, and in cheap receivers is only an interval clock (i.e. it
> does not retain date and time).

The local clock in the receiver does not *have* to be local though it
just has to have a counter that increases ideally uniformly and
monotonically with time. The CPU clock rate would be good enough and
anything likely to process GPS signals will always have one.
>
>
>> To first order it provides a local timestamp that can be
>> used to get a rough solution once three satellites are available. In
>> practice
>> four or more are needed and the local oscillator drift rate is just
>> another
>> systematic unknown that has to be determined.
>
> Yes. But the time fixes from different satellites come at different
> times, and MUST be bridged. The local oscillator is accurate enough for
> this. This is essential.

On this we are agreed. The device must be able to know the timestamp of
receipt of each signal to better than 0.1us to get a 30m fix. And the
clock must not drift too much over the period of measurement or any
drift there is must be computable from the satellite ephemeris.
>
>
>> The local clock could be replaced by the repetition frame rate of the
>> strongest
>> incoming signal for instance for the period of determination.
>
> No. That does not happen often enough. The receiver needs a local
> oscillator to interpolate time between fixes from individual satellites.

The C/A code has a transmitted frequency of 1.023MHz and a phase locked
loop could take it to 10.23MHz which would be good enough. I grant you
that it would be utterly perverse to do this and would complicate the
mathematics enormously since you would have to Doppler correct the
derived pseudo local clock as received from the satellite in software.

It boils down to just another nuisance parameter in the solution and a
bit more orbital information that has to be downloaded.
>
>
>> The receiver has to determine it's precise local time as a part of the
>> solution.
>> It is extremely convenient to have an accurate locally generated
>> timestamp but
>> it is not absolutely essential. GPS offloaded some of the hard bits to
>> the
>> satellites so that the receivers would be simple. The precise local
>> time is not
>> normally output from consumer grade devices but it is determined as a
>> part of
>> the GPS solution.
>
> Yes. Indeed NIST sells/leases devices that provide highly accurate
> timing signals derived from GPS satellite signals.

I don't think we are going to resolve our disagreement on whether a
local clock is essential. In practice there will always be a good enough
local clock for the CPU so no-one would be mad enough to ever do what I
have described. But it could still in principle be done.
>
> Actually, the really "hard bits" are in the ground segment, not
> the satellites. This of course matches their computational
> capacities. The ground segment uploads the results to the
> satellites, which send it to the receivers. These are corrections
> to individual satellite orbits and clocks; the hard bit is determining
> all those corrections, and that is done on the ground.

Does BMEWS still participate in the orbital determinations for GPS or is
there a dedicated system just for GPS satellites?

--
Regards,
Martin Brown

Koobee Wublee

unread,
Aug 30, 2012, 2:22:49 PM8/30/12
to
On Aug 29, 3:08 pm, Tom Roberts wrote:

> Think about what the software inside a GPS receiver sees (simplified to just
> address this point):
>
> * Time Stamp T1 arrives from satellite #12
> * some amount of time passes
> * Time Stamp T2 arrives from satellite #6
> * some amount of time passes
> * Time Stamp T3 arrives from satellite #2
> * some amount of time passes
> * Time Stamp T4 arrives from satellite #21
> * some amount of time passes
> * Time Stamp T5 arrives from satellite #9
> * some amount of time passes
> * Time Stamp T6 arrives from satellite #12
> ...
>
> The receiver MUST relate the unknown and essentially random arrival times of
> these signals to each other, and to do that requires a local time standard (aka
> clock) to quantify "some amount of time". For this example, the local time
> standard need not know what time it is, and just needs to be able to measure the
> time intervals between those signals moderately accurately.

Since these time intervals are so short, there is no need to introduce
relativist corrections even if existed. So, what you have brought out
is another engineering details to “perfect” a receive per each
manufacturer’s willingness to engage so compromising cost and
performance. <shrug>

> To resolve the
> theoretical ambiguities requires it to know the date and time reasonably accurately.

No, no, no. Say for 10usec difference in arrival time of two GPS
satellites. Would relativistic correction be necessary? <shrug>

You can keep searching for the elephant to satisfy your myth. Any
experimental physicists more than 100 years ago would embrace
scientific method instead. <shrug>

Pete Weber

unread,
Aug 30, 2012, 2:39:58 PM8/30/12
to
There is no delay in between arrivals, the satellites transmit
continuously, almost impossible to schedule them to do otherwise,
due to the various distance between them and wherever receivers,
atmospheric conditions, and so on

the trick is that the receiver demodulate fast and build a database
almanac

Koobee Wublee

unread,
Aug 30, 2012, 4:00:47 PM8/30/12
to
On Aug 30, 11:40 am, Pete Weber <p4g...@gmail.com> wrote:
> On Thu, 30 Aug 2012 11:22:49 -0700, Koobee Wublee wrote:

> > Since these time intervals are so short, there is no need to introduce
> > relativist corrections even if existed. So, what you have brought out
> > is another engineering details to “perfect” a receive per each
> > manufacturer’s willingness to engage so compromising cost and
> > performance. <shrug>
>
> There is no delay in between arrivals, the satellites transmit
> continuously, almost impossible to schedule them to do otherwise,
> due to the various distance between them and wherever receivers,
> atmospheric conditions, and so on

When each satellite send out a packet of almanac information including
its time as agreed so by other satellites, its altitude, its
longitude, and its latitude, that packet is only unique at that
location in space and time when it was sent out.

When a receiver receives each packet of almanac information from each
satellite, it has the choice of fine-tuning the time and position of
each satellite to a fixed time. That is when these delays between
receiving these packets would come in handy.

What Tom is trying to do is to look for that flying elephant to
justify his myth of GPS support of GR. Little did he think about the
issue and once again has jumped into conclusion way too soon.

<shrug>

Ps. For further scholarly research, also check out IEEE1588. The GPS
can employ a system similar to this.

http://en.wikipedia.org/wiki/IEEE1588_Clock_Synchronization


Pete Weber

unread,
Aug 30, 2012, 4:36:51 PM8/30/12
to
On Thu, 30 Aug 2012 13:00:47 -0700, Koobee Wublee wrote:

> On Aug 30, 11:40 am, Pete Weber <p4g...@gmail.com> wrote:
>> On Thu, 30 Aug 2012 11:22:49 -0700, Koobee Wublee wrote:
>
>> > Since these time intervals are so short, there is no need to
>> > introduce relativist corrections even if existed. So, what you have
>> > brought out is another engineering details to “perfect” a receive per
>> > each manufacturer’s willingness to engage so compromising cost and
>> > performance. <shrug>
>>
>> There is no delay in between arrivals, the satellites transmit
>> continuously, almost impossible to schedule them to do otherwise,
>> due to the various distance between them and wherever receivers,
>> atmospheric conditions, and so on
>
> When each satellite send out a packet of almanac information including
> its time as agreed so by other satellites, its altitude, its longitude,
> and its latitude, that packet is only unique at that location in space
> and time when it was sent out.

No, you are much error, i suppose, it is impossible to
do that, there is not network grid communication between
satellites. To do that you would need a stationary beacon
to synchronize in space, but all satellites are in motion

>
> When a receiver receives each packet of almanac information from each
> satellite, it has the choice of fine-tuning the time and position of
> each satellite to a fixed time. That is when these delays between
> receiving these packets would come in handy.

there is no delays, but a RF link continuous directed one way
satellite to receiver slow data communication by CDMA coding,
a spread spectrum technique

>
> What Tom is trying to do is to look for that flying elephant to justify
> his myth of GPS support of GR. Little did he think about the issue and
> once again has jumped into conclusion way too soon.
>
> <shrug>
>
> Ps. For further scholarly research, also check out IEEE1588. The GPS
> can employ a system similar to this.
>
> http://en.wikipedia.org/wiki/IEEE1588_Clock_Synchronization

Wrong again, IEEE1588 is a master-slave configuration, two ways
synchronous data communication, as said, needs a stationary
beacon that requires fixed geometry for the network

not valid

Tom Roberts

unread,
Aug 31, 2012, 10:55:55 AM8/31/12
to
On 8/30/12 8/30/12 - 1:39 PM, Pete Weber wrote:
>> On Aug 29, 3:08 pm, Tom Roberts wrote:
>>> The receiver MUST relate the unknown and essentially random arrival
>>> times of these signals to each other, and to do that requires a local
>>> time standard (aka clock) to quantify "some amount of time".
>
> There is no delay in between arrivals,

This is simply not true. Do you even understand how communication from multiple
satellites to a receiver works? -- the satellites all transmit on a single
frequency [#], using code-division multiplexing on a single data channel. This
means the arrival time of timestamps from different satellites INHERENTLY come
at different times. And indeed, timestamps occur at 30-second intervals from
each satellite, according to its LOCAL clock. That's why a local time standard
is necessary.

See: http://en.wikipedia.org/wiki/Global_Positioning_System#Communication

[#] A second frequency is used for the military high-accuracy
channel, which is no longer encrypted and is available for
civilian use; essentially all modern receivers use both. Still,
there are just 2 channels that are multiplexed among all satellites.


> the satellites transmit
> continuously,

Yes, at a time scale of minutes. No at a time scale of seconds or lower; the
timing must be performed better than 0.01 microsecond to obtain a few-meter
position resolution -- that's 3 billion times smaller than the interval between
time stamps from individual satellites, and accurate interpolation is essential.


Tom Roberts

Pete Weber

unread,
Aug 31, 2012, 1:18:57 PM8/31/12
to
On Fri, 31 Aug 2012 09:55:55 -0500, Tom Roberts wrote:

> On 8/30/12 8/30/12 - 1:39 PM, Pete Weber wrote:
>>> On Aug 29, 3:08 pm, Tom Roberts wrote:
>>>> The receiver MUST relate the unknown and essentially random arrival
>>>> times of these signals to each other, and to do that requires a local
>>>> time standard (aka clock) to quantify "some amount of time".
>>
>> There is no delay in between arrivals,
>
> This is simply not true. Do you even understand how communication from
> multiple satellites to a receiver works? -- the satellites all transmit
> on a single frequency [#], using code-division multiplexing on a single
> data channel. This means the arrival time of timestamps from different
> satellites INHERENTLY come at different times. And indeed, timestamps
> occur at 30-second intervals from each satellite, according to its LOCAL
> clock. That's why a local time standard is necessary.
>
> See:
> http://en.wikipedia.org/wiki/Global_Positioning_System#Communication

Wrong what you say even more, please learn, seems you don't
do stuff for real

GPS use CDMA coding, which is Code Division Multiple Access, not
multiplexing, a spread-spectrum technique

http://en.wikipedia.org/wiki/Cdma

Take a look at what CDMA and spread spectrum is all about, come
back and tell me you understood!


>
> [#] A second frequency is used for the military high-accuracy
channel,
> which is no longer encrypted and is available for civilian use;
> essentially all modern receivers use both. Still, there are just 2
> channels that are multiplexed among all satellites.

Irrelevant here

>
>
>> the satellites transmit continuously,
>
> Yes, at a time scale of minutes.

Absolutely unbelievable wrong, there is low bit data rate transmission,
due to merely unpredictable distances between the many satellites and
the many receivers, there is no way to schedule +24 satellites to transmit
sequentially, unless a channel arbiter. Channel arbiters requires fixed
geometry for the network

> No at a time scale of seconds or lower;
> the timing must be performed better than 0.01 microsecond to obtain a
> few-meter position resolution -- that's 3 billion times smaller than the
> interval between time stamps from individual satellites, and accurate
> interpolation is essential.
>
>
> Tom Roberts

Please read carefully, and if you have questions I could help

Pete Weber

unread,
Aug 31, 2012, 1:58:52 PM8/31/12
to
On Fri, 31 Aug 2012 09:55:55 -0500, Tom Roberts wrote:

And yes, thanks and please reread your link

"GPS message format
Each GPS satellite continuously broadcasts a navigation message
on L1 C/A and L2 P/Y at a rate of 50 bits per second (see bitrate).
...
All satellites broadcast at the same frequencies. Signals are
encoded using code division multiple access (CDMA) allowing messages
from individual satellites to be distinguished from each other based
on unique encodings for each satellite (that the receiver must be
aware of)."

Koobee Wublee

unread,
Sep 1, 2012, 4:26:25 AM9/1/12
to
On Aug 31, 7:55 am, Tom Roberts <tjroberts...@sbcglobal.net> wrote:

> This
> means the arrival time of timestamps from different satellites INHERENTLY come
> at different times. And indeed, timestamps occur at 30-second intervals from
> each satellite, according to its LOCAL clock. That's why a local time standard
> is necessary.

So, are you still suggesting, even for 30 seconds, it is necessary to
synchronize the receiver time with the satellite time and correct for
relativistic effect? If not, what is the necessity to employ GR on
the corrections of the satellite or the ground station time? <shrug>

> Yes, at a time scale of minutes. No at a time scale of seconds or lower; the
> timing must be performed better than 0.01 microsecond to obtain a few-meter
> position resolution -- that's 3 billion times smaller than the interval between
> time stamps from individual satellites, and accurate interpolation is essential.

What do you think the accuracy of the receiver clock is? 1PPM or
better? <shrug>


Pete Weber

unread,
Sep 1, 2012, 6:01:39 AM9/1/12
to
It depends on frequency, ie for a 26MHz resonator a +10 ppm is
excellent, for a watch 32.768kHz you may want to go lower, it
has more to say

In any case 20 ppm are OK, but is not significant here, the
receiver must do the decoding as fast as possible, so a higher
the clock frequency and hardware decoding is essential

Pete Weber

unread,
Sep 4, 2012, 3:03:25 PM9/4/12
to
On Tue, 28 Aug 2012 12:34:26 -0500, Tom Roberts wrote:

> On 8/28/12 8/28/12 - 11:41 AM, Steve Watson wrote:
>> it looks like the GPS satellites are not even synchronized
>
> I don't know how you are "looking", but this is wrong.
>
> The GPS arranges so every satellite clock displays the time of an ECI
> coordinate clock at its current location. This is after all uploaded
> corrections are applied, of course.

may be, but not with respect to the receivers

>
> That makes them all synchronized in the ECI frame. The system would not
> work without such synchronization.
>
>
> Tom Roberts

contrarily. the system would not work if
the satellites were in sync with the receivers
0 new messages