Re: [ntp:questions] Start of new GPS 1024 week epoch

On 2013-08-29, John Hasler wrote: > David Taylor writes: >> Ah, OK, but I think gpsd for Windows would get a much better reception >> were it not to require Cygwin to run i.e, just like ntp, use only the >> standard Windows calls. > > From : > "No, we don't support Win

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor writes: > Ah, OK, but I think gpsd for Windows would get a much better reception > were it not to require Cygwin to run i.e, just like ntp, use only the > standard Windows calls. From : "No, we don't support Windows — get a better operating system." esr i

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 29/08/2013 08:21, Rob wrote: [] Sorry... mistake. I mean when compiling *gpsd* for Windows. Looking at the source, gpsd does not have special code for Windows SHM. It could work, when it is compiled with Cygwin. Ah, OK, but I think gpsd for Windows would get a much better reception were i

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor wrote: > On 28/08/2013 13:34, Rob wrote: > [] >> No, I mean when compiling ntpd for Windows. I think that requires Cygwin. > > Not so, it compiles purely with the free MS Visual Studio Express (C++ > branch). It does need the OpenSSL source installed as well, but that > also works

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 28/08/2013 13:34, Rob wrote: [] No, I mean when compiling ntpd for Windows. I think that requires Cygwin. Not so, it compiles purely with the free MS Visual Studio Express (C++ branch). It does need the OpenSSL source installed as well, but that also works with MS VS. No Cygwin needed a

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor wrote: > On 27/08/2013 20:05, Rob wrote: >> Martin Burnicki wrote: >>> What I meant is the usage of CreateFileMapping() and MapViewOfFile() for >>> shared memory segments, as it is done in ntpd's refclock_shm.c. >>> >>> We are using this in the Windows driver package for our PCI card

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 27/08/2013 20:05, Rob wrote: Martin Burnicki wrote: What I meant is the usage of CreateFileMapping() and MapViewOfFile() for shared memory segments, as it is done in ntpd's refclock_shm.c. We are using this in the Windows driver package for our PCI cards, but this usage is not related to NT

Re: [ntp:questions] Start of new GPS 1024 week epoch

Martin Burnicki wrote: > What I meant is the usage of CreateFileMapping() and MapViewOfFile() for > shared memory segments, as it is done in ntpd's refclock_shm.c. > > We are using this in the Windows driver package for our PCI cards, but > this usage is not related to NTP. AFAIK this is support

Re: [ntp:questions] Start of new GPS 1024 week epoch

Rob schrieb: Martin Burnicki wrote: Rob wrote: Martin Burnicki wrote: Extracting some refclock driver code from ntpd, modify it so that it uses the SHM interface instead of ntpd's "native" refclock interface, and putting all this into an own Windows service would be quite some effort. Maybe

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 26/08/2013 17:00, Rob wrote: [] And there were also the days of Windows NT when Windows tried to be a Posix-compatible OS (because that was required to get US Government jobs). So I expected that there would be at least an API for Posix shared memory, a current Windows API, and maybe 2 or 3 b

Re: [ntp:questions] Start of new GPS 1024 week epoch

Martin Burnicki wrote: > Rob wrote: >> Martin Burnicki wrote: >>> Rob wrote: Aha, ok... that is a solution, but I think it is a good idea to draw a new SHM specification that adds a lot of functionality like described in the mailing list article, and make it the prime reference c

Re: [ntp:questions] Start of new GPS 1024 week epoch

Martin Burnicki wrote: > Rob wrote: >> Martin Burnicki wrote: >>> Extracting some refclock driver code from ntpd, modify it so that it >>> uses the SHM interface instead of ntpd's "native" refclock interface, >>> and putting all this into an own Windows service would be quite some effort. >>> >>>

Re: [ntp:questions] Start of new GPS 1024 week epoch

