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

Groups > sci.physics.relativity > #674843

Re: GPS clocks should run Slow Not Fast.

Cross-posted to 2 groups.

Show all headers | View raw

The Starmaker wrote:
> 
> On Mon, 19 Oct 2026 03:09:50 -0700, Ross Finlayson
> <ross.a.finlayson@gmail.com> 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.
> >
> 
> I can do 'a little simple prompting' and I can solve this thing you
> call...The Theory of Everything.


with 'a little simple prompting' i can solve all your math problems. No
need for
yous to go to math skool anymore. with 'a little simple prompting' i can
crack the
mysteries of the universe.   


Your world is changing right before your very eyes now.

i have all the knowledge i need.

i have all the 'knowledge' i need.

i have all the *knowledge* i need.









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