[time-nuts] GPS week rollover
Well, a big one will be in 2017 when all our Tbolts roll over.I have included some code in the next version of Lady Heather to compensate. If it detects a year from the unit before 2015, it converts the date/time to Julian, adds 1024 weeks worth of seconds, and then converts the date/time back to Gregorian. You can also specify a user defined rollover adjustment (in seconds). One issue that I have seen is the Tbolt occasionally spitting out a bogo-year and triggering a false/premature rollover... still trying to track that down. People using Tbolts for things like NTP servers will have to implement a similar 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? ___ 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] Divider circuit for Rubidium Standard
Hi Rick: Any suggestions for a circuit with better performance. Purpose will be a external standard for a frequency counter. -=Bryan=- Date: Mon, 4 May 2015 21:09:51 -0700 From: rich...@karlquist.com To: time-nuts@febo.com Subject: Re: [time-nuts] Divider circuit for Rubidium Standard On 4/26/2015 3:51 AM, Bryan _ wrote: All: P I was looking at the project from David partridges web site http://www.perdrix.co.uk/FrequencyDivider/index.html -=Bryan=- ___ This is a comparator based circuit. This will give you worse performance than just about anything else, but it may be good enough anyway. Rick Karlquist N6RK ___ 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] Lucent KS-24361/Thunderbolt antenna advice
On Tue, 5 May 2015 17:58:06 -0400 Bob Camp said (inter alia): Ok, all of these receivers are designed to work with an amplified antenna. The typical antennas have between 20 and 30 db of gain. They allow a cable loss of ~ 10 db between the antenna and the receiver. A 3 db splitter would come out of the “cable loss” budget. The receivers put out 5V on the coax. You can find antennas that only work with 7V. You can also find 3.3V antennas that will be damaged by 5V. Most of the low cost antennas you come across will work at 5V. OK, Bob, that's made things a bit clearer - at least I have some pointers now on what to look for :) They (mag-mount antennas) also are a bit tough to mount solidly. You will spend weeks letting the GPSDO’s stabilize and many days doing surveys. Throwing that all away each time the antenna moves is no fun. That's an important point - one which I hadn't really considered until now... The auction sites will sell you a “timing” antenna for $40 delivered. With some shopping, you can get a very good antenna for $150 delivered. You already have $300 to $500 invested. Skimping on the antenna does not make a lot of sense. OK, so one last question before I head off to scour FleaBay for something suitable: What's the difference between the $40 and $150 ones? That is to say, what is it about the $40 ones that makes them a bad choice, that isn't an issue in the $150 ones? There are a number of different antenna designs out there. You can make a good one any number of different ways. There is nothing magic about a quad helix style. Ok, I only ask becuse there seemed to be a big thing about LHCP quad helix antennas - even to the point of seein an article showing how to 'unwrap. a RHCP Q-H, and rewrap it 'inside-out' to change the polarisation to LHCP. I'm seriously considering making an active Q H if I can't find anything that looks promising - pending the answer to the question above, of course - I don't want to spend $100 making a '$40' one ;) I take your point about not skimping, given the investment I already have, and obviously am keen not to limit the equipment's capabilities in order to save a few quid. Many thanks for your continued advice/help John ___ 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] Divider circuit for Rubidium Standard
That's one of the reasons I was considering a re-spin of the board using a better ZCD solution. Dave -Original Message- From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Richard (Rick) Karlquist Sent: 05 May 2015 05:10 To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Divider circuit for Rubidium Standard This is a comparator based circuit. This will give you worse performance than just about anything else, but it may be good enough anyway. Rick Karlquist N6RK ___ 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] Divider circuit for Rubidium Standard
The Phase noise floor (~-143dBc/Hz @ 1kHz) of the 10MHz output of that divider is about 17dBc/Hz higher than either the LTC6957-4 (demo board) or the Holzworth HX2410 (both ~ -160dBc/Hz @ 1kHz).All measured with a 10MHz +14dBm input signal.For offsets below a few Hz shielding of the circuitry from air currents and reducing temperature fluctuations experienced by the circuitry is essential for accurate phase noise measurements. Bruce On Wednesday, 6 May 2015 2:36 PM, Richard (Rick) Karlquist rich...@karlquist.com wrote: On 4/26/2015 3:51 AM, Bryan _ wrote: All: P I was looking at the project from David partridges web site http://www.perdrix.co.uk/FrequencyDivider/index.html -=Bryan=- ___ This is a comparator based circuit. This will give you worse performance than just about anything else, but it may be good enough anyway. Rick Karlquist N6RK ___ 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] Divider circuit for Rubidium Standard
Wenzel has published the schematic of an excellent squaring circuit. I don't have the URL for their version handy, but I used it (with a couple of mods) in the TADD-2 and TADD-2 Mini designs. You can see the schematic in the T2-Mini users guide at http://www.tapr.org/~n8ur/T2_Mini_Manual.pdf. It will square up signals as low as -20dBm with very low jitter, and provides a TTL-compatible output. John On 5/6/2015 2:52 AM, Bryan _ wrote: Hi Rick: Any suggestions for a circuit with better performance. Purpose will be a external standard for a frequency counter. -=Bryan=- Date: Mon, 4 May 2015 21:09:51 -0700 From: rich...@karlquist.com To: time-nuts@febo.com Subject: Re: [time-nuts] Divider circuit for Rubidium Standard On 4/26/2015 3:51 AM, Bryan _ wrote: All: P I was looking at the project from David partridges web site http://www.perdrix.co.uk/FrequencyDivider/index.html -=Bryan=- ___ This is a comparator based circuit. This will give you worse performance than just about anything else, but it may be good enough anyway. Rick Karlquist N6RK ___ 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] Lucent KS-24361/Thunderbolt antenna advice
On 5/6/15 12:53 AM, John Marsden wrote: Ok, I only ask becuse there seemed to be a big thing about LHCP quad helix antennas - even to the point of seein an article showing how to 'unwrap. a RHCP Q-H, and rewrap it 'inside-out' to change the polarisation to LHCP. I'm seriously considering making an active Q H if I can't find anything that looks promising - pending the answer to the question above, of course - I don't want to spend $100 making a '$40' one ;) Helical antennas are really non-critical in terms of design. I'm not even sure that a quadrature helix is actually what you want: they tend to have more response at the horizon (for a short helix) than straight up, but I would think that for timing applications, you'd rather get strong signals from overhead, rather than low angle signals subject to multipath, etc. (remember that the GPS satellite's transmit antenna pattern is bigger at the edges than in the middle, so the incident flux on the ground is about the same regardless of elevation angle: this is different than the typical case for, say, LEO amateur radio, where the satellite is essentially omni, and you want an antenna with more gain at the horizon) A quad helix was popular for handheld GPS units because it's got a reasonably good pattern that's almost omnidirectional (even if the axial ratio isn't so hot in all directions), so it works well in any orientation. A regular helix with a gain of 10 dBi or so (4 turns) will have a 3dB beamwidth of 52 degrees, and will be about 6 cm in diameter and 20 cm long. 3 turns is 60 degrees bw (3db) The folks at JPL wind their helices on things like appropriately sized plastic cups and put them on one of those bowl shaped things that fit under a stove burner as a ground plane (hence the helibowl moniker). You get a decent match by adjusting the distance of the end of the bottom turn from the ground plane (making a sort of tapered transformer from the 100-150 ohm impedance of the helix to the 50 or 75 ohms of the feed line) ___ 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] GPS week rollover
Hi Pete, Yes, we are very fortunate that a fellow time-nut took the time to test a TBolt with a GPS simulator: https://www.febo.com/pipermail/time-nuts/2014-September/086664.html He also reported that the 1 PPS and the 10 MHz were undisturbed by the rollover. Yes, the date/time gets set back but Mark Sims updated Lady Heather to compensate. So as far as we know, all is well with that GPSDO in 2017 and 2019 and beyond. Note also that the TBolt handles rollover in a deterministic way and thus lends itself to epoch correction (since it's based on GPS time). The problem with the TymServe is that, unless they release the source code for the broken algorithm, its handling of epochs is not deterministic (since it's based on the count of leap seconds and can hop forward or back 1024 weeks without warning). /tvb - Original Message - From: Pete Stephenson p...@heypete.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, May 06, 2015 5:19 AM Subject: Re: [time-nuts] GPS week rollover On Wed, May 6, 2015 at 6:48 AM, Mark Sims hol...@hotmail.com wrote: Well, a big one will be in 2017 when all our Tbolts roll over.I have included some code in the next version of Lady Heather to compensate. If it detects a year from the unit before 2015, it converts the date/time to Julian, adds 1024 weeks worth of seconds, and then converts the date/time back to Gregorian. You can also specify a user defined rollover adjustment (in seconds). One issue that I have seen is the Tbolt occasionally spitting out a bogo-year and triggering a false/premature rollover... still trying to track that down. People using Tbolts for things like NTP servers will have to implement a similar fix... I assume the Tbolt rollover will be problematic for those who start their Tbolt completely cold (no time, almanac, or ephemeris) and without any non-GPS input, but how will the Tbolt behave in situations where the user initializes the Tbolt with the then-correct post-rollover date and time? For example, one might use Tboltmon and a wristwatch to set the approximate time on the unit and then let it figure out the precise time from GPS. Also, will the rollover cause time-of-day problems for running Tbolts? That is, would they ride through the rollover and continue to provide the correct date and time as expected (that is, they recognize that a rollover occurred and keep working normally so long as they're not cold-reset) or would they immediately jump back to December 14, 1997 (the Thunderbolt zero date)? According to https://www.febo.com/pipermail/time-nuts/2014-September/086664.html it looks like they'll output the incorrect date as they cross over the rollover point. That's not good. -- 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.
Re: [time-nuts] GPS week rollover
Quite a good thread. The old rollover is a real pain in the Especially on the old receivers circa 1990s. Whats useful is the method for calculating the week mentioned. Granted there are tools online that help. But the math associated with reversing the date now is clearer using the Julian date. May tinker in excel as I think there are date macros and such available. The output needed for the old receivers is now - 1024 weeks given as a date. On some of the really old ones I think it may be 2 rollovers at this point. Regards Paul WB8TSL On Wed, May 6, 2015 at 8:19 AM, Pete Stephenson p...@heypete.com wrote: On Wed, May 6, 2015 at 6:48 AM, Mark Sims hol...@hotmail.com wrote: Well, a big one will be in 2017 when all our Tbolts roll over.I have included some code in the next version of Lady Heather to compensate. If it detects a year from the unit before 2015, it converts the date/time to Julian, adds 1024 weeks worth of seconds, and then converts the date/time back to Gregorian. You can also specify a user defined rollover adjustment (in seconds). One issue that I have seen is the Tbolt occasionally spitting out a bogo-year and triggering a false/premature rollover... still trying to track that down. People using Tbolts for things like NTP servers will have to implement a similar fix... I assume the Tbolt rollover will be problematic for those who start their Tbolt completely cold (no time, almanac, or ephemeris) and without any non-GPS input, but how will the Tbolt behave in situations where the user initializes the Tbolt with the then-correct post-rollover date and time? For example, one might use Tboltmon and a wristwatch to set the approximate time on the unit and then let it figure out the precise time from GPS. Also, will the rollover cause time-of-day problems for running Tbolts? That is, would they ride through the rollover and continue to provide the correct date and time as expected (that is, they recognize that a rollover occurred and keep working normally so long as they're not cold-reset) or would they immediately jump back to December 14, 1997 (the Thunderbolt zero date)? According to https://www.febo.com/pipermail/time-nuts/2014-September/086664.html it looks like they'll output the incorrect date as they cross over the rollover point. That's not good. -- 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] GPS week rollover
On Wed, May 6, 2015 at 3:39 PM, Tom Van Baak t...@leapsecond.com wrote: Hi Pete, Hi Tom, Yes, we are very fortunate that a fellow time-nut took the time to test a TBolt with a GPS simulator: https://www.febo.com/pipermail/time-nuts/2014-September/086664.html That's the link I included in my message. :) I'm quite grateful for Matthias's work with the GPS simulator, but I was unclear about a few details. For example, he doesn't mention if tested the Tbolt as it transitioned over the overflow point itself (to tell if the Tbolt will maintain continuity and keep working as expected) or if he tested it by setting the date on the simulator to dates before and after the overflow point. Similarly, it's unclear if manually priming the Tbolt with the current date/time will allow it to determine the correct epoch or if it will simply use the 1997-2017 epoch baked into the firmware regardless of user input. He also reported that the 1 PPS and the 10 MHz were undisturbed by the rollover. Yes, the date/time gets set back but Mark Sims updated Lady Heather to compensate. So as far as we know, all is well with that GPSDO in 2017 and 2019 and beyond. Excellent, particularly regarding 1 PPS and 10 MHz outputs. It'd be nice if the unit itself would output the correct date rather than needing to rely on external software to interpret and correct the output. Note also that the TBolt handles rollover in a deterministic way and thus lends itself to epoch correction (since it's based on GPS time). Excellent. The problem with the TymServe is that, unless they release the source code for the broken algorithm, its handling of epochs is not deterministic (since it's based on the count of leap seconds and can hop forward or back 1024 weeks without warning). Ouch. No fun at all. Hopefully more modern receivers are more clueful about handling rollovers. At minimum, they should accept user input telling them what the current epoch is. Cheers! -Pete - Original Message - From: Pete Stephenson p...@heypete.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, May 06, 2015 5:19 AM Subject: Re: [time-nuts] GPS week rollover On Wed, May 6, 2015 at 6:48 AM, Mark Sims hol...@hotmail.com wrote: Well, a big one will be in 2017 when all our Tbolts roll over.I have included some code in the next version of Lady Heather to compensate. If it detects a year from the unit before 2015, it converts the date/time to Julian, adds 1024 weeks worth of seconds, and then converts the date/time back to Gregorian. You can also specify a user defined rollover adjustment (in seconds). One issue that I have seen is the Tbolt occasionally spitting out a bogo-year and triggering a false/premature rollover... still trying to track that down. People using Tbolts for things like NTP servers will have to implement a similar fix... I assume the Tbolt rollover will be problematic for those who start their Tbolt completely cold (no time, almanac, or ephemeris) and without any non-GPS input, but how will the Tbolt behave in situations where the user initializes the Tbolt with the then-correct post-rollover date and time? For example, one might use Tboltmon and a wristwatch to set the approximate time on the unit and then let it figure out the precise time from GPS. Also, will the rollover cause time-of-day problems for running Tbolts? That is, would they ride through the rollover and continue to provide the correct date and time as expected (that is, they recognize that a rollover occurred and keep working normally so long as they're not cold-reset) or would they immediately jump back to December 14, 1997 (the Thunderbolt zero date)? According to https://www.febo.com/pipermail/time-nuts/2014-September/086664.html it looks like they'll output the incorrect date as they cross over the rollover point. That's not good. -- 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. -- 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.
Re: [time-nuts] GPS week rollover
Whats useful is the method for calculating the week mentioned. Granted there are tools online that help. But the math associated with reversing the date now is clearer using the Julian date. May tinker in excel as I think there are date macros and such available. The output needed for the old receivers is now - 1024 weeks given as a date. On some of the really old ones I think it may be 2 rollovers at this point. Regards Paul WB8TSL Paul, there's lots of JD/MJD and GPS date time code at www.leapsecond.com/tools/ Look for gpsweek.c gpsdate.c gpsepoch.c mjd.c mjdclock.c to name a few. To plan ahead for the next century try this: C:\tvb\cl gpsweek 1980 2100 | grep rollover 10230 10231999-08-15 227 228 229 230 231 232 233 rollover 20471 10232019-03-31 90 91 92 93 94 95 96 rollover 30712 10232038-11-14 318 319 320 321 322 323 324 rollover 40953 10232058-06-30 181 182 183 184 185 186 187 rollover 51194 10232078-02-13 44 45 46 47 48 49 50 rollover 61435 10232097-09-29 272 273 274 275 276 277 278 rollover /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] GPS week rollover
On Wed, May 6, 2015 at 6:48 AM, Mark Sims hol...@hotmail.com wrote: Well, a big one will be in 2017 when all our Tbolts roll over.I have included some code in the next version of Lady Heather to compensate. If it detects a year from the unit before 2015, it converts the date/time to Julian, adds 1024 weeks worth of seconds, and then converts the date/time back to Gregorian. You can also specify a user defined rollover adjustment (in seconds). One issue that I have seen is the Tbolt occasionally spitting out a bogo-year and triggering a false/premature rollover... still trying to track that down. People using Tbolts for things like NTP servers will have to implement a similar fix... I assume the Tbolt rollover will be problematic for those who start their Tbolt completely cold (no time, almanac, or ephemeris) and without any non-GPS input, but how will the Tbolt behave in situations where the user initializes the Tbolt with the then-correct post-rollover date and time? For example, one might use Tboltmon and a wristwatch to set the approximate time on the unit and then let it figure out the precise time from GPS. Also, will the rollover cause time-of-day problems for running Tbolts? That is, would they ride through the rollover and continue to provide the correct date and time as expected (that is, they recognize that a rollover occurred and keep working normally so long as they're not cold-reset) or would they immediately jump back to December 14, 1997 (the Thunderbolt zero date)? According to https://www.febo.com/pipermail/time-nuts/2014-September/086664.html it looks like they'll output the incorrect date as they cross over the rollover point. That's not good. -- 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.
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 t...@leapsecond.com 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] Lucent KS-24361/Thunderbolt antenna advice
Hi On May 6, 2015, at 3:53 AM, John Marsden og...@live.co.uk wrote: On Tue, 5 May 2015 17:58:06 -0400 Bob Camp said (inter alia): Ok, all of these receivers are designed to work with an amplified antenna. The typical antennas have between 20 and 30 db of gain. They allow a cable loss of ~ 10 db between the antenna and the receiver. A 3 db splitter would come out of the “cable loss” budget. The receivers put out 5V on the coax. You can find antennas that only work with 7V. You can also find 3.3V antennas that will be damaged by 5V. Most of the low cost antennas you come across will work at 5V. OK, Bob, that's made things a bit clearer - at least I have some pointers now on what to look for :) They (mag-mount antennas) also are a bit tough to mount solidly. You will spend weeks letting the GPSDO’s stabilize and many days doing surveys. Throwing that all away each time the antenna moves is no fun. That's an important point - one which I hadn't really considered until now... The auction sites will sell you a “timing” antenna for $40 delivered. With some shopping, you can get a very good antenna for $150 delivered. You already have $300 to $500 invested. Skimping on the antenna does not make a lot of sense. OK, so one last question before I head off to scour FleaBay for something suitable: What's the difference between the $40 and $150 ones? That is to say, what is it about the $40 ones that makes them a bad choice, that isn't an issue in the $150 ones? You are after an antenna with: 1) Consistent delay over temperature. 2) Consistent phase center versus signal arrival angle 3) Good rejection of improperly polarized signals 4) Good rejection of signals reflected to the back side of the antenna 5) Good rejection of signals arriving at very low angles. 6) Adequate bandwidth for the bands you are after 7) Good filtering of the adjacent bands that you are not after 8) Good waterproofing, and rational mounting structure 9) Some way to keep birds from nesting on it I’m sure there are more things to look for. The list is in no particular order. There are a number of different antenna designs out there. You can make a good one any number of different ways. There is nothing magic about a quad helix style. Ok, I only ask becuse there seemed to be a big thing about LHCP quad helix antennas - even to the point of seein an article showing how to 'unwrap. a RHCP Q-H, and rewrap it 'inside-out' to change the polarisation to LHCP. I'm seriously considering making an active Q H if I can't find anything that looks promising - pending the answer to the question above, of course - I don't want to spend $100 making a '$40' one ;) GPS helix antennas were a really big deal in about 1982. Once people started to get experience with GPS and a variety of designs, they became less of a big deal. I do not know of any modern precision antennas that use a helix. I take your point about not skimping, given the investment I already have, and obviously am keen not to limit the equipment's capabilities in order to save a few quid. Far more important is not skimping on the antenna location. A crummy antenna in a great location will outperform the best antenna you can find located in the basement. Bob Many thanks for your continued advice/help John ___ 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] Microsemi versus Spetracom
I had this happen with my S250. It hangs during boot with the spinning hourglass stopping, right? The problem ended up being that the processor module had come slightly unseated. The initial boot messages on the display are independent from the functioning of the processor module. Thanks, David Slik VE7FIM On Wed, May 6, 2015 at 2:35 PM, Bob Darlington rdarling...@gmail.com wrote: My personal S300 died last month but otherwise I've fielded them in hot, cold, dusty, wet, and dry environments and they seem to keep going.It passes the initial self tetst but won't fully boot. I suspect CF card failure. Microsemi won't talk to me without an active support contract. Due to its death, I'm now working on a BeagleBone Black cape specifically for M12+ or Furuno timing receivers. I appreciate COTS hardware, but I'm a hobbyist. Mine will be cheaper, but I can't vouch for more reliable yet. -Bob On Wed, May 6, 2015 at 1:58 PM, Andrew Cooper acoo...@keck.hawaii.edu wrote: So, yes, our old TS2100's suffered the 1995 bug over the weekend like all of the others in the world. Kludged into working for the moment using 1PPS and two units. I do need to buy a couple replacements, good time is critical around an observatory, looking at a $16K purchase order. We have quoted both the SecureSync from SpectraCom and the S350 from Microsemi, both fully spec'd out with IRIG and IEEE1588. I am not really a time expert, just an everyday electrical engineer. Thrust into the problem three days ago. I have learned a bit reading through the Time Nuts archive... Thanks! Anything I should be aware of with these units. Any opinions on this purchase? Thanks for your advice, 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. ___ 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] Microsemi versus Spetracom
I worked with the Microsemi boxes at my previous employer. If you suspect it's the CF, there should actually be two in there. You might be able to revive it by taking the cards out, making backups with dd, and flashing out to new cards. This might take some trial and error (definitely preserve your card backups and know which card-slot each image came from). If I still know what I'm talking about, the reason for two cards was to allow recovery after failed software updates. This led to some interesting bugs around configuration if each card had a different version of the software. The solution I was given at the time was to always upgrade, reboot, upgrade, reboot. There may have been some factory resets in that recommendation as well. (though probably just to recover from the bad state it was in) The common failure-mode I know of is actually in the power supply. It would be obvious if this is the case, because the displays didn't light at all in that failure condition. Assuming that it's not the PS, I'd want to start by making the backups of the CFs and seeing if you can get it back into service on some new cards. It's possible that if one is corrupted, flashing the non-corrupted one to two cards might do the trick. Just a guess. I'd be happy to provide a bit more detail, but would need to know more about its death and current state. - Brian On Wed, May 6, 2015 at 2:35 PM, Bob Darlington rdarling...@gmail.com wrote: My personal S300 died last month but otherwise I've fielded them in hot, cold, dusty, wet, and dry environments and they seem to keep going.It passes the initial self tetst but won't fully boot. I suspect CF card failure. Microsemi won't talk to me without an active support contract. Due to its death, I'm now working on a BeagleBone Black cape specifically for M12+ or Furuno timing receivers. I appreciate COTS hardware, but I'm a hobbyist. Mine will be cheaper, but I can't vouch for more reliable yet. -Bob On Wed, May 6, 2015 at 1:58 PM, Andrew Cooper acoo...@keck.hawaii.edu wrote: So, yes, our old TS2100's suffered the 1995 bug over the weekend like all of the others in the world. Kludged into working for the moment using 1PPS and two units. I do need to buy a couple replacements, good time is critical around an observatory, looking at a $16K purchase order. We have quoted both the SecureSync from SpectraCom and the S350 from Microsemi, both fully spec'd out with IRIG and IEEE1588. I am not really a time expert, just an everyday electrical engineer. Thrust into the problem three days ago. I have learned a bit reading through the Time Nuts archive... Thanks! Anything I should be aware of with these units. Any opinions on this purchase? Thanks for your advice, 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. ___ 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] Divider circuit for Rubidium Standard
Hi A standard input on a frequency counter is not a very demanding thing in the hierarchy of TimeNut signals. You can drive any of them with some pretty simple logic gate based circuits. No need to spend a lot of money. Bob On May 6, 2015, at 2:52 AM, Bryan _ bpl...@outlook.com wrote: Hi Rick: Any suggestions for a circuit with better performance. Purpose will be a external standard for a frequency counter. -=Bryan=- Date: Mon, 4 May 2015 21:09:51 -0700 From: rich...@karlquist.com To: time-nuts@febo.com Subject: Re: [time-nuts] Divider circuit for Rubidium Standard On 4/26/2015 3:51 AM, Bryan _ wrote: All: P I was looking at the project from David partridges web site http://www.perdrix.co.uk/FrequencyDivider/index.html -=Bryan=- ___ This is a comparator based circuit. This will give you worse performance than just about anything else, but it may be good enough anyway. Rick Karlquist N6RK ___ 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] Microsemi versus Spetracom
My personal S300 died last month but otherwise I've fielded them in hot, cold, dusty, wet, and dry environments and they seem to keep going.It passes the initial self tetst but won't fully boot. I suspect CF card failure. Microsemi won't talk to me without an active support contract. Due to its death, I'm now working on a BeagleBone Black cape specifically for M12+ or Furuno timing receivers. I appreciate COTS hardware, but I'm a hobbyist. Mine will be cheaper, but I can't vouch for more reliable yet. -Bob On Wed, May 6, 2015 at 1:58 PM, Andrew Cooper acoo...@keck.hawaii.edu wrote: So, yes, our old TS2100's suffered the 1995 bug over the weekend like all of the others in the world. Kludged into working for the moment using 1PPS and two units. I do need to buy a couple replacements, good time is critical around an observatory, looking at a $16K purchase order. We have quoted both the SecureSync from SpectraCom and the S350 from Microsemi, both fully spec'd out with IRIG and IEEE1588. I am not really a time expert, just an everyday electrical engineer. Thrust into the problem three days ago. I have learned a bit reading through the Time Nuts archive... Thanks! Anything I should be aware of with these units. Any opinions on this purchase? Thanks for your advice, 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. ___ 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] Microsemi versus Spetracom
So, yes, our old TS2100's suffered the 1995 bug over the weekend like all of the others in the world. Kludged into working for the moment using 1PPS and two units. I do need to buy a couple replacements, good time is critical around an observatory, looking at a $16K purchase order. We have quoted both the SecureSync from SpectraCom and the S350 from Microsemi, both fully spec'd out with IRIG and IEEE1588. I am not really a time expert, just an everyday electrical engineer. Thrust into the problem three days ago. I have learned a bit reading through the Time Nuts archive... Thanks! Anything I should be aware of with these units. Any opinions on this purchase? Thanks for your advice, 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.
Re: [time-nuts] GPS week rollover
Hi Pete, I didn´t test the transition - I just entered a few dates well after the rollover. After locking, the phase of the 10 MHz output was stable against the phase of the 10 MHz REF out of the signal generator I used for testing, which was what I expected. The 1 PPS looked reasonable. I´m not aware of a way to set a date manually for the Tbolt. I have to admit that I use the thunderbolt different from many other list members: I switch it on from time to time to check the OCXO which I use as a common reference for my counter, spectrum analyzer, some generators etc. against it. If the frequency error is in the range of 1e-9, this is more than sufficient for me. So the output of date and time is a nice to have feature, but not really important for me. Anyway, if there´s something you´d like me to test with the simulator, just let me know. Best regards, Matthias Am 06.05.2015 um 16:39 schrieb Pete Stephenson: On Wed, May 6, 2015 at 3:39 PM, Tom Van Baakt...@leapsecond.com wrote: Hi Pete, Hi Tom, Yes, we are very fortunate that a fellow time-nut took the time to test a TBolt with a GPS simulator: https://www.febo.com/pipermail/time-nuts/2014-September/086664.html That's the link I included in my message. :) I'm quite grateful for Matthias's work with the GPS simulator, but I was unclear about a few details. For example, he doesn't mention if tested the Tbolt as it transitioned over the overflow point itself (to tell if the Tbolt will maintain continuity and keep working as expected) or if he tested it by setting the date on the simulator to dates before and after the overflow point. Similarly, it's unclear if manually priming the Tbolt with the current date/time will allow it to determine the correct epoch or if it will simply use the 1997-2017 epoch baked into the firmware regardless of user input. He also reported that the 1 PPS and the 10 MHz were undisturbed by the rollover. Yes, the date/time gets set back but Mark Sims updated Lady Heather to compensate. So as far as we know, all is well with that GPSDO in 2017 and 2019 and beyond. Excellent, particularly regarding 1 PPS and 10 MHz outputs. It'd be nice if the unit itself would output the correct date rather than needing to rely on external software to interpret and correct the output. Note also that the TBolt handles rollover in a deterministic way and thus lends itself to epoch correction (since it's based on GPS time). Excellent. The problem with the TymServe is that, unless they release the source code for the broken algorithm, its handling of epochs is not deterministic (since it's based on the count of leap seconds and can hop forward or back 1024 weeks without warning). Ouch. No fun at all. Hopefully more modern receivers are more clueful about handling rollovers. At minimum, they should accept user input telling them what the current epoch is. Cheers! -Pete - Original Message - From: Pete Stephensonp...@heypete.com To: Discussion of precise time and frequency measurementtime-nuts@febo.com Sent: Wednesday, May 06, 2015 5:19 AM Subject: Re: [time-nuts] GPS week rollover On Wed, May 6, 2015 at 6:48 AM, Mark Simshol...@hotmail.com wrote: Well, a big one will be in 2017 when all our Tbolts roll over.I have included some code in the next version of Lady Heather to compensate. If it detects a year from the unit before 2015, it converts the date/time to Julian, adds 1024 weeks worth of seconds, and then converts the date/time back to Gregorian. You can also specify a user defined rollover adjustment (in seconds). One issue that I have seen is the Tbolt occasionally spitting out a bogo-year and triggering a false/premature rollover... still trying to track that down. People using Tbolts for things like NTP servers will have to implement a similar fix... I assume the Tbolt rollover will be problematic for those who start their Tbolt completely cold (no time, almanac, or ephemeris) and without any non-GPS input, but how will the Tbolt behave in situations where the user initializes the Tbolt with the then-correct post-rollover date and time? For example, one might use Tboltmon and a wristwatch to set the approximate time on the unit and then let it figure out the precise time from GPS. Also, will the rollover cause time-of-day problems for running Tbolts? That is, would they ride through the rollover and continue to provide the correct date and time as expected (that is, they recognize that a rollover occurred and keep working normally so long as they're not cold-reset) or would they immediately jump back to December 14, 1997 (the Thunderbolt zero date)? According to https://www.febo.com/pipermail/time-nuts/2014-September/086664.html it looks like they'll output the incorrect date as they cross over the rollover point. That's not good. -- Pete Stephenson ___ time-nuts mailing list --time-nuts@febo.com To unsubscribe, go
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] GPS week rollover
Mark Sims kirjoitti: People using Tbolts for things like NTP servers will have to implement a similar fix... I'm pretty sure that many GPS based NTP servers will also fail. For example I have TymServe 2100 and it fails already with leap second handling. Just now the integrated GPS cannot be used until the end of June. Only way to run this baby now is to feed it with external PPS (from Thunderbolt). I'm pretty sure that this will be the permanent solution after 2017. Tymserve's integrated GPS module is from Trimble, so the risk of having same problems than Tbolt is real. We'll see.. -- 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
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
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 thinks it's 1995?
On 2015-05-05 11:58, Tom Van Baak wrote: And now I guess we can't blame Trimble either since their 15-year old Ace documentation [1] says: ACE III GPS System Designer Reference Manual Part Number: 41265-00 Revision: A Date: June 2000 Firmware: 8.08 3.5.1 Effect of GPS Week Number Roll-over (WNRO) The ACE III GPS module has been designed to handle WNRO, and there are no problems with either dates or first fix after WNRO through the year 2015. Caution Trimble OEM GPS receivers have reported the true GPS Week Number in TSIP messages 0x41 and 0x8F-20 as a number between 0 and 1023. The ACE III GPS outputs the Extended GPS Week Number as the absolute number of weeks since the beginning of GPS time or 06 January 1980. If the true GPS Week Number is desired, the system developer should ignore the extra MSBs of the Extended GPS Week Number and use only the 10 LSBs. From that, I would say we can blame Trimble as they receive the extended week number which supports operation up to 2137, but says there will be problems in 2015. Does anyone on the list know how well the http://www.heoldesign.com replacement works? Hopefully the upgrade supports operation after 2015, but it still may not work if the Tymserve 2100 does not handle the increased range. Neither the Holodesign N024 nor the Trimble Copernicus II manuals state any limits similar to that in the ACE III manual. -- 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] Microsemi versus Spetracom
Hi Once you dig inside the TS2100 to add a CPU board between the GPS and other guts, you have reliability issues as well….. Bob On May 6, 2015, at 5:35 PM, Bob Darlington rdarling...@gmail.com wrote: My personal S300 died last month but otherwise I've fielded them in hot, cold, dusty, wet, and dry environments and they seem to keep going.It passes the initial self tetst but won't fully boot. I suspect CF card failure. Microsemi won't talk to me without an active support contract. Due to its death, I'm now working on a BeagleBone Black cape specifically for M12+ or Furuno timing receivers. I appreciate COTS hardware, but I'm a hobbyist. Mine will be cheaper, but I can't vouch for more reliable yet. -Bob On Wed, May 6, 2015 at 1:58 PM, Andrew Cooper acoo...@keck.hawaii.edu wrote: So, yes, our old TS2100's suffered the 1995 bug over the weekend like all of the others in the world. Kludged into working for the moment using 1PPS and two units. I do need to buy a couple replacements, good time is critical around an observatory, looking at a $16K purchase order. We have quoted both the SecureSync from SpectraCom and the S350 from Microsemi, both fully spec'd out with IRIG and IEEE1588. I am not really a time expert, just an everyday electrical engineer. Thrust into the problem three days ago. I have learned a bit reading through the Time Nuts archive... Thanks! Anything I should be aware of with these units. Any opinions on this purchase? Thanks for your advice, 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. ___ 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.