Rob wrote: Martin Burnicki wrote: Rob wrote: Aha, ok... that is a solution, but I think it is a good idea to draw a new SHM specification that adds a lot of functionality like described in the mailing list article, and make it the prime reference clock interface for ntpd. ntpd can then foc

Re: [ntp:questions] Start of new GPS 1024 week epoch

Rob wrote: Martin Burnicki wrote: Extracting some refclock driver code from ntpd, modify it so that it uses the SHM interface instead of ntpd's "native" refclock interface, and putting all this into an own Windows service would be quite some effort. Maybe it would make more sense to try to por

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor wrote: > On 24/08/2013 20:03, Martin Burnicki wrote: [] Usually the SHM segment is fed by some other daemon/service, so if e.g gpsd could be built under Windows as service this could be used to do this. I don't know, though, if gpsd can also be used under Windows. Extracting some r

Re: [ntp:questions] Start of new GPS 1024 week epoch

Martin Burnicki wrote: > Extracting some refclock driver code from ntpd, modify it so that it > uses the SHM interface instead of ntpd's "native" refclock interface, > and putting all this into an own Windows service would be quite some effort. > > Maybe it would make more sense to try to port g

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 24/08/2013 20:03, Martin Burnicki wrote: [] Usually the SHM segment is fed by some other daemon/service, so if e.g gpsd could be built under Windows as service this could be used to do this. I don't know, though, if gpsd can also be used under Windows. Extracting some refclock driver code fro

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor wrote: On 23/08/2013 15:08, Martin Burnicki wrote: [] Indeed. I've just enabled the SHM refclock in the config.h file for Windows, tried to build it with VS2008, and found that it builds after I had fixed a tiny bug, a missing semicolon. However, I have also no idea if it works. D

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 23/08/2013 15:08, Martin Burnicki wrote: [] Indeed. I've just enabled the SHM refclock in the config.h file for Windows, tried to build it with VS2008, and found that it builds after I had fixed a tiny bug, a missing semicolon. However, I have also no idea if it works. David, if you want to

Re: [ntp:questions] Start of new GPS 1024 week epoch

Martin Burnicki wrote: > Rob wrote: > > Aha, ok... that is a solution, but I think it is a good idea to draw >> a new SHM specification that adds a lot of functionality like described >> in the mailing list article, and make it the prime reference clock interface >> for ntpd. ntpd can then foc

Re: [ntp:questions] Start of new GPS 1024 week epoch

Michael Tatarinov wrote: > Yes, SHM driver is commented out but look at refclock_shm.c. The shm refclock supports Windows and it's added over 15 year ago (according to the BitKeeper). ps. I don't know if it works? Indeed. I've just enabled the SHM refclock in the config.h file for Windows, tri

Re: [ntp:questions] Start of new GPS 1024 week epoch

2013/8/23, Martin Burnicki : > David Taylor wrote: >> On 20/08/2013 13:25, Martin Burnicki wrote: >> [] >>> There were 2 fields in the SHM segment which were previously unused and >>> are now used to take the nanoseconds from the refclock and from the >>> system time. >>> >>> Thus programs like gps

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor wrote: On 20/08/2013 13:25, Martin Burnicki wrote: [] There were 2 fields in the SHM segment which were previously unused and are now used to take the nanoseconds from the refclock and from the system time. Thus programs like gpsd can now write the nanoseconds in addition to the mi

Re: [ntp:questions] Start of new GPS 1024 week epoch

Rob wrote: > Aha, ok... that is a solution, but I think it is a good idea to draw a new SHM specification that adds a lot of functionality like described in the mailing list article, and make it the prime reference clock interface for ntpd. ntpd can then focus on the main task: the network su

Re: [ntp:questions] Start of new GPS 1024 week epoch

Martin Burnicki writes: > Harlan Stenn wrote: > > The SHM refclock now supports nanoseconds, as I recall. > > > > And I'd be happy to look at these issues for ntp4-5.0 too. How about a > > bug report that refers to a topic in the Dev web for discussion? > > Done. See: > > Request for a more vers

