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

Groups > sci.physics.relativity > #674708

Re: GPS clocks should run Slow Not Fast.

Cross-posted to 2 groups.

Show key headers only | View raw

The Starmaker wrote:
> 
> 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.
> 

A dog thinks, "Hey this is great, they feed me!"





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