Re: [time-nuts] LeoNTP PPS output to PC DB9 input
Hello Anthony, Those cables will NOT work. The BNC connectors are 75 Ohms, which will damage the 50 Ohm connector on the server. Yes, pin1 is DCD. You might need level shifting, but probably not. For the cable, just buy a cheap BNC cable and a DE-9 (sometimes erroneously called DB-9) connector. Cut one end off of the cable, strip the outer jacket back a couple of centimeters, unravel then twist the braid, strip the white insulation back about 2 millimeters, and put some heat shrink on the braid so about 2 mm is showing. Solder the center conductor to pin one and the braid to pin five. Put a hood or some tape over the connector and you're done. Brent On 5/28/2019 9:28 PM, Anthony Dunne wrote: Hi Everyone I am hoping one of you may be able to help with a specific problem? Some time ago, I purchased the excellent LeoNTP time server available here:- https://store.uputronics.com/index.php?route=product/product&path=60_70&product_id=92 It serves network time via NTP over Ethernet primarily but it also has PPS/1Mhz/10Mhz via a female BNC connector on the rear. I would like to connect the BNC output to a DB9 Serial input (female) on a machine running FreeBSD (pfSense) to provide PPS reference/accuracy to the NTPD running there. Firstly would this work? Secondly, my dilemma is the pin-out. I believe on the DB9 pin 1 is DCD (the actual pulse) and pin 5 is the ground. Is this correct? Could I use a cable such as this:- http://www.l-com.com/multimedia/eng_drawings/CTL4CAD.pdf even though pin five is not connected or would I need to use something like this:- http://www.l-com.com/multimedia/eng_drawings/CTL5CAD.pdf and make sure the pin 5/plug 5 is grounded in some way? Alternatively, is there a simpler way to achieve the goal? Sorry if this is vague but I would really appreciate some help on this :) Thank-you in advance Anthony New South Wales Australia ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] LeoNTP PPS output to PC DB9 input
Quoting Anthony Dunne : Firstly would this work? Yes. Secondly, my dilemma is the pin-out. I believe on the DB9 pin 1 is DCD (the actual pulse) and pin 5 is the ground. Is this correct? Yes. Could I use a cable such as this:- No. Alternatively, is there a simpler way to achieve the goal? No, you really need a level shifting stage that converts the PPS to RS232 levels. Tom ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] LeoNTP PPS output to PC DB9 input
Hi Everyone I am hoping one of you may be able to help with a specific problem? Some time ago, I purchased the excellent LeoNTP time server available here:- https://store.uputronics.com/index.php?route=product/product&path=60_70&product_id=92 It serves network time via NTP over Ethernet primarily but it also has PPS/1Mhz/10Mhz via a female BNC connector on the rear. I would like to connect the BNC output to a DB9 Serial input (female) on a machine running FreeBSD (pfSense) to provide PPS reference/accuracy to the NTPD running there. Firstly would this work? Secondly, my dilemma is the pin-out. I believe on the DB9 pin 1 is DCD (the actual pulse) and pin 5 is the ground. Is this correct? Could I use a cable such as this:- http://www.l-com.com/multimedia/eng_drawings/CTL4CAD.pdf even though pin five is not connected or would I need to use something like this:- http://www.l-com.com/multimedia/eng_drawings/CTL5CAD.pdf and make sure the pin 5/plug 5 is grounded in some way? Alternatively, is there a simpler way to achieve the goal? Sorry if this is vague but I would really appreciate some help on this :) Thank-you in advance Anthony New South Wales Australia ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] imprecise but adequate time
> Le 28 mai 2019 à 16:38, Eric Scace a écrit : > > Hi fellow time nuts — > > I’m looking for a sanity check or alternative suggestions for the problem > and tentative solution described below. You have a situation where the application in any one system is unaware of the validity of the underlying OS time. So I think you have to have a mechanism where transactions are refused/re-routed if that validity can not be established. So I would say that some mechanism be put in place to check the local clock against the time reported by a majority , or a large enough sample, of the networks systems. Depending on the transaction rate that could be done on a per transaction, or reasonable interval. > > Thanks for your thoughts. > > — Eric > > Problem: > > In one of my day jobs, I am designing a global network of systems (using > open-source software) that provide well-researched information about rights > and licenses for musical works (e.g., songs, compositions). > > Claiming rights, registering licenses (some of which are temporary), and > time-stamping changes to data each exemplify cases where date/time must be > included. In many cases the time order of events can be important — > potentially changing who gets paid how much when music is performed or > distributed. > > The machines are scattered around the planet and the usual problems of time > distribution exist. Furthermore, systems are operated independently. We > assume occasional use of NTP to correct system clocks, but not a local > GPS-provided time. The software development team is generally oblivious to > the issues of time in distributed computer networks. > > A grim picture — but, fortunately, this application does not require high > precision time. > > My tentative proposal: > > 1. To avoid burdening systems with multiple local time conversions, all > date/time information throughout the system shall be UTC. Implications: > user apps will be responsible for converting from a human user’s local time > to UTC > thus, user app developers will have to do this conversion correctly > > 2. Date/time stamps in the data shall be rounded to the nearest EVEN second > by the system instances; e.g., to 2019 May 28 14:24:28 UTC. Implications: > user apps that submit claims or updates will have their claims/updates > date/time-stamped by the receiving system node with this rounding method. > Example: “John Smith claims that he and Jane Doe wrote these lyrics, making > an equal contribution between them, on 2019 May 27 15:00:00 UTC. His claim > was received by the system at 2019 May 28 14:26:50 UTC.” One or more > blockchain ledgers record a hash of the musical work [the lyrics, in this > example], the claim [who wrote the lyrics when], and which app/system > registered the claim and when. > events occurring roughly within ±1 second of each other will be deemed to > have occurred simultaneously. This is entirely adequate for this application. > competing leap second smearing methods employed by different operating > systems and data center operators will be washed out of the time stamp by > this rounding requirement. > > — end — > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. "Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité." Benjimin Franklin ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Updating the unit of,time: the second.
> Le 27 mai 2019 à 11:13, Dave B via time-nuts a > écrit : > > Hi. > > This from the recent ShortWave Radiogram broadcast, may be of interest. > > ~ ~ ~ > > (Snipped stuff about other SI units undergoing a revamp...) > > Scientists now have their sights set on updating the unit of > time: the second. > > Currently, the second is defined by atomic clocks made of cesium > atoms. Those atoms absorb a certain frequency of light. The > wiggling of the light's electromagnetic waves functions like the > pendulum on a grandfather clock, rhythmically keeping time. One > second is defined as 9,192,631,770 oscillations of the light. > > But a new generation of atomic clocks, known as optical atomic > clocks, outdo the cesium clocks. "Their performance is a lot > better than what currently defines the second," says physicist > Andrew Ludlow of the National Institute of Standards and > Technology in Boulder, Colo. Because those optical atomic clocks > operate at a higher frequency, their "ticks" are more closely > spaced, making them about 100 times more precise than cesium > clocks. > > Ideally, the length of a second should be defined using the most > precise timepieces available. A switch might happen in the late > 2020s, Ludlow says. I disagree with this. a. There is no need for a new definition. b. Any new definition would have to be realizable and easily verifiable. c. The first commercial cesium clocks were available in 1956, but the second did not get redefined until 1967. There is no rush. I believe that commercial optical clocks are available but: d. There are too many flavors of optical clocks around on lab benches. So despite their increased precision and stability which flavor would get the vote? So I predict that that will be no change in the definition in the next 20 years and chip scale optical clocks will be available before five years hence. > > The change to the kilogram's definition was carefully > orchestrated so that it wouldn't affect normal people: A kilogram > of flour still makes the same number of biscuits. Any change to > the second will be similarly coordinated. > > So, sorry, there'll be no chance to squeeze any extra seconds > into a day. > > https://www.sciencenews.org/article/kilogram-just-got-revamp-unit-time-might-be-next > > ~ ~ ~ > > So, perhaps a host of surplus cesium clocks on the market at some point? > > 73 > > Dave B G0WBX. > > -- > Created on and sent from a Unix like PC running and using free and open > source software: > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. "Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité." Benjimin Franklin ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design
On Sunday, May 26, 2019, 7:24:31 AM PDT, Attila Kinali wrote: As you state that you are familiar with PLL design, I guess your confusion comes from having a 1Hz signal and trying to use that for a "normal" phase detector. While this is possible and can be done, it leads imediatly to the problems you have stumbled upon. The canonical way to do it, is instead measuring the arrival time of the PPS relative to a clock derived from the 10MHz. Ie you timestamp the PPS. Then you take the timestamp modulo 1 second and substract from it the setpoint value (can be 0 or anything else that makes your math easier), which then gives you the error or your control loop. Having the error value, you now can apply the digital PLL knowledge you have and design the loop filter. There are of course a few complications of the system: 1) You need to apply the saw-tooh correction to the measured PPS timestamp. Otherwise you get a spread in the order of 10ns and, much worse, "hanging bridges" 2) The systems sampling clock is 1Hz, which is unusual to most people who are used kHz or even MHz sampling rate digital loops. But the advantage is that it's so slow, that you can do all the calculations with minimal dead time, compared to the sampling period. Just keep in mind that everything has to have a sub-Hz bandwidth. 3) To achieve a decent frequency stability and low noise OCXO output, the DAC you use to control it needs to have at the very least 16bit (mostly DNL, but INL shouldn't change too much or too quickly, otherwise the loop becomes unstable). For one of my design, I calculated that I would need ~23bit for the stability I wanted, which poses a problem by itself. Luckily, having the DAC in the control loop simplifies things quite a bit. Using a 16bit DAC (eg AD5560 or AD5683R, the latter would be better suited for this application due to the LDAC pin) and using a delta-sigma modulator (at least 2nd order, better 4-8th order) should give you enough resolution to work with. Alternatively, a 1bit DAC using a high order delta-sigma modulator and an external D-FF (don't use one in the FPGA as the jitter from the FPGA would kill the resolution) would also work. Audio DACs don't work for this application as they have too much low-frequency noise (aka drift). 4) The filter after the DAC will require some good opamps. Even though using chopper/autozero opamps is tempting, I'd rather go for low flicker noise bipolar opamps (eg LT6018 or LTC6081, LT6010,...) as the loop will compensate for the drift of the opamp (given it's not too big). 5) The easiest way to timestamp PPS if you already have a FPGA is using a ring oscillator based TDC. There is code out there that works for Xilinx[1]. I have a port to Altera/Intel Cyclone4 lying around if you are interested. This will give you a resolution in the order of 100-200ps, which should be good enough for a GPSDO. The second way would be to implement a time-to-amplitude converter (the simplest, I am aware of, is the one in Nick Sayer's GPSDO[2]), but that is already quite a bit more effort in the analog domain than what a ring oscillator TDC would require. > I need the output of two of these units I design to have to be phase > coherent relative to each other. Your knowledge, experience and scholarly > references are welcome. There is not much out there on refernces that I could send you. Most of what I know I gathered from looking at other peoples GPSDOs and reading what they have done. An outdated summary of that can be found at [3]. Additional to this you will need good knowledge of digital PLL design, for which I recommend having a look at the standard books (e.g. Gardner[4] and Best[5]). How well you can get the GPSDOs synchronized depends a bit on the effort you spend on the receiver. Standard L1 receivers (of the same model with the same firmware) will be better than 10ns if they are not too far apart (a few 10km to maybe 100km). If you need better than 1ns, you will need an L1/L2 receiver and have to manually calibrate the offset of the receiver. HTH Attila Kinali [1] https://ohwr.org/project/tdc-core/wikis/home [2] https://hackaday.io/project/6872-gps-disciplined-xcxo [3] https://attila.kinali.ch/blog/2016/02/07/gps-disciplined-oscillator [4] "Phaselock Techniques", 3rd edition, 2015 by Floyd Gardner [5] "Phase-locked lopps", 6th edition, 2009, by Roland Best -- The bad part of Zurich is where the degenerates throw DARK chocolate at you. Attila, Thanks for taking the time to respond and share your practical experiences in this area. Your explanations are very helpful, I have a few more questions if you don't mind: 1) Would you elaborate on the "saw-tooth" correction, is this related to the "correction" data made available by the GPS receiver that is in addition to the 1PPS output, which apparently has limited accuracy by itself. 2) I think I understand this. Further I will have to understand what the optimal PLL BW is in lig
Re: [time-nuts] imprecise but adequate time
Hi Eric, > 2. Date/time stamps in the data shall be rounded to the nearest EVEN second by the system instances That's a clever way to both mask accuracy & uncertainty and to avoid leap seconds. Still, it smells like a hack, unfit for the 21st century. But I feel your pain. BTW, this is how mod times are stored in the FAT file system. [1] For example, if a camera uses a SD card, you'll see that every photo has an EVEN time stamp. In this case it wasn't to avoid leap seconds but rather it allowed time-of-day to fit in 16 bits (back in the era when bytes mattered). So there's ancient (any maybe even forensic or legal) precedent for what you're doing. I worry, though, about the next person tasked with improving your design. You have fused two separate issues together: the issue of timestamp accuracy / resolution / legal traceability, and the issue of properly handling UTC (leap seconds). Are you sure there's no other practical solution than to use EVEN seconds? /tvb [1] https://en.wikipedia.org/wiki/File_Allocation_Table ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Truetime XL / XLi question
Here is the exact output from my XLi. There are extra lines for F18 and F72 but not F73. >F18 F18 BOOTLOADER 192-8000 SOFTWARE192-8001 FILE SYSTEM 192-8002V2.0 PROJ REV # 2.0 FPGA # 184-8000V64 >F72 F72 CLOCK PLL LOCKED CLOCK STATUS LOCKED GPS PRI PRIMARY POWER SUPPLY OK SECONDARY POWER SUPPLY OK RUBIDIUM OSC OK >F73 F73 SLP IA- > William ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] imprecise but adequate time
Something to think about. Leap seconds. But that said I suspect the reason for the reasonable time is that many publishers wouldn't have access to a solid time source like GPS or some other universal reference. Really agree with Mike on the litigation aspect and the need for accurate time. How do you stay clear of that issue. It will ultimately show up on your door step. Regards Paul WB8TSL On Tue, May 28, 2019 at 12:00 PM K5ROE Mike wrote: > If the data collected by your system could potentially be used in > litigation , I would reconsider your accuracy requirement, especially > the OKness of simultaneous transactions. > > I assume that all nodes can write to the blockchain; how do you sanity > check if one node's clock is wildly off? > > Since you don't control the operating system, but do control the > application code, you may want/have to maintain time in your application. > > Since everybody is writing to the same chain, I don't see how you can > not use a mutual time reference among the nodes. > > > On 5/28/19 10:38 AM, Eric Scace wrote: > > Hi fellow time nuts — > > > > I’m looking for a sanity check or alternative suggestions for the > problem and tentative solution described below. > > > > Thanks for your thoughts. > > > > — Eric > > > > Problem: > > > > In one of my day jobs, I am designing a global network of systems > (using open-source software) that provide well-researched information about > rights and licenses for musical works (e.g., songs, compositions). > > > > Claiming rights, registering licenses (some of which are temporary), > and time-stamping changes to data each exemplify cases where date/time must > be included. In many cases the time order of events can be important — > potentially changing who gets paid how much when music is performed or > distributed. > > > > The machines are scattered around the planet and the usual problems > of time distribution exist. Furthermore, systems are operated > independently. We assume occasional use of NTP to correct system clocks, > but not a local GPS-provided time. The software development team is > generally oblivious to the issues of time in distributed computer networks. > > > > A grim picture — but, fortunately, this application does not require > high precision time. > > > > My tentative proposal: > > > > 1. To avoid burdening systems with multiple local time conversions, > all date/time information throughout the system shall be UTC. Implications: > > user apps will be responsible for converting from a human user’s local > time to UTC > > thus, user app developers will have to do this conversion correctly > > > > 2. Date/time stamps in the data shall be rounded to the nearest EVEN > second by the system instances; e.g., to 2019 May 28 14:24:28 UTC. > Implications: > > user apps that submit claims or updates will have their claims/updates > date/time-stamped by the receiving system node with this rounding method. > Example: “John Smith claims that he and Jane Doe wrote these lyrics, making > an equal contribution between them, on 2019 May 27 15:00:00 UTC. His claim > was received by the system at 2019 May 28 14:26:50 UTC.” One or more > blockchain ledgers record a hash of the musical work [the lyrics, in this > example], the claim [who wrote the lyrics when], and which app/system > registered the claim and when. > > events occurring roughly within ±1 second of each other will be deemed > to have occurred simultaneously. This is entirely adequate for this > application. > > competing leap second smearing methods employed by different operating > systems and data center operators will be washed out of the time stamp by > this rounding requirement. > > > > — end — > > ___ > > time-nuts mailing list -- time-nuts@lists.febo.com > > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > > and follow the instructions there. > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] imprecise but adequate time
If the data collected by your system could potentially be used in litigation , I would reconsider your accuracy requirement, especially the OKness of simultaneous transactions. I assume that all nodes can write to the blockchain; how do you sanity check if one node's clock is wildly off? Since you don't control the operating system, but do control the application code, you may want/have to maintain time in your application. Since everybody is writing to the same chain, I don't see how you can not use a mutual time reference among the nodes. On 5/28/19 10:38 AM, Eric Scace wrote: Hi fellow time nuts — I’m looking for a sanity check or alternative suggestions for the problem and tentative solution described below. Thanks for your thoughts. — Eric Problem: In one of my day jobs, I am designing a global network of systems (using open-source software) that provide well-researched information about rights and licenses for musical works (e.g., songs, compositions). Claiming rights, registering licenses (some of which are temporary), and time-stamping changes to data each exemplify cases where date/time must be included. In many cases the time order of events can be important — potentially changing who gets paid how much when music is performed or distributed. The machines are scattered around the planet and the usual problems of time distribution exist. Furthermore, systems are operated independently. We assume occasional use of NTP to correct system clocks, but not a local GPS-provided time. The software development team is generally oblivious to the issues of time in distributed computer networks. A grim picture — but, fortunately, this application does not require high precision time. My tentative proposal: 1. To avoid burdening systems with multiple local time conversions, all date/time information throughout the system shall be UTC. Implications: user apps will be responsible for converting from a human user’s local time to UTC thus, user app developers will have to do this conversion correctly 2. Date/time stamps in the data shall be rounded to the nearest EVEN second by the system instances; e.g., to 2019 May 28 14:24:28 UTC. Implications: user apps that submit claims or updates will have their claims/updates date/time-stamped by the receiving system node with this rounding method. Example: “John Smith claims that he and Jane Doe wrote these lyrics, making an equal contribution between them, on 2019 May 27 15:00:00 UTC. His claim was received by the system at 2019 May 28 14:26:50 UTC.” One or more blockchain ledgers record a hash of the musical work [the lyrics, in this example], the claim [who wrote the lyrics when], and which app/system registered the claim and when. events occurring roughly within ±1 second of each other will be deemed to have occurred simultaneously. This is entirely adequate for this application. competing leap second smearing methods employed by different operating systems and data center operators will be washed out of the time stamp by this rounding requirement. — end — ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] imprecise but adequate time
Hi fellow time nuts — I’m looking for a sanity check or alternative suggestions for the problem and tentative solution described below. Thanks for your thoughts. — Eric Problem: In one of my day jobs, I am designing a global network of systems (using open-source software) that provide well-researched information about rights and licenses for musical works (e.g., songs, compositions). Claiming rights, registering licenses (some of which are temporary), and time-stamping changes to data each exemplify cases where date/time must be included. In many cases the time order of events can be important — potentially changing who gets paid how much when music is performed or distributed. The machines are scattered around the planet and the usual problems of time distribution exist. Furthermore, systems are operated independently. We assume occasional use of NTP to correct system clocks, but not a local GPS-provided time. The software development team is generally oblivious to the issues of time in distributed computer networks. A grim picture — but, fortunately, this application does not require high precision time. My tentative proposal: 1. To avoid burdening systems with multiple local time conversions, all date/time information throughout the system shall be UTC. Implications: user apps will be responsible for converting from a human user’s local time to UTC thus, user app developers will have to do this conversion correctly 2. Date/time stamps in the data shall be rounded to the nearest EVEN second by the system instances; e.g., to 2019 May 28 14:24:28 UTC. Implications: user apps that submit claims or updates will have their claims/updates date/time-stamped by the receiving system node with this rounding method. Example: “John Smith claims that he and Jane Doe wrote these lyrics, making an equal contribution between them, on 2019 May 27 15:00:00 UTC. His claim was received by the system at 2019 May 28 14:26:50 UTC.” One or more blockchain ledgers record a hash of the musical work [the lyrics, in this example], the claim [who wrote the lyrics when], and which app/system registered the claim and when. events occurring roughly within ±1 second of each other will be deemed to have occurred simultaneously. This is entirely adequate for this application. competing leap second smearing methods employed by different operating systems and data center operators will be washed out of the time stamp by this rounding requirement. — end — ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Updating the unit of,time: the second.
On 5/28/19 2:12 AM, Attila Kinali wrote: On Tue, 28 May 2019 03:06:12 +0100 Another way to look at it is, before you reach the point where the redefinition of the kg change becomes visible, other errors like buoyancy of air will introduce errors that are orders of magnitude largers (uncorrected the buoyancy induced uncertainty is IIRC in the a few ppm range, corrected its induced uncertainty goes to 1e-8). So, unless you are doing your weight measurements in vacuum, there is no need to care about the change of definition of kg. Air is about 1mg/cc, so your measured mass is off by 1000 ppm if you're measuring water (depending on how much air your vessel displaces). If you're weighing lumps of lead (11.3 g/cc), then only 100ppm error. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Network Time Puzzle
I would broaden your experiment to try many different remote servers. Maybe using different chunks of the global NTP pool (https://www.ntppool.org/en/use.html) It could be traffic shaping on your ISP , an ISP in the middle, or one on the remote end. It could be traffic prioritization from one of the above that lowers priority for ports > 1024 It could be weirdness from the network stack on your Windows XP clients. You might considering using something more modern. K5ROE Mike On 5/26/19 4:26 AM, Peter Martinez via time-nuts wrote: Greetings, Time Nuts, from a new member. I have two old Windows XP laptops on which I can lock the timing to GPS, which means I can read the time at which things happen to a few microseconds. I thought I would modify some of my old NTP software, both client and server, to make use of this and see how well the ntp system performs. It's all working fine, but in the course of trying to decide what to set for the "local port address", I discovered a strange effect. If I set the local port address of my ntp client to one value (somewhere between 49152 and 65535 for example), then query an ntp server on the internet, then change the local port to another value and do it again, the Time Offset and Round Trip Delay readings come back different. Change the port back and the offset/delay values go back to the original. Same on the other PC. But ONLY on some distant servers. Most of them don't show the effect. I have seen jumps of about 6.2msec in delay and 3.1msec in offset, but the offset might be positive or negative. This leads me to think that this wierd effect is a propagation delay occuring in one of the two paths, either the path from me to the server or from the server back to me. On some servers I have seen the delay jump by 12.4msec with no jump in the offset. This must be a 6.2 msec. delay in BOTH propagation delays. In this case, four different values of local port address can give rise to 4 different delay/offset combinations. A scatter plot of delay versus offset, with random port address, shows four dots in a diamond shape. Different delay values give different-sized diamonds. Routes with more than one such effect show even prettier patterns of superimposed diamonds. The effect is stable over time, at least for the length of time (weeks) I have been studying it. If this is real (and I am fairly sure it's not a bug at my end or at the servers), then it will impact on the accuracy which can be achieved with NTP. I ask myself "Why does the network do this?". Is there a valid reason for it, or is it a side-effect of something else? Has anyone else seen this effect? Is there anyone out there reading this who could modify an NTP client program so that the loal port address can be changed manually, and see if this is a widespread feature of the internet. If this effect didn't occur, NTP could be a lot better than it is now. Regards Peter Martinez G3PLX ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Updating the unit of,time: the second.
On Tue, 28 May 2019 at 11:03, Attila Kinali wrote: > On Tue, 28 May 2019 03:06:12 +0100 > "Dr. David Kirkby" wrote: > > > I notice a lot of 1 kg weights on eBay, so perhaps the same will happen > > with Cs clocks! > > This is rather unlikely. For one, Cs beam standards have a very limited > life span. For an other I am pretty sure that the surge of kg weight > standards on ebay is due to their manufacturing becoming cheap rather > than the kg definition changing. Most of these standards are M1 or M2 > anyways (or in other words, they are accurate to 50ppm or 160ppm > respectively [1]), which is way more than the slight change in the > definition of the kg. I assume that you missed the fact that I was joking about the 1 kg weights on eBay. > > > Attila Kinali Dave, G8WRB -- Dr David Kirkby Ph.D C.Eng MIET Kirkby Microwave Ltd Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, CHELMSFORD, Essex, CM3 6DT, United Kingdom. Registered in England and Wales as company number 08914892 https://www.kirkbymicrowave.co.uk/ Tel 01621-680100 / +44 1621-680100 ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Updating the unit of,time: the second.
On Tue, 28 May 2019 03:06:12 +0100 "Dr. David Kirkby" wrote: > I notice a lot of 1 kg weights on eBay, so perhaps the same will happen > with Cs clocks! This is rather unlikely. For one, Cs beam standards have a very limited life span. For an other I am pretty sure that the surge of kg weight standards on ebay is due to their manufacturing becoming cheap rather than the kg definition changing. Most of these standards are M1 or M2 anyways (or in other words, they are accurate to 50ppm or 160ppm respectively [1]), which is way more than the slight change in the definition of the kg. Another way to look at it is, before you reach the point where the redefinition of the kg change becomes visible, other errors like buoyancy of air will introduce errors that are orders of magnitude largers (uncorrected the buoyancy induced uncertainty is IIRC in the a few ppm range, corrected its induced uncertainty goes to 1e-8). So, unless you are doing your weight measurements in vacuum, there is no need to care about the change of definition of kg. If we look at frequency standards, then using a simple L1-only GPSDO brings us to better than 1e-10 for τ > 1s. If you do PPP frequency transfer as Ole did, you get to 1e-11 for τ > 1s and down to 1e-14 for τ > 1000s. And all that with a very moderate budget. Why spend thousands of € for a surplus Cs beam that will be out of Cs fumes in 5-10 years, when I can build a similar quality standard for a fraction of the cost that is probably going to work for decades to come? Attila Kinali [1] OIML R111-1 https://www.oiml.org/en/files/pdf_r/r111-1-e04.pdf -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neal Stephenson ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