Re: [ntp:questions] Start of new GPS 1024 week epoch

Michael Tatarinov schrieb: 2013/8/20, Martin Burnicki : Thus programs like gpsd can now write the nanoseconds in addition to the microseconds. If there's an old version of ntpd running then it just evaluates the microseconds, but new versions (ntp-dev for now) check if the nanoseconds fields are

Re: [ntp:questions] Start of new GPS 1024 week epoch

Harlan Stenn wrote: The SHM refclock now supports nanoseconds, as I recall. And I'd be happy to look at these issues for ntp4-5.0 too. How about a bug report that refers to a topic in the Dev web for discussion? Done. See: Request for a more versatile shared memory (SHM) refclock driver http

Re: [ntp:questions] Start of new GPS 1024 week epoch

r > Sent: Tuesday, August 20, 2013 10:49 AM > To: questions@lists.ntp.org > Subject: Re: [ntp:questions] Start of new GPS 1024 week epoch > > On 20/08/2013 13:25, Martin Burnicki wrote: > [] > > There were 2 fields in the SHM segment which were previously unused > and > &g

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 20/08/2013 13:25, Martin Burnicki wrote: [] There were 2 fields in the SHM segment which were previously unused and are now used to take the nanoseconds from the refclock and from the system time. Thus programs like gpsd can now write the nanoseconds in addition to the microseconds. If there'

Re: [ntp:questions] Start of new GPS 1024 week epoch

Martin Burnicki wrote: > Rob wrote: >> Harlan Stenn wrote: >>> Martin Burnicki writes: Rob wrote: > Only the shared memory interface currently has functionality like this, > and it has some limitations in the information it can convey. If this > interface is improved, all the lo

Re: [ntp:questions] Start of new GPS 1024 week epoch

2013/8/20, Martin Burnicki : > Thus programs like gpsd can now write the nanoseconds in addition to the > microseconds. If there's an old version of ntpd running then it just > evaluates the microseconds, but new versions (ntp-dev for now) check if > the nanoseconds fields are filled up and use the

Re: [ntp:questions] Start of new GPS 1024 week epoch

Rob wrote: Harlan Stenn wrote: Martin Burnicki writes: Rob wrote: Only the shared memory interface currently has functionality like this, and it has some limitations in the information it can convey. If this interface is improved, all the local clock drivers can be moved out into separate pr

Re: [ntp:questions] Start of new GPS 1024 week epoch

Harlan Stenn wrote: > Martin Burnicki writes: >> Rob wrote: >> > Only the shared memory interface currently has functionality like this, >> > and it has some limitations in the information it can convey. If this >> > interface is improved, all the local clock drivers can be moved out >> > into se

Re: [ntp:questions] Start of new GPS 1024 week epoch

Martin Burnicki writes: > Rob wrote: > > Only the shared memory interface currently has functionality like this, > > and it has some limitations in the information it can convey. If this > > interface is improved, all the local clock drivers can be moved out > > into separate processes and everyon

Re: [ntp:questions] Start of new GPS 1024 week epoch

Martin Burnicki writes: > unruh wrote: > > On 2013-08-18, Rob wrote: > >> Only the shared memory interface currently has functionality like this, > >> and it has some limitations in the information it can convey. If this > > > > What limitations bother you? > > This one comes to my mind: > https

Re: [ntp:questions] Start of new GPS 1024 week epoch

Martin Burnicki wrote: > Rob wrote: >> Only the shared memory interface currently has functionality like this, >> and it has some limitations in the information it can convey. If this >> interface is improved, all the local clock drivers can be moved out >> into separate processes and everyone ca

Re: [ntp:questions] Start of new GPS 1024 week epoch

Rob wrote: Only the shared memory interface currently has functionality like this, and it has some limitations in the information it can convey. If this interface is improved, all the local clock drivers can be moved out into separate processes and everyone can tinker his driver to fix problems

