Hello!!
I have time jumps made by ntpd because gpsd sometimes puts wrong data to SHM
because of wrong data from gps receiver(very bad chips)
I have only one time source in ntp.conf — 127.127.28.1 with PPS enabled
I want to add another two internet sources for stability but at first i want to
On 2020-06-04, a...@avtodoria.ru wrote:
> Hello!!
>
> I have time jumps made by ntpd because gpsd sometimes puts wrong data to SHM
> because of wrong data from gps receiver(very bad chips)
What is the wrong data? Ie, how much of an offset does the wrong data
imply?
What does wrong data mean? D
On 2020-06-05, a...@avtodoria.ru wrote:
>> This sounds more like bit errors in serial reception.
>> ( i.e errors coming up in all magnitudes.)
>
>> That is reception via NMEA?
>> do you check the NMEA checksum ( Portion after * afair)?
>
> Thank you for response. Yes, that is reception via NMEA. N
пятница, 5 июня 2020 г., 10:04:44 UTC+3 пользователь William Unruh написал:
> On 2020-06-05, a...@avtodoria.ru wrote:
> >> This sounds more like bit errors in serial reception.
> >> ( i.e errors coming up in all magnitudes.)
> >
> >> That is reception via NMEA?
> >> do you check the NMEA checksum
> This sounds more like bit errors in serial reception.
> ( i.e errors coming up in all magnitudes.)
> That is reception via NMEA?
> do you check the NMEA checksum ( Portion after * afair)?
Thank you for response. Yes, that is reception via NMEA. No i didn't check
checksum, i think gpsd should c
Am 05.06.2020 um 08:36 schrieb a...@avtodoria.ru:
This sounds more like bit errors in serial reception.
( i.e errors coming up in all magnitudes.)
That is reception via NMEA?
do you check the NMEA checksum ( Portion after * afair)?
Thank you for response. Yes, that is reception via NMEA. No
> What is the wrong data? Ie, how much of an offset does the wrong data
> imply?
> What does wrong data mean? Do you mean that the PPS is wrong? that of
> course has no time attached so can be wrong by only up to 1 second.
> Or do you mean that the time reported by the NMEA sentences is wrong?
> Ho
Am 05.06.2020 um 00:10 schrieb a...@avtodoria.ru:
The typical
behaviour in case of time jump is that suddenly we have time in
gpspipe jumped forth or back for [some seconds - some years].
This sounds more like bit errors in serial reception.
( i.e errors coming up in all magnitudes.)
That is r
пятница, 5 июня 2020 г., 10:25:24 UTC+3 пользователь Uwe Klein написал:
> Am 05.06.2020 um 08:36 schrieb ah@***.ru:
> >> This sounds more like bit errors in serial reception.
> >> ( i.e errors coming up in all magnitudes.)
> >
> >> That is reception via NMEA?
> >> do you check the NMEA checksum ( P
Am 05.06.2020 um 09:53 schrieb ah@***.ru:
пятница, 5 июня 2020 г., 10:25:24 UTC+3 пользователь Uwe Klein написал:
Am 05.06.2020 um 08:36 schrieb ah@***.ru:
This sounds more like bit errors in serial reception.
( i.e errors coming up in all magnitudes.)
That is reception via NMEA?
do you chec
On 6/4/20 9:15 PM, a...@avtodoria.ru wrote:
> Hello!!
>
> I have time jumps made by ntpd because gpsd sometimes puts wrong data to SHM
> because of wrong data from gps receiver(very bad chips)
>
> I have only one time source in ntp.conf — 127.127.28.1 with PPS enabled
>
> I want to add another
On 2020-06-04, a...@avtodoria.ru wrote:
> I want to add two another sources to fullfill the complect of three
> generals)) but at first i want to understand how to cheat ntpd as gpsd
> regularly does. I think i did all i need. But it looks like i did
> something wrong in that test. Ntpd eats my da
On 2020-06-08, a...@avtodoria.ru wrote:
> понедельник, 8 июня 2020 г., 10:52:36 UTC+3 пользователь Miroslav
> Lichvar написал:
>> If you need something to report a large offset to ntpd via SHM, you
>> could try this program for testing leap seconds:
>>
>> https://github.com/mlichvar/leapshm
> Th
I monitor many NTP servers and have observed off-by-N second errors (N
often 1, 2, 3) for years. Some of these errors are understood: fuzzing
errors in ntpd, late NMEA arrival times. But many of these errors have
unknown causes. These errors can recur on a given server with the same
offset. On
Yo Steven!
On Mon, 8 Jun 2020 17:06:55 -0500
Steven Sommars wrote:
> The off by N-second errors are often seen soon after NTP server
> initialization.
This is common to all GPS based NTP servers. It is distinct from
long lasting off-by one errors that one version of gpsd could fall
victimm to.
Gary,
Sounds sort of plausible. However if the GPS doesn't have the almanac, how
can it get a fix?If this is a known issue, shouldn't the GPS delay
sending validity="A" or otherwise signal that the UTC offset may be
incorrect?
This should be reproducible, correct? What kind of reset will ca
Yo Steven!
On Mon, 8 Jun 2020 18:48:02 -0500
Steven Sommars wrote:
> Sounds sort of plausible. However if the GPS doesn't have the
> almanac, how can it get a fix?
A GPS never uses the Almanac to compute a fix. A GPS uses the
Ephemeris to compute a fix. Each satellite sends its own
Ephemeris
On 2020-06-08, a...@avtodoria.ru wrote:
> Currently i'm looking at ntp sources. as i said i have read data from
> SHM at June 4th, now i'm trying to write them into SHM. What i see in
> ntpq output:
...
> You can see reftime is June 4th, but nevertheless offset is small. How
> does it work? When i
18 matches
Mail list logo