Re: [time-nuts] Update on Rb Performance
Hi Warren -- for these tests, I wasn't capturing raw data, jut using the tables and graphs that come out of the TSC box. John On Feb 18, 2012, at 11:57 PM, ws at Yahoo warrensjmail-...@yahoo.com wrote: John If you have the raw phase data, can you post a plot of what the well filtered freq offset looks like over that 10 day period? I've have found a properly filtered high resolution freq vs. time plot provides a lot more useful information than the couple of data numbers of a ADEV plot for evaluating long term performance of an Osc and helps separate all the many different possible causes of poor ADEV numbers. This is because then one can see the shape and magnitude of the Freq drift, therefore being able to see if the freq drift has a short term cycle due to temperature or if it is linear due to ageing or 2nd order due to still stabilizing or if it contains freq jumps due to 1/f flicker, or a single large jump due ...etc, etc. To be of any long term use, the freq data must be filtered over a long enough time period, such as a 1 hr running averaged, so the plot is more than just the 1 sec noise shown on most freq plots. The big avantage of using long term freq plot instead of a ADEV plot is the freq error is not noise but sytimatic errors which I have found to generally be the casse over longer time periods, then 10days worth of data can be use to prdict the what the future performance will be, compart that to what 10days of ADEV give, a lot of uncetaiy to even prdict what the one day drift will ber.if the Noise is not noise but due to Using a 10 day ws John Ackermann N8UR jra at febo.com This isn't the real long-term stability test I'm planning to do, but I did let the measurement continue on the last unit I was testing (an Efratrom FRS-type) out to 10+ days, which should give fairly reasonable data out to 100K seconds. An ADEV plot is attached. I would ignore the last two plot points as there isn't enough data for them to be very meaningful. Bottom line is that Efratom specs the FRS units at 1e-10/day, and this one seems to do more than an order of magnitude better. But also looks like you need a lot more than 10 days data to draw any real conclusions; you can look at this plot and think that the ADEV is maybe heading back down after a peak near 1e-11. 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.
[time-nuts] export controls and reverse engineering
Do you believe there may be a problem for those who are reverse-engineering, and posting on the open net, items which may be covered under these regulations? If you do, you may want to consider contacting them off-list and letting them know your concern. Peter Man, export controls are a complex, confusing, and not at all tidy and rule-driven so that mere engineers can figure out what is covered and what isn't. It is left up to diplomats and folks at departments of Commerce and State (in the US, anyway) to figure out using whatever means they have at their disposal. (When I started getting into the whole export control and negotiating licenses thing at work, the first thing they told me was that as an engineer, I'd find it horribly frustrating, because it doesn't necessarily make sense) In general, I would think that reverse engineering something bought surplus would NOT be subject to export controls. Obviously, if a spacecraft or spare nuclear weapon fell in your backyard and you commenced reversing it, that would probably raise some issues. A lot revolves around whether the thing you are fooling with is considered a defense article or munition, for which you need to go to the lists. Spaceflight qualified atomic clocks are definitely on that list, but these are not them. FEI does, however, produce things that are export controlled, so they may take the easy way and treat everything as controlled unless there's a reason not to: hence the boiler plate on invoices from parts distributors when you order BNC jacks warning you about export controls. The US Munitions List (USML) does have a whole section on atomic frequency standards, and you want to take a look at the performances listed there and see if you're in the ballpark (I suspect not). They would be interested in particularly small, low power, or rugged sources. Be aware that ITAR is only half of export control. Department of Commerce also has the EAR. There you want to look at dual-use technologies. ___ 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] Update on Rb Performance
John said in part; ignore the last two (ADEV) plot points as there isn't enough data for them to be very meaningful. you need a lot more than 10 days data to draw any real conclusions; IMHO, ADEV is not the right tool or even a very useful tool for evaluation the long term performance of these Rb Osc. Whenever possible, best to record the Raw data so other tools, such as available in TimeLab can be used to better compare the different Rbs. I have to wonder how many others notice ADEV's severe limitation in its able to reliable predict even 1 day in the future from 10 days worth of past data. Where as, ADEV is a great tool for measuring 1 sec noise, It is a poor tool to use for predicting future 1 day errors. This is especially true when the majority of the errors are due to measurable systematic things such as ageing and tempCo, as is the case with these Rb oscillators. This seems like a case of using the wrong tool for the job. ADEV's usefulness and power is its ability to predict future errors from past random Noise. For this, it helps to have at least a 10 to one and preferable a 100 to one ratio of raw data to tau. Because of the randomness of Noise, in order to get good consistent ADEV results, The larger the ratio of recorded data to tau the better the answers. So to get a good consistent 1 sec ADEV answer, best to have 100 seconds or more of raw data. To get good 1 day ADEV answers from noisy data, would need to have 100 or so days worth of raw data. One of the ironic things of trying to use ADEV plots to predict long term future errors, is that during the 100 days of recording raw data, the systematic things that are causing the errors will have likely changed enough that the raw long data run may still be near useless to predict future errors over even the next day or two using ADEV. The ratio of time that raw data needs to be collected compared to future predicable time, can be greatly improved by using any number of more appropriate tools. By using something rather than ADEV, taking 10 days worth of the right data, one can then better predict the next 10 or even 100 days in the future when the major error sources are systematic rather than Random. from http://en.wikipedia.org/wiki/Allan_variance The Allan variance is intended to estimate stability due to noise processes and not that of systematic errors or imperfections such as frequency drift or temperature effects ws - Original Message - From: John Ackermann N8UR Subject: Re: [time-nuts] Update on Rb Performance Hi Warren -- for these tests, I wasn't capturing raw data, just using the tables and graphs that come out of the TSC box. John * On Feb 18, 2012, at 11:57 PM, ws at Yahoo John If you have the raw phase data, can you post a plot of what the well filtered freq offset looks like over that 10 day period? I've have found a properly filtered high resolution freq vs. time plot provides a lot more useful information than the couple of data numbers of a ADEV plot for evaluating long term performance of an Osc and helps separate all the many different possible causes of poor ADEV numbers. This is because then one can see the shape and magnitude of the Freq drift, therefore being able to see if the freq drift has a short term cycle due to temperature or if it is linear due to ageing or 2nd order due to still stabilizing or if it contains freq jumps due to 1/f flicker, or a single large jump due ...etc, etc. To be of any long term use, the freq data must be filtered over a long enough time period, such as a 1 hr running averaged, so the plot is more than just the 1 sec noise shown on most freq plots. ... ws John Ackermann N8UR jra at febo.com This isn't the real long-term stability test I'm planning to do, but I did let the measurement continue on the last unit I was testing (an Efratrom FRS-type) out to 10+ days, which should give fairly reasonable data out to 100K seconds. An ADEV plot is attached. I would ignore the last two plot points as there isn't enough data for them to be very meaningful. Bottom line is that Efratom specs the FRS units at 1e-10/day, and this one seems to do more than an order of magnitude better. But also looks like you need a lot more than 10 days data to draw any real conclusions; you can look at this plot and think that the ADEV is maybe heading back down after a peak near 1e-11. 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] Update on Rb Performance
There seems to be some confusion about stability and drift; about ADEV and other tools. The tone of this thread is not heading in a positive direction. So instead I will offer to put together a short tutorial or series of tutorials that focus on factual education and gracious explanation. Give me a few days. If any of you have a week or two of Rb raw data, however good or bad it looks, send it to me off-line and I'll add it to the mix of phase data that I already have for the worked examples. Thanks, /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] Update on Rb Performance
On 2/19/12 2:47 PM, Tom Van Baak wrote: There seems to be some confusion about stability and drift; about ADEV and other tools. The tone of this thread is not heading in a positive direction. So instead I will offer to put together a short tutorial or series of tutorials that focus on factual education and gracious explanation. Most excellent.. I'm always looking for this kind of thing for new engineers at work.. ___ 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] Update on Rb Performance
Thank you, Tom. I REALLY look forward to your tutorials. How interesting and thought provoking for you to take your time(sic) for such. Thanks a million. -Don - -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van Baak Sent: Sunday, February 19, 2012 4:48 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Update on Rb Performance There seems to be some confusion about stability and drift; about ADEV and other tools. The tone of this thread is not heading in a positive direction. So instead I will offer to put together a short tutorial or series of tutorials that focus on factual education and gracious explanation. Give me a few days. If any of you have a week or two of Rb raw data, however good or bad it looks, send it to me off-line and I'll add it to the mix of phase data that I already have for the worked examples. Thanks, /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.
[time-nuts] Low-long-term-drift clock for board level integration?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi. This is my first posting to this list, and I'm not a timekeeping engineer, so my apologies in advance for my ignorance in this area. I'm building a small device to do one-way delay measurements through network. Once I'm done with prototyping, I'm planning a production run of several hundred of the devices. They'll have a GPS receiver, probably a Trimble Resolution SMT, and they have a bit of battery so they can initially go outdoors for ~30 minutes to get a good fix, but then they get taken indoors and plugged into the network, and probably never get a clear view of a GPS or GLONASS satellite again. - From that point forward (and we hope the devices will have an operational life of at least ten years) they'll be dependent on their internal clock and NTP, but we really need them to stay synchronized to within 100 microseconds. 10 microseconds would be ideal, but 100 would be acceptable. And in order to be useful, they need to stay synchronized at that level of precision essentially forever. My plan, such as it is, was just to get the best clock I could find within budget, integrate it onto the motherboard we're laying out as the system clock, and depend on NTPd to do the right thing with it. Anyone have any thoughts or advice on clocks I could use that would be, say, under USD 300 in quantity 500, and would be optimized for minimal long-term drift? Power-use is not particularly constrained. It needs to be integrated onto our board, but space isn't too constrained either. I'm also happy to pay for a few consulting hours if people want to give me detailed advice on a professional basis. Thanks, -Bill -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPQYw8AAoJEG+kcEsoi3+HfuUP/3+VVQs+dyRL4ToEoCaAI0eQ 8TMEV1PD7r775P/rSA0M1wWzFsTxAegixUbBHmQDvgc2ouaEiN0ZJvQrbNwBxR8M +b7QIuxB4h84JYyvw+Add6l8HjWWWttDW52YiUEdNmv228Q+XO7z/CMBrZ79c9bB VeZ5CEJl3zLcEDthpBKxgtEKtHFqURUCQ0b3uqWC4dTYld3yTJ9NB7/mt5bLDlEF IoA02IKurWBgkmNf92FU2SeC458mPejw2EiYaQ/acSv8mK23q56XJoo0O1ogNhAk qajdSBj/z9hlLTKgRH5jBorwNeRwr0TN8AoyPjBBqIRAI14Q1QHbLJu5twhy5C92 oE78LzedFa93GBPg8+6mdxYgevG4Pm8v8qeB6CdlDBJVD8s91QF0m52Gce+l2H9V PUGO7ACWjhVdi7VIWSOeSYGlIlqsLV4C7UYLYS+4zy0+dnrgeLFeYf9A29i6Krhr BCrtPvE6XrC0JUr3oZ0gDzh/T9JPr0XFmWkA0w9JmOAK7D+YWfa7jTBS+vbSXemo 5XBpjK2Ioo9JBwKmUF1Gd8dOO7fSm7cclxfRYwmjjzvSGG+vXCihWhaLzJdwJz6Z PYf60+hk23Mhrfk4V2qjTi1hVg9FJtxxNA3oC0MRuuwU45tXGIFcUqpSw3F+FS6f IuLyIrTqwVzdakZL997f =PpgK -END PGP SIGNATURE- ___ 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] Low-long-term-drift clock for board level integration?
What you are looking for is the Caesium standard on a chip that is presently only available for mostly military projects. This will become available as war surplus after WW III. But if you are going to correct it with NTP, a simple crystal oscillator will do. If you're using NTP, why do you need to initially set it to GPS accuracy? Your best solution is to maintain the GPS antenna and only use GPS to discipline a good crystal oscillator. Do you plan to regulate the ambient and power environment to some degree of accuracy? Note that 10 microseconds is 1 part in 10E5. The folks on this list deal in parts per 10E12. $300 will buy you a standalone GPS receiver that does parts in 10E9, but it is bigger than a circuit board. Can you use a standalone receiver to always generate a 10 MHz signal or pulse per second signal that is distributed to all of the measurement devices in a facility? Bill Hawkins, who has ideas but is not a professional -Original Message- From: Bill Woodcock Sent: Sunday, February 19, 2012 5:57 PM Hi. This is my first posting to this list, and I'm not a timekeeping engineer, so my apologies in advance for my ignorance in this area. I'm building a small device to do one-way delay measurements through network. Once I'm done with prototyping, I'm planning a production run of several hundred of the devices. They'll have a GPS receiver, probably a Trimble Resolution SMT, and they have a bit of battery so they can initially go outdoors for ~30 minutes to get a good fix, but then they get taken indoors and plugged into the network, and probably never get a clear view of a GPS or GLONASS satellite again. - From that point forward (and we hope the devices will have an operational life of at least ten years) they'll be dependent on their internal clock and NTP, but we really need them to stay synchronized to within 100 microseconds. 10 microseconds would be ideal, but 100 would be acceptable. And in order to be useful, they need to stay synchronized at that level of precision essentially forever. My plan, such as it is, was just to get the best clock I could find within budget, integrate it onto the motherboard we're laying out as the system clock, and depend on NTPd to do the right thing with it. Anyone have any thoughts or advice on clocks I could use that would be, say, under USD 300 in quantity 500, and would be optimized for minimal long-term drift? Power-use is not particularly constrained. It needs to be integrated onto our board, but space isn't too constrained either. I'm also happy to pay for a few consulting hours if people want to give me detailed advice on a professional basis. Thanks, -Bill ___ 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] Low-long-term-drift clock for board level integration?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Feb 19, 2012, at 5:07 PM, Bill Hawkins wrote: If you are going to correct it with NTP, a simple crystal oscillator will do. Yeah, my assumption was that something like a DOCXO or a VCTCXO would be about the best I'd get within budget. But I'm very new to this, and just beginning to dip into all the articles about SC cut versus AT cut, etc. If you're using NTP, why do you need to initially set it to GPS accuracy? We need the GPS fix for location, and get the time for free, so figured we'd use it. Your best solution is to maintain the GPS antenna and only use GPS to discipline a good crystal oscillator. That would be nice, of course, and we'll get the best GPS antenna we can afford and fit, but we can't have an externally-cabled antenna, or require that people put these on windowsills, or anything like that… There will be too many of them, and the level of clue of the people plugging them in out in the field is likely to be too low. Do you plan to regulate the ambient and power environment to some degree of accuracy? Yes… They'll all be indoors, which helps, and temperature-regulated crystals seem to be relatively widely available, if in a dizzying number of styles. Regulated power is something that we need to just have someone spec out, or use a reference design, if one exists. Anyone have pointers? Note that 10 microseconds is 1 part in 10E5. The folks on this list deal in parts per 10E12. So that's something I've been having a hard time understanding… If that's the amount of inaccuracy _per oscillation_, then at the time-scales I'm dealing with, it would quickly accumulate and become unuseful… that is, 10 microseconds of drift per second is almost a second of drift in a day, whereas I need, ideally, something I can discipline to within 100 microseconds _total_, using just a single GPS fix, plus NTP over the long haul. Now, I don't know whether what I want is possible or not, but that's why I'm asking these questions. Or am I misunderstanding the parts-per-foo notation? Can you use a standalone receiver to always generate a 10 MHz signal or pulse per second signal that is distributed to all of the measurement devices in a facility? There will only be one device per location, and we can't have any external stuff plugged into them. Else yes, I'd just use GPS and be done with it. -Bill -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPQaZgAAoJEG+kcEsoi3+HofkP/iEYz5UKHvHuifCUe3YZwoz/ SSzYbPDnODHFBvf3QBipUVt54lFRxqapcXrSJrtM7qeu52CTKP9kl8OUmZHABogQ iSUafnPcjOoxByStt9EucEQOp68QnLsXciELSsOR6K9Pl69i6V/A84Eg+eSXTbm5 LE/kPVDOVHI/eL6m7E70vCk9qreQY6ujCiaeUIAlgM14DWVczU1ke1IcXSbCajdl seX3byHZOQDgL1MD+IYdi1VU/3AC8NbSwce6j0H3bYpuA1knWlfNQlrKPVWSbIfF 21QEgYgJ8ZmDG6BWounFAhjN2MqzPm4mJ4MyVBJwGi1atzLzgPWWZJFh9GoValCC OezajJdUlAQdUEYf1bSPpbBhzK8qzVHRmBIFKDWJew62ab5VyzJt+m01y5wZJkR6 w2vz8awh5ZCDI77YVm7dsRqxRDj54QsiFIyvJV9qLGW5ubj3SQy//Bx9X4W3nIYu WbxQD1g8o2yB8Ci9OB6Ox2Wiy3UcZegNxX+8nrupp89qDAWCk3dKxLxR/acXAQ1L DFQbs+lxgNVTXygLnFm2GY9VgvCUKw/GW9oZqdhiDlhFQilR7vMsYrAdAyOZfv7e 6hU3g2FtoGgax9KPd7Zmyg0nhamDphnjumNnnxqUu4gXMZzGLBoeZAWy7LmSkUn0 qGQ4Qv1ff2PwTqAAlqn1 =l7OV -END PGP SIGNATURE- ___ 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] Low-long-term-drift clock for board level integration?
On 19 Feb, 2012, at 15:56 , Bill Woodcock wrote: Hi. This is my first posting to this list, and I'm not a timekeeping engineer, so my apologies in advance for my ignorance in this area. I'm building a small device to do one-way delay measurements through network. Once I'm done with prototyping, I'm planning a production run of several hundred of the devices. They'll have a GPS receiver, probably a Trimble Resolution SMT, and they have a bit of battery so they can initially go outdoors for ~30 minutes to get a good fix, but then they get taken indoors and plugged into the network, and probably never get a clear view of a GPS or GLONASS satellite again. - From that point forward (and we hope the devices will have an operational life of at least ten years) they'll be dependent on their internal clock and NTP, but we really need them to stay synchronized to within 100 microseconds. 10 microseconds would be ideal, but 100 would be acceptable. And in order to be useful, they need to stay synchronized at that level of precision essentially forever. My plan, such as it is, was just to get the best clock I could find within budget, integrate it onto the motherboard we're laying out as the system clock, and depend on NTPd to do the right thing with it. 10, or even 100, microseconds is tough with NTP. I don't think it is impossible, but it requires a good, reliable network connection and a bunch of work to identify and reduce the systematic errors. And if NTP == ntpd I'm not sure putting a better oscillator on the board is likely to help all by itself since ntpd's magic internal constants are organized to work with the class of oscillators you typically find in computers, and this would need to be redone to do anything useful with something better. I think making use of NTP at the 10-100 microsecond level might require doing your own software, the generic reference implementation probably won't cut it. Before doing that you might consider some alternatives: - If you are deploying this stuff in the US, and if cell phones (particularly Verizon or Sprint phones) work where you are installing the stuff, you might look at this for a time source: http://www.endruntechnologies.com/time-frequency-reference-cdma.htm This is good if it works everywhere you need it, and assuming CDMA networks continue to operate for another 10 years. - Failing that, look at IEEE 1588. The trouble with this is that it severely constrains the kind of network the equipment is attached to, and the gear used to build that network, but if this is in your control you can buy stuff for this without having to build it. If none of the above works, and you just can't get GPS antennas installed, then you may be stuck with NTP, but getting a reliable 10-100 microseconds out of that is a lot closer to the research part of RD then the development part. I don't think running the generic reference implementation, ntpd, will deliver this. Dennis Ferguson ___ 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] Low-long-term-drift clock for board level integration?
On Sun, Feb 19, 2012 at 3:56 PM, Bill Woodcock wo...@pch.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi. This is my first posting to this list, and I'm not a timekeeping engineer, so my apologies in advance for my ignorance in this area. I'm building a small device to do one-way delay measurements through network. Once I'm done with prototyping, I'm planning a production run of several hundred of the devices. They'll have a GPS receiver, probably a Trimble Resolution SMT, and they have a bit of battery so they can initially go outdoors for ~30 minutes to get a good fix, but then they get taken indoors and plugged into the network, and probably never get a clear view of a GPS or GLONASS satellite again. - From that point forward (and we hope the devices will have an operational life of at least ten years) they'll be dependent on their internal clock and NTP, but we really need them to stay synchronized to within 100 microseconds. 10 microseconds would be ideal, but 100 would be acceptable. And in order to be useful, they need to stay synchronized at that level of precision essentially forever. So you can live with a 100 uSec drift over ten years or you say 10 uSec per year is OK. How many uSec are there in one year? I get 3.1E+13. So you can tolerate 10 parts in 3E13 or 1 part in 3E12 drift per year. And you have a $300 budget.Somehow I think either the spec of the budget will have to move by orders of magnitude. Of you can have both with margin to spare if you can keep a GPS antenna in view of the sky continuously Your plan to sync the system to GPS be exposing it briefly to the GPS signal will not work The reason is that, let's say you wanted to adjust your wrist watch by adjusting the fast/slow lever. Assume you have a perfect clock in your house. You adjust the time just fine. But now if you only wait 5 minutes to see if the watch is moving fast or slow you will not get good result. but if you wait a week then maybe you can measure a difference in the two rates.Same for NTP. It needs a bit of time, maybe hours or days to measure the relative rates. The math is not hard. GPS, after it has settled for about an hour or so can get the time to about 50 nano seconds. So you capture the time, Now you wait an hour and capture it again. You could easy have 0.1 uSecond per hour error in the rate. You say you's like 10 uSecond per year. So you need either a better GPS or wait longer than one hour. So it's not like you can sync time to GPS in an instant. it takes at least a few hours if you care about microseconds. Again this becomes easy and within $300 if you can have an outdoor antenna. Chris Albertson Redondo Beach, California ___ 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] Low-long-term-drift clock for board level integration?
Hello Bill, this is potentially possible with the small M9108 or the Jackson Labs Technologies GPSTCXO. Some caveats: 1) The Trimble Resolution-T May work, but the above stated units have a 50 channel WAAS/EGNOS/MSAS GPS receiver and are also GPS Disciplined Oscillators not just timing GPS receivers. The trimble unit may only be a 12 channel receiver like the Resolution-T and doesn't seem to support SBAS? 2) The two mentioned units above may work with indoor GPS reception. This would then be able to get to your 100us goal no problem. Indoor GPS reception depends on your setup, it works better when there are windows that allow signal propagation and multipath to reach the indoors antenna. The antenna won't have to sit next to the window. It will depend on a case-by-case basis if these units can get GPS reception indoors, but we even had units receiving GPS signals inside a metal thermal chamber without an antenna connected(!)... so it may be possible 3) The M9108 has an external 1PPS input you could use to feed a 1PPS signal from a 1588 or NTP system into it as an alternative to the GPS. That 1PPS should be fairly accurate though (within +/-200ns to UTC) to get your 100us per 24 hours holdover accuracy 4) The above units will give you position, velocity, and time as NMEA strings as requested, with WAAS accuracy (typically better than 0.8 meters horizontal rms) when they are used with an outdoor antenna. 5) The above units are priced in the ballpark of your goal in quanity, and have very highly stable oscillators (OCXO and TCXO) that should help with your stability requirements. They are rated at 25ppb and 75ppb over temperature for example, and that would mean you could reach ~100us drift without any external reference (units in holdover) over 24 hours with a +/-5 Degree C temperature variation. bye, Said In a message dated 2/19/2012 19:49:21 Pacific Standard Time, albertson.ch...@gmail.com writes: On Sun, Feb 19, 2012 at 3:56 PM, Bill Woodcock wo...@pch.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi. This is my first posting to this list, and I'm not a timekeeping engineer, so my apologies in advance for my ignorance in this area. I'm building a small device to do one-way delay measurements through network. Once I'm done with prototyping, I'm planning a production run of several hundred of the devices. They'll have a GPS receiver, probably a Trimble Resolution SMT, and they have a bit of battery so they can initially go outdoors for ~30 minutes to get a good fix, but then they get taken indoors and plugged into the network, and probably never get a clear view of a GPS or GLONASS satellite again. - From that point forward (and we hope the devices will have an operational life of at least ten years) they'll be dependent on their internal clock and NTP, but we really need them to stay synchronized to within 100 microseconds. 10 microseconds would be ideal, but 100 would be acceptable. And in order to be useful, they need to stay synchronized at that level of precision essentially forever. So you can live with a 100 uSec drift over ten years or you say 10 uSec per year is OK. How many uSec are there in one year? I get 3.1E+13. So you can tolerate 10 parts in 3E13 or 1 part in 3E12 drift per year. And you have a $300 budget.Somehow I think either the spec of the budget will have to move by orders of magnitude. Of you can have both with margin to spare if you can keep a GPS antenna in view of the sky continuously Your plan to sync the system to GPS be exposing it briefly to the GPS signal will not work The reason is that, let's say you wanted to adjust your wrist watch by adjusting the fast/slow lever. Assume you have a perfect clock in your house. You adjust the time just fine. But now if you only wait 5 minutes to see if the watch is moving fast or slow you will not get good result. but if you wait a week then maybe you can measure a difference in the two rates.Same for NTP. It needs a bit of time, maybe hours or days to measure the relative rates. The math is not hard. GPS, after it has settled for about an hour or so can get the time to about 50 nano seconds. So you capture the time, Now you wait an hour and capture it again. You could easy have 0.1 uSecond per hour error in the rate. You say you's like 10 uSecond per year. So you need either a better GPS or wait longer than one hour. So it's not like you can sync time to GPS in an instant. it takes at least a few hours if you care about microseconds. Again this becomes easy and within $300 if you can have an outdoor antenna. Chris Albertson Redondo Beach, California ___ 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
Re: [time-nuts] Low-long-term-drift clock for board level integration?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Feb 19, 2012, at 7:28 PM, Dennis Ferguson wrote: 10, or even 100, microseconds is tough with NTP. I don't think it is impossible, but it requires a good, reliable network connection… We will have a very large mesh of devices, but the connections between them may be poor. It's my assumption that some of them will be able to get enough GPS signal (or GPS via a GSM BTS, as we also have a Sierra Wireless GSM chipset onboard) and would thus be able to act as Stratum 1 servers for the others. Not that there's any big shortage of Stratum 1 servers out there. It's been a while since I've tried a large mesh of NTP servers, so I don't have much sense of what a reasonable degree of accuracy to expect is. And... I'm not sure putting a better oscillator on the board is likely to help all by itself since ntpd's magic internal constants are organized to work with the class of oscillators you typically find in computers, and this would need to be redone to do anything useful with something better. …you're probably right about that, so my experience probably isn't applicable at all. We've supported a lot of open-source development over the years, so I guess I need to figure out who's most actively doing NTPv4 development now, and see if they want to take a whack at it. - If you are deploying this stuff in the US, and if cell phones (particularly Verizon or Sprint phones) work where you are installing the stuff, you might look at this for a time source: http://www.endruntechnologies.com/time-frequency-reference-cdma.htm Nice, I hadn't seen that before. Only a small portion of our boxes will wind up in the U.S., though, so we're using a Sierra Wireless SL6087 receiver in essentially the same role. - Failing that, look at IEEE 1588. The trouble with this is that it severely constrains the kind of network the equipment is attached to, and the gear used to build that network, Yeah, I did look at it a bit, more to see if there was anything useful to be learned from it than in an attempt to actually use it, since we're connecting through the general-purpose Internet. On Feb 19, 2012, at 7:48 PM, Chris Albertson wrote: So you can tolerate 10 parts in 3E13 or 1 part in 3E12 drift per year. And you have a $300 budget. Somehow I think either the spec of the budget will have to move by orders of magnitude. …or we use something to discipline the clock more often, which is why we've got GPS, GSM, and NTP… I just have to assume that some or all of those either won't work, or won't work well enough to be useful, in many cases. With hundreds or thousands of units in the field, it's much more about trying to make a reasonable general solution than trying to get one thing exactly right… There'll be some sort of bell-curve distribution for the reliability of each of those methods of improving the time, and I'm just trying to figure out the best way to maximize the area under all of those curves within a budget that still allows us to build a useful number of measurement devices. So it's not like you can sync time to GPS in an instant. it takes at least a few hours if you care about microseconds. Yeah, the Trimble guys ran some numbers and figure that we can get single fixes with ~100 microsecond accuracy in twenty minutes, with the chipset they're selling us. The tradeoff in battery size to get that down one more order of magnitude isn't worthwhile… It would push the battery up from $35 to $200, and more battery doesn't have much collateral benefit in our application. Again this becomes easy and within $300 if you can have an outdoor antenna. The number of sites where anyone would be able to install and maintain an outdoor antenna would be way out under one of the skinny ends of those bell curves, so essentially not worth spending any time thinking about. If wishes were horses, etc. Thank you very much for the advice. -Bill -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPQdVKAAoJEG+kcEsoi3+HTNUQAIx0EzXPiYPtKeogyFdw+L3s kg1TvnM847NwavbwoY82Z1XMQ1MLZHVitR+xIbDmR45jUa73ZreD5PD9PfGZ7iej /LPzrc+6MIi6nHJjeMF5u73IJ0oHx5Guri3Z1iANBaOFSQjioEfQOwOSs/H0ysN2 HpETfLLzxSlLg55Fg7HUq6zFZ12i8HeBrngbWbMPRTUyjU+DosV4MbOoYS3o8QVO hWyvkMq4tIgbunKJgYm4+zDww52J2e4NlOWqqWW6cYRJ07A+gpfJa3lJgyutRV6o 4CTYR0ZecMN4kSgzpvqWyleweBftn0dCQ+Zb4F3GIJG33fehq+POmQQAQUbbdmCZ bbQAXpgHWN+BufRvwm+UiP9fK1GWO6f1CCFRbwbIFCE3jKlKzKjQWIW/vn+DR8eK GsPvMqCKP3YiJNdCqd8dVEMgJN+t3qksEHgn0k3hUNsKHfVGjs2BzPz49TPBm/Ik eXp3f9ZiXqZ0NFb4mCx5Zfl/8ZI3jN4hPxa8ktMr4NDK+uiDgeuNj+vKjWKW6sxC MKbHG6VGyfWoULTJ+DFOw+uTkA7Xb8GseBC/f05tNw5cLUg2j9I3XlsZPpAUbiET zQGceSSVIyyVht9F+y4qGJG+N8IqTa5LVsyCtHKgVy+RECV9QaPUG5hF37VbvhGT etC2gTjqXt6hnegVE+jG =QCcW -END PGP SIGNATURE- ___ time-nuts mailing list
Re: [time-nuts] Low-long-term-drift clock for board level integration?
On Sun, Feb 19, 2012 at 5:48 PM, Bill Woodcock wo...@pch.net wrote: .. So that's something I've been having a hard time understanding… If that's the amount of inaccuracy _per oscillation_, then at the time-scales I'm dealing with, it would quickly accumulate and become unuseful… I think you have it right. There are two things (1) the RATE of a clock and (2) the PHASE of a clock. The phase is the time between a true UTC per second tick and the tick on your clock. When you see that your wrist watch is 5 seconds different from another, that is five seconds of phase. Phase is measure in units of duration, like 1 uSec or 5 seconds Rate is is always per unit time. A perfect clock runs at one second per second. Sorry if this is to obvious. That is my point. It's not rocket science.(See Below, I think NTP might work for you if you are willing to push the state of the art forward with some purpose built hardware. Now about GPS and NTP. It's huge advantage is that if you average over enough time it runs at one second per second rate, exactly The trouble is the noise in the phase. NTP over the Internet has tens of milliseconds on uncertainty in the phase. It is useless for what you want. You need uS not mS. GPS also has some uncertainty in the phase on the order of about between 1uS and 10nS depending at the type of GPS and how much care was used in setting it up. You need a good site survey and time for an OXCO to reach equilibrium to get good time data. Turn on your basic consumer level Garmin and you get time to about 1/2 second. Yes it really can be that poor. You are correct if the rate is wrong by X the phase will drift at X per unit time and soon can be very far off. What you do with NTP or GPS is work the other way: NTP tells you the time (plus or minus say 1 mS) So you wait 1,000 seconds and get the time again. Now you now your RATE to within 2mS per 1,000 seconds or to within 2uS per second. In theory you could wait 1,000,000 seconds and get better rate determination but what kills you is that we must assume the local clock's rate is constant for this to work. It is maybe constant enough over 1,000 seconds but certainly not over 10K seconds unless you spend that $300 budget on a good local oscillator. If you do then NTP can use a very long time constant in it's loop.Typical NTP software can't use such a long time constant because typical local clocks are cheap ($2 or less) 20PPM crystals. If you can afford 20PPB (1000 times better) you just might, maybe be able to get uSecond level time from NTP over a network. But how long would that take? Can your users wait 100,000 seconds? You will be pushing the current state of the art. Most everyone finds it is easier to simply connect to GPS. GPS is the same as NTP but has less uncertainty so you can get good rate determination with a MUCH shorter integration time. If you are willing to build a custom motherboard around an OCXO and modify some system software and right a custom NTP driver you just might get to 100X better than is typical. It sure would be a fun experiment to have NTP try and discipline a Rubidium oscillator New TOPIC:Mmaybe there is a better way? Sounds like your system uses absolute time to measure time intervals. Better maybe to use relative time.Maybe for example your units all ping each other at some rate. then you measure time relative to the ping rate. All your units know the ping rate and don't need to know the wall clock time as they have their own time unit. later you can figure out the conversion for ping rate to seconds. It could be very accurate. If say you want to measure the time to do one HTTP request then you send 1000 HTTP requests and you see that you got 13,500 pings per 1000 HTTPs, the ratio is 13.5:1. Just make up your own unit of time Chris Albertson Redondo Beach, California ___ 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] Low-long-term-drift clock for board level integration?
... but then they get taken indoors and plugged into the network, and probably never get a clear view of a GPS or GLONASS satellite again. A high-sensitivity GPS receiver might still give useful results here, especially if it has a high-quality reference oscillator like an OCXO. Even 20 or 30 dB of path loss from roof to your device might be manageable. Of course, your deployment environment could well be worse. Since you get an initial fix outdoors, you could tell the GPS unit its location, then put it in time-only mode, which needs only a single usable satellite. This is the usual mode for timing receivers. If the number of satellites drops to zero, though, an OCXO will not hold over for long inside a 10 microsecond window. Cheers, Peter ___ 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] Low-long-term-drift clock for board levelintegration?
Hello Bill Woodcock, Many, many questions come to mind. Is this a fixed network that never changes its character ? Or by network do you mean via the internet where you have no control over path variations ? I guess the latter based upon your comments thus far. What is driving the requirements of your delay measurements ? Are they realistic ? It seems to me that to do a one-way delay measurement, the precise absolute time of transmission would be quite important. Otherwise how would you know the start of the timing pulse ? How would you otherwise account for variables in the path ? Doing a few fixes for 30 minutes will, under best conditions, get you somewhere on a circumference around your location with a radius of 15 meters (50 feet). For GPS to get a useful coordinate result with meaningful data will take longer than 30 minutes or so. Typically, you would want to do a 48 hour survey of your position to try to achieve a 3 to 5 meter resolution. However, that only gives you an idea of where the GPS antenna was located and specifically not where the start of the path is located. Your intended use of GPS will not help you with the time at all because once you lose the GPS signals (i.e., going back inside the building) the reported time is meaningless because the GPS internal oscillator is no where near stable enough to maintain that time properly. This is the case for all but a few special GPS units. Trying to study SC verses AT cut crystals and other minutiae is a complete waste of your time. Either one in its proper circuit will do the same job. No matter which, for any decently designed ovenized oscillator, it takes 30 days to truly achieve stable thermal equalibrium and reach the best specifications, as to drift, for that particular unit. In the mean time transporting, jarring around and warmup retrace factors will guarantee the oscillator will not be where it was at its last long term runup. Not knowing the requirements for your measurements makes it tough to give any meaningful answers. Clearly, it seems that your needs are to correlate data from many nodes at indeterminate positions. If this is truly the case, then time would be the critical factor that needs to be focused on, more so then location in my opinion. If so, then your budget may need to increase more than your planning for. BillWB6BNQ Bill Woodcock wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Feb 19, 2012, at 5:07 PM, Bill Hawkins wrote: If you are going to correct it with NTP, a simple crystal oscillator will do. Yeah, my assumption was that something like a DOCXO or a VCTCXO would be about the best I'd get within budget. But I'm very new to this, and just beginning to dip into all the articles about SC cut versus AT cut, etc. If you're using NTP, why do you need to initially set it to GPS accuracy? We need the GPS fix for location, and get the time for free, so figured we'd use it. Your best solution is to maintain the GPS antenna and only use GPS to discipline a good crystal oscillator. That would be nice, of course, and we'll get the best GPS antenna we can afford and fit, but we can't have an externally-cabled antenna, or require that people put these on windowsills, or anything like that⦠There will be too many of them, and the level of clue of the people plugging them in out in the field is likely to be too low. Do you plan to regulate the ambient and power environment to some degree of accuracy? Yes⦠They'll all be indoors, which helps, and temperature-regulated crystals seem to be relatively widely available, if in a dizzying number of styles. Regulated power is something that we need to just have someone spec out, or use a reference design, if one exists. Anyone have pointers? Note that 10 microseconds is 1 part in 10E5. The folks on this list deal in parts per 10E12. So that's something I've been having a hard time understanding⦠If that's the amount of inaccuracy _per oscillation_, then at the time-scales I'm dealing with, it would quickly accumulate and become unuseful⦠that is, 10 microseconds of drift per second is almost a second of drift in a day, whereas I need, ideally, something I can discipline to within 100 microseconds _total_, using just a single GPS fix, plus NTP over the long haul. Now, I don't know whether what I want is possible or not, but that's why I'm asking these questions. Or am I misunderstanding the parts-per-foo notation? Can you use a standalone receiver to always generate a 10 MHz signal or pulse per second signal that is distributed to all of the measurement devices in a facility? There will only be one device per location, and we can't have any external stuff plugged into them. Else yes, I'd just use GPS and be done with it. -Bill Bill Woodcock wrote: -BEGIN PGP SIGNED
Re: [time-nuts] Low-long-term-drift clock for board level integration?
From that point forward (and we hope the devices will have an operational life of at least ten years) they'll be dependent on their internal clock and NTP, but we really need them to stay synchronized to within 100 microseconds. 10 microseconds would be ideal, but 100 would be acceptable. And in order to be useful, they need to stay synchronized at that level of precision essentially forever. It's going to be interesting. I suggest you start experimenting. How good a crystal do you need if you run without NTP? Note that you don't need accuracy, just stability. Software can correct for a frequency that is slightly off. NTP calls it drift. Let's play with some numbers. Let's talk about 3 years. That's 94608000 seconds, or 1E8, a handy round number. So if your clock is off by 1 part in 1E8, it will drift 1 second in 3 years. You need 100 microseconds, or 1E-4, so you need a clock good for 1E-12. Here is a typical high end OCXO. (It may blow your budget, but we can use it as an example.) http://www.mti-milliren.com/ocxo_270_ocxo.html The typical 5 MHz aging performance is 5E-10 per day and 5E-08 per year. That's not in the right ballpark. So, can you do it in software? After the typical NTP packet exchange, you have 4 time stamps. The (local) time the request left the client, the time it arrived at the server, the time the response left the server, and the time it got back to the client. You have 3 unknowns: transit time out, transit time back, and clock offset. From the timestamps, you get two equations: the transit times fudged by the clock offset. NTP assumes that the network is symmetric. That's the 3rd equation that lets it compute the clock offset which it uses to correct the local clock. If you assume the local clock is accurate, you can compute the network delays. There is a chicken-egg problem. You can't do both at the same time. If you have a lot of NTP data and everything goes right, you get a picture like the one here: http://www.eecis.udel.edu/~mills/ntp/html/huffpuff.html You need to know how sharp the point on the left is. That depends on the network path between your box and the NTP servers you are using. The traffic pattern on the last hop (from your site to your ISP) is likely to be the nasty part. In my experience, getting to 100 microseconds is going to be hard. I wouldn't call it impossible, but it sure won't be easy. Suppose you can find good NTP servers with a stable network path. If you collect a bunch of data the packets with the minimum total network delay will be the ones that didn't encounter any queuing delays in the network. If you cross your fingers and assume the network path is symmetric, you now have a good measure of the clock offset. If you remember that transit time and only use packets with similar transit times, you should be able to get good results. There are a lot of loose ends in there. The reference version of ntpd used by most Unix like OSes is setup to run on typical PCs and servers. Their crystals are actually a pretty good thermometers. :) http://www.ijs.si/time/temp-compensation/ If you have a good crystal (good, not great) it should be possible to ride over busy periods when you don't get any packets with short delays. That would be nice, of course, and we'll get the best GPS antenna we can afford and fit, but we can't have an externally-cabled antenna, or require that people put these on windowsills, or anything like that⦠There will be too many of them, and the level of clue of the people plugging them in out in the field is likely to be too low. How are you going to find good NTP servers for all your boxes? Are you targeting homes, offices, or machine rooms? GPS works inside my house. (Not great, but good enough.) Are you trying to measure arrival times of packets you control, or get accurate times from tcpdump/wireshark on arbitrary traffic? Can you post-process the data? I'm thinking of something like get a reasonably good crystal and let your system run off that crystal without trying to get time from the network. The idea is to keep NTP from doing something stupid. You can poke it occasionally from a central server to track the long term drift. Or setup nearby servers in noselect mode, turn on logging, and get the info out of the log files. -- These are my opinions, not necessarily my employer's. 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] Low-long-term-drift clock for board levelintegration?
In a message dated 2/19/2012 21:21:35 Pacific Standard Time, wb6...@cox.net writes: Doing a few fixes for 30 minutes will, under best conditions, get you somewhere on a circumference around your location with a radius of 15 meters (50 feet). For GPS to get a useful coordinate result with meaningful data will take longer than 30 minutes or so. Typically, you would want to do a 48 hour “survey” of your position to try to achieve a 3 to 5 meter resolution. However, that only gives you an idea of where the GPS antenna was Bill, that may have been true for some older commercial GPS receivers, but not for the newer high performance receivers. We did flight testing of our FireFly-IIA unit fed from a GPS simulator, and the results are: better than 0.8 meters horizontal accuarcy rms better than 2.1 meters vertical accuracy rms This was then verified in a Turboprop airplane. This was in the USA with WAAS being active. 30 minutes should be more than enough to get a position with the above accuracy at very high confidence levels. bye, Said ___ 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] Low-long-term-drift clock for boardlevelintegration?
Hi Said, That may be, but I think he indicated he was using the common hobby type units. I seriously don't think they measure up to your unit. I should have stated I was speaking specifically about GPS by itself not using differential methods. Your comments are noted, however. Thanks, BillWB6BNQ saidj...@aol.com wrote: In a message dated 2/19/2012 21:21:35 Pacific Standard Time, wb6...@cox.net writes: Doing a few fixes for 30 minutes will, under best conditions, get you somewhere on a circumference around your location with a radius of 15 meters (50 feet). For GPS to get a useful coordinate result with meaningful data will take longer than 30 minutes or so. Typically, you would want to do a 48 hour âsurveyâ of your position to try to achieve a 3 to 5 meter resolution. However, that only gives you an idea of where the GPS antenna was Bill, that may have been true for some older commercial GPS receivers, but not for the newer high performance receivers. We did flight testing of our FireFly-IIA unit fed from a GPS simulator, and the results are: better than 0.8 meters horizontal accuarcy rms better than 2.1 meters vertical accuracy rms This was then verified in a Turboprop airplane. This was in the USA with WAAS being active. 30 minutes should be more than enough to get a position with the above accuracy at very high confidence levels. bye, Said ___ 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] Low-long-term-drift clock for boardlevelintegration?
Hi Bill, the good news is that industrial units are becoming as inexpensive as hobby type units.. bye, Said In a message dated 2/19/2012 21:48:36 Pacific Standard Time, wb6...@cox.net writes: Hi Said, That may be, but I think he indicated he was using the common hobby type units. I seriously don't think they measure up to your unit. I should have stated I was speaking specifically about GPS by itself not using differential methods. Your comments are noted, however. Thanks, BillWB6BNQ ___ 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] Low-long-term-drift clock for board level integration?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Feb 19, 2012, at 9:02 PM, saidj...@aol.com wrote: this is potentially possible with the small M9108 or the Jackson Labs Technologies GPSTCXO. Thanks for the pointer to both of them… It looks like Jackson Labs have several interesting similar products, and I didn't know about them before. I'll give them a call. 1) The Trimble Resolution-T May work, but the above stated units have a 50 channel WAAS/EGNOS/MSAS GPS receiver and are also GPS Disciplined Oscillators not just timing GPS receivers. The trimble unit may only be a 12 channel receiver like the Resolution-T and doesn't seem to support SBAS? With and without integrated oscillators: http://trl.trimble.com/docushare/dsweb/Get/Document-50/022542-014A_ICM-SMT_DS_US_08_11.pdf http://trl.trimble.com/docushare/dsweb/Get/Document-454103/Resolution-SMT_DS.pdf My understanding was that they support WAAS but not EGNOS, but I may be misremembering. Admittedly, the Trimble datasheets are a little short on hard numbers. It will depend on a case-by-case basis if these units can get GPS reception indoors, but we even had units receiving GPS signals inside a metal thermal chamber without an antenna connected(!)... so it may be possible I just spent the day in a facility that was four stories underground, and managed to get some intermittent GSM coverage, so yeah, my faith in radio waves is a little higher than average, today. Anyway, yes, I presume that we'll be able to get some GPS, some of the time, in some locations. Just trying to optimize it as much as possible, by getting the best internal antenna I can find within budget, for instance. On Feb 19, 2012, at 9:19 PM, Peter Monta wrote: Since you get an initial fix outdoors, you could tell the GPS unit its location, then put it in time-only mode, which needs only a single usable satellite. This is the usual mode for timing receivers. Yep, that's one of our requirements. On Feb 19, 2012, at 9:20 PM, WB6BNQ wrote: By network do you mean via the internet where you have no control over path variations? Yes, the general-purpose Internet. What is driving the requirements of your delay measurements? In large part, we need sub-millisecond accuracy in order to distinguish asymmetric components in paths between our measurement boxes. Which, as Mr. Murray points out, is a chicken-and-egg problem, if we turn to NTP to discipline the clock. It assumes symmetric paths, which is an invalid assumption, but impossible to correct without accurate time. Thus, we want to have accurate time. :-) It seems to me that to do a one-way delay measurement, the precise absolute time of transmission would be quite important. Otherwise how would you know the start of the timing pulse ? How would you otherwise account for variables in the path ? Exactly. Your intended use of GPS will not help you with the time at all because once you lose the GPS signals (i.e., going back inside the building) the reported time is meaningless because the GPS internal oscillator is no where near stable enough to maintain that time properly. This is the case for all but a few special GPS units. Right, we were only considering the special ones, that either have an integrated oscillator, or that are built specifically to feed a good oscillator. Trying to study SC verses AT cut crystals and other minutiae is a complete waste of your time. Either one in its proper circuit will do the same job. Fair enough. Yeah, this is a huge field, and I'm trying to pick up as much of it as I can as quickly as I can, but there's a tremendous amount of detail that I will undoubtedly miss. Good to hear that some of it doesn't matter too much. :-) No matter which, for any decently designed ovenized oscillator, it takes 30 days to truly achieve stable thermal equalibrium and reach the best specifications, as to drift, for that particular unit. In the mean time transporting, jarring around and warmup retrace factors will guarantee the oscillator will not be where it was at its last long term runup. That probably won't be a problem, as I think most of these boxes will be installed and then not touched again for very long times. The exception are the ones that we're going to have to put on taxicabs and busses, which will be a separate production run; they'll be really bad environments for oscillators, but much better for GPS/GLONASS/Galileo. On Feb 19, 2012, at 9:26 PM, Hal Murray wrote: Note that you don't need accuracy, just stability. Software can correct for a frequency that is slightly off. Yeah, that was the distinction I was trying to figure out the terminology for. Thanks. So if your clock is off by 1 part in 1E8, it will drift 1 second in 3 years. You need 100 microseconds, or 1E-4, so you need a clock good for 1E-12. I think a box that can't get some external source of time in three years is
Re: [time-nuts] Low-long-term-drift clock for board level integration?
On 19 Feb, 2012, at 21:08 , Bill Woodcock wrote: It's my assumption that some of them will be able to get enough GPS signal (or GPS via a GSM BTS, as we also have a Sierra Wireless GSM chipset onboard) and would thus be able to act as Stratum 1 servers for the others. In the US I suspect all GSM base stations have GPS available (E911 support generally requires it), but I think you may find that in many (most?) other countries the GSM BTS gear has no idea what time it is. GSM doesn't require the time synchronization (it requires frequency, but they can often recover that from the tail circuit connecting the BTS to the network), so in many places they do without GPS either to save money or because the carriers are subject to regulatory requirements to avoid allowing the country's telecommunications facilities to become dependent on GPS (I assume because their regulators don't fully trust the owners of GPS)… GPS can sometimes work under non-optimum circumstances, but it sounds like you have run out of fallback options apart from trying to advance the state of the NTP art. Dennis Ferguson ___ 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] Low-long-term-drift clock for board level integration?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Feb 19, 2012, at 10:20 PM, Dennis Ferguson wrote: I think you may find that in many (most?) other countries the GSM BTS gear has no idea what time it is. Pretty wide range there… I've certainly seen some pretty crazy time-and-dates show up on my phone upon landing in some countries. But it's been a while since I've gotten a weird one in Europe or the more developed parts of Asia. Africa and South and Central Asia are pretty much all over the map, though. -Bill -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPQejmAAoJEG+kcEsoi3+H1E4P/jYB0QRd5zUMBVUQdpc48xSX kwzZv/TmYUhTGkyBKifbeDrcTEmNmov9GscB+25oObEE6nfoSansDUJV0dxK6ux/ BPsMfYWZraTv3AJFJwGQ+R8ab9JTts/FgNoBUWCOaQwPkAN6lWE0LHU+8TW5o59R LFIeZ7tsD6BnIS+kiSLsLxrAQ6RzvxtzOwZXxCejGl04VwG6NcrfE/kJjzTn6WLk 0eanG6fvqZUdNQaD37uCZKf0SDneV9EKBIkoUMK+n3X1MS4N5gNQ3uFM/rli9JGz R7Cd2x1AgJzddNR+aOlPTTv//eWKR/nBiR2AHZRx8PjbzGrziQHVRakiJdeyqWa2 X09AKlSnaeG2+ZAFLUAxJbL2YJFSqMo/9RgTQKc65VQ7anA13OxxpioJ5W5vW+h5 E5uCMdQE7SKuChdkb+8dWJPvq4wYNwBT6MyDcvMqSQrEnDEcc/0NDsPPhHjcOKW5 ZR+1ASncyQYymI17aOHVYpLnW89bu2gUADzhfTviWLHzEgiDL9qSCVtIR5IiFVOj 8sAM+uTnd6He/96EWd6vIguY6IOGAVQX1RGBhXhOsm26Hhx11p3qAEhzuGHJLZZ2 N3bMQD8hJcFhKh0b6TkeC7a1QI2cr6cH0dKd74YnUFuJDK/NGixUUzZ1azP+iHkR kvdseSQTGWaRrpWWY+5f =H8L/ -END PGP SIGNATURE- ___ 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] Low-long-term-drift clock for board level integration?
Here is a typical high end OCXO. (It may blow your budget, but we can use it as an example.) http://www.mti-milliren.com/ocxo_270_ocxo.html The typical 5 MHz aging performance is 5E-10 per day and 5E-08 per year. That's not in the right ballpark. Here's another way to look at it. A typical quartz frequency aging rate of 5E-10 per day means you could be off by 5e-10 in frequency a day later, which means you are now off by 20 microseconds in time at the end of the first day. Time error grows linearly with frequency error and quadratically with linear frequency drift (time error = fe * t + 1/2 * fd * t^2). After 2 days you will be off by only 1e-9 in frequency but a total of 80 microseconds in time. Assuming the linear frequency drift trend continued, at the end of a week you're under 4e-9 in frequency error but the time error will now have grown to 1 ms! And this is under laboratory conditions... So this is why you have to use an external timing reference. /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] Low-long-term-drift clock for board level integration?
Hi Bill, should have added a disclaimer, I am involved with Jackson Labs Tech.. The Trimble part with oscillator looks interesting, probably an NCO not a GPSDO I would think. They are as usually not putting any real data in their specsheets.. The TCXO they are using will determine performance in hodover mode, so it would be interesting to see the thermal spec on that unit. Do you know what price point they are looking at? bye, Said In a message dated 2/19/2012 22:18:46 Pacific Standard Time, wo...@pch.net writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Feb 19, 2012, at 9:02 PM, saidj...@aol.com wrote: this is potentially possible with the small M9108 or the Jackson Labs Technologies GPSTCXO. Thanks for the pointer to both of them… It looks like Jackson Labs have several interesting similar products, and I didn't know about them before. I'll give them a call. 1) The Trimble Resolution-T May work, but the above stated units have a 50 channel WAAS/EGNOS/MSAS GPS receiver and are also GPS Disciplined Oscillators not just timing GPS receivers. The trimble unit may only be a 12 channel receiver like the Resolution-T and doesn't seem to support SBAS? With and without integrated oscillators: http://trl.trimble.com/docushare/dsweb/Get/Document-50/022542-014A_ICM-S MT_DS_US_08_11.pdf http://trl.trimble.com/docushare/dsweb/Get/Document-454103/Resolution-SMT_DS .pdf ___ 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.