Re: [ntp:questions] Start of new GPS 1024 week epoch

unruh wrote: On 2013-08-18, Rob wrote: Only the shared memory interface currently has functionality like this, and it has some limitations in the information it can convey. If this What limitations bother you? This one comes to my mind: https://bugs.ntp.org/417 Martin -- Martin Burnicki

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 2013-08-18, Rob wrote: > David Taylor wrote: >> On 18/08/2013 09:19, Magnus Danielson wrote: > > Perhaps the code should be restructured so that the "network time protocol" > remains part of ntpd, and local reference clocks are moved out into > processes that are more loosely coupled than driv

Re: [ntp:questions] Start of new GPS 1024 week epoch

Le 16 août 2013 à 15:34, David Taylor a écrit : > On 16/08/2013 13:02, John Hasler wrote: >> David Taylor writes: >>> A pity that they haven't been able to find two or three spare bits to >>> reduce the 1024 week ambiguity to nearer a half-century or even 100 >>> years. >> >> From the Wikipedia

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 08/18/2013 12:16 PM, Rob wrote: > David Taylor wrote: >> On 18/08/2013 09:19, Magnus Danielson wrote: >> [] >>> If you want this feature to be disabled by default, you end up with >>> causing the disruption that the fix is there to avoid. Few will know >>> that they need to fiddle with that bit

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor wrote: > On 18/08/2013 09:19, Magnus Danielson wrote: > [] >> If you want this feature to be disabled by default, you end up with >> causing the disruption that the fix is there to avoid. Few will know >> that they need to fiddle with that bit, and it becomes a continuous >> support t

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 18/08/2013 09:19, Magnus Danielson wrote: [] If you want this feature to be disabled by default, you end up with causing the disruption that the fix is there to avoid. Few will know that they need to fiddle with that bit, and it becomes a continuous support thing, rather than letting the defau

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 08/18/2013 07:51 AM, David Taylor wrote: > On 17/08/2013 18:31, Magnus Danielson wrote: > [] >> What might be useful is to store the corrected 1024 weeks offsets, since >> if the NTPD is restarted, those corrections can be applied up-front and >> then can these corrected values be used to provid

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 17/08/2013 18:31, Magnus Danielson wrote: [] What might be useful is to store the corrected 1024 weeks offsets, since if the NTPD is restarted, those corrections can be applied up-front and then can these corrected values be used to provide good basis for majority decisions about "correct time

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 08/17/2013 06:02 PM, David Taylor wrote: > On 17/08/2013 09:30, Terje Mathisen wrote: >> David Taylor wrote: > [] >>> Thanks for the pointers to the documents. A pity that they haven't >>> been >>> able to find two or three spare bits to reduce the 1024 week ambiguity >>> to nearer a half-centu

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 17/08/2013 09:30, Terje Mathisen wrote: David Taylor wrote: [] Thanks for the pointers to the documents. A pity that they haven't been able to find two or three spare bits to reduce the 1024 week ambiguity to nearer a half-century or even 100 years. Oh, well! That would be even worse: E

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor wrote: On 16/08/2013 08:12, Magnus Danielson wrote: Using ICD-GPS-200D gives a fair idea of what the older GPS receivers was designed to meet. In these documents, the "gears" of GPS is explained such that you should be able to implement a correctly working receiver (in principle).

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 08/16/2013 03:34 PM, David Taylor wrote: > On 16/08/2013 13:02, John Hasler wrote: >> David Taylor writes: >>> A pity that they haven't been able to find two or three spare bits to >>> reduce the 1024 week ambiguity to nearer a half-century or even 100 >>> years. >> >> From the Wikipedia articl

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 08/16/2013 10:36 AM, David Taylor wrote: > > Yes, all my receivers are very simple, consumer-level ones. Sometimes > I see as low as 2m "location accuracy" on the GPS 60 CSx, more likely > 3m when walking. > > Thanks for the pointers to the documents. A pity that they haven't > been able to fi

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 16/08/2013 13:02, John Hasler wrote: David Taylor writes: A pity that they haven't been able to find two or three spare bits to reduce the 1024 week ambiguity to nearer a half-century or even 100 years. From the Wikipedia article: To determine the current Gregorian date, a GPS receiver mu

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor writes: > A pity that they haven't been able to find two or three spare bits to > reduce the 1024 week ambiguity to nearer a half-century or even 100 > years. >From the Wikipedia article: To determine the current Gregorian date, a GPS receiver must be provided with the approximat

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 16/08/2013 08:12, Magnus Danielson wrote: [] If you go here: http://www.gps.gov/technical/icwg/ you will find IS-GPS-200G (which is the new name since 2006, I have failed to adapt) on this link here: http://www.gps.gov/technical/icwg/IS-GPS-200G.pdf Using ICD-GPS-200D gives a fair idea of wh

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 08/15/2013 11:02 PM, unruh wrote: > On 2013-08-15, Magnus Danielson wrote: >> On 08/15/2013 10:22 AM, David Taylor wrote: >>> On 15/08/2013 08:34, Rob wrote: David Taylor wrote: > On 14/08/2013 17:44, Rob wrote: > [] >> How does a "good" receiver know the correct time? Does i

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 08/16/2013 05:44 AM, David Taylor wrote: > On 15/08/2013 21:33, Magnus Danielson wrote: > [] >> They completely avoid it by not numbering it that way. They have their >> own numbering scheme that fit's the system, and the conversion over to >> UTC is an added feature. It's all in ICD-GPS-200 for

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 15/08/2013 21:33, Magnus Danielson wrote: [] They completely avoid it by not numbering it that way. They have their own numbering scheme that fit's the system, and the conversion over to UTC is an added feature. It's all in ICD-GPS-200 for the current set of details, and in the ION red book se

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 15/08/2013 20:18, Magnus Danielson wrote: [] I do not mention a 500 week period. I mention a 1024 week period with various phases, 500, 512 and obviously 729 (wrapped this Sunday as we went into week 1753). OK, swap period with phase. Judging by some reports here, people may be using NTP m

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 2013-08-15, Magnus Danielson wrote: > On 08/15/2013 10:22 AM, David Taylor wrote: >> On 15/08/2013 08:34, Rob wrote: >>> David Taylor wrote: On 14/08/2013 17:44, Rob wrote: [] > How does a "good" receiver know the correct time? Does it rely on > local (backed-up) storage, or

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 08/15/2013 10:22 AM, David Taylor wrote: > On 15/08/2013 08:34, Rob wrote: >> David Taylor wrote: >>> On 14/08/2013 17:44, Rob wrote: >>> [] How does a "good" receiver know the correct time? Does it rely on local (backed-up) storage, or is there some way of receiving it via the

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 08/15/2013 07:55 AM, David Taylor wrote: > On 14/08/2013 22:07, Harlan Stenn wrote: >> David Malone writes: >>> Indeed - you need to have a timestamp within about ten years of >>> correct before you start up, otherwise the problem will be worse. Ntp >>> has the same problem in figuring out the

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor wrote: > On 15/08/2013 08:34, Rob wrote: >> David Taylor wrote: >>> On 14/08/2013 17:44, Rob wrote: >>> [] How does a "good" receiver know the correct time? Does it rely on local (backed-up) storage, or is there some way of receiving it via the almanac? Or are "good"

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 15/08/2013 08:34, Rob wrote: David Taylor wrote: On 14/08/2013 17:44, Rob wrote: [] How does a "good" receiver know the correct time? Does it rely on local (backed-up) storage, or is there some way of receiving it via the almanac? Or are "good" receivers hardwired as well, only with a dif

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 15/08/2013 08:27, Rob wrote: The file is /etc/fake-hwclock.data It is set by the command "fake-hwclock save" which is in /etc/cron.hourly/fake-hwclock and in /etc/init.d/fake-hwclock which is called in the startup and shutdown sequence. Thanks, Rob, and my apologies for a finger slip misspel

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor wrote: > On 14/08/2013 21:20, Rob wrote: > [] >> The raspberry pi already does that. It regularly (and on shutdown) >> saves the date/time in a file and loads that on boot. >> >> No need to handle this in ntpd. it is done in the /etc/init.d scripts. > > Thanks, Rib, I didn't know th

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor wrote: > On 14/08/2013 17:44, Rob wrote: > [] >> How does a "good" receiver know the correct time? Does it rely on >> local (backed-up) storage, or is there some way of receiving it via >> the almanac? Or are "good" receivers hardwired as well, only with >> a different valid span? >

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 14/08/2013 17:44, Rob wrote: [] How does a "good" receiver know the correct time? Does it rely on local (backed-up) storage, or is there some way of receiving it via the almanac? Or are "good" receivers hardwired as well, only with a different valid span? I would not be surprised when "good

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 14/08/2013 22:07, Harlan Stenn wrote: David Malone writes: Indeed - you need to have a timestamp within about ten years of correct before you start up, otherwise the problem will be worse. Ntp has the same problem in figuring out the ntp epoch, though we've yet to see an ntp timestamp wrap a

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 14/08/2013 21:20, Rob wrote: [] The raspberry pi already does that. It regularly (and on shutdown) saves the date/time in a file and loads that on boot. No need to handle this in ntpd. it is done in the /etc/init.d scripts. Thanks, Rib, I didn't know that. Do you happen to know which fil

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 08/14/2013 06:21 PM, David Taylor wrote: > On 14/08/2013 17:14, David Malone wrote: > [] >> Possibly - this was a handy timestamp to use, but there may be a >> better choice. It's also possible that this should be an optional >> flag to the driver, so that people with perfectly good GPS units >>

