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

Groups > sci.physics.relativity > #674629

Re: GPS clocks should run Slow Not Fast.

Show all headers | View raw

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.

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