Re: [time-nuts] An embedded NTP server
albertson.ch...@gmail.com said: The VXCO quality hardly matters for an NTP server. As long as it does not gain out loose more then 1 uSecond per second. In other words one part per million is fine for NTP. The goal is not to produce a 10MHz GDPDO. Clients using this server over the Ethernet are happy to keep time ti 1 millisecond. This is time nuts. It's always fair game to discuss how good things are and/or how to make them better. :) The reference NTP package goes to a lot of work to figure out how far off the clock is and tell the kernel so it can keep (much) better time. In many systems, that's a pretty good thermometer. Another thing the reference package tries to do is stretch out the polling interval to minimize load on the network and servers. It's trying to find the bottom of the ADEV curve. The default range is 64-1024 seconds. It keeps track of it on disk to PPB. That doesn't work very well if the temperature/frequency isn't stable. The temperature swing with load change has probably gotten worse with newer machines. It would be interesting to see what ntpd would do on a system with a very good clock and/or what you could do to the code/heuristics to take advantage of a stable clock. Most (almost all) NTP servers use a TTL can oscillator. Are you sure? Or what's the current practice? A while ago (several/many years?) it was common for Intel boxes to have a clock generator chip. They ran off the standard 14.xxx MHz crystal and generated clocks for the CPU, PCI, USB, ... It usually included the spread spectrum hack. The ARM SOC chips I've worked with had similar stuff on chip. You connect up a crystal. It has an amplifier to make an oscillator and PLLs to make whatever clocks are needed. -- 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.
[time-nuts] clock-block any need ?
hi, I want to setup a time servere so I saw in many configuration that a clock-block was used, do I need it too ? what are the benefits ? thanks, Dan ___ 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] clock-block any need ?
The Clock-Block is a clock generator that is useful if you want to replace the computer's onboard crystal clock with an external high-stability source. For example, you can configure it to take a 10 MHz input from a GPSDO and create a 14.318182 MHz output to replace the crystal in a PC that uses that frequency. The external clock improves the NTP system's short term stability because the typical PC crystal is quite temperature sensitive and overall just isn't very good. You do not need to use something like the Clock-Block to build a very good NTP server, but if you want to build the *ultimate* server it is part of the mix. John On Dec 27, 2012, at 8:43 AM, Dan Nica t...@crystal.rdstm.ro wrote: hi, I want to setup a time servere so I saw in many configuration that a clock-block was used, do I need it too ? what are the benefits ? thanks, Dan ___ 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] Need info on Trimble Trooper
If anyone has interfacing info on the Trimble Trooper GPS disciplined oscillator I'd appreciate hearing from you. Per Trimble the Trooper was a contract manufactured device so they will not release documentation directly. Thanks in advance 73, Lenny W2BVH ___ 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] clock-block any need ?
You do not need to use something like the Clock-Block to build a very good NTP server, but if you want to build the *ultimate* server it is part of the mix. Yes this is true. The server can be very good, meaning that if it were better the clients that it servers could not know the difference. A simple is if a wall clock moved the hands with millisecond precision, it would not serve the clients (human eyeballs) any better if it moved with nanosecond precision because human perception is measured in mS not nS. Same with the time server, it communicates with its clients over a network that has someuncertainy in th delay and ultra-presision is lost. So nanosecond level timekeeping in the server is not required. You can do uSec level time keeping with the standard TTL can on most mother boards. However this list is for nuts and you might think it is fun to try and do 1000 times better time keeping than is needed, in that case you will need some kind of specialized clock hardware. Most nuts, I think would like to have a microsecond level wall clock even if it were pointless. -- 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.
[time-nuts] New to Time Synching hardware - needing some advice
Hello I am new to time synching hardware but have done Linux NTP so I have a little experience in that but I need some advice for a different project. I have a PC running Linux that I would like to have on a stable time with roughly 10 millisecond accuracy however this machine is located in a place where it cant get network, GPS, or radio signals. Is there something like an Atomic Clock that I could set to the correct time over radio/gps/network and then take this box to the PC? Anything that I have looked at just assumes that you have a continuous outside connection from somewhere. Roy ___ 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] New to Time Synching hardware - needing some advice
Why not a gpsdo in holdover?? On Thu, Dec 27, 2012 at 12:52 PM, Roy B saska...@hotmail.com wrote: Hello I am new to time synching hardware but have done Linux NTP so I have a little experience in that but I need some advice for a different project. I have a PC running Linux that I would like to have on a stable time with roughly 10 millisecond accuracy however this machine is located in a place where it cant get network, GPS, or radio signals. Is there something like an Atomic Clock that I could set to the correct time over radio/gps/network and then take this box to the PC? Anything that I have looked at just assumes that you have a continuous outside connection from somewhere. Roy ___ 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] New to Time Synching hardware - needing some advice
Yes you could us something like one of the low-cost rubidium oscilators to supply a pulse per second to Linux NTP and it would work for some time before the error was as large as 10 mS. One missing requirement is how long you need be without GPS or networking. Obviously you can't stay out of contact with the world forever but it is very easy and cheap if you only need a day. Harder if you need a month and expensive if you are talking about years. Let's say there are on-order of 100,000 seconds in a day. You can tolerate 0.01 second error. So, can tolerate a one part in 10,000,000 drift in the clock per day. That is the kind of thingking you need to do to come up with a clock requirement. All it takes in money and you can get almost whatever you need. But don't over-specify your needs you it will cost you, a bunch. On Thu, Dec 27, 2012 at 9:52 AM, Roy B saska...@hotmail.com wrote: Hello I am new to time synching hardware but have done Linux NTP so I have a little experience in that but I need some advice for a different project. I have a PC running Linux that I would like to have on a stable time with roughly 10 millisecond accuracy however this machine is located in a place where it cant get network, GPS, or radio signals. Is there something like an Atomic Clock that I could set to the correct time over radio/gps/network and then take this box to the PC? Anything that I have looked at just assumes that you have a continuous outside connection from somewhere. Roy ___ 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. -- 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] New to Time Synching hardware - needing some advice
On Thu, 27 Dec 2012 10:19:46 -0800 Chris Albertson albertson.ch...@gmail.com wrote: Yes you could us something like one of the low-cost rubidium oscilators to supply a pulse per second to Linux NTP and it would work for some time before the error was as large as 10 mS. One missing requirement is how long you need be without GPS or networking. Obviously you can't stay out of contact with the world forever but it is very easy and cheap if you only need a day. Harder if you need a month and expensive if you are talking about years. Actually, a couple of months is still quite simple. The Rb approace gives you at least something in the range of 10^-9 stability, long term. Which gets you into the ballpark of 100 days (with 10ms). If you temperature stabilize the Rb you should get down to 10^-11, which would be 30 years. At least theoretically, aging is AFAIK larger than this. But a couple of years should be still possible without too much effort. IIRC the FE5680 sell now for 200USD. Some heatsink and temperature control come maybe at 50-100USD. Some equipment to measure where the PPS lies relative to UTC and a powersupply that can get you 15V from mains and a battery (to get the Rb where the computer is) would also be necessary. Alternatively, put the Rb next to the computer in question, hook a powerfull linedriver to the PPS output, and a wire that goes all the way out where you have GPS reception and can measure the PPS pulse. After measurement, you can remove that cable. Ofcourse this only works, if you can lay a cable temporarily. If you are in a EMP secured room, the only way to get the pulse measured is the approach with the traveling Rb. Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ 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] New to Time Synching hardware - needing some advice
It could be possible to use two Rb GPSDOs, one providing the PPS and another disciplined by GPS, then rotate them every month. On Fri, Dec 28, 2012 at 2:41 AM, Attila Kinali att...@kinali.ch wrote: On Thu, 27 Dec 2012 10:19:46 -0800 Chris Albertson albertson.ch...@gmail.com wrote: Yes you could us something like one of the low-cost rubidium oscilators to supply a pulse per second to Linux NTP and it would work for some time before the error was as large as 10 mS. One missing requirement is how long you need be without GPS or networking. Obviously you can't stay out of contact with the world forever but it is very easy and cheap if you only need a day. Harder if you need a month and expensive if you are talking about years. Actually, a couple of months is still quite simple. The Rb approace gives you at least something in the range of 10^-9 stability, long term. Which gets you into the ballpark of 100 days (with 10ms). If you temperature stabilize the Rb you should get down to 10^-11, which would be 30 years. At least theoretically, aging is AFAIK larger than this. But a couple of years should be still possible without too much effort. IIRC the FE5680 sell now for 200USD. Some heatsink and temperature control come maybe at 50-100USD. Some equipment to measure where the PPS lies relative to UTC and a powersupply that can get you 15V from mains and a battery (to get the Rb where the computer is) would also be necessary. Alternatively, put the Rb next to the computer in question, hook a powerfull linedriver to the PPS output, and a wire that goes all the way out where you have GPS reception and can measure the PPS pulse. After measurement, you can remove that cable. Ofcourse this only works, if you can lay a cable temporarily. If you are in a EMP secured room, the only way to get the pulse measured is the approach with the traveling Rb. Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ 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] clock-block any need ?
On 27 Dec, 2012, at 08:05 , Chris Albertson albertson.ch...@gmail.com wrote: You do not need to use something like the Clock-Block to build a very good NTP server, but if you want to build the *ultimate* server it is part of the mix. Yes this is true. The server can be very good, meaning that if it were better the clients that it servers could not know the difference. A simple is if a wall clock moved the hands with millisecond precision, it would not serve the clients (human eyeballs) any better if it moved with nanosecond precision because human perception is measured in mS not nS. Same with the time server, it communicates with its clients over a network that has someuncertainy in th delay and ultra-presision is lost. So nanosecond level timekeeping in the server is not required. You can do uSec level time keeping with the standard TTL can on most mother boards. However this list is for nuts and you might think it is fun to try and do 1000 times better time keeping than is needed, in that case you will need some kind of specialized clock hardware. I don't think I buy this. It takes 70 milliseconds for a signal transmitted from a GPS satellite to be received on the ground, but we don't use this fact to argue that sub-70 ms timing from GPS is not possible. If you have a network of high-bandwidth routers and switches doing forwarding in hardware, and carrying no traffic other than the packets you are timing (I have access to lab setups that can meet this description) you can observe packet delivery times that are stable at well under the microsecond level even though the total time required to deliver a packet is much larger. If you add competing traffic, like real life networks, the packet-to-packet variability becomes much worse, but this is sample noise that can be addressed by taking larger numbers of samples and filtering based on the expected statistics of that noise. That is, the level of noise effecting each individual sample entering the filter does not alone predict the noise level of the result coming out, the latter also depends on the number of samples and the quality of the model of the noise employed by the filter. Note that I often see claims of time synchronization with PTP at the 10 ns level or better. As this level of synchronization is usually achieved by the brute force method of measuring transit times across every network device on the path from source to destination I have no doubt that what NTP can do will necessarily be worse than this, but I don't know of a basis that would predict whether NTP's worse is necessarily going to be 10,000x worse or can be just 10x worse. Knowing that would require actually trying it to measure what can be done. What is certain, however, that if you want to measure this at the levels that might be possible you probably want nanosecond-level clock hardware in both the server, so that it can produce time of this quality, and in the clients, so that you can measure how well they do directly rather than attempting to have the NTP implementation grade its own homework. I don't think this is a waste of time at all. The best case is that the ability to measure at this level would lead to an understanding of what it would take to transfer time with NTP at this level, but even the worst case would be that one would be able to support one's assertions about what can't usefully be done with data, and that's not bad either. If no one tries then no one will ever know. 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] New to Time Synching hardware - needing some advice
IIRC the FE5680 sell now for 200USD. Some heatsink and temperature control come maybe at 50-100USD. Some equipment to measure where the PPS lies relative to UTC and a powersupply that can get you 15V from mains and a battery (to get the Rb where the computer is) would also be necessary. I suspect the cost of the Rb from eBay is nothing compared to the equipment yu will need to verify proper operation of the finished system. You of course would need to do LOTS of detailed testing (many test runs at different room temperatures) before you took the system down into your coal mine, submarine or where ever. You'd need a way to compare your system to GPS and unless you have a year to test you need a very sensitive test so you can detect drift in only a few hours, not months. Like I said your test rig will cost more than the device under test. This will be more and more the case the longer your hold-over requirement. 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.
[time-nuts] 2.5 Ghz 12 digit counter project
Did anyone see the article in the December Silicon Chips magazine about building a 12 digit 2.5 GHz counter? It has an option for a GPS 1pps input so you could have some expectation that the last couple of digits mean something. The website only has the article cover page in pretty much unreadable type. -- Paul Amaranth, GCIH | Rochester MI, USA Aurora Group, Inc. | Security, Systems Software p...@auroragrp.com | Unix Windows ___ 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] clock-block any need ?
On Thu, Dec 27, 2012 at 10:55 AM, Dennis Ferguson dennis.c.fergu...@gmail.com wrote: I don't think I buy this. It takes 70 milliseconds for a signal transmitted from a GPS satellite to be received on the ground, but we don't use this fact to argue that sub-70 ms timing from GPS is not possible. We don't care how long it takes, we care about the uncertainty in the length of time. The speed of light through space is very, very certain and . If you have a network of high-bandwidth routers and switches doing forwarding in hardware, and carrying no traffic other than the packets you are timing (I have access to lab setups that can meet this description) you can observe packet delivery times that are stable at well under the microsecond level even though the total time required to deliver a packet is much larger. If you add competing traffic, like real life networks, the packet-to-packet variability becomes much worse, but this is sample noise that can be addressed by taking larger numbers of samples and filtering based on the expected statistics of that noise. This is what NTP does. It looks at the clocks over a long period of time. That is, the level of noise effecting each individual sample entering the filter does not alone predict the noise level of the result coming out, the latter also depends on the number of samples and the quality of the model of the noise employed by the filter. Note that I often see claims of time synchronization with PTP at the 10 ns level or better. As this level of synchronization is usually achieved by the brute force method of measuring transit times across every network device on the path from source to destination I have no doubt that what NTP can do will necessarily be worse than this, but I don't know of a basis that would predict whether NTP's worse is necessarily going to be 10,000x worse or can be just 10x worse. Knowing that would require actually trying it to measure what can be done. We know the numbers, many peole have done this. I could be off by 10X because maybe my memory is wrong or terminology does not match yours but in principle we know these numbers. We know what the best NTP servers using their built-in TTL oscillators can do. BSD based PCs connected to a good timing mode GPS get to 2 uSecond offsets from true. This seems to be the limit unless one resorts to heroic efforts involving special built hardware. But even the best lab setups using Ethernet are not this good. So my conclusion was that if accurate client timing is the goal then it will NOT help. The Ethernet based NTP clients will still have mS level timing (1000x worse than the GPS connected server) not matter how good the server is. Hence my advice to NOT bother with a special purpose clock block That was the bottom line, that a purpose built clock is not needed. If good client timming is desired using NTP you are going to have to distribute the PPS from GPS using some side channel, making the server better is of no use. Or use PTP and special purpose network equipment (But I bet PPS distribution would be cheaper if you simply used the extra unused twisted pairs inside most Cat-5 cable.) The reason you can't distribute ns level time over a network to normal NTP clients is because of the random queing that happens inside the client's ethernet interfaces. The normal installed base of ethernet cards does not do time stamping. So even uSec level timing is lost in the typical client. What is certain, however, that if you want to measure this at the levels that might be possible you probably want nanosecond-level clock hardware in both the server, so that it can produce time of this quality, and in the clients, so that you can measure how well they do directly rather than attempting to have the NTP implementation grade its own homework. I don't think this is a waste of time at all. The best case is that the ability to measure at this level would lead to an understanding of what it would take to transfer time with NTP at this level, but even the worst case would be that one would be able to support one's assertions about what can't usefully be done with data, and that's not bad either. If no one tries then no one will ever know. 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. -- 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] clock-block any need ?
On Thu, 27 Dec 2012 10:55:12 -0800 Dennis Ferguson dennis.c.fergu...@gmail.com wrote: I don't think I buy this. It takes 70 milliseconds for a signal transmitted from a GPS satellite to be received on the ground, but we don't use this fact to argue that sub-70 ms timing from GPS is not possible. If you have a network of high-bandwidth routers and switches doing forwarding in hardware, and carrying no traffic other than the packets you are timing (I have access to lab setups that can meet this description) you can observe packet delivery times that are stable at well under the microsecond level even though the total time required to deliver a packet is much larger. I'm not sure about this. Knowing about how switches work internally, i'd guess they have jitter of something in the range of 1-10us, but i've never done any measurements. Have you any hard numbers? If you add competing traffic, like real life networks, the packet-to-packet variability becomes much worse, but this is sample noise that can be addressed by taking larger numbers of samples and filtering based on the expected statistics of that noise. Here lies the big problem. While with GPS we pretty much know what the time is that the signal takes to reach earth, we have no clue with network packets in a loaded network. We don't even have an idea what the packet transmit distribution is in the moment we are doing our measurements. Neither the queue length in the router/switch nor anything else. And the loading of a switch changes momentarily and this in turn changes the delay of our packets. You can of course apply math and try to get rid of quite a bit of noise, but you will never get rid of it down to ns levels. If i'm not mistaken, IEEE1588v1 had exactly that problem. They tried to use normal switches and hoped the jitter would be predictable enough to get compensated for. This didnt work out, so v2 now demands that all switches act as border clocks As this level of synchronization is usually achieved by the brute force method of measuring transit times across every network device on the path from source to destination I have no doubt that what NTP can do will necessarily be worse than this, but I don't know of a basis that would predict whether NTP's worse is necessarily going to be 10,000x worse or can be just 10x worse. Knowing that would require actually trying it to measure what can be done. You can guestimate that getting below 200us is not easy in a normal network, but sub-1ms should be possible unless the network is very loaded. Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ 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] clock-block any need ?
On 12/27/12 11:17 AM, Chris Albertson wrote: On Thu, Dec 27, 2012 at 10:55 AM, Dennis Ferguson dennis.c.fergu...@gmail.com wrote: The reason you can't distribute ns level time over a network to normal NTP clients is because of the random queing that happens inside the client's ethernet interfaces. The normal installed base of ethernet cards does not do time stamping. So even uSec level timing is lost in the typical client. I've been playing with Arduinos and Ethernet over the past couple weeks (all those home automation kind of chores.. not like I need to time the smoker temperature ramps to nanosecond precision), but this brings up an interesting issue.. A lot of the uncertainty is because of the smart Ethernet interface that tries to do stuff to offload the processor (buffering, etc.). This is one of the cases where old, less capable interfaces might do better. So, what about the USB-Ethernet dongles? (I use them a lot at work to add a second interface for a laptop in test equipment setups, talking to a Prologix, for instance) Or, the Wiznet Ethernet/IP stack on a chip devices that talk via SPI, or basically, a serial port. https://www.sparkfun.com/products/9473 for a widget https://www.sparkfun.com/products/9471? for the part http://www.saelig.com/product/BRD002.htm a Ethernet to serial port board Some of these might have deterministic enough timing that it would be useful. They sure are cheap. ___ 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] New to Time Synching hardware - needing some advice
Yes or even more compllex setups. NTP can work with any number of clocks. In fact the old joke that goes A man with one clock knows what time it is, but a man with two is never sure of the time. This is 100% true. NTP can work with three or five PPS clocks and will compare them and stop listening to the ones that do not agree with the others (It uses a fairly sophisticated method to select the subset of conected clocks to use) So if you are going to rotate Rb units get four of them and always have one outside on the GPS being adjusted and three inside and then you have a good check on the Rb units and saw out worst clock. This way you have zero down time as you will always have two good clocks even after an automated tai over. Kind of like RAID disks if this is going inside some RF shielded room or submarine the sub captain is going to want a way to detect a failure. I think you need three clocks as a minimum for that. Then every month you surface and swap ut the worst of you three clocks. A truly paranoid timekeeper would use a system of five clocks. Also using five clocks is common. Many GPS clients will use five Internet time servers from the pool, works the same way with three GPS or Rb clocks. On Thu, Dec 27, 2012 at 10:48 AM, Gabs Ricalde gsrica...@gmail.com wrote: It could be possible to use two Rb GPSDOs, one providing the PPS and another disciplined by GPS, then rotate them every month. On Fri, Dec 28, 2012 at 2:41 AM, Attila Kinali att...@kinali.ch wrote: On Thu, 27 Dec 2012 10:19:46 -0800 Chris Albertson albertson.ch...@gmail.com wrote: Yes you could us something like one of the low-cost rubidium oscilators to supply a pulse per second to Linux NTP and it would work for some time before the error was as large as 10 mS. One missing requirement is how long you need be without GPS or networking. Obviously you can't stay out of contact with the world forever but it is very easy and cheap if you only need a day. Harder if you need a month and expensive if you are talking about years. Actually, a couple of months is still quite simple. The Rb approace gives you at least something in the range of 10^-9 stability, long term. Which gets you into the ballpark of 100 days (with 10ms). If you temperature stabilize the Rb you should get down to 10^-11, which would be 30 years. At least theoretically, aging is AFAIK larger than this. But a couple of years should be still possible without too much effort. IIRC the FE5680 sell now for 200USD. Some heatsink and temperature control come maybe at 50-100USD. Some equipment to measure where the PPS lies relative to UTC and a powersupply that can get you 15V from mains and a battery (to get the Rb where the computer is) would also be necessary. Alternatively, put the Rb next to the computer in question, hook a powerfull linedriver to the PPS output, and a wire that goes all the way out where you have GPS reception and can measure the PPS pulse. After measurement, you can remove that cable. Ofcourse this only works, if you can lay a cable temporarily. If you are in a EMP secured room, the only way to get the pulse measured is the approach with the traveling Rb. Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ 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. -- 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] clock-block any need ?
Actually those smart interface and the low cost interface on dongles use very dumb hardware and depend on software. So they are not as deterministic as you'd like.The very best network hardware is purpose built and expensive and does the timing in hardware. I still think the lowest cos tmemthodis to distribute PPS to every computer. Then the only special wardware the PC needs is a serial port A lot of the uncertainty is because of the smart Ethernet interface that tries to do stuff to offload the processor (buffering, etc.). This is one of the cases where old, less capable interfaces might do better. So, what about the USB-Ethernet dongles? (I use them a lot at work to add a second interface for a laptop in test equipment setups, talking to a Prologix, for instance) Or, the Wiznet Ethernet/IP stack on a chip devices that talk via SPI, or basically, a serial port. https://www.sparkfun.com/products/9473 for a widget https://www.sparkfun.com/products/9471? for the part http://www.saelig.com/product/BRD002.htm a Ethernet to serial port board Some of these might have deterministic enough timing that it would be useful. They sure are cheap. ___ 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. -- 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] clock-block any need ?
On Thu, 27 Dec 2012 11:30:37 -0800 Jim Lux jim...@earthlink.net wrote: So, what about the USB-Ethernet dongles? (I use them a lot at work to add a second interface for a laptop in test equipment setups, talking to a Prologix, for instance) A lot worse! One thing is that USB has a polled protocol (ie the host has to ask whether the device has any data) and the slot when an USB device can signal that a packet came in repeates it self at most a couple of times per 1ms frame for FS (don't know from the top of my head for HS). The bigger issue though is that drivers for ethernet dongles are usally of quite bad quality (ie it takes them a long time to do anything), and they try to queue as much as possible to increase troughput (which adds unpredictable delay). Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ 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] 2.5 Ghz 12 digit counter project
Found the magazine´s site: http://www.siliconchip.com.au/Issue/2012/December You can look at the first pages of the article without paying. Daniel Em 27/12/2012 17:12, Paul Amaranth escreveu: Did anyone see the article in the December Silicon Chips magazine about building a 12 digit 2.5 GHz counter? It has an option for a GPS 1pps input so you could have some expectation that the last couple of digits mean something. The website only has the article cover page in pretty much unreadable type. ___ 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] clock-block any need ?
att...@kinali.ch said: Here lies the big problem. While with GPS we pretty much know what the time is that the signal takes to reach earth, we have no clue with network packets in a loaded network. I agree that if you are running on a busy network you are out of luck. On the other hand, if the network is lightly loaded and the topology is stable, you can measure the round trip time and learn the unloaded time. Then you can ignore samples with longer round trip times. You can guestimate that getting below 200us is not easy in a normal network, but sub-1ms should be possible unless the network is very loaded. I can easily get ping times of under 150 us. One switch. I've got lots of ntp log files. I should make a histogram. -- 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] 2.5 Ghz 12 digit counter project
It depends on how long to wait for that last digit to be meaningful... On Thu, Dec 27, 2012 at 8:12 PM, Paul Amaranth p...@auroragrp.com wrote: Did anyone see the article in the December Silicon Chips magazine about building a 12 digit 2.5 GHz counter? It has an option for a GPS 1pps input so you could have some expectation that the last couple of digits mean something. The website only has the article cover page in pretty much unreadable type. -- Paul Amaranth, GCIH | Rochester MI, USA Aurora Group, Inc. | Security, Systems Software p...@auroragrp.com | Unix Windows ___ 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] 2.5 Ghz 12 digit counter project
You can see that high end counters (HP53181A, PM6681, SR620 and others) claims 12 digits per second speed. That kind of performance is the result of a reciprocal counting technique and/or various type of interpolation methods. A simple counter with a 1 second timebase (like a PPS) can have 12 digits (at, say, 100MHz input frequency) only if you wait 1000 seconds. On Thu, Dec 27, 2012 at 9:28 PM, Azelio Boriani azelio.bori...@screen.itwrote: It depends on how long to wait for that last digit to be meaningful... On Thu, Dec 27, 2012 at 8:12 PM, Paul Amaranth p...@auroragrp.com wrote: Did anyone see the article in the December Silicon Chips magazine about building a 12 digit 2.5 GHz counter? It has an option for a GPS 1pps input so you could have some expectation that the last couple of digits mean something. The website only has the article cover page in pretty much unreadable type. -- Paul Amaranth, GCIH | Rochester MI, USA Aurora Group, Inc. | Security, Systems Software p...@auroragrp.com | Unix Windows ___ 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] An embedded NTP server
On 12/27/2012 01:41 AM, Michael Tharp wrote: The good news is that the disciplining algorithm I lifted from my previous GPSDO project works quite well, and I have the gritty details of measuring the PPS worked out. If I can get the Trimble working tomorrow I might have much better results soon, otherwise I'm traveling for a few days so it'll have to wait until the new year. And here we go, it works. Much more reasonable, tens-of-microseconds jitter figures. [root@rei ~]# ntpq -pn remote refid st t when poll reach delay offset jitter == -138.236.128.36 216.218.254.202 2 u 21 1024 377 68.8193.228 0.641 +108.59.14.130 209.51.161.238 2 u 298 1024 377 34.9201.167 0.288 +108.61.73.244 96.47.67.105 2 u 300 1024 377 39.5241.135 1.604 -64.6.144.6 128.252.19.1 2 u 772 1024 377 84.3296.609 0.252 *172.24.0.6 .GPS.1 u2 16 3770.320 -0.073 0.016 -172.24.0.66 135.34.116.162 3 u 237 1024 3770.1970.130 0.581 x172.24.0.68 172.24.0.6 2 u 291 1024 3770.237 113.341 77.665 -172.24.0.1 172.24.0.6 2 u 287 512 3770.1232.382 0.876 [root@maruko ~]# ntpq -pn remote refid st t when poll reach delay offset jitter == -67.18.187.111 129.7.1.66 2 u 965 1024 37 66.6951.952 0.842 +174.129.25.69 131.188.3.2212 u 753 1024 377 35.9261.734 0.250 *2001:470:1:15b: 132.239.1.6 2 u 513 1024 377 107.2400.982 0.373 -172.24.0.1 172.24.0.6 2 u 786 1024 3770.1872.960 1.027 +172.24.0.6 .GPS.1 u 55 16 3770.356 -0.008 0.060 -172.24.0.64 108.59.14.1303 u 912 1024 3770.3010.058 0.685 x172.24.0.68 135.6.140.0 3 u 938 1024 3770.378 243.604 166.234 [root@hanmyo ~]# ntpq -pn remote refid st t when poll reach delay offset jitter == *172.24.0.6 .GPS.1 u 25 64 3770.399 -2.390 0.258 172.24.0.64 172.24.0.6 2 u9 1024 3770.134 -2.273 0.708 -172.24.0.66 135.34.116.162 3 u 342 512 3770.216 -2.607 1.728 172.24.0.68 172.24.0.6 2 u 300 512 3770.092 245.910 124.378 -72.251.251.11 62.192.15.2123 u 22 1024 377 122.988 -0.097 1.585 +67.18.187.111 129.7.1.66 2 u 270 512 377 66.916 -1.235 3.977 -199.7.177.206 64.147.116.229 2 u 368 512 377 59.0353.838 1.815 +50.97.210.169 131.107.13.100 2 u8 1024 377 100.0032.547 1.025 hanmyo (172.24.0.1) is a small digital engine computer that I use as a router; it is pretty much 100% idle, has no fans, and is located in a closet where it is temperature stable. At the same time, it shows by far the highest jitter figure so I'm guessing its clock is not very good. I will have to probe around and see if there is something I can replace, because it is the best candidate for characterizing the performance of my little NTP server. It's hard to get quality measurements when the peer boxes are just ordinary desktops. I've only been testing this new firmware for ~30m so I will let it soak while I'm traveling and when I get back the numbers should look even better. -- m. tharp ___ 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] 2.5 Ghz 12 digit counter project
Hi Paul, Thanks for bringing this to our attention. The block diagram of the counter is at http://siliconchip.com.au/ (also see attached). It looks like a standard 1970's gated/reciprocal frequency counter design; using 4 digits of high frequency prescaler before it goes into the 8 digit PIC. So the 12 digit refers to the number of LED's on the front panel. Not to be confused with the 12 digits per second spec of a modern interpolator-based frequency counter. I.e., it's high range, not high resolution. I see it accepts external 1 Hz gate times from a GPS receiver; further suggesting the resolution is 7- or 8-digits/sec. Still, a nicely designed PIC-based casual bench frequency counter. If eventually the full article is available online let us know. It would be an interesting read. Does anyone know Jim Rowe (Australia)? A related project of his was the UHF Prescaler For Frequency Counters (http://archive.siliconchip.com.au/cms/A_107676/article.html). /tvb - Original Message - From: Paul Amaranth p...@auroragrp.com To: time-nuts@febo.com Sent: Thursday, December 27, 2012 11:12 AM Subject: [time-nuts] 2.5 Ghz 12 digit counter project Did anyone see the article in the December Silicon Chips magazine about building a 12 digit 2.5 GHz counter? It has an option for a GPS 1pps input so you could have some expectation that the last couple of digits mean something. The website only has the article cover page in pretty much unreadable type. -- Paul Amaranth, GCIH | Rochester MI, USA Aurora Group, Inc. | Security, Systems Software p...@auroragrp.com | Unix Windows attachment: 2012-12-silicon-chip-12d-freq-counter.gif___ 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] 2.5 Ghz 12 digit counter project
If you right click then zoom in, you can then read the article. On 2012-12-27 2:12 PM, Paul Amaranth wrote: The website only has the article cover page in pretty much unreadable type. ___ 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] 2.5 Ghz 12 digit counter project
Thanks Tom, It wasn't clear to me if they were using the GPS to discipline an internal oscillator or just as a 1 second gate. That diagram was just a little too small for me to make out. Paul Date: Thu, 27 Dec 2012 13:17:08 -0800 From: Tom Van Baak t...@leapsecond.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: Re: [time-nuts] 2.5 Ghz 12 digit counter project Message-ID: 5CB6972C54284AFCAD9E209143C6ECD6@pc52 Content-Type: text/plain; charset=iso-8859-1 Hi Paul, Thanks for bringing this to our attention. The block diagram of the counter is at http://siliconchip.com.au/ (also see attached). It looks like a standard 1970's gated/reciprocal frequency counter design; using 4 digits of high frequency prescaler before it goes into the 8 digit PIC. So the 12 digit refers to the number of LED's on the front panel. Not to be confused with the 12 digits per second spec of a modern interpolator-based frequency counter. I.e., it's high range, not high resolution. I see it accepts external 1 Hz gate times from a GPS receiver; further suggesting the resolution is 7- or 8-digits/sec. Still, a nicely designed PIC-based casual bench frequency counter. If eventually the full article is available online let us know. It would be an interesting read. Does anyone know Jim Rowe (Australia)? A related project of his was the UHF Prescaler For Frequency Counters (http://archive.siliconchip.com.au/cms/A_107676/article.html). /tvb - Original Message - From: Paul Amaranth p...@auroragrp.com To: time-nuts@febo.com Sent: Thursday, December 27, 2012 11:12 AM Subject: [time-nuts] 2.5 Ghz 12 digit counter project Did anyone see the article in the December Silicon Chips magazine about building a 12 digit 2.5 GHz counter? It has an option for a GPS 1pps input so you could have some expectation that the last couple of digits mean something. The website only has the article cover page in pretty much unreadable type. -- Paul Amaranth, GCIH | Rochester MI, USA Aurora Group, Inc. | Security, Systems Software p...@auroragrp.com | Unix Windows -- next part -- A non-text attachment was scrubbed... Name: 2012-12-silicon-chip-12d-freq-counter.gif Type: image/gif Size: 38040 bytes Desc: not available URL: http://www.febo.com/pipermail/time-nuts/attachments/20121227/16bf1891/attachment.gif -- ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts End of time-nuts Digest, Vol 101, Issue 176 *** -- Paul Amaranth, GCIH | Rochester MI, USA Aurora Group, Inc. | Security, Systems Software p...@auroragrp.com | Unix Windows ___ 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] clock-block any need ?
On 12/27/2012 08:28 PM, Attila Kinali wrote: On Thu, 27 Dec 2012 10:55:12 -0800 Dennis Fergusondennis.c.fergu...@gmail.com wrote: I don't think I buy this. It takes 70 milliseconds for a signal transmitted from a GPS satellite to be received on the ground, but we don't use this fact to argue that sub-70 ms timing from GPS is not possible. If you have a network of high-bandwidth routers and switches doing forwarding in hardware, and carrying no traffic other than the packets you are timing (I have access to lab setups that can meet this description) you can observe packet delivery times that are stable at well under the microsecond level even though the total time required to deliver a packet is much larger. I'm not sure about this. Knowing about how switches work internally, i'd guess they have jitter of something in the range of 1-10us, but i've never done any measurements. Have you any hard numbers? Switches and routers can contribute significant amount of time. On GE, a full-length packet is about 12 us, so a single packets head-of-line blocking can be anything up to that amount, multiple packets... well, it keeps adding. Knowing how switches works doesn't really help as packets arrive in a myriad of rates, they interact and cross-modulate and create strange patterns and dance in interesting ways that is ever changing in unpredictable fashion. The GPS situation with ionosphere and troposphere is benign in comparison, yet challenging in their own right. If you add competing traffic, like real life networks, the packet-to-packet variability becomes much worse, but this is sample noise that can be addressed by taking larger numbers of samples and filtering based on the expected statistics of that noise. Here lies the big problem. While with GPS we pretty much know what the time is that the signal takes to reach earth, we have no clue with network packets in a loaded network. We don't even have an idea what the packet transmit distribution is in the moment we are doing our measurements. Neither the queue length in the router/switch nor anything else. And the loading of a switch changes momentarily and this in turn changes the delay of our packets. You can of course apply math and try to get rid of quite a bit of noise, but you will never get rid of it down to ns levels. A challenging thing, indeed. If i'm not mistaken, IEEE1588v1 had exactly that problem. They tried to use normal switches and hoped the jitter would be predictable enough to get compensated for. This didnt work out, so v2 now demands that all switches act as border clocks The irony of it being that 1588v2 aware switches can work worse than dirt cheap switches, since the extra packet-handling is taking a slow an painful route through the switch. As this level of synchronization is usually achieved by the brute force method of measuring transit times across every network device on the path from source to destination I have no doubt that what NTP can do will necessarily be worse than this, but I don't know of a basis that would predict whether NTP's worse is necessarily going to be 10,000x worse or can be just 10x worse. Knowing that would require actually trying it to measure what can be done. You can guestimate that getting below 200us is not easy in a normal network, but sub-1ms should be possible unless the network is very loaded. The trouble is that you milage will vary on a typical network, these delays keeps shifting and you can get a good idea by measuring it for a few weeks, but you can't reliably predict it, just the overall shape of it. Doing ~200 us for a non-trival network with real data on it sound about right. What kills many assumptions is that the noise-forms fail most of the normal assumptions about noise. It's not zero mean, it does not have a static mean, it does not have a static variance, it is not symmetric, it is not independent of other traffic, it is not just another service. Cheers, Magnus ___ 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] New to Time Synching hardware - needing some advice
Dear Roy, On 12/27/2012 06:52 PM, Roy B wrote: Hello I am new to time synching hardware but have done Linux NTP so I have a little experience in that but I need some advice for a different project. I have a PC running Linux that I would like to have on a stable time with roughly 10 millisecond accuracy however this machine is located in a place where it cant get network, GPS, or radio signals. Is there something like an Atomic Clock that I could set to the correct time over radio/gps/network and then take this box to the PC? Anything that I have looked at just assumes that you have a continuous outside connection from somewhere. These requirements puzzles me. Why do you need 10 ms accuracy when it is not connected to anything? If you have a network connection to it, providing NTP timing over it so that whatever time-application in it can also interact with the environment where the interaction requires 10 ms accuracy counts. If you have a system where two machines needs to agree within 10 ms, but can't be reachable from the outside, just set one of them up as the NTP server and the other as slave, and run their own taliban time and be done with it. Point being, do you have absolute timing requirements (to UTC) or relative timing requirments (between machines)? Sometimes when you have isolated machines, the absolute time may not need to be very accurate, but the relative timing between them can be. Adjusting from wrist-watch every once in a while may suffice for absolute time. So, what is it? A rubidium may take time to drift off the mark, but for what purpose do you take that effort? Cheers, Magnus ___ 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] clock-block any need ?
Magnus, Doing ~200 us for a non-trival network with real data on it sound about right. What kills many assumptions is that the noise-forms fail most of the normal assumptions about noise. It's not zero mean, it does not have a static mean, it does not have a static variance, it is not symmetric, it is not independent of other traffic, it is not just another service. Cheers, Magnus But NTP is very much aware of the measurements coming from a complicated statistical source. Look for 'wedge scattergram'. http://www.eecis.udel.edu/~mills/database/brief/algor/algor.pdf http://www.eecis.udel.edu/~mills/database/brief/distlec/distlec.ppt -- Björn ___ 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] New to Time Synching hardware - needing some advice
mag...@rubidium.dyndns.org said: Sometimes when you have isolated machines, the absolute time may not need to be very accurate, but the relative timing between them can be. Adjusting from wrist-watch every once in a while may suffice for absolute time. If the OS allows you to tweak the clock, you can probably get to within a second per week. It will probably depend mostly on temperature (and load) stability. -- 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] clock-block any need ?
Björn, On 12/28/2012 12:31 AM, b...@lysator.liu.se wrote: Magnus, Doing ~200 us for a non-trival network with real data on it sound about right. What kills many assumptions is that the noise-forms fail most of the normal assumptions about noise. It's not zero mean, it does not have a static mean, it does not have a static variance, it is not symmetric, it is not independent of other traffic, it is not just another service. Cheers, Magnus But NTP is very much aware of the measurements coming from a complicated statistical source. Look for 'wedge scattergram'. http://www.eecis.udel.edu/~mills/database/brief/algor/algor.pdf http://www.eecis.udel.edu/~mills/database/brief/distlec/distlec.ppt I am fully aware of it. NTP has many treatments to the measurements to combat these issues, but it can't cut down the noise all the way down as you would like to do 1 us or so over large scale networks. My comment above was to point out that you do need to look hard at the topic to grasp all the details of it. There are many subtleties and the wedge scattergram is one of several methods to approach it. NTP only come that far, given some of the design constraints it has. It does a good job within those limits. Cheers, Magnus ___ 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] 2.5 Ghz 12 digit counter project
Watch out for Silicon Chip designs, they have a habit of not making the source code available, which you only find out at the end of the project. I suppose that it is to allow the author to make a few extra $$ selling programmed micros. They had a nice 3 phase inverter design a year ago that had this problem, I wrote to the author promising not to distribute the source, I just wanted to read it, but didn't even get the courtesy of an answer. I suspect that this counter is like the inverter, an oldish design that is not worth building as you can get the same for half the cost out of China. What makes it worthwhile is getting the hardware the source code, so that you can tinker with it. Actually I had a look at the counter and it looks similar to the 8 digit designs using the Intersil 7217 IC from the 80's. Gripe ends. On 28 December 2012 06:12, Paul Amaranth p...@auroragrp.com wrote: Did anyone see the article in the December Silicon Chips magazine about building a 12 digit 2.5 GHz counter? It has an option for a GPS 1pps input so you could have some expectation that the last couple of digits mean something. The website only has the article cover page in pretty much unreadable type. -- Paul Amaranth, GCIH | Rochester MI, USA Aurora Group, Inc. | Security, Systems Software p...@auroragrp.com | Unix Windows ___ 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. -- Tom Harris celephi...@gmail.com ___ 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] 2.5 Ghz 12 digit counter project
On Thu, Dec 27, 2012 at 6:45 PM, Tom Harris celephi...@gmail.com wrote: Watch out for Silicon Chip designs, they have a habit of not making the source code available, which you only find out at the end of the project. I suppose that it is to allow the author to make a few extra $$ selling programmed micros. They had a nice 3 phase inverter design a year ago that had this problem, I wrote to the author promising not to distribute the source, I just wanted to read it, but didn't even get the courtesy of an answer. I suspect that this counter is like the inverter, an oldish design that is not worth building as you can get the same for half the cost out of China. What makes it worthwhile is getting the hardware the source code, so that you can tinker with it. I have a 2.7GHz counter out of China and cannot recommend it. If I feed it 10 MHz from a OCXO that is within 1Hz (as checked on my 5335A with high stability timebase), the counter will read fine for a while, then the reading will start drifting upwards and become unstable. I forget how high the reading drifts, hundreds of Hz at least. It will count to at least 2.7GHz, but I cannot trust it. It also has a 13 MHz output on the back. I looked at it on my TDS210 digital scope and there is a glitch on the leading edge of the waveform! It clearly goes up, returns to zero then finally goes back up for the rest of half a period. Whether this glitch affects the gating, I don't know. It's possible it is generated in whatever circuit buffers the clock for the output. Orin. ___ 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] 2.5 Ghz 12 digit counter project
Tom Harris wrote: Watch out for Silicon Chip designs, they have a habit of not making the source code available, which you only find out at the end of the project. I suppose that it is to allow the author to make a few extra $$ selling programmed micros. They had a nice 3 phase inverter design a year ago that had this problem, I wrote to the author promising not to distribute the source, I just wanted to read it, but didn't even get the courtesy of an answer. I suspect that this counter is like the inverter, an oldish design that is not worth building as you can get the same for half the cost out of China. What makes it worthwhile is getting the hardware the source code, so that you can tinker with it. Actually I had a look at the counter and it looks similar to the 8 digit designs using the Intersil 7217 IC from the 80's. Gripe ends. On 28 December 2012 06:12, Paul Amaranthp...@auroragrp.com wrote: Did anyone see the article in the December Silicon Chips magazine about building a 12 digit 2.5 GHz counter? It has an option for a GPS 1pps input so you could have some expectation that the last couple of digits mean something. The website only has the article cover page in pretty much unreadable type. -- Paul Amaranth, GCIH | Rochester MI, USA Aurora Group, Inc. | Security, Systems Software p...@auroragrp.com | Unix Windows ___ 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. I've read the entire set of articles and like most of the designs from this particular designer its largely an unadulterated piece of junk. Aside from the usual logic design errors I've come to expect from this designer the GPS PPS input is used directly to set the gate time so jitter on this signal directly (several tens of nanaosec or even more if sawtooth error is present better if the PPS is derived from a GPSDO) affects accuracy. Bruce Bruce ___ 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.