Re: [ntp:questions] Start of new GPS 1024 week epoch

Hi, On 08/14/2013 03:54 PM, unruh wrote: > On 2013-08-14, Mark C. Stephens wrote: >> Um Let's see, Datum was bought by Austron, who was bought by ... etc. >> For collectors such as myself, having this 'mature' equipment still working >> is great. >> >> Looking at Mr Malone's code, he added 2 lin

Re: [ntp:questions] Start of new GPS 1024 week epoch

Harlan Stenn wrote:> ntp-dev has a fix for this problem - while the original > solution was "make sure the clock is correct to within > ~65 years' time" the new code uses a "date of compile" value, > and needs the system time to be either 10 years' before > that date or up to 128 years' after t

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Malone writes: > Indeed - you need to have a timestamp within about ten years of > correct before you start up, otherwise the problem will be worse. Ntp > has the same problem in figuring out the ntp epoch, though we've yet > to see an ntp timestamp wrap around. ntp-dev has a fix for this p

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor wrote: > On 14/08/2013 12:54, unruh wrote: > [] >> Except of course if the rd_timestamp.l_i is way out (that is why one >> would want to use a gps clock to fix it-- eg on bootup with the >> Raspberry Pi say), > [] > > Could you not use something like the timestamp of some file (e.g. t

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 2013-08-14, David Taylor wrote: > On 14/08/2013 12:54, unruh wrote: > [] >> Except of course if the rd_timestamp.l_i is way out (that is why one >> would want to use a gps clock to fix it-- eg on bootup with the >> Raspberry Pi say), > [] > > Could you not use something like the timestamp of so

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor wrote: > On 14/08/2013 17:14, David Malone wrote: > [] >> Possibly - this was a handy timestamp to use, but there may be a >> better choice. It's also possible that this should be an optional >> flag to the driver, so that people with perfectly good GPS units >> won't ever trip over t

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 14/08/2013 17:14, David Malone wrote: [] Possibly - this was a handy timestamp to use, but there may be a better choice. It's also possible that this should be an optional flag to the driver, so that people with perfectly good GPS units won't ever trip over the code ;-) David. Yes,

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor writes: >Could you not use something like the timestamp of some file (e.g. the >drift file) or other system file to get the approximate year? I haven't >studied the code (I find C not easy to read or navigate) so perhaps it >already does this. Then you would only need to set the

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 14/08/2013 12:54, unruh wrote: [] Except of course if the rd_timestamp.l_i is way out (that is why one would want to use a gps clock to fix it-- eg on bootup with the Raspberry Pi say), [] Could you not use something like the timestamp of some file (e.g. the drift file) or other system file

