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

Groups > sci.physics.relativity > #674859

Re: GPS clocks should run Slow Not Fast.

Cross-posted to 2 groups.

Show key headers only | View raw

Ross Finlayson wrote:
> 
> On 10/22/2026 12:28 PM, The Starmaker wrote:
> > The Starmaker wrote:
> >>
> >> 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.
> >>
> >
> >
> >
> > Ai is built incorectly. It needs to be rebuilt from the bottom up.
> >
> > It needs to be fed only pictures, no words or numbers.
> >
> > Just show a picture of Mars (without using the word Mars) and ask Ai,
> >
> > Prompt: What do you see?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> Don't be quoting me and not quoting me.
> 
> Though, I guess after Starmaker had the "over my dead body"
> there was my "You'll be spinning in your grave a long time."
> 
> Clocks either slow or meet, there are a variety of
> natural clocks, micro and macro and macro again and meso, scales,
> that's what Einstein needs is more timebases for clocks and
> less inaccurate pocketwatches.
> 
> Einstein is pretty remarkable as a grandiose hedge,
> meaning that his summary or final word from
> "Out of My Later Years" says quite a bit less
> than usual given accounts, while distinguishing
> the linear and rotational after distinguishing
> the "spatial" and "spacial" and making for the
> L-principle that RoS is non-local, that SR is local.
> 
> Most people don't get that, yet, many do.


You seem to say everything and nothing at the same time...





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