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

Groups > sci.physics.relativity > #674845

Re: GPS clocks should run Slow Not Fast.

Cross-posted to 2 groups.

Show all headers | View raw

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?










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