Re: [ntp:questions] Start of new GPS 1024 week epoch

Mark C. Stephens wrote: > Um Let's see, Datum was bought by Austron, who was bought by ... etc. > For collectors such as myself, having this 'mature' equipment still working > is great. > > Looking at Mr Malone's code, he added 2 lines which enabled NTPD > compatibility with GPS receivers that w

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 2013-08-14, David Malone wrote: > unruh writes: > >>Surely if the receiver is delivering the wrong date, it is the receiver >>manufacturer that needs to make the changes, not ntp, including sending >>you a new receiver if necessary. Warrenty limits notwithstanding, this >>fails that "fitness f

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 2013-08-14, Mark C. Stephens wrote: > Um Let's see, Datum was bought by Austron, who was bought by ... etc. > For collectors such as myself, having this 'mature' equipment still working > is great. > > Looking at Mr Malone's code, he added 2 lines which enabled NTPD > compatibility with GPS r

Re: [ntp:questions] Start of new GPS 1024 week epoch

unruh writes: >Surely if the receiver is delivering the wrong date, it is the receiver >manufacturer that needs to make the changes, not ntp, including sending >you a new receiver if necessary. Warrenty limits notwithstanding, this >fails that "fitness for purpose" test, and you could hardly have

Re: [ntp:questions] Start of new GPS 1024 week epoch

