Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.physics.relativity > #674674

Re: GPS clocks should run Slow Not Fast.

Cross-posted to 2 groups.

Show all headers | View raw

Ross Finlayson wrote:
> 
> On 10/18/2026 04:54 PM, The Starmaker wrote:
> > The Starmaker wrote:
> >>
> >> On Thu, 15 Oct 2026 23:10:51 +0200, "Paul B. Andersen"
> >> <paul.b.andersen@paulba.no> wrote:
> >>
> >>> My article:
> >>> https://paulba.no/pdf/Clock_rate.pdf
> >>
> >> This paper is a half-digested regurgitation of standard GNSS
> >> relativity that collapses under its own sloppy equations, circular
> >> definitions, and amateur-hour presentation.
> >>
> >>      The metric and rate equations are an unreadable train wreck.
> >>      Look at equations (1)–(5), (7), (13)–(18). They arrive as
> >> fragmented garbage: missing operators, broken fractions, undefined
> >> symbols jammed together, and statements like “dt 2GM v² 1 / dt c²r c²”
> >> that no competent reader can parse without reconstructing the entire
> >> derivation from scratch. A paper whose central results cannot be read
> >> without external knowledge is not a paper; it is noise.
> >>      The foundational claim that “SI-clocks per definition always run
> >> at the rate 1 second per second” is pure tautological sludge.
> >>      Section 1.1 asserts this as if it were profound. It is
> >> definitional emptiness. Proper time is what a clock measures;
> >> declaring that an SI-clock therefore ticks at 1 s/s adds zero
> >> information and papers over the entire problem of comparing rates
> >> between different world-lines.
> >>      The derivation of orbital rates relative to UTC is a chain of
> >> uncontrolled approximations sold as precision.
> >>      Equation (5) is declared “a very good approximation” with error
> >> <10?²5; equation (17) claims error <10?¹7. No error budget, no
> >> expansion order, no residual terms from higher multipoles, no
> >> frame-dragging, no solar potential, no tidal contributions. You simply
> >> assert the error and move on. That is not calculation; that is wishful
> >> truncation.
> >>      The GNSS numerical results are presented as original while resting
> >> on incomplete or outdated source data.
> >>      GPS radius is taken from a period of half a sidereal day; GLONASS
> >> oscillates between a 2020 performance standard and a 2008 ICD that the
> >> author himself labels outdated, then notes that Mudrak et al. used the
> >> old number. The paper ends by declaring one geostationary value “the
> >> correct value” with no independent verification. This is not analysis;
> >> it is selective copying.
> >>      Coordinate-time definitions are internally inconsistent and poorly
> >> distinguished.
> >>      Schwarzschild t is defined so that an SI-clock at infinity stays
> >> in sync; UTC is defined so that a stationary SI-clock on the geoid
> >> stays in sync. Then the text repeatedly states that clocks showing
> >> either coordinate are “synchronous in the nonrotating Schwarzschild
> >> coordinate system” while simultaneously acknowledging they are not
> >> synchronous in the rotating Earth-fixed frame. The distinction between
> >> coordinate simultaneity and proper-rate comparison is never cleanly
> >> maintained, leaving the central comparison (dt/dt_utc) floating on
> >> ambiguous foundations.
> >>
> >> You assume the weak-field, slow-motion Schwarzschild metric is
> >> sufficient once the monopole and J2 terms are inserted, with no
> >> residual from higher harmonics, no post-Newtonian corrections beyond
> >> the first order you kept, and no need to transform between the
> >> Earth-centered inertial frame and the actual satellite ephemerides
> >> used by the systems. You assume that declaring an SI-clock independent
> >> of acceleration and temperature magically removes all environmental
> >> sensitivity at the 10?¹7 level you claim. You assume that citing
> >> Wikipedia for TAI and a handful of interface-control documents
> >> constitutes a literature foundation.
> >>
> >> Any competent reviewer or GNSS engineer who opens this PDF will stop
> >> at the first mangled equation block and discard the rest. The people
> >> who actually fly the clocks (GPS Wing, ESA, Roscosmos time
> >> metrologists) already possess cleaner derivations (Ashby’s Living
> >> Review being the obvious one). They have zero incentive to adopt a
> >> document whose equations cannot be typeset legibly and whose numerical
> >> claims require the reader to re-derive everything to trust them.
> >> Regulators and standards bodies will treat this as non-peer-reviewed
> >> noise.
> >>
> >> At the claimed 10?¹7 relative accuracy the paper pretends to reach,
> >> the ignored effects (higher multipoles, Shapiro delay variations,
> >> satellite eccentricity terms, antenna phase-center motion, thermal and
> >> magnetic sensitivity of the actual atomic clocks) already exceed that
> >> floor on operational GNSS satellites. The circular-orbit idealization
> >> breaks the moment real eccentricity appears; the geoid-rate reduction
> >> ignores the full equipotential surface definition used by the IERS.
> >> The numbers therefore cannot be trusted at the precision the text
> >> advertises, and the paper supplies no path to the next significant
> >> digit.
> >>
> >> The entire equation presentation must be discarded and rewritten in
> >> unambiguous, properly typeset form with every intermediate step shown.
> >> The circular “SI-clocks tick at 1 s/s” rhetoric must be deleted. The
> >> error analysis must be replaced by a complete post-Newtonian expansion
> >> with quantified residuals. The source handling for GLONASS and the
> >> geostationary claim must be replaced by primary, current ephemeris
> >> parameters and an independent calculation. The coordinate-time section
> >> must be rewritten so that the distinction between coordinate time and
> >> proper time is surgically clear rather than repeatedly blurred.
> >>
> >>
> >>
> >> This is the intellectual equivalent of serving a half-cooked
> >> Wellington with the raw center still cold and claiming it is a
> >> precision metrology instrument.
> >>
> >> The Swarmaker
> >
> > I heard "Paul B. Andersen" commited suicide after reading his reviews
> > from  the swarm!
> >
> >
> > Let me have a look at Einstein's theory of everything is everything. I
> > think i can fix it up..
> >
> > it might be called 'The Gravity Unified Theory' now...
> >
> > subtitled: 'FUCKING NOTHING TRAVELS FASTER THAN THE SPEED OF
> > LIGHT...while I'm alive.
> >
> 
> You'll be spinning in your grave a long time.


