On 2013-08-14, Mark C. Stephens <ma...@non-stop.com.au> 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 would have long ago have been sent to > the TIP as waste.
It is however fragile code. Ie, all kinds of situations could arise in which it would give the wrong time. Now, you may say that there are situations in which it will give the right time when, without the kludge, it would give the wrong time. > > It is shame as a society we are being trained to consume. It is a shame that manufacturers get away with delivering defective products whose defects only show up years later. It is like a car designed so that the wheels fall off a year after the warrenty is up. I think we would not tolerate that. > New model phone, got to have it so they queue up outside the shop 2 days > before its released. > Never mind they have a fully functional working phone already! Just got to > have the latest. s> And some people demand that they have the time on their computer to microseconds and buy products to accomplish that, when all they really need is the time to a few seconds. What a waste of resources:-) > We need to start reducing our waste product, > These manufacturers that design equipment to die a month after the warranty > finishes should be put on the wall of shame for a start. Agreed. But this thread is about NOT putting them on the wall of shame, but rather trying to design around their errors. > > But, I digress off subject for this newsgroup... > > I have heard of people in desperation trying to patch the firmware of the > receiver. But along came David with his patch for NTPD and put a lot of us at > rest. That is of course great, except that you and others have to realise that it is kludge which can fail often. EG I believe, if you start up a Raspberry Pi and try to use the GPS to give it a reasonable semblence of the proper time. It has no onboard RTC, and thus always starts up on Jan 1 1970. Of course realising the problems is a way of avoiding them, but if this kludge were made a part of ntpd, most people using it would not realise the problems, and spend days trying to figure out why their machine always reverted to the wrong date. > > Thanks David :) Agreed. > > > --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 > unruh > Sent: Wednesday, 14 August 2013 9:55 PM > To: questions@lists.ntp.org > Subject: Re: Start of new GPS 1024 week epoch > > On 2013-08-14, Mark C. Stephens <ma...@non-stop.com.au> 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----- >> From: questions-bounces+marks=non-stop.com...@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: Start of new GPS 1024 week epoch >> >> Magnus Danielson <mag...@rubidium.dyndns.org> 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 time-nuts. > > 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 detected it when you > bought it. > > >> >> 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); >> >> with >> >> reftime.l_ui += caltontp(&date); >> while (reftime.l_i + 512*7*86400 < rd_timestamp.l_i) >> reftime.l_i += 1024*7*86400; >> >> I'm trying to adjust the timestamp given by NMEA might be slow by some >> multiple of 1024 weeks, and so tries to adjust it so that it is reasonably >> close to the system time associated with the read of the NMEA data. I'm not >> sure if I've got the code exactly bang-on, but it has got ntp running with >> the unit again. > > 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), >> >> David. >> >> _______________________________________________ >> questions mailing list >> questions@lists.ntp.org >> http://lists.ntp.org/listinfo/questions > > _______________________________________________ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