August 2013 9:55 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Start of new GPS 1024 week epoch On 2013-08-14, Mark C. Stephens wrote: > Good on you David and welcome back to 2013. > I do hope that some official changes are made to refclock_nmea to catch this > receiver b

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 2013-08-14, Mark C. Stephens wrote: > Good on you David and welcome back to 2013. > I do hope that some official changes are made to refclock_nmea to catch this > receiver bug and process it accordingly. > There are a lot of folks stranded in 1993. > > --marki > > -Original Message- >

Re: [ntp:questions] Start of new GPS 1024 week epoch

Terje Mathisen <"terje.mathisen at tmsw.no"> writes: >Nice! >You've replaced the 1024-week epoch with a +/- 512-week window around >the "current" time. :-) Indeed - ntp already sort of has to do a similar, because the timestamps are mod 2^32 seconds from 1900, so using a trick like this is only

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Malone wrote: It seems my ancient GPSclock 200 has recently slipped back to December 1993 too. Resetting it hasn't helped and I doubt I will be able to do a firmware update, so I've made a hack to refclock_nmea.c (version ntp-4.2.6p5), by replacing: reftime.l_ui += caltontp(&date)

Re: [ntp:questions] Start of new GPS 1024 week epoch

...@lists.ntp.org [mailto:questions-bounces+marks=non-stop.com...@lists.ntp.org] On Behalf Of David Malone Sent: Wednesday, 14 August 2013 5:30 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Start of new GPS 1024 week epoch Magnus Danielson writes: >Remember that any Sunday, it is likely tha

Re: [ntp:questions] Start of new GPS 1024 week epoch

Magnus Danielson writes: >Remember that any Sunday, it is likely that a GPS reciever have slipped >a multiple of 1024 weeks. NTP drivers should be able to recognice it and >compensate for it, as it is a re-occuring bug in many recievers. >This issue have been discussed over and over again at tim

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 2013-08-11 00:44, David Taylor wrote: Today is the start of a new GPS 1024 week epoch - see: http://adn.agi.com/GNSSWeb/ Folks with really old GPS units are reporting problems, those of us with current millennium GPS receivers should be OK, though. You must have been looking at 1999! Ab

