Re: [time-nuts] June 30 2015 leap second
The referenced article indicates that they apply the smear to their NTP servers and allow the clients to track the servers. This approach would place some limits on the minimum lead time you would need to implement the smear. 1) you would have to start early enough for the servers to detect the change. Unless Google has an internal policy to limit maxpoll you would expect the clients to be operating at the default value of 1024 seconds. They would have to start well before 1024 seconds to allow the clients to detect the change and start tracking. 2) NTP has a maximum slew rate of 500ppm ( http://doc.ntp.org/4.1.0/ntpd.htm) . In practice you wouldn't be able to use this full range because the clients would already have some error in their clocks. The scary part of the referenced article is in the third to last paragraph: and Google engineers developing code don’t have to worry about leap seconds. That seems like the kind of attitude that would have caused such a mess with computer timekeeping in the first place. On 1/11/2015 09:31, Tom Van Baak wrote: The google code is lie(t) = (1.0 - cos(pi * t / w)) / 2.0 and they are wise not to publish the actual window value, w. If it were me I'd make it somewhere between a couple of seconds or couple of minutes but I too would not make it a published or hardcoded constant. Here's the link again: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html ___ 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] June 30 2015 leap second
I've often wondered why more systems don't use TAI or other similar time scales as their time source. If needed the time displayed to end users or third parties could be converted to UTC just prior to presentation or transmittal. For example a financial system that needs to time stamp individual transactions could sync their system clocks to TAI. As the difference between TAI and UTC changed (or was scheduled to change) a lookup table could be updated that would provide the offset between UTC and TAI for given date ranges. Sent from my iPad On 2015-01-10, at 7:49 AM, Jim Lux jim...@earthlink.net wrote: On 1/9/15 4:57 PM, Henry Hallam wrote: Such slewing solutions are OK for Google. They wouldn't work well for one of the systems I work with, which uses system time to calculate the position of a LEO satellite for purpose of pointing a 7.6 meter X-band dish. Half a second of error corresponds to a pointing error of 0.5 degrees, well outside the main lobe of the antenna beam. Which is why we use TAI in the space business and don't fool with this Greenwich Mean Time or Coordinated Universal Time which is discontinuous and potentially non-monotonic. We DO need to compensate for the earth's varying rotational speed, though, but that's just handled as a separate model for deep space, or for LEO, where the coordinate system is Earth Centered, absorbed into the spacecraft orbital elements.. nobody is going to use 1 year old ephemerides) I do find myself explaining exactly WHY we can't just use PC system time, etc. and periodic leap seconds are an object lesson in why not. (or, you can arrange to not being doing any operations at the moment of leap...that's been done too) ___ 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] Sources for Mission Time Clock
Martin, [] 4) The television monitor ideas are an easy solution. Use a PC or Raspberry Pi. One example here: https://www.youtube.com/watch?v=vBQ3uqMep58 /tvb = .. and a Raspberry Pi clock with source code you could easily modify: http://www.satsignal.eu/raspberry-pi/DigitalClock.html Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ 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] June 30 2015 leap second
martin.burni...@burnicki.net said: So I think they smeared it over more than just a few minutes. I'd expect some hours, so standard NTP clients would just notify this as clock drift (oscillator frequency offset) which they'd have to compensate. Since ntpd's control loop is pretty slow it wouldn't respond quickly to smears over a few seconds our hours. NTP and/or most kernels have a limit on how far they are willing to push the clock. ntpd's limit is 500 ppm. It's common for normal clocks to be off 100 ppm, so you can't use all of that for leap-smearing. If you assume that you can slew at 100 ppm, then it will take 1 seconds to slew 1 second. That's assuming a step function. But Google uses cos to round off the corners, so the time will be longer. -- 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] GPS 1PPS ultimate accuracy
Hello all. I am planning to do some experiments to evaluate the aging of oscillators (this one of the reasons I'm willing to buy the Milleren without EFC). What I would like to do exactly is to sample the total of a counter (of suitable number of bits, taking in account the fact that it will overflow) whose clock is the DUT. The sampling interval could come from a (long time based on a) sawtooth uncorrected PPS from a cheap GPS, a sawtooth corrected from a good one (perhaps the Lucent GPSDO), or a computer using NTP. Each of these sources should reach a goal stability (say, 1 part in 10^13) after averaging them on a different (and very high I suppose) number of seconds (averaging them for an infinity number of seconds should give the stability of the underlying reference clock, but I'm willing to stop sooner...). I know there's no reason to go 1E-13 when the Milliren couldn't go that far, but the DUT may be also something else like a FE-5680A). The sawtooth uncorrected GPS receiver may never yeld a good stability in the short term, but in the long one it should as well because the internal clock jitter would average results. If I'm using the correct teminology, after what tau the ADEV graph of the different references intersect the 1E-13? By the way, the stability of the TAI is known or, because it's the reference one, it has zero deviation for definition (so you can reach its ultimate stability through GPS really only at the infinity...)? Best regards, Andrea Baldoni ___ 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] In search of ways to improve Raspberry Pi stratum 1 server
Hi all, This is my first post to the list. I have a Raspberry Pi B+ and a HAB Supplies U-Blox Max-M8Q set in stationary mode connected to a Virgin Media Superhub (broadband router) by a 0.5m cat7 ethernet cable. The GPS is attached to the Pi's GPIO and has an external active antenna placed on an inside window sill. The Pi is running Raspbian on a fast Class10 microSD card and has a kernel (Linux raspberrypi 3.12.35 #1 PREEMPT Sun Jan 11 17:40:22 GMT 2015 armv6l GNU/Linux) rebuilt to disable tickless, enable PHY timestamping and enable all appropriate PPS options, and has NTP 4.2.8p1-beta5 compiled with: ./configure --enable-linuxcaps --enable-ATOM --enable-NMEA --disable-ipv6 --disable-all-clocks --disable-parse-clocks --disable-debugging and with my ntp.conf file set up thus: -- logfile /var/log/ntp.log driftfile /var/lib/ntp/ntp.drift statsdir /var/log/ntpstats/ statistics loopstats peerstats clockstats protostats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable filegen protostats file protostats type day enable leapfile /home/time/leap-seconds.3629404800 server ntp0.catn.com iburst server ntp2c.mcc.ac.uk iburst server ntp1.luns.net.uk iburst server ntp1.uk.uu.net iburst server ntp.colinbarrett.co.uk iburst server 127.127.20.0 mode 17 minpoll 4 maxpoll 4 prefer fudge 127.127.20.0 flag1 0 flag2 0 flag3 0 flag4 0 time1 0.0 time2 0.1137 server 127.127.22.0 minpoll 4 maxpoll 4 fudge 127.127.22.0 refid PPS time1 0.000 flag2 0 flag3 1 restrict default limited kod nomodify notrap nopeer restrict 127.0.0.1 -- After an hour or so, ntpq -crv -pn; ntptime; ntpq -c clockvar shows: associd=0 status=011d leap_none, sync_pps, 1 event, kern, version=ntpd 4.2.8p1-beta5@1.3265-o Sun Jan 11 19:10:22 UTC 2015 (1), processor=armv6l, system=Linux/3.12.35, leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=1.015, refid=PPS, reftime=d85e39b2.e1489c74 Mon, Jan 12 2015 12:16:50.880, clock=d85e39b4.0ea565be Mon, Jan 12 2015 12:16:52.057, peer=4258, tc=4, mintc=3, offset=-0.000466, frequency=-17.209, sys_jitter=0.001907, clk_jitter=0.001, clk_wander=0.000, tai=35, leapsec=20150701, expire=20151228 remote refid st t when poll reach delay offset jitter == *127.127.20.0 .GPS. 0 l 3 16 377 0.000 -1.066 2.801 o127.127.22.0 .PPS. 0 l 2 16 377 0.000 0.000 0.002 -87.124.126.49 195.66.241.3 2 u 34 64 377 29.758 8.186 0.977 -130.88.200.6 130.88.200.4 3 u 14 64 377 17.783 1.952 0.580 +217.114.59.3 158.43.192.66 2 u 7 64 377 15.947 4.033 0.814 +158.43.128.66 193.67.79.202 2 u 15 64 377 10.319 1.873 0.553 81.174.247.243 .INIT. 16 u - 1024 0 0.000 0.000 0.000 ntp_gettime() returns code 0 (OK) time d85e39b4.49e7c8d4 Mon, Jan 12 2015 12:16:52.288, (.288693882), maximum error 2000 us, estimated error 1 us, TAI offset 35 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 0.000 us, frequency -17.209 ppm, interval 256 s, maximum error 2000 us, estimated error 1 us, status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO), time constant 4, precision 0.001 us, tolerance 500 ppm, pps frequency -17.207 ppm, stability 0.004 ppm, jitter 0.507 us, intervals 73, jitter exceeded 45, stability exceeded 0, errors 0. associd=0 status= no events, clk_unspec, device=PPS Clock Discipline, timecode=, poll=828, noreply=0, badformat=0, baddata=0, stratum=16, refid=80.80.83.0, flags=4 I've tried using Banana Pi and Beaglebone Black SBCs and have also used u-blox Max-7Q and Trimble Copernicus II GPS breakout boards with no improvement (The Banana Pi is the best but is stuck on the Allwinner 3.4 kernel, which I'm not thrilled about), leading me to believe the roadblock to a more precise clock lies in my less than ideal antenna setup, but my questions are: can I improve upon this and, if so, how? Have I made any obvious errors? I'm relatively new to this and would appreciate any advice I can get. Thanks, Neil. ___ 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] 53132A Cooling fan
Hallo Stan Anyone have any thoughts on exactly where to put a temperature sensor for a proportional fan controller? I have some fans having a thermistor built in -like shown in http://img.techpowerup.org/091114/1114091748.jpg. Seems to me to be a good enough place. Rises the next question about the temprature threshold which should be set... br, Ulli ___ 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] Current state of optical clocks and the definition of the second
Hi, I just stumbled over this [1] nice article by Fritz Riehle that might be of interest to others as well. Attila Kinali [1] Towards a Re-definition of the Second Based on Optical Atomic Clocks, by Fritz Riehle, 2015 http://arxiv.org/abs/1501.02068 -- 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, Neil Stephenson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Current state of optical clocks and the definition of the second
On Mon, 12 Jan 2015 13:34:03 +0100 Attila Kinali att...@kinali.ch wrote: I just stumbled over this [1] nice article by Fritz Riehle that might be of interest to others as well. And while we are at it: 2e-18 total uncertainty in an atomic clock, by T.L. Nicholson et.al., 2015 http://arxiv.org/abs/1412.8261 -- 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, Neil Stephenson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Arduino GPIB
Yes, you can get an Arduino R3 on eBay for $4 with shipping... The GPIB connector will cost you more! Didier KO4BB On January 12, 2015 8:45:12 AM CST, paul swed paulsw...@gmail.com wrote: That certainly is a hack. But its something I have often thought about and never did. He is right its really a one instrument interface as it doesn't have the buffers to drive the load of multiple instruments. But heavens that has to be a really cheap interface for a bit of soldering effort. My type of effort. :-) Regards Paul. WB8TSL On Sun, Jan 11, 2015 at 11:57 PM, Joseph Gray jg...@zianet.com wrote: I thought everyone here would find this of interest. I stumbled across it a few days ago on the 'net. It is a Prologix GPIB-USB compatible made with an Arduino Uno. http://egirland.blogspot.com/2014/03/arduino-uno-as-usb-to-gpib-controller.html Like on his web site, I just took a cheap GPIB cable, cut off about 12 inches and shoved the wires into the socket holes on an Uno. I uploaded his program and did some minor testing so far. BTW, it didn't work the first time due to poor contact. I shoved some pin headers in, after the wires and now it works fine. John's Prologix config program works just fine with this cobbled together GPIB adapter. I attached it to my HP 3457A and then ran the demo program that comes with Ulrich's EZGPIB. It is logging data as I type this. I will do more testing with other instruments, as I have time. As mentioned on the web page linked above, a few commands are not yet implemented, although they appear to be little used commands (except perhaps the ++savecfg command). I think I have a way to implement the ++rst command using the watchdog timer. For ++savecfg, it shouldn't be too difficult to store things in the Arduino EEPROM. I have some cheap Arduino Nano's and PCB-mount GPIB connectors on order. I will be making a couple of these Proligix-compatible adapters with those parts, so that they aren't just wires shoved into a board. I'll have to find a small box to house things. I have also ordered some buffer chips to add to the design. Total cost should be under $20 for each adapter. The firmware uses a serial baud rate of 115200, which I assume is the same as a real Prologix. I'm going to try some higher baud rates to see how fast the Arduino can push bits without losing them. I understand that with the default 16 MHz clock, non-standard baud rates that are evenly divisible into the clock rate should work even better I'll report back. One question about the baud rate - are there any reasons not to change from 115200? Since we are simply moving bits through a USB/Serial adapter, does any software really care what the baud rate is, as long as we don't drop any bits? Joe Gray W5JG ___ 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. -- Sent from my Motorola Droid Razr HD 4G LTE wireless tracker while I do other things. ___ 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] Arduino GPIB
Yes, you can get an Arduino R3 on eBay for $4 with shipping... The GPIB connector will cost you more! Didier KO4BB A sandwich of two PCB is about the same thickness as the center plug of a GPIB male connector. So layout 2x12 pads to match the pins and you have a one-piece Arduino and GPIB connector board. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Hi Tom, You are correct, but it does not really matter because it will not be instantaneous, and for a period of time that is well within the range of human perception, the clock will be off by more than you would normally expect. We have been talking about NTP being able to keep the time to within uS or better and this is a system that deliberately introduces an error a million times bigger. I am just surprised Time-Nuts would not go nuts about it :) Didier KO4BB On January 11, 2015 8:31:12 AM CST, Tom Van Baak t...@leapsecond.com wrote: Keep in mind that this system drives you to having pretty bad time for the better part of a whole day, on purpose... I realize that when the Hi Didier, The google article never claims the smear spans an entire day. I think you may be confusing references to the leap smear with a DIY digital clock someone on the list wanted to build (and they proposed using a slow 86400 second slew). The google code is lie(t) = (1.0 - cos(pi * t / w)) / 2.0 and they are wise not to publish the actual window value, w. If it were me I'd make it somewhere between a couple of seconds or couple of minutes but I too would not make it a published or hardcoded constant. Here's the link again: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html Again, I don't know what value they use, or even if they use the same value from one leap second to the next. If any of you have inside contacts with google and can find out let me know, off-list. Regardless, it should be possible to experimentally determine the smear duration by repeatedly using some google service that returns time-stamps during the day, hours, minutes, or seconds before and after June 30. It would make a nice posting for a time nut, or a research paper for a high school student or undergrad: Experimental Confirmation of Google's Leap Smear Algorithm. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Sent from my Motorola Droid Razr HD 4G LTE wireless tracker while I do other things. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPS 1PPS ultimate accuracy
Hi Actually it’s a bit worse than you might expect. The uncorrected sawtooth will give you about 20 ns of wander. At the one day level, GPS without some sort of ionosphere help (like a dual frequency receiver) will add another 10 ns or so to that. Net, your pps is spread over a 30 ns range. The output of the OCXO is at 5 MHz, the Rb is at 10 MHz. Maybe you double the OCXO to 10 MHz. It only has a zero crossing every 100 ns. (200 ns if you don’t double it). You will have a 100 ns “dead zone” in your counter. That assumes it’s synchronous. If it’s a ripple counter, who knows what it will do. Net result, You have 30 ns of error, and a 100 ns resolution. Net is 130 ns. You will hit 1x10^-9 at a bit over 100 seconds. You will get to 1x10^-12 at around 13,000 seconds. Since it’s a dead zone, averaging really does not help you much. In fact, long averages will mess up the ADEV computations. If you have a goal that resolution should be 5X your data, then you get to 1x10^-12 data at around 80,000 seconds. For a good ADEV number, you would like about 100 samples. This gets you out to a 100 day run. Even for a minimalist number, you are running for 10 days. Any time you have a power interruption, the process re-starts. With things like 5335’s running around for cheap prices, I would suggest doing this with a counter. You are going to spend a lot of days getting very much data. Your time’s got to be worth something …. Bob On Jan 12, 2015, at 9:10 AM, Attila Kinali att...@kinali.ch wrote: Ciao Andrea, On Mon, 12 Jan 2015 11:59:26 +0100 Andrea Baldoni erm1ea...@ermione.com wrote: The sampling interval could come from a (long time based on a) sawtooth uncorrected PPS from a cheap GPS, a sawtooth corrected from a good one (perhaps the Lucent GPSDO), or a computer using NTP. The GNSS Timing AppNote for the LEA6-T receiver[1] will give you an idea what jitter you get with GPS. Please be aware that these measurements were done with an antenna located at a _good_ position (ontop of a 4 story building with no other high buildings around). Unless you have a simlarly good location you will have worse performance. Said Jackson reported some time ago that he got around 1us of jitter for a GPS receiver (i presume it was either a LEA5-T or a LEA6-T) behind a window. After he averaged the position for a long time (several days) manually and stored that in the receiver he got much better performance (sorry i cannot find the mail at the moment, you have to look for it in the archives yourself). NTP will give you a jitter in the range of 1-100ms, depending on your internet connection and its conguestion. On a local network based NTP system, you can expect jitter in the range of 10-100us IIRC. Each of these sources should reach a goal stability (say, 1 part in 10^13) after averaging them on a different (and very high I suppose) number of seconds (averaging them for an infinity number of seconds should give the stability of the underlying reference clock, but I'm willing to stop sooner...). I know there's no reason to go 1E-13 when the Milliren couldn't go that far, but the DUT may be also something else like a FE-5680A). To get to 1e-13 with GPS (assuming 1-10ns jitter) you need somewhere around 10k to 100k seconds. At these time scales, the temperature dependent deviation of your OCXO is likely to dominate your measurement. I would rather do a two step measurement. If you have a FE-5680A measure its drift with a tau in the 100ks-200ks region. Then use the FE-5680A as refrence to measure the drift of the OCXO in 10s-1000s timescales. If you do both continuously, you can apply some math and get out pretty good numbers (see three cornered hat method) Additional to GPS jitter you also have the deviation of GPS time in respect to TAI/UTC. This has been in recent years below 5ns (GPS vs UTC(USNO)). But because GPS time is steered to be close to UTC it will oscillate slightly around it. How much, i do not know. (But then the deviation between the different UTC realizations is larger) [2] The sawtooth uncorrected GPS receiver may never yeld a good stability in the short term, but in the long one it should as well because the internal clock jitter would average results. It would average out if and only if the sawtooth correction would be completely independent of anything else. But it isn't. This results in effects where the cycle to cycle jitter is quite low, but there is a large offset in the sawtooth correction. This is know as hanging bridges in the GNSS world. By the way, the stability of the TAI is known or, because it's the reference one, it has zero deviation for definition (so you can reach its ultimate stability through GPS really only at the infinity...)? There is an uncertainty number attached to TAI, but i dont know any numbers from the top of my head. I'm sure it is mentioned in the BIPM report somewhere.
[time-nuts] A novel use of Injection locking of ring oscillators
Every good time nut knows about the hazards and subtle wonders of unintentional injection locking of oscillators. Other people apparently don't... How forced injection locking of ring oscillators can be hazardous to your wallet: http://www.cl.cam.ac.uk/~atm26/papers/markettos-ches2009-inject-trng.pdf I saw a followup where they breached an ATM machine by modulating a 10 GHz microwave signal with the injection locking signal and beaming it into the ATM. ___ 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] In search of ways to improve Raspberry Pi stratum 1server
Your antenna could be better. But really the bottle neck on any NTP server is time stamping the PPS. There is greater uncertainty in the time stamp then of the PPS. The best solution ever (I can't find the link) was done using an external clock. It was a low power Intel PC running BSD and the system clock was an external counter running off some kind of precision crystal oscillator. The PPS would sample the counter then interrupt the PC. The PC could be as slow as it likes responding to the interrupt because the time is already sampled. The OS got it's time from this earth clock too. Yes some modification the Kernel was required but it's simple. This removed an unknowable interrupt latency. Look at the Linux PPS driver code. It is very simple. It samples the internal counter then sets a flag to say a sample is received. NTP only has to be fast enough to read the sample before the next PPS. What these guys did was make the counter external driven from something like an OCXO. On Mon, Jan 12, 2015 at 7:25 AM, David J Taylor david-tay...@blueyonder.co.uk wrote: Hi all, This is my first post to the list. I have a Raspberry Pi B+ and a HAB Supplies U-Blox Max-M8Q set in stationary mode connected to a Virgin Media Superhub (broadband router) by a 0.5m cat7 ethernet cable. The GPS is attached to the Pi's GPIO and has an external active antenna placed on an inside window sill. The Pi is running Raspbian on a fast Class10 microSD card and has a kernel (Linux raspberrypi 3.12.35 #1 PREEMPT Sun Jan 11 17:40:22 GMT 2015 armv6l GNU/Linux) rebuilt to disable tickless, enable PHY timestamping and enable all appropriate PPS options, and has NTP 4.2.8p1-beta5 compiled with: [] I've tried using Banana Pi and Beaglebone Black SBCs and have also used u-blox Max-7Q and Trimble Copernicus II GPS breakout boards with no improvement (The Banana Pi is the best but is stuck on the Allwinner 3.4 kernel, which I'm not thrilled about), leading me to believe the roadblock to a more precise clock lies in my less than ideal antenna setup, but my questions are: can I improve upon this and, if so, how? Have I made any obvious errors? I'm relatively new to this and would appreciate any advice I can get. Thanks, Neil. === Neil, I see approximately the same here, with the exception of those systems using a kernel which /is/ tickless where the jitter is a factor of about two worse. I can see anything wrong. I couldn't face recompiling the kernel another time, and have asked that nohz=no be accepted by the stock kernel, particularly now that it includes PPS support. Based on plotting the jitter with MRTG the Raspberry Pi cards perform at least as well as an Intel Atom system running Linux. http://www.satsignal.eu/mrtg/performance_ntp.php The Intel system did work rather better with FreeBSD, so it would be interesting to know whether the Raspberry Pi is capable of improved performance using that OS. I would be most interested to know the outcome. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ 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] June 30 2015 leap second
Today, I did the check the settings for my BC637 card. I was surprised that its overwrite my manual setting for the Leap Event by following information: Time Settings: Mode : GPS Time Format: Binary Year : 1995 Local Offset : 0.0 Propagation Delay : 0 Current Leap Seconds : 16 Scheduled Leap Event Time : 876614400 Scheduled Leap Event Flag : Insertion GPS Time Format: UTC Format IEEE Daylight Savings Flag : Enable Sun, 12 Oct 1997 00:00:00 GMT. Its weird. I am going to re-insert it and will check it again later. New Time Settings are: Mode : GPS Time Format: Binary Year : 2015 Local Offset : 0.0 Propagation Delay : 0 Current Leap Seconds : 16 Scheduled Leap Event Time : 1435708799 Scheduled Leap Event Flag : Insertion GPS Time Format: UTC Format IEEE Daylight Savings Flag : Enable Also, my NTP, which rely on that card, didn't get the value for leap second event yet: # ntpq -c rv associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer, version=ntpd 4.2.6p5@1.2349 Mon Sep 22 20:41:39 UTC 2014 (14), processor=x86_64, system=Linux/3.2.0-74-generic, leap=00, stratum=1, precision=-23, rootdelay=0.000, rootdisp=8248.907, refid=BTFP, reftime=d85e7526.957a1b17 Mon, Jan 12 2015 11:30:30.583, clock=d85ec544.e1effe31 Mon, Jan 12 2015 17:12:20.882, peer=0, tc=4, mintc=3, offset=3.757, frequency=-243.698, sys_jitter=0.000, clk_jitter=1.328, clk_wander=15.616 Regards, Vlad It's fragile enough that there have been accidental false leap-second events. Yes, for example if there have been GPS receivers which decoded the UTC parameters incorrectly, and started to announce a leap second when there wasn't one (end of September). That's why, for example, ntpd's leap second handling code has been changed in v4.2.6 to accept a leap second warning only if the warning is received from a majority of the configured servers. If you want to be sure you can also provide ntpd with a leap second file which is then (in current versions) considered as authentic source for leap second information. Martin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- WBW, V.P. ___ 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] Arduino GPIB
On Mon, Jan 12, 2015 at 6:45 AM, paul swed paulsw...@gmail.com wrote: its really a one instrument interface as it doesn't have the buffers to drive the load of multiple instruments. But heavens that has to be a really cheap interface for a bit of soldering effort. My type of effort. :-) With Arduinos going for well under $10 You could afford to place one Aruino INSIDE your test instrument. Those old instruments usually have some air space inside and a power supply suitable for an Arduino. Now you have added a USB port to some 1980's vintage test gear. If the Arduino is inside you may not even need the GPIB connector.You could do this to many older instruments then use USB to a USB hub, then to a computer. -- 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] GPS 1PPS ultimate accuracy
Ciao Andrea, On Mon, 12 Jan 2015 11:59:26 +0100 Andrea Baldoni erm1ea...@ermione.com wrote: The sampling interval could come from a (long time based on a) sawtooth uncorrected PPS from a cheap GPS, a sawtooth corrected from a good one (perhaps the Lucent GPSDO), or a computer using NTP. The GNSS Timing AppNote for the LEA6-T receiver[1] will give you an idea what jitter you get with GPS. Please be aware that these measurements were done with an antenna located at a _good_ position (ontop of a 4 story building with no other high buildings around). Unless you have a simlarly good location you will have worse performance. Said Jackson reported some time ago that he got around 1us of jitter for a GPS receiver (i presume it was either a LEA5-T or a LEA6-T) behind a window. After he averaged the position for a long time (several days) manually and stored that in the receiver he got much better performance (sorry i cannot find the mail at the moment, you have to look for it in the archives yourself). NTP will give you a jitter in the range of 1-100ms, depending on your internet connection and its conguestion. On a local network based NTP system, you can expect jitter in the range of 10-100us IIRC. Each of these sources should reach a goal stability (say, 1 part in 10^13) after averaging them on a different (and very high I suppose) number of seconds (averaging them for an infinity number of seconds should give the stability of the underlying reference clock, but I'm willing to stop sooner...). I know there's no reason to go 1E-13 when the Milliren couldn't go that far, but the DUT may be also something else like a FE-5680A). To get to 1e-13 with GPS (assuming 1-10ns jitter) you need somewhere around 10k to 100k seconds. At these time scales, the temperature dependent deviation of your OCXO is likely to dominate your measurement. I would rather do a two step measurement. If you have a FE-5680A measure its drift with a tau in the 100ks-200ks region. Then use the FE-5680A as refrence to measure the drift of the OCXO in 10s-1000s timescales. If you do both continuously, you can apply some math and get out pretty good numbers (see three cornered hat method) Additional to GPS jitter you also have the deviation of GPS time in respect to TAI/UTC. This has been in recent years below 5ns (GPS vs UTC(USNO)). But because GPS time is steered to be close to UTC it will oscillate slightly around it. How much, i do not know. (But then the deviation between the different UTC realizations is larger) [2] The sawtooth uncorrected GPS receiver may never yeld a good stability in the short term, but in the long one it should as well because the internal clock jitter would average results. It would average out if and only if the sawtooth correction would be completely independent of anything else. But it isn't. This results in effects where the cycle to cycle jitter is quite low, but there is a large offset in the sawtooth correction. This is know as hanging bridges in the GNSS world. By the way, the stability of the TAI is known or, because it's the reference one, it has zero deviation for definition (so you can reach its ultimate stability through GPS really only at the infinity...)? There is an uncertainty number attached to TAI, but i dont know any numbers from the top of my head. I'm sure it is mentioned in the BIPM report somewhere. Attila Kinali [1] http://www.u-blox.com/images/downloads/Product_Docs/Timing_AppNote_%28GPS.G6-X-11007%29.pdf [2] GPS time and its steering to UTC(USNO), presentatin by Edward Powers, 2009 http://www.gps.gov/multimedia/presentations/2009/09/ICG/powers.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, Neil Stephenson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] In search of ways to improve Raspberry Pi stratum 1server
Hi all, This is my first post to the list. I have a Raspberry Pi B+ and a HAB Supplies U-Blox Max-M8Q set in stationary mode connected to a Virgin Media Superhub (broadband router) by a 0.5m cat7 ethernet cable. The GPS is attached to the Pi's GPIO and has an external active antenna placed on an inside window sill. The Pi is running Raspbian on a fast Class10 microSD card and has a kernel (Linux raspberrypi 3.12.35 #1 PREEMPT Sun Jan 11 17:40:22 GMT 2015 armv6l GNU/Linux) rebuilt to disable tickless, enable PHY timestamping and enable all appropriate PPS options, and has NTP 4.2.8p1-beta5 compiled with: [] I've tried using Banana Pi and Beaglebone Black SBCs and have also used u-blox Max-7Q and Trimble Copernicus II GPS breakout boards with no improvement (The Banana Pi is the best but is stuck on the Allwinner 3.4 kernel, which I'm not thrilled about), leading me to believe the roadblock to a more precise clock lies in my less than ideal antenna setup, but my questions are: can I improve upon this and, if so, how? Have I made any obvious errors? I'm relatively new to this and would appreciate any advice I can get. Thanks, Neil. === Neil, I see approximately the same here, with the exception of those systems using a kernel which /is/ tickless where the jitter is a factor of about two worse. I can see anything wrong. I couldn't face recompiling the kernel another time, and have asked that nohz=no be accepted by the stock kernel, particularly now that it includes PPS support. Based on plotting the jitter with MRTG the Raspberry Pi cards perform at least as well as an Intel Atom system running Linux. http://www.satsignal.eu/mrtg/performance_ntp.php The Intel system did work rather better with FreeBSD, so it would be interesting to know whether the Raspberry Pi is capable of improved performance using that OS. I would be most interested to know the outcome. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ 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] In search of ways to improve Raspberry Pi stratum 1 server
Neil Welcome to time-nuts. You say that your antenna is less then ideal. OK on time-nuts your going to find out details matter. So what does that mean? Typically the antenna needs to be high enough to have a clear view of the sky and it does matter. But there have been posts in the past about the Pi and I think there are internal issues with the Pi itself that may limit its use. Not an expert and maybe one day I will build a Pi NTP server. To many other things cooking. Regards Paul WB8TSL On Mon, Jan 12, 2015 at 7:30 AM, Neil Green nc...@hotmail.co.uk wrote: Hi all, This is my first post to the list. I have a Raspberry Pi B+ and a HAB Supplies U-Blox Max-M8Q set in stationary mode connected to a Virgin Media Superhub (broadband router) by a 0.5m cat7 ethernet cable. The GPS is attached to the Pi's GPIO and has an external active antenna placed on an inside window sill. The Pi is running Raspbian on a fast Class10 microSD card and has a kernel (Linux raspberrypi 3.12.35 #1 PREEMPT Sun Jan 11 17:40:22 GMT 2015 armv6l GNU/Linux) rebuilt to disable tickless, enable PHY timestamping and enable all appropriate PPS options, and has NTP 4.2.8p1-beta5 compiled with: ./configure --enable-linuxcaps --enable-ATOM --enable-NMEA --disable-ipv6 --disable-all-clocks --disable-parse-clocks --disable-debugging and with my ntp.conf file set up thus: -- logfile /var/log/ntp.log driftfile /var/lib/ntp/ntp.drift statsdir /var/log/ntpstats/ statistics loopstats peerstats clockstats protostats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable filegen protostats file protostats type day enable leapfile /home/time/leap-seconds.3629404800 server ntp0.catn.com iburst server ntp2c.mcc.ac.uk iburst server ntp1.luns.net.uk iburst server ntp1.uk.uu.net iburst server ntp.colinbarrett.co.uk iburst server 127.127.20.0 mode 17 minpoll 4 maxpoll 4 prefer fudge 127.127.20.0 flag1 0 flag2 0 flag3 0 flag4 0 time1 0.0 time2 0.1137 server 127.127.22.0 minpoll 4 maxpoll 4 fudge 127.127.22.0 refid PPS time1 0.000 flag2 0 flag3 1 restrict default limited kod nomodify notrap nopeer restrict 127.0.0.1 -- After an hour or so, ntpq -crv -pn; ntptime; ntpq -c clockvar shows: associd=0 status=011d leap_none, sync_pps, 1 event, kern, version=ntpd 4.2.8p1-beta5@1.3265-o Sun Jan 11 19:10:22 UTC 2015 (1), processor=armv6l, system=Linux/3.12.35, leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=1.015, refid=PPS, reftime=d85e39b2.e1489c74 Mon, Jan 12 2015 12:16:50.880, clock=d85e39b4.0ea565be Mon, Jan 12 2015 12:16:52.057, peer=4258, tc=4, mintc=3, offset=-0.000466, frequency=-17.209, sys_jitter=0.001907, clk_jitter=0.001, clk_wander=0.000, tai=35, leapsec=20150701, expire=20151228 remote refid st t when poll reach delay offset jitter == *127.127.20.0.GPS.0 l3 16 3770.000 -1.066 2.801 o127.127.22.0.PPS.0 l2 16 3770.0000.000 0.002 -87.124.126.49 195.66.241.3 2 u 34 64 377 29.7588.186 0.977 -130.88.200.6130.88.200.4 3 u 14 64 377 17.7831.952 0.580 +217.114.59.3158.43.192.662 u7 64 377 15.9474.033 0.814 +158.43.128.66 193.67.79.2022 u 15 64 377 10.3191.873 0.553 81.174.247.243 .INIT. 16 u- 102400.0000.000 0.000 ntp_gettime() returns code 0 (OK) time d85e39b4.49e7c8d4 Mon, Jan 12 2015 12:16:52.288, (.288693882), maximum error 2000 us, estimated error 1 us, TAI offset 35 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 0.000 us, frequency -17.209 ppm, interval 256 s, maximum error 2000 us, estimated error 1 us, status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO), time constant 4, precision 0.001 us, tolerance 500 ppm, pps frequency -17.207 ppm, stability 0.004 ppm, jitter 0.507 us, intervals 73, jitter exceeded 45, stability exceeded 0, errors 0. associd=0 status= no events, clk_unspec, device=PPS Clock Discipline, timecode=, poll=828, noreply=0, badformat=0, baddata=0, stratum=16, refid=80.80.83.0, flags=4 I've tried using Banana Pi and Beaglebone Black SBCs and have also used u-blox Max-7Q and Trimble Copernicus II GPS breakout boards with no improvement (The Banana Pi is the best but is stuck on the Allwinner 3.4 kernel, which I'm not thrilled about), leading me to believe the roadblock to a more precise clock lies in my less than ideal antenna setup, but my questions are: can I improve upon this and, if so, how? Have I made any obvious errors? I'm relatively new to this and would appreciate any advice I can get. Thanks, Neil. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go
Re: [time-nuts] Arduino GPIB
That certainly is a hack. But its something I have often thought about and never did. He is right its really a one instrument interface as it doesn't have the buffers to drive the load of multiple instruments. But heavens that has to be a really cheap interface for a bit of soldering effort. My type of effort. :-) Regards Paul. WB8TSL On Sun, Jan 11, 2015 at 11:57 PM, Joseph Gray jg...@zianet.com wrote: I thought everyone here would find this of interest. I stumbled across it a few days ago on the 'net. It is a Prologix GPIB-USB compatible made with an Arduino Uno. http://egirland.blogspot.com/2014/03/arduino-uno-as-usb-to-gpib-controller.html Like on his web site, I just took a cheap GPIB cable, cut off about 12 inches and shoved the wires into the socket holes on an Uno. I uploaded his program and did some minor testing so far. BTW, it didn't work the first time due to poor contact. I shoved some pin headers in, after the wires and now it works fine. John's Prologix config program works just fine with this cobbled together GPIB adapter. I attached it to my HP 3457A and then ran the demo program that comes with Ulrich's EZGPIB. It is logging data as I type this. I will do more testing with other instruments, as I have time. As mentioned on the web page linked above, a few commands are not yet implemented, although they appear to be little used commands (except perhaps the ++savecfg command). I think I have a way to implement the ++rst command using the watchdog timer. For ++savecfg, it shouldn't be too difficult to store things in the Arduino EEPROM. I have some cheap Arduino Nano's and PCB-mount GPIB connectors on order. I will be making a couple of these Proligix-compatible adapters with those parts, so that they aren't just wires shoved into a board. I'll have to find a small box to house things. I have also ordered some buffer chips to add to the design. Total cost should be under $20 for each adapter. The firmware uses a serial baud rate of 115200, which I assume is the same as a real Prologix. I'm going to try some higher baud rates to see how fast the Arduino can push bits without losing them. I understand that with the default 16 MHz clock, non-standard baud rates that are evenly divisible into the clock rate should work even better I'll report back. One question about the baud rate - are there any reasons not to change from 115200? Since we are simply moving bits through a USB/Serial adapter, does any software really care what the baud rate is, as long as we don't drop any bits? Joe Gray W5JG ___ 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.
