David is correct - this is why multiple exchanges and satellites are needed to accurately synchronize and then determine location. v
On Mon, Apr 1, 2024 at 8:34 PM David Lang via Starlink < starlink@lists.bufferbloat.net> wrote: > I don't think we are talking about relative motion (which would affect the > radio > frequency) but rather the fact that the time taken for the signal to get > from > the satellite to the ground station will vary depending on the distance > between > the satellite and the ground station, and that distance is changing, so > you > can't compensate for it as easily as you can a fixed path latency. > > David Lang > > On Mon, 1 Apr 2024, Hesham ElBakoury via Starlink wrote: > > > Time from GPS is a one way transmission from the satellites down. The > > relative motion must be accounted for. It is called the Sagnac effect. > > > > On Mon, Apr 1, 2024, 3:22 PM Sebastian Moeller <moell...@gmx.de> wrote: > > > >> Hi Hesham, > >> > >> > >>> On 2. Apr 2024, at 00:04, Hesham ElBakoury <helbako...@gmail.com> > wrote: > >>> > >>> Hi Christian, > >>> The problems is that Satellites move, therefore, the delay between the > >> different directions is different which violates the condition to run > NTP > >> and PTP. > >> > >> But GPS Satellites themselves are not in geostationary oprbit, and still > >> we can get precision time from them... so I would argue that must be a > >> solved problem, no? > >> > >> Regards > >> Sebastian > >> > >>> > >>> Hesham > >>> > >>> On Sat, Mar 2, 2024, 8:19 AM Christian von der Ropp <c...@vdr.net> > >> wrote: > >>> Hi Hesham, > >>> > >>> You do not acquire the time from a LEO satellite but directly from the > >> GPS satellites which carry an atomic clock on board. > >>> I'd not be aware of any LEO providing a GNSS signal but Xona plan such > >> system (although not carrying proper atomic clocks but probably > chip-sized > >> atomic clocks that require frequent syncing with proper atomic clocks): > >>> https://twitter.com/Megaconstellati/status/1708091536439673323 > >>> > >>> There are efforts to build trapped-ion quantum clocks that are expected > >> to become significantly smaller and cheaper than traditional atomic > clocks > >> while as accurate which would make it viable to put an atomic > >> clock-equivalent on small LEO satellites. Once that happens you would > have > >> an independent alternative to the big GNSS birds in MEO but with > stronger > >> signals. I'm told that we are 5-10 years away from such trapped-ion > quantum > >> clocks. > >>> > >>> But for NTP clients, the described method (running a local NTP server > in > >> the satellite terminal synced to GPS) should be good enough. > >>> > >>> Christian > >>> > >>> > >>> Am 2. März 2024 18:02:47 OEZ schrieb Hesham ElBakoury < > >> helbako...@gmail.com>: > >>> Hi Christian, > >>> How you synchronize the time of the satellites in the network? Are you > >> saying each satellite has a master clock? > >>> > >>> Hesham > >>> > >>> On Sat, Mar 2, 2024, 7:38 AM Christian von der Ropp <c...@vdr.net> > >> wrote: > >>> Why not acquire the time directly from by the satellite terminal and > run > >> local NTP servers instead of syncing via the Internet? LEO satellite > >> terminals always have onboard GNSS antennas for geolocation which is > >> necessary to find the satellites, so integrating a local > GNSS-disciplined > >> Stratum-1 NTP server seems trivial to me. > >>> > >>> > >>> Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink < > >> starlink@lists.bufferbloat.net>: > >>> Hi Sebastian, > >>> Can we still use PTP and NTP for time synchronization in Satellite > >> networks or we need new protocols? If we need new protocols, do such > >> protocols exist? > >>> > >>> Thanks > >>> Hesham > >>> > >>> On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moell...@gmx.de> > wrote: > >>> Hi Hesham > >>> > >>>> On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink < > >> starlink@lists.bufferbloat.net> wrote: > >>>> > >>>> Time synchronization, for satellite networks, faces several > challenges: > >>>> 1. Signal Propagation Delays: Unlike terrestrial networks where > >> signals travel through cables at the speed of light, > >>> > >>> [SM] The speed of light in your typical glas fibers (and accidentally > >> the information propagation speed in metallic conductors) comes in > roughly > >> at 2/3 of the speed of light in vacuum, while the speed of light in air > at > >> see level is a mere 90 KM/s slower than in vacuum. > >>> > >>>> satellite communication involves signals traveling vast distances > >> through space. This creates significant delays. > >>> > >>> [SM] Sure distances might be larger, but propagation speed is around > >> 100000Km/s faster... my main point is speed of light is a) dependent on > the > >> medium b) not the things that differentiates space from the earth's > surface > >> here, but mere geometry and larger distances on larger spheres... > >>> > >>>> 2. Clock Drift: Even highly precise atomic clocks, used in satellites, > >> are susceptible to "drift" - gradually losing or gaining time. This > drift, > >> caused by factors like temperature variations, radiation exposure, and > >> power fluctuations, can lead to inconsistencies in timekeeping across > the > >> network. > >>>> 3. Signal Degradation: As signals travel through space, they can > >> degrade due to factors like atmospheric interference, ionospheric > >> disturbances, and solar activity. This degradation can introduce noise > and > >> errors, impacting the accuracy of time synchronization messages. > >>>> 4. Limited Resources: Satellites have limited power and processing > >> capabilities. Implementing complex synchronization protocols can be > >> resource-intensive, requiring careful optimization to minimize their > impact > >> on other functionalities. > >>>> 5. Evolving Technologies: As satellite technologies and applications > >> continue to evolve, new challenges related to synchronization might > emerge. > >> For example, the integration of constellations with thousands of > satellites > >> poses unique synchronization challenges due to the sheer scale and > >> complexity of the network. > >>>> These challenges necessitate the development of robust and efficient > >> time synchronization protocols for satellite networks and an integrated > >> satellite and terrestrial networks > >>>> Are you aware of such time synchronization protocols? > >>>> I would think that using Satellite simulators is the most viable way > >> to develop and test these protocols given that using satellites is not > that > >> easy. > >>>> Thanks > >>>> Hesham > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Starlink mailing list > >>>> Starlink@lists.bufferbloat.net > >>>> https://lists.bufferbloat.net/listinfo/starlink > >>> > >>> -- > >>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > >> gesendet. > >>> -- > >>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > >> gesendet. > >> > >> > >_______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > -- Please send any postal/overnight deliveries to: Vint Cerf Google, LLC 1900 Reston Metro Plaza, 16th Floor Reston, VA 20190 +1 (571) 213 1346 until further notice
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Starlink mailing list Starlink@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/starlink