Re: [ntp:questions] Start of new GPS 1024 week epoch

Hi again, On 08/11/2013 03:36 PM, Magnus Danielson wrote: > Hi David, > > On 08/11/2013 08:44 AM, David Taylor wrote: >> Today is the start of a new GPS 1024 week epoch - see: >> >> http://adn.agi.com/GNSSWeb/ >> >> Folks with really old GPS units are reporting problems, those of us >> with curr

Re: [ntp:questions] Start of new GPS 1024 week epoch

Hi David, On 08/11/2013 08:44 AM, David Taylor wrote: > Today is the start of a new GPS 1024 week epoch - see: > > http://adn.agi.com/GNSSWeb/ > > Folks with really old GPS units are reporting problems, those of us > with current millennium GPS receivers should be OK, though. I would word it dif

Re: [ntp:questions] Start of new GPS 1024 week epoch

A C wrote: > On 8/10/2013 23:44, David Taylor wrote: >> Today is the start of a new GPS 1024 week epoch - see: >> >>http://adn.agi.com/GNSSWeb/ >> >> Folks with really old GPS units are reporting problems, those of us with >> current millennium GPS receivers should be OK, though. > > I must no

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 11/08/2013 11:33, Martin Burnicki wrote: [] That page also says today's week number in the current epoch is 729, not 0, and the absolute week number is 1753=129+1024, which matches what I see on our GPS receivers. David, maybe you have misread something? Martin -- Martin Burnicki Meinberg F

Re: [ntp:questions] Start of new GPS 1024 week epoch

Martin Burnicki wrote: David Taylor wrote: Today is the start of a new GPS 1024 week epoch - see: http://adn.agi.com/GNSSWeb/ That page also says today's week number in the current epoch is 729, not 0, and the absolute week number is 1753=129+1024, which matches what I see on our GPS rec

Re: [ntp:questions] Start of new GPS 1024 week epoch

David Taylor wrote: Today is the start of a new GPS 1024 week epoch - see: http://adn.agi.com/GNSSWeb/ Folks with really old GPS units are reporting problems, those of us with current millennium GPS receivers should be OK, though. I doubt this is correct. GPS week 0 was in January 1980, a

Re: [ntp:questions] Start of new GPS 1024 week epoch

...@blueyonder.co.uk; questions@lists.ntp.org Subject: Re: [ntp:questions] Start of new GPS 1024 week epoch I have 2 GPS down, a Z3815A and a HP 58534A. Both are rolled back to Dec 12, 1993. Nothing I do will get them on the right year. Once they see a bird, they rollback to 1993. Of interest is they

Re: [ntp:questions] Start of new GPS 1024 week epoch

, ouch.. --marki -Original Message- From: questions-bounces+marks=non-stop.com...@lists.ntp.org [mailto:questions-bounces+marks=non-stop.com...@lists.ntp.org] On Behalf Of David Taylor Sent: Sunday, 11 August 2013 4:45 PM To: questions@lists.ntp.org Subject: [ntp:questions] Start of new

Re: [ntp:questions] Start of new GPS 1024 week epoch

On 8/10/2013 23:44, David Taylor wrote: Today is the start of a new GPS 1024 week epoch - see: http://adn.agi.com/GNSSWeb/ Folks with really old GPS units are reporting problems, those of us with current millennium GPS receivers should be OK, though. I must not be reading the page correctl

[ntp:questions] Start of new GPS 1024 week epoch

Today is the start of a new GPS 1024 week epoch - see: http://adn.agi.com/GNSSWeb/ Folks with really old GPS units are reporting problems, those of us with current millennium GPS receivers should be OK, though. -- Cheers, David Web: http://www.satsignal.eu __