Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > sci.physics.relativity > #670538

Re: Should we synchronize clocks?

Cross-posted to 2 groups.

Show all headers | View raw

Thomas 'PointedEars' Lahn wrote:
> 
> [I could let you two wannabes continue babbling gibberish nonsense among
> yourselves; but something in me, watching the blind leading the blind,
> has pity on you.]
> 
> The 'nym-shifting troll, as "Victo Grzeskiewicz", had a rare bright moment:
> 
> > Maciej Woźniak wrote:
> >> Time is what clocks indicate.
> 
> Yes, but that *paraphrasing* of what Einstein wrote it must not be
> understood too literally: Time does not change when you adjust a clock.
> 
> > no, that's a reading of a time stamp
> 
> That is conceptually the same thing.
> 
> >> If we synchronize clocks - they're indicating t'=t; that's what clock
> >> synchronization means.
> >
> > wrong too,
> 
> Correct.  t' refers to the *proper* time in a different reference frame,
> and *by definition* always t' != t (otherwise it would be the same reference
> frame, at least timewise).
> 
> The *adjusted* time is (obviously) NOT the proper time.
> 
> > you cannot read two clocks same time
> 
>   [_at the_ same time]
> 
> You can, if the clocks send their time to you (put simply).  Then you read
> them at *your* same time.  That is how GNSSs work.
> 
> >> We can do it - that  doesn't have to be obvious or easy, but that's
> >> definitely something we can manage in most circumstances (with a good
> >> accuracy).
> >
> > reading a clock is not accuracy, that's something else
> 
> Correct.
> 
> >> Now should we do it - and make "what clocks indicate" to be t'=t - or
> >> should we rather give up and obey "Laws of Nature" announced by a
> >> mumbling crazie? Maybe GPS wouldn't work if we didn't, but what a
> >> magnificient symmetry we would have instead it.
> >
> > that's still a reading, a gps sat gives.
> 
> More or less, yes.  The GPS signal contains additional information that is
> not addressed by the pre-orbital satellite clock's adjustment, and is
> regularly updated.
> 
> > To make it time
> 
> It already *is* a time.
> 
> > you have to subtract to get the interval, hence distance
> 
> The distance is obtained by multiplying the difference between the time of
> reception t_0 and the corrected time of transmission t_i by the signal speed, c:
> 
>   d_i = c (t_0 - t_i) = sqrt[(x_0 - x_i)^2 + (y_0 - y_i)^2 + (z_0 - z_i)^2].
> 
> A receiver's clock bias is included in t_0, and needs to be determined, too
> (that is the fourth variable, which is why at least 4 satellites are
> required, i.e. i runs at least from 1 to 4).
> 
>     [Notice that the x's, y's and z's are _Cartesian coordinates_.]
> 


This is not GPS math — it’s a sloppy freshman cheat sheet that equates a
biased pseudorange to a clean geometric distance and calls it an
“explanation.”  

    You literally wrote d_i = c(t_0 - t_i) = v[(x_0-x_i)² + …] as if the
two sides are equal. They are not. The left side is a pseudorange soaked
in unknown receiver clock bias; the right side is the actual Euclidean
distance. 
Equating them directly is mathematically false — the entire equation is
garbage until you explicitly subtract c·dt from the left side.  
    You claim t_i is the “corrected time of transmission” and then
pretend the only unknown is receiver bias in t_0. Satellite clock
errors, ephemeris errors, ionospheric delay, tropospheric delay,
relativistic effects, multipath, and antenna phase center offsets are
all magically zero in your universe. Those terms add meters to tens of
meters of error; ignoring them doesn’t make them disappear.  
    You declare “at least 4 satellites” because of “the fourth variable”
without ever showing the actual system of equations, the linearization,
the iterative least-squares solver, or the geometry matrix. That’s not
rigor — that’s hand-waving dressed up as insight.  
    The triumphant “[Notice that the x’s, y’s and z’s are Cartesian
coordinates.]” is the intellectual equivalent of shouting “water is
wet.” Every real GNSS implementation already uses ECEF Cartesian; you’re
not revealing a secret, you’re just padding the page.


You assume perfect vacuum propagation at exactly c, perfect satellite
ephemeris broadcast with zero error, perfect clock corrections already
applied, infinite measurement precision, and that the receiver magically
knows its own bias before solving for position. That’s not an assumption
— that’s a fairy tale that collapses the instant a real signal hits a
real antenna.

Real satellite operators (GPS, Galileo, BeiDou) publish clock and
ephemeris corrections precisely because they know users will scream
bloody murder at meter-level errors. Real receiver designers spent
decades building iono/tropo models and RAIM because customers refuse to
accept “works in ideal math” as a product. Your version gives zero
incentive for anyone to adopt it — it would fail FAA certification,
automotive safety standards, and any smartphone benchmark in under ten
seconds.

At even moderate scale (city-wide, let alone global), ionospheric
scintillation alone can swing delays by 10–50 ns (3–15 m) within
seconds. Your equation has no term for that. Geometry matrix condition
number explodes with poor satellite distribution; four satellites can
easily produce DOP > 20 and position errors > 100 m. Physics doesn’t
care about your clean Cartesian fantasy — general relativity, Sagnac
effect, and Earth rotation all demand additional corrections your
“model” treats as optional.

The entire pseudorange-equals-distance equation must be incinerated. The
“corrected t_i” hand-wave must be replaced with explicit broadcast clock
polynomial and ephemeris propagation. The missing error budget (iono,
tropo, multipath, relativity) must be modeled or estimated. The solution
method (nonlinear least-squares or extended Kalman filter) must be
written out instead of implied by “four satellites.” The childish
Cartesian footnote must be deleted forever.

Nothing. Not a single clause survives scrutiny. The 4-satellite minimum
is a well-known textbook fact you didn’t invent and still managed to
present incorrectly.

This isn’t an idea — it’s a half-remembered Wikipedia paragraph
pretending to be original insight, and it dies the instant it meets
reality. Stop. Just stop.


I'm going to throw up...







-- 
The Starmaker -- To question the unquestionable, ask the unaskable,
to think the unthinkable, mention the unmentionable, say the unsayable, 
and challenge the unchallengeable.

Back to sci.physics.relativity | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Should we synchronize clocks? Maciej Woźniak <mlwozniak@wp.pl> - 2026-03-29 19:45 +0200
  Re: Should we synchronize clocks? Victo Grzeskiewicz <wtoi@cizk.pl> - 2026-03-29 19:36 +0000
    Re: Should we synchronize clocks? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-03-29 23:40 +0200
      Re: Should we synchronize clocks? Berry Von brandt <yon@daydvyn.de> - 2026-03-29 21:50 +0000
        Re: Should we synchronize clocks? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-03-31 02:47 +0200
      Re: Should we synchronize clocks? The Starmaker <starmaker@ix.netcom.com> - 2026-03-29 16:12 -0700
      Re: Should we synchronize clocks? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-03-30 04:34 +0200
      Re: Should we synchronize clocks? Maciej Woźniak <mlwozniak@wp.pl> - 2026-03-30 06:29 +0200
      Re: Should we synchronize clocks? Winfield Glöckner <rcd@lc.de> - 2026-03-30 21:06 +0000
    Re: Should we synchronize clocks? Thomas Heger <ttt_heg@web.de> - 2026-03-30 08:58 +0200
      Re: Should we synchronize clocks? Maciej Woźniak <mlwozniak@wp.pl> - 2026-03-30 10:14 +0200
        Re: Should we synchronize clocks? Thomas Heger <ttt_heg@web.de> - 2026-03-31 09:14 +0200
          Re: Should we synchronize clocks? Maciej Woźniak <mlwozniak@wp.pl> - 2026-03-31 10:05 +0200
            Re: Should we synchronize clocks? Python <python@cccp.invalid> - 2026-03-31 20:35 +0000
            Re: Should we synchronize clocks? Thomas Heger <ttt_heg@web.de> - 2026-04-01 09:41 +0200
              Re: Should we synchronize clocks? Maciej Woźniak <mlwozniak@wp.pl> - 2026-04-01 10:21 +0200
                Re: Should we synchronize clocks? Thomas Heger <ttt_heg@web.de> - 2026-04-03 09:56 +0200
                Re: Should we synchronize clocks? Maciej Woźniak <mlwozniak@wp.pl> - 2026-04-03 10:08 +0200
      Re: Should we synchronize clocks? Modesto Karameros <dteoo@mmed.gr> - 2026-03-30 21:10 +0000
        Re: Should we synchronize clocks? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-03-30 23:47 +0200
          Re: Should we synchronize clocks? Maciej Woźniak <mlwozniak@wp.pl> - 2026-03-31 07:48 +0200
      Re: Should we synchronize clocks? Python <python@cccp.invalid> - 2026-04-01 19:03 +0000
        Re: Should we synchronize clocks? Thomas Heger <ttt_heg@web.de> - 2026-04-03 10:41 +0200
          Re: Should we synchronize clocks? Python <python@cccp.invalid> - 2026-04-06 19:46 +0000
            Re: Should we synchronize clocks? Thomas Heger <ttt_heg@web.de> - 2026-04-08 09:34 +0200

csiph-web