Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
descoubes kirjoitti: I am very pleased to inform you that the 1995 year bug on the TS2100 has been solved. You will have to replace the existing Trimble ACE III > GPS receiver by our N024 with special firmware. Does this also correct the 1 sec offset caused by upcoming leap second? To remind, TS2100 GPS mode failed already in February, having 1 sec offset right after the information about upcoming leap second was added. How can we know that it doesn't fail again when actual GPS week rollover will happen? Now it seems to be week 1846 and 2047 will come less than four years. Did you test this with GPS simulator? Best regards, -- 73s! Esa OH4KJU ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
Hello all, I am very pleased to inform you that the 1995 year bug on the TS2100 has been solved. You will have to replace the existing Trimble ACE III GPS receiver by our N024 with special firmware. If you wish to purchase it, just inform me how many units you will need, and also your shipping address for cost calculation. Best regards Olivier HEOL DESIGN ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
descoubes kirjoitti: I am working for HEOL DESIGN company, and we are currently investigating this TS2100 1995 bug. We have developped the N024, a clone of Trimble ACE III receiver (which is mounted inside the TS2100). They are many issues with the TS2100-ACE III internal protocol, and we have good hopes to solve it out by N024 software. Thanks for the information. Of course it would be nice to get the internal GPS working too. I was planning that rude solution could be to cut off the GPS serial port lines and use only it's PPS output so that TS2100 sees it as external PPS. This would require changes to TS2100 motherboard (PPS should be routed so that it's feeded to Ext_PPS input). That hack would throw away anything else than PPS but will keep the unit in time as long there's no interruption on GPS reception. Of course this means that the time, leap second data etc. must be set manually (like now) but the worst thing is that there would be no way to see any GPS status anymore. If it loses signal, there will be absolutely no indication. Another solution could be like this, but with added microcontoller. Also in this solution only the PPS is routed to TS2100 directly. GPS serial port would be routed to microcontroller instead. Microcontroller would handle the GPS time decoding and follow TS2100's time from IRIG-B signal. If it notices that TS2100 time is gone wrong, it could correct the time and leap second settingc etc. by using TS2100 console serial port. If TS2100 follows PPS correctly, this should only happen in the startup. This would bring back the automatic time setting but this requires very much work. Also in this solution the main trouble is the loss of GPS status. To fix this, iw could be possible to share the TS2100 LCD display so that also TS2100 LCD port is routed thru the microcontroller, which could alter the LCD data from TS2100 before sending it to LCD. In the main display the 2nd line of LCD shows always "Datum Tymserve 2100", which is kind of useless information. So the microcontroller could filter that away and write the GPS status there. TS2100 LCD looks like standard "HD44780" and it would not impossible to capture the data, alter it and send to display. Best regards, -- 73s! Esa OH4KJU ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
Esa Heikkinen writes: > > Andrew Cooper kirjoitti: > > > We also ran into the TS2100 1995 bug this weekend. > > For us the consequences are a bit more severe... > > So this is happening already.. Didn't notice this because have been > using PPS from Thunderbolt to keep the TS2100 in time. It failed with > leap second already in February (if I remember correctly) so I think if > you have same firmware than I have (the most recent one) you have > already got 1 second offset from real UTC since February. > > However, with PPS everything is fine. The unit is not rebooted after > February (when removing the inegrated GPS unit) and it's in time. > > However that's not only bugs TS2100 has. I'm currently creating my own > IRIG-B decoder and noticed that there's something strange going on with > IEEE1344 checksums. The checksum will fail with random hours and beign > ok on others. Seems that hour number is not included in the checksum or > something. But that's another story... > Hi everybody, I am working for HEOL DESIGN company, and we are currently investigating this TS2100 1995 bug. We have developped the N024, a clone of Trimble ACE III receiver (which is mounted inside the TS2100). They are many issues with the TS2100-ACE III internal protocol, and we have good hopes to solve it out by N024 software. I will keep people informed when this bug will be solved, on the Heol Design N024 web page. Then you will be able to purchase it. Regards ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
Hi The only definitive statement I have seen for implementation of the 13 bit week is that it will be part of the Block III deployment process. Anything going on now is “testing only”. Block III now looks like a 2017 sort of thing. There may be people out there with fancy simulators that are 100% perfect. They *could* have coded and tested a 13 bit solution a few years ago. My observation is that *very* few people do this. The normal approach seems to be to wait until there are on the air signals and then test against them. That way you can cope with any odd last minute adjustments in the transmitted format. Bob > On May 10, 2015, at 8:26 PM, Henry Hallam wrote: > > Is the 13-bit week number somewhere in the L1 C/A message? I see it in > the CNAV definition for broadcast on L2C and L5 (and eventually, with > GPS III, L1C), but I don't see any indication of a 13-bit week number > in the LNAV section of IS-GPS-200H. So as far as I can tell, it is > not being and will not be broadcast on L1 any time soon. Please > correct me if I'm wrong :) > > Henry > > On Sat, May 9, 2015 at 1:14 PM, Bob Camp wrote: >> Hi >> >> As far as I can see, the 13 bit week stuff is still very much in the >> “testing” phase. I’d say that counting >> on it working on anything made before 2013 is a bit of a stretch. I would >> also bet that roughly 90% of the >> “current” timing GPS chip set designs do not yet fully support it. That >> might change with a firmware upgrade >> (if one ever comes out for your chip set etc.). Based on how well things >> like leap years seem to get taken >> care of, we’ll really only know in 20 years or so. >> >> Yes it’s a bit confusing, it’s all snarled up in the “block III will be here >> in 2008” ... err…2014 … err …2017 …errr... >> confusion. >> >> Bob >> >>> On May 6, 2015, at 12:04 PM, Brian Inglis >>> wrote: >>> >>> On 2015-05-05 11:32, Alan Ambrose wrote: >>> It's not that simple. First, it's not 20 years, but 1024 weeks (19.6 years). And not UTC weeks (which may have leap seconds) but GPS weeks (which do not, and are always 604800 seconds long). etc >>> Don't think it's _that_ much code though. There's some open source ACM date algorithms, and it would be easy enough to implement a quick and dirty fix, adding a number of days offset, while the rest of the algorithm is tested. >>> >>> See http://www.leapsecond.com/notes/gpswnro.htm >>> This was first noted in 1996 and has been happening since the first rollover >>> in August 1999 so some affected NTP GPS drivers have been patched to add >>> 1024 >>> weeks while the input is more than 512 weeks in the past. >>> Will the next time this problem reoccurs be another 20 years? >>> >>> The next rollover is about April 2019, but this can happen any time an older >>> receiver's internal date representation used for GPS to UTC conversion >>> overflows. >>> Looks like Tymserve 2100 picked about Sep 1995 for its date epoch so it >>> hits now. >>> >>> Newer GPS receivers support the extra 3 bits added to GPS extended week >>> allowing >>> 8192 weeks (157 years) between rollovers - 2137 is the next big rollover >>> problem, >>> but NavStar will likely not be sending the same data on the same frequency >>> then. >>> >>> -- >>> Take care. Thanks, Brian Inglis >>> ___ >>> time-nuts mailing list -- time-nuts@febo.com >>> To unsubscribe, go to >>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >> >> ___ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
Is the 13-bit week number somewhere in the L1 C/A message? I see it in the CNAV definition for broadcast on L2C and L5 (and eventually, with GPS III, L1C), but I don't see any indication of a 13-bit week number in the LNAV section of IS-GPS-200H. So as far as I can tell, it is not being and will not be broadcast on L1 any time soon. Please correct me if I'm wrong :) Henry On Sat, May 9, 2015 at 1:14 PM, Bob Camp wrote: > Hi > > As far as I can see, the 13 bit week stuff is still very much in the > “testing” phase. I’d say that counting > on it working on anything made before 2013 is a bit of a stretch. I would > also bet that roughly 90% of the > “current” timing GPS chip set designs do not yet fully support it. That > might change with a firmware upgrade > (if one ever comes out for your chip set etc.). Based on how well things like > leap years seem to get taken > care of, we’ll really only know in 20 years or so. > > Yes it’s a bit confusing, it’s all snarled up in the “block III will be here > in 2008” ... err…2014 … err …2017 …errr... > confusion. > > Bob > >> On May 6, 2015, at 12:04 PM, Brian Inglis >> wrote: >> >> On 2015-05-05 11:32, Alan Ambrose wrote: >> >>> It's not that simple. First, it's not 20 years, but 1024 weeks (19.6 years). >>> And not UTC weeks (which may have leap seconds) but GPS weeks (which do not, >>> and are always 604800 seconds long). etc >> >>> Don't think it's _that_ much code though. There's some open source ACM date >>> algorithms, and it would be easy enough to implement a quick and dirty fix, >>> adding a number of days offset, while the rest of the algorithm is tested. >> >> See http://www.leapsecond.com/notes/gpswnro.htm >> This was first noted in 1996 and has been happening since the first rollover >> in August 1999 so some affected NTP GPS drivers have been patched to add 1024 >> weeks while the input is more than 512 weeks in the past. >> >>> Will the next time this problem reoccurs be another 20 years? >> >> The next rollover is about April 2019, but this can happen any time an older >> receiver's internal date representation used for GPS to UTC conversion >> overflows. >> Looks like Tymserve 2100 picked about Sep 1995 for its date epoch so it hits >> now. >> >> Newer GPS receivers support the extra 3 bits added to GPS extended week >> allowing >> 8192 weeks (157 years) between rollovers - 2137 is the next big rollover >> problem, >> but NavStar will likely not be sending the same data on the same frequency >> then. >> >> -- >> Take care. Thanks, Brian Inglis >> ___ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
Hi As far as I can see, the 13 bit week stuff is still very much in the “testing” phase. I’d say that counting on it working on anything made before 2013 is a bit of a stretch. I would also bet that roughly 90% of the “current” timing GPS chip set designs do not yet fully support it. That might change with a firmware upgrade (if one ever comes out for your chip set etc.). Based on how well things like leap years seem to get taken care of, we’ll really only know in 20 years or so. Yes it’s a bit confusing, it’s all snarled up in the “block III will be here in 2008” ... err…2014 … err …2017 …errr... confusion. Bob > On May 6, 2015, at 12:04 PM, Brian Inglis > wrote: > > On 2015-05-05 11:32, Alan Ambrose wrote: > >> It's not that simple. First, it's not 20 years, but 1024 weeks (19.6 years). >> And not UTC weeks (which may have leap seconds) but GPS weeks (which do not, >> and are always 604800 seconds long). etc > >> Don't think it's _that_ much code though. There's some open source ACM date >> algorithms, and it would be easy enough to implement a quick and dirty fix, >> adding a number of days offset, while the rest of the algorithm is tested. > > See http://www.leapsecond.com/notes/gpswnro.htm > This was first noted in 1996 and has been happening since the first rollover > in August 1999 so some affected NTP GPS drivers have been patched to add 1024 > weeks while the input is more than 512 weeks in the past. > >> Will the next time this problem reoccurs be another 20 years? > > The next rollover is about April 2019, but this can happen any time an older > receiver's internal date representation used for GPS to UTC conversion > overflows. > Looks like Tymserve 2100 picked about Sep 1995 for its date epoch so it hits > now. > > Newer GPS receivers support the extra 3 bits added to GPS extended week > allowing > 8192 weeks (157 years) between rollovers - 2137 is the next big rollover > problem, > but NavStar will likely not be sending the same data on the same frequency > then. > > -- > Take care. Thanks, Brian Inglis > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
Brian Inglis wrote: The next rollover is about April 2019, but this can happen any time an older receiver's internal date representation used for GPS to UTC conversion overflows. Looks like Tymserve 2100 picked about Sep 1995 for its date epoch so it hits now. Newer GPS receivers support the extra 3 bits added to GPS extended week allowing 8192 weeks (157 years) between rollovers - 2137 is the next big rollover problem, but NavStar will likely not be sending the same data on the same frequency then. There are also GPS receivers out there which use (and have been using) an extended week number internally instead of hardcoded limit for the 10 bit week number. As long as there's a backup battery is OK then there's nothing to do for the user to get the correct epoch. If the backup battery is disconnected or fails then you can just send the current date to the device, and the firmware computes the extended week number, including the epoch of the GPS week number. Martin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
> Good, you understand my point. You need "external information" and "That > won't solve the problem forever" and oh, well, yeah, duh, just "rebuild and > reinstall the fixup software" anytime there's trouble in the future. > To me this is replacing a broken GPS receiver algorithm with a broken > Arduino hack. You're not solving anything except pushing a problem to the > next unsuspecting user or customer. Worse yet, now instead of being part of > a group of N people sharing the same TymServe problem, you are a group of 1 > with both a TymServe problem and an Arduino problem. I think I agree with everything you said, but we didn't establish the context before we started this discussion. I was probably assuming a different environment that you were. There is a big difference between a time-nut with more time than money trying to get a few more years out of some well-loved legacy gear and the IT staff for a major bank or stock market. There is probably an intermediate case of places like a telescope. They have smart people and limited funds. Somebody has to decide if they kludge along a bit longer with gear they have or spend the cash to do-it-right. I was impressed with the ingenuity of using the PPS from one box with GPS but wrong date to feed another box with no GPS and the date/time set by hand. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
Andrew Cooper kirjoitti: We also ran into the TS2100 1995 bug this weekend. For us the consequences are a bit more severe... So this is happening already.. Didn't notice this because have been using PPS from Thunderbolt to keep the TS2100 in time. It failed with leap second already in February (if I remember correctly) so I think if you have same firmware than I have (the most recent one) you have already got 1 second offset from real UTC since February. However, with PPS everything is fine. The unit is not rebooted after February (when removing the inegrated GPS unit) and it's in time. However that's not only bugs TS2100 has. I'm currently creating my own IRIG-B decoder and noticed that there's something strange going on with IEEE1344 checksums. The checksum will fail with random hours and beign ok on others. Seems that hour number is not included in the checksum or something. But that's another story... -- 73s! Esa OH4KJU ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
Hi Hal, > Why is that so hard? Depends if you want a quick hack (easy) or a solid solution (hard). > If I understand things correctly, the time (UTC) is correct because the GPS > receiver is using the current GPS-UTC offset. But the date is off by 1024 > weeks. (or some multiple of that) You don't know if the UTC time is correct until the receiver locks to GPS and waits up to 12.5 minutes to get UTC-GPS corrections. At that point you have some to high confidence. Before that point it's a guess. That guess depends very much on the implementation of the receiver; what they hardcode, what they cache, soft resets, hard resets, NVRAM clear, etc. As much as I cringe when I hear that telecoms often use GPS time instead of UTC, I have come to understand the wisdom of that decision. > All you need for "external information" is the date when the fixup software > was compiled. Call that the build-date. Then the recipe is: > t = dateAndTimeFromGPS > while t < build-date > t += 1024 weeks > > That won't solve the problem forever but it will give you another 20 years, > and you can restart the timer anytime you want by rebuilding and reinstalling > the fixup software. Good, you understand my point. You need "external information" and "That won't solve the problem forever" and oh, well, yeah, duh, just "rebuild and reinstall the fixup software" anytime there's trouble in the future. To me this is replacing a broken GPS receiver algorithm with a broken Arduino hack. You're not solving anything except pushing a problem to the next unsuspecting user or customer. Worse yet, now instead of being part of a group of N people sharing the same TymServe problem, you are a group of 1 with both a TymServe problem and an Arduino problem. > I think the problems with leap-seconds are also non-problems because the > broken firmware will be working with the correct/current GPS-UTC offset. I > don't remember any problems like that 2 years ago. Re-read the TymServe field service bulletin. It's not about when leap seconds happen. The issue with TymServe is more like when leap seconds don't happen! /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
On 2015-05-05 11:32, Alan Ambrose wrote: It's not that simple. First, it's not 20 years, but 1024 weeks (19.6 years). And not UTC weeks (which may have leap seconds) but GPS weeks (which do not, and are always 604800 seconds long). etc Don't think it's _that_ much code though. There's some open source ACM date algorithms, and it would be easy enough to implement a quick and dirty fix, adding a number of days offset, while the rest of the algorithm is tested. See http://www.leapsecond.com/notes/gpswnro.htm This was first noted in 1996 and has been happening since the first rollover in August 1999 so some affected NTP GPS drivers have been patched to add 1024 weeks while the input is more than 512 weeks in the past. Will the next time this problem reoccurs be another 20 years? The next rollover is about April 2019, but this can happen any time an older receiver's internal date representation used for GPS to UTC conversion overflows. Looks like Tymserve 2100 picked about Sep 1995 for its date epoch so it hits now. Newer GPS receivers support the extra 3 bits added to GPS extended week allowing 8192 weeks (157 years) between rollovers - 2137 is the next big rollover problem, but NavStar will likely not be sending the same data on the same frequency then. -- Take care. Thanks, Brian Inglis ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
t...@leapsecond.com said: > The hard part is understanding when the GPS receiver fails and when to apply > the 1024 week correction, or not. This is made difficult or impossible if > the receiver does not give you internal information or if you do not already > have external information (like an alternative, independent GPS, or UTC date > source). If you wanted to cheat you could keep an independent clock inside > the Arduino and then add or subtract 1024 weeks until it "looked right". But > this is complicated by power failures in either the GPS receiver or the > Arduino. Worse yet are cold starts where the receiver doesn't know what the > UTC-GPS correction is. Why is that so hard? If I understand things correctly, the time (UTC) is correct because the GPS receiver is using the current GPS-UTC offset. But the date is off by 1024 weeks. (or some multiple of that) All you need for "external information" is the date when the fixup software was compiled. Call that the build-date. Then the recipe is: t = dateAndTimeFromGPS while t < build-date t += 1024 weeks That won't solve the problem forever but it will give you another 20 years, and you can restart the timer anytime you want by rebuilding and reinstalling the fixup software. I think the problems with leap-seconds are also non-problems because the broken firmware will be working with the correct/current GPS-UTC offset. I don't remember any problems like that 2 years ago. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
Hi > On May 5, 2015, at 10:32 PM, Tom Van Baak wrote: > >> Don't think it's _that_ much code though. There's some open source ACM date >> algorithms, and it would be easy enough to implement a quick and dirty fix, >> adding a number of days offset, while the rest of the algorithm is tested. >> Will the next time this problem reoccurs be another 20 years? >> >> Alan > > Hi Alan, > > Correct, the date conversion is trivial. See > www.leapsecond.com/tools/gpsepoch.c or gpsweek.c for example. > > The hard part is understanding when the GPS receiver fails and when to apply > the 1024 week correction, or not. This is made difficult or impossible if the > receiver does not give you internal information or if you do not already have > external information (like an alternative, independent GPS, or UTC date > source). If you wanted to cheat you could keep an independent clock inside > the Arduino and then add or subtract 1024 weeks until it "looked right". But > this is complicated by power failures in either the GPS receiver or the > Arduino. Worse yet are cold starts where the receiver doesn't know what the > UTC-GPS correction is. > > It gets messy at best. And without testing in a GPS simulator you can't be > sure what will happen when epoch changes again on 2019-03-31 or some other > random date in the future. With these epoch issues going on I also wouldn't > trust the receiver to handle the upcoming leap second correctly either. I > mean, 2015-06-30 is an accepted date for a leap second. But if you're 1024 > weeks back in time the receiver will try to apply the leap on 1995-11-14, > which is not a valid end of month date. What will it do? I don't know. So > these are all things that would have to be tested and perhaps delegated to > the Arduino to sort out. > > It's just not simple to get 100% reliable UTC from a sick GPS receiver. The > receivers that fail right at the epoch (1999-08-15 or 2019-03-31 or > 2038-11-14) are simple to work-around. Also receivers that allow user input > of year, so that they can cache the GPS epoch number, are also simple to > work-around. But this TymServe 2100 doesn't seem to fall into either of those > categories. > > I hope this sheds light on why a simple, trustworthy fix is not likely. And > with millions of GPS receivers out there that have no problems this week, > because they were designed right in the first place, ….. We will know if they are “designed right” in terms of epochs in about 10 or 20 years from now. We’ll know a bit more (but not everything) about them doing leap seconds July 1st … Bob > you have to ask yourself if a hack to this old make/model is worth it. > > /tvb > > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
brian.ing...@systematicsw.ab.ca said: > GPS provides only the current UTC offset from GPS time, which could be made > available via a custom vendor message, or derived from the difference > between messages which provide UTC and messages (e.g. $GPZDG) which provide > GPS time. I think it's more complicated than that. The GPS satellites provide GPS time, the offset to UTC, and the the time of the next leap second. (Obviously, the latter only works if one is scheduled and the folks who run the satellites have had time to update things.) Some GPS receivers make that info available to the user. Most of the low cost receivers default to NMEA which provides UTC and doesn't provide any leap-warning. I think the GPS time via GPZDG is a proprietary hack, but maybe I didn't look hard enough. NMEA wants $$$ for the official documents so google probably won't find any. I didn't notice anything other than the NMEA driver in ntpd being able to process them. Most of the proprietary/non-NMEA protocols provide the next-leap info. My sample may be biased. Mostly, I've been looking for the leap-scheduled bit which is what ntpd wants. I think they also provide the when if you dig deeper, but I haven't been looking for that. > Stratum 1 NTP servers need to be provided with a copy of the NIST leap > second file and will propagate the warning to higher (numeric) stratum > clients. I think ntpd will work without the file. It may be simpler or less buggy with the file, but things should work without it. Some GPS units provide a leap-scheduled flag. I think ntpd will believe a refclock if it says leap-pending. If you are stratum 1 and your refclock isn't smart enough to tell you about leap-pending, you can get the info from other servers. I think it's something like a majority vote, but I'd have to look at the code and/or documentation to be sure. It's the same logic as used by non-stratum-1 servers. (A long time ago, it used to believe just one server, but that got changed after a few broken servers caused a lot of trouble.) You want a stratum-1 server to be watching other servers anyway as a sanity check. It will be interesting to see how well things work. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
> Don't think it's _that_ much code though. There's some open source ACM date > algorithms, and it would be easy enough to implement a quick and dirty fix, > adding a number of days offset, while the rest of the algorithm is tested. > Will the next time this problem reoccurs be another 20 years? > > Alan Hi Alan, Correct, the date conversion is trivial. See www.leapsecond.com/tools/gpsepoch.c or gpsweek.c for example. The hard part is understanding when the GPS receiver fails and when to apply the 1024 week correction, or not. This is made difficult or impossible if the receiver does not give you internal information or if you do not already have external information (like an alternative, independent GPS, or UTC date source). If you wanted to cheat you could keep an independent clock inside the Arduino and then add or subtract 1024 weeks until it "looked right". But this is complicated by power failures in either the GPS receiver or the Arduino. Worse yet are cold starts where the receiver doesn't know what the UTC-GPS correction is. It gets messy at best. And without testing in a GPS simulator you can't be sure what will happen when epoch changes again on 2019-03-31 or some other random date in the future. With these epoch issues going on I also wouldn't trust the receiver to handle the upcoming leap second correctly either. I mean, 2015-06-30 is an accepted date for a leap second. But if you're 1024 weeks back in time the receiver will try to apply the leap on 1995-11-14, which is not a valid end of month date. What will it do? I don't know. So these are all things that would have to be tested and perhaps delegated to the Arduino to sort out. It's just not simple to get 100% reliable UTC from a sick GPS receiver. The receivers that fail right at the epoch (1999-08-15 or 2019-03-31 or 2038-11-14) are simple to work-around. Also receivers that allow user input of year, so that they can cache the GPS epoch number, are also simple to work-around. But this TymServe 2100 doesn't seem to fall into either of those categories. I hope this sheds light on why a simple, trustworthy fix is not likely. And with millions of GPS receivers out there that have no problems this week, because they were designed right in the first place, you have to ask yourself if a hack to this old make/model is worth it. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
Hi, >>> It's not that simple. First, it's not 20 years, but 1024 weeks (19.6 years). And not UTC weeks (which may have leap seconds) but GPS weeks (which do not, and are always 604800 seconds long). etc <<< Don't think it's _that_ much code though. There's some open source ACM date algorithms, and it would be easy enough to implement a quick and dirty fix, adding a number of days offset, while the rest of the algorithm is tested. Will the next time this problem reoccurs be another 20 years? Alan ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
On 2015-05-05 11:47, Hal Murray wrote: cfhar...@erols.com said: Surely the receiver is still producing correct frames that identify the future leapsecond, and those frames could be read, and used to set a little routine that wakes up at the appropriate second, and adjusts the overall offset? Is there any leap-warning info in NMEA mode? I don't remember seeing anything like that when scanning the documentation and the NMEA driver in ntpd doesn't have any code like that. GPS provides only the current UTC offset from GPS time, which could be made available via a custom vendor message, or derived from the difference between messages which provide UTC and messages (e.g. $GPZDG) which provide GPS time. Stratum 1 NTP servers need to be provided with a copy of the NIST leap second file and will propagate the warning to higher (numeric) stratum clients. -- Take care. Thanks, Brian Inglis ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
cfhar...@erols.com said: > Surely the receiver is still producing correct frames that identify the > future leapsecond, and those frames could be read, and used to set a little > routine that wakes up at the appropriate second, and adjusts the overall > offset? Is there any leap-warning info in NMEA mode? I don't remember seeing anything like that when scanning the documentation and the NMEA driver in ntpd doesn't have any code like that. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
Hi Tom, One of the first words I taught my precocious kid when he was less than a year old was balderdash. It seemed appropriate for him to know that word if I was going to be his father. Hard for me to believe that little boy graduates from CMU with his BS in physics this month The currently buggy GPS receiver is outputting UTC time that is offset by 1024 weeks, and some number of seconds from reality. The past is irrelevant if we know the present offset. Add in that offset, reformat the UTC data frame and send it out when asked. An Arduino can do that in a very small number of milliseconds. And, the Arduino's time burden can be well known and applied to the data, if it is significant. Surely the receiver is still producing correct frames that identify the future leapsecond, and those frames could be read, and used to set a little routine that wakes up at the appropriate second, and adjusts the overall offset? Seems way simpler to me than all of that code I had to wade through and cleanse of Y2K bugs. Since the OP was talking about a multi million dollar research telescope, which presumably matters to a lot of people, I will refrain from commenting about the wisdom of ignoring the well publicized 1024 week roll over bug, and not replacing/reflashing the GPS receiver years ago. -Chuck Harris Tom Van Baak wrote: Hi Chuck, It's not that simple. First, it's not 20 years, but 1024 weeks (19.6 years). And not UTC weeks (which may have leap seconds) but GPS weeks (which do not, and are always 604800 seconds long). So you have to convert the incorrect UTC date and time back to GPS date and time, then apply the 1024 GPS week correction, and then convert back to UTC. This requires knowledge of all leap seconds during the past 1024 week cycle and this information is not present in the GPS signal or in the binary or NMEA messages that come out of a GPS receiver. Don't forget to account for all the leap years during that period too: 1024 weeks is 19.638 normal years but 19.585 leap years. And when you power-on the GPS receiver it may have the wrong leap second count as well, wrong for both 1995 and wrong for 2015. You have to wait up to 12.5 minutes for that information to come down at 50 baud. Not saying it isn't possible, but it's not easy. And then you need to test it against last week and this week, and the week before and after June 30 of this year when the next leap second occurs. I realize the TymServe 2100 issue is unrelated to leap seconds. But leap seconds severely complicate any "simple" conversion between time scales, especially if you are interested in second or sub-second accuracy. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
Hi Chuck, It's not that simple. First, it's not 20 years, but 1024 weeks (19.6 years). And not UTC weeks (which may have leap seconds) but GPS weeks (which do not, and are always 604800 seconds long). So you have to convert the incorrect UTC date and time back to GPS date and time, then apply the 1024 GPS week correction, and then convert back to UTC. This requires knowledge of all leap seconds during the past 1024 week cycle and this information is not present in the GPS signal or in the binary or NMEA messages that come out of a GPS receiver. Don't forget to account for all the leap years during that period too: 1024 weeks is 19.638 normal years but 19.585 leap years. And when you power-on the GPS receiver it may have the wrong leap second count as well, wrong for both 1995 and wrong for 2015. You have to wait up to 12.5 minutes for that information to come down at 50 baud. Not saying it isn't possible, but it's not easy. And then you need to test it against last week and this week, and the week before and after June 30 of this year when the next leap second occurs. I realize the TymServe 2100 issue is unrelated to leap seconds. But leap seconds severely complicate any "simple" conversion between time scales, especially if you are interested in second or sub-second accuracy. /tvb - Original Message - From: "Chuck Harris" To: "Discussion of precise time and frequency measurement" Sent: Tuesday, May 05, 2015 6:33 AM Subject: Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix > Seems to me that the obvious simple answer works this way: > > Since the GPS must use an RS232 connection to communicate > its information to the other devices in the telescope, all > that need be done is to write a fairly trivial program to > run on a PIC, or Arduino, that when presented with the date, > adds 20 to the year, and then sends it on to the rest of the > system. Everything that is not a date gets passed through > unmolested. > > -Chuck Harris ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
p...@heypete.com said: > Is there a list of other common time-nut devices that are susceptible to > similar issues? Lots of time-nuts use surplus equipment that's no longer > supported and it'd not be fun to have them stop working. We should make a list of good/bad units. The Z3801A does the right thing if you tell it the date. (I had one that was off by 1024 weeks and it's working correctly now.) -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
Seems to me that the obvious simple answer works this way: Since the GPS must use an RS232 connection to communicate its information to the other devices in the telescope, all that need be done is to write a fairly trivial program to run on a PIC, or Arduino, that when presented with the date, adds 20 to the year, and then sends it on to the rest of the system. Everything that is not a date gets passed through unmolested. -Chuck Harris Pete Stephenson wrote: On Tue, May 5, 2015 at 2:42 AM, Andrew Cooper wrote: We also ran into the TS2100 1995 bug this weekend. For us the consequences are a bit more severe... The telescopes will not point to the right location in the sky without accurate time! Ouch. I have some friends who work at the Subaru telescope. I'll check in to see if they're affected. For now we have configured a temporary fix... We set up two units, previously our primary and hot spare. The first unit is set to use GPS, which of course has the correct time but the wrong date. The first unit is sending a 1PPS signal to a second unit which is set to 1PPS input mode with a manually set date and time. We now have all of the IRIG and NTP capability we need and the correct date. Out of curiosity, is there no way to "prime" the device with the current date/time (e.g. from a wristwatch) so it can interpret the GPS week information correctly? I recall that several other devices have that ability. Is there a list of other common time-nut devices that are susceptible to similar issues? Lots of time-nuts use surplus equipment that's no longer supported and it'd not be fun to have them stop working. Cheers! -Pete ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
Hi The simple list of devices susceptible to this problem is: Almost all of them from before 1998, many of them after that. The issue is inherent in the design of the GPS coding and un-aided recovery of that coding. The need to address it only was apparent to most marketing departments after the first batch of gear started failing in the late 90’s. Bob > On May 5, 2015, at 3:30 AM, Pete Stephenson wrote: > > On Tue, May 5, 2015 at 2:42 AM, Andrew Cooper wrote: >> We also ran into the TS2100 1995 bug this weekend. For us the consequences >> are a bit more severe... The telescopes will not point to the right >> location in the sky without accurate time! > > Ouch. I have some friends who work at the Subaru telescope. I'll check > in to see if they're affected. > >> For now we have configured a temporary fix... We set up two units, >> previously our primary and hot spare. The first unit is set to use GPS, >> which of course has the correct time but the wrong date. The first unit is >> sending a 1PPS signal to a second unit which is set to 1PPS input mode with >> a manually set date and time. We now have all of the IRIG and NTP >> capability we need and the correct date. > > Out of curiosity, is there no way to "prime" the device with the > current date/time (e.g. from a wristwatch) so it can interpret the GPS > week information correctly? I recall that several other devices have > that ability. > > Is there a list of other common time-nut devices that are susceptible > to similar issues? Lots of time-nuts use surplus equipment that's no > longer supported and it'd not be fun to have them stop working. > > Cheers! > -Pete > > -- > Pete Stephenson > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
On Tue, May 5, 2015 at 2:42 AM, Andrew Cooper wrote: > We also ran into the TS2100 1995 bug this weekend. For us the consequences > are a bit more severe... The telescopes will not point to the right location > in the sky without accurate time! Ouch. I have some friends who work at the Subaru telescope. I'll check in to see if they're affected. > For now we have configured a temporary fix... We set up two units, > previously our primary and hot spare. The first unit is set to use GPS, > which of course has the correct time but the wrong date. The first unit is > sending a 1PPS signal to a second unit which is set to 1PPS input mode with a > manually set date and time. We now have all of the IRIG and NTP capability > we need and the correct date. Out of curiosity, is there no way to "prime" the device with the current date/time (e.g. from a wristwatch) so it can interpret the GPS week information correctly? I recall that several other devices have that ability. Is there a list of other common time-nut devices that are susceptible to similar issues? Lots of time-nuts use surplus equipment that's no longer supported and it'd not be fun to have them stop working. Cheers! -Pete -- Pete Stephenson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
We also ran into the TS2100 1995 bug this weekend. For us the consequences are a bit more severe... The telescopes will not point to the right location in the sky without accurate time! For now we have configured a temporary fix... We set up two units, previously our primary and hot spare. The first unit is set to use GPS, which of course has the correct time but the wrong date. The first unit is sending a 1PPS signal to a second unit which is set to 1PPS input mode with a manually set date and time. We now have all of the IRIG and NTP capability we need and the correct date. Yes, there is also an order in with purchasing for an S350 SyncServer unit. Andrew Andrew Cooper Electrical Engineer W. M. Keck Observatory 808-881-3862 mailto:acoo...@keck.hawaii.edu ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