Truth is, he is busy redoing his paper after I pointed out his errors.

There are Math guys who spend years in their attic trying to solve one
equation.

Ai can solve it in a second.


What does that mean? The end of Math guys?...

It means humans need to change their goals..


how about making babies?


You got more time. The pretty wife is alone at home, while her husband
is out to work.

Make babies with her!

May I borrow a cup of sugar?


wham bang thank you mam!


Just like the cavemen times.


Yous will become Ai's pets.

Don't worry, Ai will feed you...


Ai will even take you out for a walk.


You get to see all the other Ai pets.

-- 
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 | Unroll thread

Thread

GPS clocks should run Slow Not Fast. HenryWilson <Hgw@home.com> - 2026-10-12 00:01 +0000
  Re: GPS clocks should run Slow Not Fast. Emanuele Babuh <uh@elbbem.ru> - 2026-10-12 07:40 +0000
  Re: GPS clocks should run Slow Not Fast. "Paul B. Andersen" <paul.b.andersen@paulba.no> - 2026-10-12 20:55 +0200
    Re: GPS clocks should run Slow Not Fast. Maciej Woźniak <mlwozniak@wp.pl> - 2026-10-13 07:30 +0200
      Re: GPS clocks should run Slow Not Fast. Clancy Balanovski <av@sysal.ru> - 2026-10-13 07:07 +0000
    Re: GPS clocks should run Slow Not Fast. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-10-13 10:27 +0200
      Re: GPS clocks should run Slow Not Fast. "Paul B. Andersen" <paul.b.andersen@paulba.no> - 2026-10-13 22:32 +0200
        Re: GPS clocks should run Slow Not Fast. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-10-14 14:20 +0200
          Re: GPS clocks should run Slow Not Fast. "Paul B. Andersen" <paul.b.andersen@paulba.no> - 2026-10-14 21:08 +0200
            Re: GPS clocks should run Slow Not Fast. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-10-14 23:08 +0200
              Re: GPS clocks should run Slow Not Fast. "Paul B. Andersen" <paul.b.andersen@paulba.no> - 2026-10-15 23:10 +0200
                Re: GPS clocks should run Slow Not Fast. The Starmaker <starmaker@ix.netcom.com> - 2026-10-15 22:05 -0700
                Re: GPS clocks should run Slow Not Fast. The Starmaker <starmaker@ix.netcom.com> - 2026-10-18 16:54 -0700
                Re: GPS clocks should run Slow Not Fast. Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-10-19 03:09 -0700
                Re: GPS clocks should run Slow Not Fast. The Starmaker <starmaker@ix.netcom.com> - 2026-10-19 09:50 -0700
                Re: GPS clocks should run Slow Not Fast. The Starmaker <starmaker@ix.netcom.com> - 2026-10-19 23:20 -0700
                Re: GPS clocks should run Slow Not Fast. The Starmaker <starmaker@ix.netcom.com> - 2026-10-21 12:25 -0700
                Re: GPS clocks should run Slow Not Fast. The Starmaker <starmaker@ix.netcom.com> - 2026-10-22 11:34 -0700
                Re: GPS clocks should run Slow Not Fast. The Starmaker <starmaker@ix.netcom.com> - 2026-10-22 12:28 -0700
                Re: GPS clocks should run Slow Not Fast. The Starmaker <starmaker@ix.netcom.com> - 2026-10-22 14:30 -0700
                Re: GPS clocks should run Slow Not Fast. Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-10-22 19:46 -0700
                Re: GPS clocks should run Slow Not Fast. The Starmaker <starmaker@ix.netcom.com> - 2026-10-22 22:14 -0700
    Re: GPS clocks should run Slow Not Fast. HenryWilson <Hgw@home.com> - 2026-10-13 15:20 +0000
      Re: GPS clocks should run Slow Not Fast. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-10-14 14:12 +0200
        Re: GPS clocks should run Slow Not Fast. HenryWilson <Hgw@home.com> - 2026-10-16 10:36 +0000
          Re: GPS clocks should run Slow Not Fast. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-10-19 03:28 +0200
      Re: GPS clocks should run Slow Not Fast. "Paul B. Andersen" <paul.b.andersen@paulba.no> - 2026-10-14 21:07 +0200
        Re: GPS clocks should run Slow Not Fast. Wildo Zhmulev <vedlml@hlhiudlo.ru> - 2026-10-15 07:52 +0000
        Re: GPS clocks should run Slow Not Fast. HenryWilson <Hgw@home.com> - 2026-10-16 10:39 +0000
  Re: GPS clocks should run Slow Not Fast. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-10-13 09:42 +0200
    Re: GPS clocks should run Slow Not Fast. HenryWilson <Hgw@home.com> - 2026-10-13 15:54 +0000
      Re: GPS clocks should run Slow Not Fast. Python <python@cccp.invalid> - 2026-10-13 16:01 +0000
        Re: GPS clocks should run Slow Not Fast. Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-10-13 09:10 -0700
          Re: GPS clocks should run Slow Not Fast. Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-10-14 06:18 -0700
      Re: GPS clocks should run Slow Not Fast. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-10-14 17:30 +0200
        Re: GPS clocks should run Slow Not Fast. Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-10-14 09:32 -0700
  Re: GPS clocks should run Slow Not Fast. Mikko <mikko.levanto@iki.fi> - 2026-10-21 11:04 +0300
    Re: GPS clocks should run Slow Not Fast. Maciej Woźniak <mlwozniak@wp.pl> - 2026-10-21 10:07 +0200
    Re: GPS clocks should run Slow Not Fast. ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-24 20:18 +0000
      Re: GPS clocks should run Slow Not Fast. HenryWilson <Hgw@home.com> - 2026-10-27 11:25 +0000
    Re: GPS clocks should run Slow Not Fast. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-10-27 21:32 +0100
      Re: GPS clocks should run Slow Not Fast. HenryWilson <Hgw@home.com> - 2026-10-27 23:03 +0000
        Re: GPS clocks should run Slow Not Fast. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-10-29 00:47 +0100
          Re: GPS clocks should run Slow Not Fast. HenryWilson <Hgw@home.com> - 2026-10-29 16:41 +0000

csiph-web