Re: [time-nuts] GPSDO for my rubber duckie
msoko...@ivan.harhan.org said: But I _*REFUSE*_ to do it that way. You've mentioned UTC: that's one thing I'm taking great care to avoid in my solution. I want my system to be completely insulated from whatever evil things the ITU may do to UTC and leap seconds. ... I think you have two choices. One is to use time as defined by ITU and their friends like GPS and something like IERS to tell you the offset from UTC/GPS/whatever to mean solar time. After that, it's just a bit of software. (Most of us probably can't help much because we don't understand which parts of the system you don't like and/or we don't understand the implementation details that you have already selected.) The other choice is to get a telescope and camera and track the sun yourself and setup a PLL to track mean solar time. You might check the Long Now project. I think they are PLL-ing to solar time, but it's all mechanical, no opportunities for FPGAs or your own OS. -- These are my opinions, not necessarily my employer's. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO for my rubber duckie
Maybe I missed it, but did somebody think about the uBlox LEA-6 rx? has two timemark outputs, which are programmable.. so you can have both 1PPS and 1000PPS. Achim ___ 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] GPSDO for my rubber duckie
Chris Albertson albertson.ch...@gmail.com wrote: It's even less logical than that. With rubber seconds tied to the Earth's rotation. You ultra stable cesium clock is no longer running at a fixed frequency. Wait a minute here, Chris... Weren't you just telling me the other day how important it is to maintain a distinction between primary requirements, derived requirements and implementation details? Cesium clocks and whatnot are implementation details, so let's set them aside until we cover the primary requirements. There two fundamentally different kinds of time: interval time and time-of-day. I realize that this mailing list is mostly inhabited by people who care the most about the former, but there are some people for whom the latter (time-of-day) is much more important. I am one of the latter people. Since the beginning of human civilisation the notion of time of day had absolutely nothing to do with interval time. Interval time is a strictly relative measure, yet ToD has always been an absolute measure of Earth's position in the heavens. (In the minds of the ancient peoples it was relative to the gods.) I wish to preserve the millennia-old time-of-day that is completely separate and independent from interval time. For me that is a basic primary requirement. As an engineer faced with an external requirement, you can be as innovative as you want with how you implement it, but you don't get to negate the requirement itself - basic primary requirements are non-negotiable. In my case the hard requirement is to provide a form of time that represents Earth's position in heavens, just like the word time has been defined for all those millennia before atomic clocks. That is a hard non-negotiable requirement. If this requirement is a pita for cesium clocks, tough. Don't use a cesium clock if that device is not suitable for the given task of satisfying the requirement at hand. (2) define the day as 60 x 60 x 24 seconds long. And let the length of a second be continuously variable or [...] Using #2 makes the job of maintaining a frequency standard more interesting. I have never advocated for use of rubber seconds in frequency standards. Frequency is the inverse of time interval, *not* of true time as in time-of-day, hence it belongs in an entirely different department. Clearly there exists a need for both kinds of time. I have always advocated for a two-tier time distribution architecture: 1. At the lower level you have your atomic clocks that tick independent of the Earth's rotation. Use this timescale for all your techie applications, but *please* don't try to forcibly impose it on anyone who has not explicitly opted in. 2. At the higher user-friendly level, rubber duckies like the one I'm about to build take this fancy non-Earth-rotation-based techie time as input and produce old-fashioned Earth orientation time on output, or more precisely produce a synthetic timescale that is rubberized to pass as an acceptable approximation of the Earth's true position in the heavens relative to the gods. Use *this* time for civil/social purposes, i.e., to tell grandmothers when to go to church, don't make them switch to Earth-decoupled time. MS ___ 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] GPSDO for my rubber duckie
That said of all the systems I like the Mayan one best. They defined the year as 360 days. Then after 360 days they stopped counting and had a party while they waited for the priest to watch the sun and declare the start of a new year. They got a week off. Chris Albertson Redondo Beach, California With the exception of the counting, that almost happens in the UK, particularly Scotland, where it's about two weeks off rather than just a few days. I guess NTP or Big Ben would replace the priest now! 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] GPSDO for my rubber duckie
On Wed, 03 Aug 2011 07:39:28 +0200 Achim Vollhardt avoll...@physik.uzh.ch wrote: Maybe I missed it, but did somebody think about the uBlox LEA-6 rx? has two timemark outputs, which are programmable.. so you can have both 1PPS and 1000PPS. I thought the same when reading this discussion. The LEA-6T (only the T version) has two time pulse outputs, one fixed to 1PPS and the other with variable frequency up to 10MHz. According to u-blox the precision is high enough for timing applications, but the documentation they provide is rather simplicistic. Though, i guess that the precision required in this application is met with a large margin by the LEA-6T. Attila Kinali -- The trouble with you, Shev, is you don't say anything until you've saved up a whole truckload of damned heavy brick arguments and then you dump them all out and never look at the bleeding body mangled beneath the heap -- Tirin, The Dispossessed, U. Le Guin ___ 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] GPSDO for my rubber duckie
On Tue, Aug 2, 2011 at 09:18, Michael Sokolov msoko...@ivan.harhan.orgwrote: 2. When/if the muggle/mainstream UTC stops being acceptable as a form of mean solar time (i.e., when DUT1 passes the 1.0 s mark and no leap second is inserted to correct for it), I will take the matters into my own hands and start issuing rubberization instances on the UTR timescale (previously matching IERS leap seconds) by my own authority as the Republic of Terra Calendar Keeper. As with any email thread, people with no intelligent contributions will focus on minor punctuation errors. In this case, may I point out that you misspelt pan-galactic latex meridian dictator. :-) -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane ___ 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] GPSDO for my rubber duckie
2. At the higher user-friendly level, rubber duckies like the one I'm about to build take this fancy non-Earth-rotation-based techie time as input and produce old-fashioned Earth orientation time on output, or more precisely produce a synthetic timescale that is rubberized to pass as an acceptable approximation of the Earth's true position in the heavens relative to the gods. Use *this* time for civil/social purposes, i.e., to tell grandmothers when to go to church, don't make them switch to Earth-decoupled time. So do that then. Use whatever techie time you deem acceptable. Implement the conversion in C/fortran/python/verilog/whatever. Display the result on your duckie. Problem solved. Don't much see the issue. regards, Fred ___ 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] GPSDO for my rubber duckie
On 8/2/11 10:47 PM, David J Taylor wrote: That said of all the systems I like the Mayan one best. They defined the year as 360 days. Then after 360 days they stopped counting and had a party while they waited for the priest to watch the sun and declare the start of a new year. They got a week off. Chris Albertson Redondo Beach, California With the exception of the counting, that almost happens in the UK, particularly Scotland, where it's about two weeks off rather than just a few days. I guess NTP or Big Ben would replace the priest now! Didn't the Romans do the same thing.. 5 day intercalary period during which the Saturnalia occurred. And they had 10 day weeks, ___ 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] GPSDO for my rubber duckie
Le 02/08/2011 04:35, Michael Sokolov a écrit : snip Henry Hallamhe...@pericynthion.org wrote: The parameters you'll want for conversion between MCAT and mean solar time are given daily in the IERS bulletins: http://hpiers.obspm.fr/eop-pc/products/bulletins/bulletins.html Yes, I know. By making use of these you should be able to do much better than the slightly inelegant leap second rubberization-over-10-seconds method you had proposed. Your rubber seconds should be smooth and continuous, to the limit of the IERS measurement accuracy. But that would be quite a bit harder. :-) I'll leave that as an exercise for Version 2.0; but I'll start with building 1.0 that does my simple rubberization. I am also looking to create a duck, quacking to MST. I have a T'bolt for a tick which configures easily for GPS time rather than UTC, though other GPS receivers could do as well as I wasn't thinking of using the 10MHz source. There are also receivers which provide GPS/UTC locked 10KHz signals as well as 1PPS, ex.Jupiter T that could be another option for you. . My original idea was to use the IERS data to steer the system clock frequency to tick to MST. However, I did not want to have to script a weekly data transfer from the IERS bullitins to get dUT1, and was hoping that I could get it from the GPS data. Unfortunately, it seems not to be avialable there, or at least I can't find it. Various radio time transmissions do carry it, ex. MSF in my neck of the woods, and as I have lashed up an MSF receiver I may start testing with that, or more likely a hybrid, just using the dUT1 data from MSF, as MSF spews legal time rather than TAI. However, even that would only be good if leap secs do not disappear as the current data format only allows for a dUT1 of +/-1 sec with a resolution of 0,1 sec. As an aside, there does not appear to be anything in the American proposal to abandon leap seconds to get a larger dUT1 corrections into the radio transmissions. ___ 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] GPSDO for my rubber duckie
Hello again, Thank you all for your recommendations. It looks like I will go with a ThunderBolt: I have found Trimble's manual online, read all of it, and it looks like the unit will do exactly what I am after. I will feed all 3 outputs from the TBolt (10 MHz, 1 PPS, EIA-232) to a custom timekeeper motherboard I'm going to build. My board will feature a daughterboard seat for the HECPQ CPU module (a type of PowerPC, the same kind I've decided to use for my otherwise totally unrelated non-Ethernet WAN router work) and an FPGA for the timing functions. The 10 MHz and 1 PPS inputs will go to the FPGA which will generate millisecond interrupts to the PowerPC module per the logic which I have described in my previous posts. The way the TBolt generates its 10 MHz and 1 PPS signals (according to Trimble's manual at least) is perfect for my logic. Why millisecond interrupts and not something else? Well, my firm desire and intent is to run my own HECBSD on this thing, a stripped-down embedded version of 4.3BSD-Quasijarus. The latter is my very own operating system and I obviously know it very well inside out. That includes the timekeeping code, and I know that feeding it timer interrupts that are spaced 1 ms (SI) apart and which have a known relation to MCAT PPS will make it easy for me to do what I want in terms of HECBSD in-kernel timekeeping and UTR timescale generation. I'm also going to write a formal spec for my UTR timescale; I will post it both here and on leapsecs. MS ___ 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] GPSDO for my rubber duckie
On Tue, Aug 2, 2011 at 9:12 AM, Michael Sokolov msoko...@ivan.harhan.org wrote: Hello again, Thank you all for your recommendations. It looks like I will go with a ThunderBolt: I have found Trimble's manual online, read all of it, and it looks like the unit will do exactly what I am after. I will feed all 3 outputs from the TBolt (10 MHz, 1 PPS, EIA-232) to a custom timekeeper motherboard I'm going to build. My board will feature a daughterboard seat for the HECPQ CPU module (a type of PowerPC, the same kind I've decided to use for my otherwise totally unrelated non-Ethernet WAN router work) and an FPGA for the timing functions. Why such complex a system when you don't need it?An FPGA??? 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] GPSDO for my rubber duckie
Chris Albertson albertson.ch...@gmail.com wrote: Why such complex a system when you don't need it?An FPGA??? Fixing a logic mistake in an FPGA involves editing a Verilog source file and recompiling; fixing a logic mistake in discrete logic involves a board respin. I much prefer editing ASCII text source files and recompiling over respinning PCBs. MS ___ 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] GPSDO for my rubber duckie
As someone who is currently tinkering with a design in an fpga I had to smile at that statement. :-) If you want the edit + compile, then you may want to rethink that part. There are plenty of microcontrollers out there that are significantly easier to get going. And yes, you can do things faster in an fpga. As in better timing granularity compared to a micro. But unless you are already well versed in fpga tinkering count on the fpga route being WAY more expensive (time wise) than a microcontroller implementation. But if you want to use the complex thingy purely for kicks, noone's stopping you of course. :P regards, Fred From: Michael Sokolov msoko...@ivan.harhan.org To: time-nuts@febo.com Sent: Tuesday, August 2, 2011 6:52 PM Subject: Re: [time-nuts] GPSDO for my rubber duckie Chris Albertson albertson.ch...@gmail.com wrote: Why such complex a system when you don't need it? An FPGA??? Fixing a logic mistake in an FPGA involves editing a Verilog source file and recompiling; fixing a logic mistake in discrete logic involves a board respin. I much prefer editing ASCII text source files and recompiling over respinning PCBs. MS ___ 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] GPSDO for my rubber duckie
On Tue, Aug 2, 2011 at 9:52 AM, Michael Sokolov msoko...@ivan.harhan.org wrote: Fixing a logic mistake in an FPGA involves editing a Verilog source file and recompiling; fixing a logic mistake in discrete logic involves a board respin. I much prefer editing ASCII text source files and recompiling over respinning PCBs. Yes, compared to a PCB FPGA's are easy to change. But all you need is software, most of which already exists. NTP software can keep system time within a few milliseconds of UTC. No custom hardware, no FPGA or PCB.And this software is already in common use.The only remaining task is to convert UTC to this new kind of time. You don't need an FPGA to do a time conversion. If the requirement were for nano second level accuracy then you need the hardware but software using Internet pool servers is OK for Milliseconds and NTP with a local GPS receiver can do micro seconds. MS ___ 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] GPSDO for my rubber duckie
Chris Albertson albertson.ch...@gmail.com wrote: NTP software can keep system time within a few milliseconds of UTC. No custom hardware, no FPGA or PCB. But I _*REFUSE*_ to do it that way. You've mentioned UTC: that's one thing I'm taking great care to avoid in my solution. I want my system to be completely insulated from whatever evil things the ITU may do to UTC and leap seconds. By starting from GPS time coming *directly* out of a GPS receiver via its native EIA-232 port, I can take untampered GPS time in the week number + time-of-week format, convert it to TAI by adding a constant 19 s offset, and then convert from TAI to UTR. GPS time - TAI - UTR; there is no UTC involved at any intermediate step. Standard NTP software is another thing I wish to avoid like the plague in this project. That software has been touched by the hands of people like PHK and Warner Losh, the same criminals whose handprints are on the axe that is about to sever most of the world's civil time from the millennia-old tradition of mean solar time. Those people are criminals of the highest degree in my book, and I do not want to use any software that has been touched by them. If the requirement were for nano second level accuracy [...] I don't care for that level of accuracy, but I do very much care about the philosophical puriry of the system, end to end and at every intermediate step. but software using Internet pool servers is OK for Milliseconds I have no idea / don't want to think about what will happen to those NTP servers when/if leap seconds are killed. I wish to *insulate* myself and all computer systems under my care from that insanity. And even now while the leap seconds are still with us, NTP does an utter mess in the vicinity of one. Once again, I wish to insulate myself from it. Although my rubber duckie will never act as an NTP client, i.e., will never ask another NTP server for the time, it *will* act as an NTP server itself, i.e., it will serve my UTR timescale to the public Internet. For as long as the leap seconds are still with us, UTR will agree with UTC except in the immediate vicinity of one. However, if and when the ITU/PHK bastards kill the leap second, the NTP timescale will fork. My NTP servers will serve UTR, linked to Earth's rotation just like the current leap-enabled UTC is. Don't know / don't care about NTP servers operated by muggles. I hope this clarifies a little better what I am after. MS ___ 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] GPSDO for my rubber duckie
If you live your life on a timescale that is anchored to mean solar time, what happens on February 29th? Chris -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Michael Sokolov Sent: 02 August 2011 20:33 To: time-nuts@febo.com Subject: Re: [time-nuts] GPSDO for my rubber duckie Chris Albertson albertson.ch...@gmail.com wrote: NTP software can keep system time within a few milliseconds of UTC. No custom hardware, no FPGA or PCB. But I _*REFUSE*_ to do it that way. You've mentioned UTC: that's one thing I'm taking great care to avoid in my solution. I want my system to be completely insulated from whatever evil things the ITU may do to UTC and leap seconds. By starting from GPS time coming *directly* out of a GPS receiver via its native EIA-232 port, I can take untampered GPS time in the week number + time-of-week format, convert it to TAI by adding a constant 19 s offset, and then convert from TAI to UTR. GPS time - TAI - UTR; there is no UTC involved at any intermediate step. Standard NTP software is another thing I wish to avoid like the plague in this project. That software has been touched by the hands of people like PHK and Warner Losh, the same criminals whose handprints are on the axe that is about to sever most of the world's civil time from the millennia-old tradition of mean solar time. Those people are criminals of the highest degree in my book, and I do not want to use any software that has been touched by them. If the requirement were for nano second level accuracy [...] I don't care for that level of accuracy, but I do very much care about the philosophical puriry of the system, end to end and at every intermediate step. but software using Internet pool servers is OK for Milliseconds I have no idea / don't want to think about what will happen to those NTP servers when/if leap seconds are killed. I wish to *insulate* myself and all computer systems under my care from that insanity. And even now while the leap seconds are still with us, NTP does an utter mess in the vicinity of one. Once again, I wish to insulate myself from it. Although my rubber duckie will never act as an NTP client, i.e., will never ask another NTP server for the time, it *will* act as an NTP server itself, i.e., it will serve my UTR timescale to the public Internet. For as long as the leap seconds are still with us, UTR will agree with UTC except in the immediate vicinity of one. However, if and when the ITU/PHK bastards kill the leap second, the NTP timescale will fork. My NTP servers will serve UTR, linked to Earth's rotation just like the current leap-enabled UTC is. Don't know / don't care about NTP servers operated by muggles. I hope this clarifies a little better what I am after. MS ___ 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] GPSDO for my rubber duckie
At 05:33 PM 8/2/2011, Chris Stake wrote... If you live your life on a timescale that is anchored to mean solar time, what happens on February 29th? Nothing. From the OP: I want MJD numbers instead of Gregorian dates, or GPS week numbers / day-of-week / time-of-day. ___ 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] GPSDO for my rubber duckie
I don't get it. Does that mean that leap days are OK but leap seconds are unacceptable? Chris -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Mike S Sent: 02 August 2011 23:02 To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] GPSDO for my rubber duckie At 05:33 PM 8/2/2011, Chris Stake wrote... If you live your life on a timescale that is anchored to mean solar time, what happens on February 29th? Nothing. From the OP: I want MJD numbers instead of Gregorian dates, or GPS week numbers / day-of-week / time-of-day. ___ 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] GPSDO for my rubber duckie
On Tue, Aug 2, 2011 at 3:49 PM, Chris Stake st...@btinternet.com wrote: I don't get it. Does that mean that leap days are OK but leap seconds are unacceptable? It's even less logical than that. With rubber seconds tied to the Earth's rotation. You ultra stable cesium clock is no longer running at a fixed frequency. If the length of the second changs with the Earth's rate then the frequency of the cesium clock can be effected by earth quakes in Japan, tides and what not. I guess it's a valid decision to either (1) fix the length of the second and let the number of seconds per day be whatever the Earth decides so some days have an extra second and most don't. or, (2) define the day as 60 x 60 x 24 seconds long. And let the length of a second be continuously variable or (3) fix the length of the second AND define the day as 60 x 60 x 24 seconds long and just accept that after some centuries the sun will raise in mid morning. Using #2 makes the job of maintaining a frequency standard more interesting. That said of all the systems I like the Mayan one best. They defined the year as 360 days. Then after 360 days they stopped counting and had a party while they waited for the priest to watch the sun and declare the start of a new year. They got a week off. 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] GPSDO for my rubber duckie
Le 03/08/2011 00:49, Chris Stake a écrit : I don't get it. Does that mean that leap days are OK but leap seconds are unacceptable? Chris For the moment yes, as they are animals from two different species. Leap seconds form part of the current definition of UTC which is a time scale, even though not uniform due to the leap seconds. Leap days form part of a calendar and there are lots of different flavours to chose from. They are needed as the year isn't exactly 365 mean solar days days but about 365,2424. However if leap seconds are abandoned and nothing is done in between times there may need to be a real leap day in around 86400 years as MST is slow by about 1s/year. ___ 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] GPSDO for my rubber duckie
Yep, Lady Heather does several versions of the Mayan, Aztek, and Druid calendars you can specify the correlation constant to suit your interpretation of the reference date. That said of all the systems I like the Mayan one best. They defined the year as 360 days. Then after 360 days they stopped counting andhad a party while they waited for the priest to watch the sun and declare the start of a new year. They got a week off. ___ 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] GPSDO for my rubber duckie
Michael, You are entitled to your opinions, but opinions that cannot be expressed with civility like those in the message below have no place on this list. You are welcome to keep them for yourself. Didier KO4BB Sent from my BlackBerry Wireless thingy while I do other things... -Original Message- From: msoko...@ivan.harhan.org (Michael Sokolov) Sender: time-nuts-boun...@febo.com Date: Tue, 2 Aug 2011 19:33:17 To: time-nuts@febo.com Reply-To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: Re: [time-nuts] GPSDO for my rubber duckie Chris Albertson albertson.ch...@gmail.com wrote: NTP software can keep system time within a few milliseconds of UTC. No custom hardware, no FPGA or PCB. But I _*REFUSE*_ to do it that way. You've mentioned UTC: that's one thing I'm taking great care to avoid in my solution. I want my system to be completely insulated from whatever evil things the ITU may do to UTC and leap seconds. By starting from GPS time coming *directly* out of a GPS receiver via its native EIA-232 port, I can take untampered GPS time in the week number + time-of-week format, convert it to TAI by adding a constant 19 s offset, and then convert from TAI to UTR. GPS time - TAI - UTR; there is no UTC involved at any intermediate step. Standard NTP software is another thing I wish to avoid like the plague in this project. That software has been touched by the hands of people like PHK and Warner Losh, the same criminals whose handprints are on the axe that is about to sever most of the world's civil time from the millennia-old tradition of mean solar time. Those people are criminals of the highest degree in my book, and I do not want to use any software that has been touched by them. If the requirement were for nano second level accuracy [...] I don't care for that level of accuracy, but I do very much care about the philosophical puriry of the system, end to end and at every intermediate step. but software using Internet pool servers is OK for Milliseconds I have no idea / don't want to think about what will happen to those NTP servers when/if leap seconds are killed. I wish to *insulate* myself and all computer systems under my care from that insanity. And even now while the leap seconds are still with us, NTP does an utter mess in the vicinity of one. Once again, I wish to insulate myself from it. Although my rubber duckie will never act as an NTP client, i.e., will never ask another NTP server for the time, it *will* act as an NTP server itself, i.e., it will serve my UTR timescale to the public Internet. For as long as the leap seconds are still with us, UTR will agree with UTC except in the immediate vicinity of one. However, if and when the ITU/PHK bastards kill the leap second, the NTP timescale will fork. My NTP servers will serve UTR, linked to Earth's rotation just like the current leap-enabled UTC is. Don't know / don't care about NTP servers operated by muggles. I hope this clarifies a little better what I am after. MS ___ 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] GPSDO for my rubber duckie
Hello time-nuts, I've been on this list for several years now and I've made a few little comments on occasion, but this will be my first real technical post. I desire to build a timekeeping apparatus which I have nicknamed the rubber duckie, or a Rubber Time Generator. As I've voiced very vigorously on the leapsecs list, I wish to live my personal life on a timescale that is anchored to Earth rotation via elastic (rubber) seconds rather than leap seconds or PHK/ITU-style total decoupling. I do not wish to go into the reasons for that in this thread - the leapsecs list would be better for that - but here I am soliciting technical advice with the actual implementation. In technical terms I envision a device (a physical piece of hardware) that takes MCAT (Muggle Consensus Atomic Time) as input and produces UTR (UT Rubber) as output. MCAT is my term that encompasses all of UTC, TAI, GPS time, other GNSS time etc, basically all the various timescales which produce their 1 PPS at exactly the same time but label their seconds differently. As a matter of practical implementation my choice of specific MCAT realization for Version 1 of my rubber duckie will probably be GPS. Thus what I am soliciting on this list is advice with choosing a good GPS receiver / GPSDO for my application, which is feeding MCAT input to my rubber duckie. My requirements are: * I want to be able to disable the leap second correction in the GPS receiver, i.e., have it output time such that I can add a constant 19 to it and get TAI. (Or TAPF = Temps Atomique Pedant-Free, which is defined to be identical with TAI in every respect except that it is free from the edict of though shalt not use TAI.) * I'm striving to move away from the Gregorian calendar wherever I can. Therefore, if the GPS receiver is trying to be user-friendly and convert the date part of GPS time into Gregorian format, I want to be able to disable that function. I want MJD numbers instead of Gregorian dates, or GPS week numbers / day-of-week / time-of-day. * I think I need a GPSDO rather than just a GPS receiver. The hardware design I have in mind for my rubber duckie is a custom PowerPC board on which I will run a specially modified and heavily stripped-down version of 4.3BSD-Quasijarus, an embedded PowerPC port thereof. In order to run a version of 4.3BSD-Quasijarus on my custom PowerPC board and make it do what I want (generate UTR from MCAT), I would like to implement a circuit on my board that generates an interrupt per millisecond. These millisecond interrupts need to be aligned with 1 PPS such that every 1000th millisecond interrupt also serves as an on-time mark for MCAT (TAI/UTC/GPS/etc) seconds. Someone please correct me if I'm missing some other simpler way, but it seems to me that in order to generate these 1 ms interrupts with the properties I require, I will need a 10 MHz input in addition to 1 PPS, hence the need for a GPSDO rather than just a GPS receiver. I envision my clock interrupt generation logic working as follows: * Starting at power-up boot, divide 10 MHz input by 1 and produce an interrupt every 1 ms. At this point these interrupts aren't aligned with anything, but they are good enough for the OS to boot. * The FPGA in which this circuit resides gets an acquire lock command from the software. It hunts for an external 1 PPS pulse, generates its own 1 ms interrupt at the same time (modulo a few cycles of 10 MHz for logic and synchronizer delays), and resets its divide-by-1 logic from there, such that all subsequent 1 ms interrupts will follow in proper sequence. * In the preceding description the external 1 PPS pulse is acted upon only once, and all subsequent 1 ms and 1 s timing is derived from 10 MHz. However, there will also be a sanity check circuit that will look for the external 1 PPS in the vicinity (+/- 1 ms maybe?) of the internally-derived 1000th 1 ms interrupt. If the internal and external 1 PPS signals disagree, signal an error indication to the software. The software will then declare the UTR output as possibly invalid and resync itself; the resync sequence will include telling the FPGA to resync itself to the external 1 PPS. In order for my clock interrupt generation circuit to work as I envision, the 10 MHz and 1 PPS signals going from the GPSDO to my rubber duckie will need to meet certain requirements: 1. The 10 MHz and 1 PPS signals will need to match each other in the sense that the 10 MHz does exactly 10 million cycles between two successive 1 PPS pulses. 2. Simultaneous with requirement 1, the 1 PPS signal also needs to indicate the true UTC/TAI/GPS second boundaries decoded from the GPS signal. To satisfy this simultaneously with #1, the 10 MHz freq reference will also need to be locked to the true 1 PPS from GPS - is that what a GPSDO does? 3. I've heard something about sawtooth correction, and I'm guessing I'll need
Re: [time-nuts] GPSDO for my rubber duckie
You left out the most important requirements. 1) How acurate does this all need to be? Is 1/10 of a second good enough or is this all to run at the handful of nano seconds level? 2) How is the time to be output or displayed? Are we driving an analog clock with sweep second hand or a time code generator? If All you need is a digital clock display on an LCD that is accurate enough to be perceived by eye as perfect then this whole thing is nearly trivial to build because your eyes are not so good (remember that a 24 frame per second movie completely fools your eyes into thinking it's continuous motion. So an update 30 times per second is better then you need for a visual clock display. In engineering something like this it is very impotent NOT to mix up primary requirements, derived requirements, implementation details. primary requirements describe the thing you want, NOT how it works. Derived ones are the logical fallout from the first ones. It takes great discipline to NOT jump into implementation. So I don't blame you for talking about GPS and 10Mhz oscillators and what kind of CPU will be inside. But leave all of that for later. All that said. If the goal is a visual display you can do this with off the shelf hardware and software pus a bit of custom software I don't 100% understand your time keeping system. You say it's based on Earth rotation. Is it like this http://en.wikipedia.org/wiki/Sidereal_time On Mon, Aug 1, 2011 at 12:23 PM, Michael Sokolov msoko...@ivan.harhan.org wrote: Hello time-nuts, I've been on this list for several years now and I've made a few little comments on occasion, but this will be my first real technical post. I desire to build a timekeeping apparatus which I have nicknamed the rubber duckie, or a Rubber Time Generator. As I've voiced very vigorously on the leapsecs list, I wish to live my personal life on a timescale that is anchored to Earth rotation via elastic (rubber) seconds rather than leap seconds or PHK/ITU-style total decoupling. I do not wish to go into the reasons for that in this thread - the leapsecs list would be better for that - but here I am soliciting technical advice with the actual implementation. In technical terms I envision a device (a physical piece of hardware) that takes MCAT (Muggle Consensus Atomic Time) as input and produces UTR (UT Rubber) as output. MCAT is my term that encompasses all of UTC, TAI, GPS time, other GNSS time etc, basically all the various timescales which produce their 1 PPS at exactly the same time but label their seconds differently. As a matter of practical implementation my choice of specific MCAT realization for Version 1 of my rubber duckie will probably be GPS. Thus what I am soliciting on this list is advice with choosing a good GPS receiver / GPSDO for my application, which is feeding MCAT input to my rubber duckie. My requirements are: * I want to be able to disable the leap second correction in the GPS receiver, i.e., have it output time such that I can add a constant 19 to it and get TAI. (Or TAPF = Temps Atomique Pedant-Free, which is defined to be identical with TAI in every respect except that it is free from the edict of though shalt not use TAI.) * I'm striving to move away from the Gregorian calendar wherever I can. Therefore, if the GPS receiver is trying to be user-friendly and convert the date part of GPS time into Gregorian format, I want to be able to disable that function. I want MJD numbers instead of Gregorian dates, or GPS week numbers / day-of-week / time-of-day. * I think I need a GPSDO rather than just a GPS receiver. The hardware design I have in mind for my rubber duckie is a custom PowerPC board on which I will run a specially modified and heavily stripped-down version of 4.3BSD-Quasijarus, an embedded PowerPC port thereof. In order to run a version of 4.3BSD-Quasijarus on my custom PowerPC board and make it do what I want (generate UTR from MCAT), I would like to implement a circuit on my board that generates an interrupt per millisecond. These millisecond interrupts need to be aligned with 1 PPS such that every 1000th millisecond interrupt also serves as an on-time mark for MCAT (TAI/UTC/GPS/etc) seconds. Someone please correct me if I'm missing some other simpler way, but it seems to me that in order to generate these 1 ms interrupts with the properties I require, I will need a 10 MHz input in addition to 1 PPS, hence the need for a GPSDO rather than just a GPS receiver. I envision my clock interrupt generation logic working as follows: * Starting at power-up boot, divide 10 MHz input by 1 and produce an interrupt every 1 ms. At this point these interrupts aren't aligned with anything, but they are good enough for the OS to boot. * The FPGA in which this circuit resides gets an acquire lock command from the software. It hunts for an external 1 PPS pulse, generates its own 1 ms
Re: [time-nuts] GPSDO for my rubber duckie
Hi Without knowing the full objective it's always hard to offer up suggestions. I'm going to *assume* that you want a PPS that is good to 1 ms on your custom time scale. I'm also assuming that sidereal time is a reasonable analog to what you are trying to do. I think your approach is overly complex for implementing this. An alternative approach: 1) Take the PPS out of the GPS and route it to an interrupt on a cheap processor. 2) Use the interrupt to start a timer 3) Take your custom PPS off of the output of the timer The timer only needs a one second range and the process only needs to be good to 1 ms. You need to calculate the number that goes into the timer and get it there. Assuming your time scale isn't to crazy, you don't need to do the calculation very often. Minutes / Hours / Days / Weeks / Years simply come off of the calculated PPS. You only need to get them in synch once. You likely do need to pay attention to the GPS's calendar to calculate the number to feed into your timer. Precision wise, the oscillator that drives the timer needs to be good to 0.1%. You can overkill that by 10X and still not spend any real money. No need for a 10 MHz out of the GPS. No need for the clock and PPS to be phase locked. Unless there's something really wild about the calculations, it all should fit in something in the sub $10 range CPU wise. Any GPS with a half way decent serial data stream should be good enough for 1 ms. The auction sites likely will sell you a GPS like that for $20. Again - I could be way off base. I'm not at all sure what your calculations look like. Bob On Aug 1, 2011, at 3:23 PM, Michael Sokolov wrote: Hello time-nuts, I've been on this list for several years now and I've made a few little comments on occasion, but this will be my first real technical post. I desire to build a timekeeping apparatus which I have nicknamed the rubber duckie, or a Rubber Time Generator. As I've voiced very vigorously on the leapsecs list, I wish to live my personal life on a timescale that is anchored to Earth rotation via elastic (rubber) seconds rather than leap seconds or PHK/ITU-style total decoupling. I do not wish to go into the reasons for that in this thread - the leapsecs list would be better for that - but here I am soliciting technical advice with the actual implementation. In technical terms I envision a device (a physical piece of hardware) that takes MCAT (Muggle Consensus Atomic Time) as input and produces UTR (UT Rubber) as output. MCAT is my term that encompasses all of UTC, TAI, GPS time, other GNSS time etc, basically all the various timescales which produce their 1 PPS at exactly the same time but label their seconds differently. As a matter of practical implementation my choice of specific MCAT realization for Version 1 of my rubber duckie will probably be GPS. Thus what I am soliciting on this list is advice with choosing a good GPS receiver / GPSDO for my application, which is feeding MCAT input to my rubber duckie. My requirements are: * I want to be able to disable the leap second correction in the GPS receiver, i.e., have it output time such that I can add a constant 19 to it and get TAI. (Or TAPF = Temps Atomique Pedant-Free, which is defined to be identical with TAI in every respect except that it is free from the edict of though shalt not use TAI.) * I'm striving to move away from the Gregorian calendar wherever I can. Therefore, if the GPS receiver is trying to be user-friendly and convert the date part of GPS time into Gregorian format, I want to be able to disable that function. I want MJD numbers instead of Gregorian dates, or GPS week numbers / day-of-week / time-of-day. * I think I need a GPSDO rather than just a GPS receiver. The hardware design I have in mind for my rubber duckie is a custom PowerPC board on which I will run a specially modified and heavily stripped-down version of 4.3BSD-Quasijarus, an embedded PowerPC port thereof. In order to run a version of 4.3BSD-Quasijarus on my custom PowerPC board and make it do what I want (generate UTR from MCAT), I would like to implement a circuit on my board that generates an interrupt per millisecond. These millisecond interrupts need to be aligned with 1 PPS such that every 1000th millisecond interrupt also serves as an on-time mark for MCAT (TAI/UTC/GPS/etc) seconds. Someone please correct me if I'm missing some other simpler way, but it seems to me that in order to generate these 1 ms interrupts with the properties I require, I will need a 10 MHz input in addition to 1 PPS, hence the need for a GPSDO rather than just a GPS receiver. I envision my clock interrupt generation logic working as follows: * Starting at power-up boot, divide 10 MHz input by 1 and produce an interrupt every 1 ms. At this point these interrupts aren't aligned with anything, but they are good enough for the OS to boot.
Re: [time-nuts] GPSDO for my rubber duckie
Michael, GPS provides leapsecond information, BUT, to my knowledge, does not implement it. The GPS time reported by GPS is the invariant time of the Cesium references that are used to steer the BIRDS. That said, any software that displays UTC would have to take the GPS time and add or subtract the leapsecond information that transmitted by the BIRDS. If I am in error I am sure others will correct me. BillWB6BNQ Michael Sokolov wrote: Hello time-nuts, I've been on this list for several years now and I've made a few little comments on occasion, but this will be my first real technical post. I desire to build a timekeeping apparatus which I have nicknamed the rubber duckie, or a Rubber Time Generator. As I've voiced very vigorously on the leapsecs list, I wish to live my personal life on a timescale that is anchored to Earth rotation via elastic (rubber) seconds rather than leap seconds or PHK/ITU-style total decoupling. I do not wish to go into the reasons for that in this thread - the leapsecs list would be better for that - but here I am soliciting technical advice with the actual implementation. In technical terms I envision a device (a physical piece of hardware) that takes MCAT (Muggle Consensus Atomic Time) as input and produces UTR (UT Rubber) as output. MCAT is my term that encompasses all of UTC, TAI, GPS time, other GNSS time etc, basically all the various timescales which produce their 1 PPS at exactly the same time but label their seconds differently. As a matter of practical implementation my choice of specific MCAT realization for Version 1 of my rubber duckie will probably be GPS. Thus what I am soliciting on this list is advice with choosing a good GPS receiver / GPSDO for my application, which is feeding MCAT input to my rubber duckie. My requirements are: * I want to be able to disable the leap second correction in the GPS receiver, i.e., have it output time such that I can add a constant 19 to it and get TAI. (Or TAPF = Temps Atomique Pedant-Free, which is defined to be identical with TAI in every respect except that it is free from the edict of though shalt not use TAI.) * I'm striving to move away from the Gregorian calendar wherever I can. Therefore, if the GPS receiver is trying to be user-friendly and convert the date part of GPS time into Gregorian format, I want to be able to disable that function. I want MJD numbers instead of Gregorian dates, or GPS week numbers / day-of-week / time-of-day. * I think I need a GPSDO rather than just a GPS receiver. The hardware design I have in mind for my rubber duckie is a custom PowerPC board on which I will run a specially modified and heavily stripped-down version of 4.3BSD-Quasijarus, an embedded PowerPC port thereof. In order to run a version of 4.3BSD-Quasijarus on my custom PowerPC board and make it do what I want (generate UTR from MCAT), I would like to implement a circuit on my board that generates an interrupt per millisecond. These millisecond interrupts need to be aligned with 1 PPS such that every 1000th millisecond interrupt also serves as an on-time mark for MCAT (TAI/UTC/GPS/etc) seconds. Someone please correct me if I'm missing some other simpler way, but it seems to me that in order to generate these 1 ms interrupts with the properties I require, I will need a 10 MHz input in addition to 1 PPS, hence the need for a GPSDO rather than just a GPS receiver. I envision my clock interrupt generation logic working as follows: * Starting at power-up boot, divide 10 MHz input by 1 and produce an interrupt every 1 ms. At this point these interrupts aren't aligned with anything, but they are good enough for the OS to boot. * The FPGA in which this circuit resides gets an acquire lock command from the software. It hunts for an external 1 PPS pulse, generates its own 1 ms interrupt at the same time (modulo a few cycles of 10 MHz for logic and synchronizer delays), and resets its divide-by-1 logic from there, such that all subsequent 1 ms interrupts will follow in proper sequence. * In the preceding description the external 1 PPS pulse is acted upon only once, and all subsequent 1 ms and 1 s timing is derived from 10 MHz. However, there will also be a sanity check circuit that will look for the external 1 PPS in the vicinity (+/- 1 ms maybe?) of the internally-derived 1000th 1 ms interrupt. If the internal and external 1 PPS signals disagree, signal an error indication to the software. The software will then declare the UTR output as possibly invalid and resync itself; the resync sequence will include telling the FPGA to resync itself to the external 1 PPS. In order for my clock interrupt generation circuit to work as I envision, the 10 MHz and 1 PPS signals going from the GPSDO to my rubber duckie will need to meet certain requirements: 1. The 10 MHz and 1 PPS signals
Re: [time-nuts] GPSDO for my rubber duckie
The below could work but even it is overly complex. Try this.. 1) Get any computer and install NTP. Use any decent timing GPS as a reference.Now you have a computer with system time accurate to UTC and the sub millisecond level. This is a 100% conventional setup, no rocket science. 2) Next in software you run an infinite loop, not interrupts, no precision timing, just a plain out user mode loop. The loop does the following. read the system clock, convert to siderial time, display the time, go to start of loop.Yes, there is a delay during the conversion but it is hundreds of time less than the delay between your eyes and your brain so you will never notice. Plus NTP is the ability to back out a fixed bias, you can use that too. The above does not require any advanced level of programming, no interrupts or real time software. NTP takes care of almost all the details and will easily work at the 100 micro second level. Google will turn up the UTC to Sidereal conversion code. You need to add the loop and display code. On Mon, Aug 1, 2011 at 2:56 PM, Bob Camp li...@rtty.us wrote: Hi Without knowing the full objective it's always hard to offer up suggestions. I'm going to *assume* that you want a PPS that is good to 1 ms on your custom time scale. I'm also assuming that sidereal time is a reasonable analog to what you are trying to do. I think your approach is overly complex for implementing this. An alternative approach: 1) Take the PPS out of the GPS and route it to an interrupt on a cheap processor. 2) Use the interrupt to start a timer 3) Take your custom PPS off of the output of the timer 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] GPSDO for my rubber duckie
Hi or drop the GPS and just run NTP. Simpler still run SNTP on something small. You won't hit 1ms in either case. You will be plenty good by wall clock standards. Bob On Aug 1, 2011, at 6:27 PM, Chris Albertson albertson.ch...@gmail.com wrote: The below could work but even it is overly complex. Try this.. 1) Get any computer and install NTP. Use any decent timing GPS as a reference.Now you have a computer with system time accurate to UTC and the sub millisecond level. This is a 100% conventional setup, no rocket science. 2) Next in software you run an infinite loop, not interrupts, no precision timing, just a plain out user mode loop. The loop does the following. read the system clock, convert to siderial time, display the time, go to start of loop.Yes, there is a delay during the conversion but it is hundreds of time less than the delay between your eyes and your brain so you will never notice. Plus NTP is the ability to back out a fixed bias, you can use that too. The above does not require any advanced level of programming, no interrupts or real time software. NTP takes care of almost all the details and will easily work at the 100 micro second level. Google will turn up the UTC to Sidereal conversion code. You need to add the loop and display code. On Mon, Aug 1, 2011 at 2:56 PM, Bob Camp li...@rtty.us wrote: Hi Without knowing the full objective it's always hard to offer up suggestions. I'm going to *assume* that you want a PPS that is good to 1 ms on your custom time scale. I'm also assuming that sidereal time is a reasonable analog to what you are trying to do. I think your approach is overly complex for implementing this. An alternative approach: 1) Take the PPS out of the GPS and route it to an interrupt on a cheap processor. 2) Use the interrupt to start a timer 3) Take your custom PPS off of the output of the timer 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 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] GPSDO for my rubber duckie
I think that a Thunderbolt GPSDO with Lady Heather should be able to do what you want. It can be set up for GPS time (no leapseconds) or UTC time. It can handle time zone offsets to the second for fine tuning your whacko time scales. It can display the date in JD, MJD, ISO, and a bunch of others. It can handle several different calendar systems (including a few you have probably never heard of). Also does sidereal time. Since it's open source, you can further munge the time to your perverted heart's content... ___ 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] GPSDO for my rubber duckie
Chris Albertson albertson.ch...@gmail.com wrote: In engineering something like this it is very impotent NOT to mix up primary requirements, derived requirements, implementation details. primary requirements describe the thing you want, NOT how it works. Derived ones are the logical fallout from the first ones. Fair enough. My most basic primary requirement is to live my life on a timescale that is anchored to mean solar time, just like timekeeping used to be for hundreds if not thousands of years before atomic clocks. At the present moment I can satisfy my requirement simply by looking at a WWVB-synced wristwatch: WWVB transmits UTC, and UTC *as presently implemented* with leap seconds passes as an acceptable realisation of GMT. However, certain forces have been pursuing a relentless push to abolish the leap seconds, and there is a strong chance that these people may finally have their way at the ITU vote in 2012-01. If/when the PHKs of this world (the folks who want the leap seconds gone) get their way, UTC as transmitted by WWVx etc, displayed on radio- synced clocks and maintained on mainstream computer systems via NTP will no longer be an acceptable realisation of GMT *in my eyes*, i.e., it will no longer satisfy the requirements of my personal philosophy. Therefore, I will need to build my own timescale to replace UTC for the purposes of my personal life. I have heard that if the PHKs have their way at the ITU in January 2012, the leap seconds will continue for 5 more years and go away in 2017. Therefore, I have to have my replacement timescale working no later than 2017. But I don't like waiting till the last minute, I prefer to be prepared and ahead of the game, hence I'm starting the work NOW. I don't 100% understand your time keeping system. You say it's based on Earth rotation. Is it like this http://en.wikipedia.org/wiki/Sidereal_time Nope. I want *mean solar* time, not sidereal. A secondary requirement for me (if you want to call it that) is my preference for rubber seconds over leap seconds. I want my timescale to pass as a realisation/approximation of GMT, but I also want it to read as a real number at all times, i.e., no 23:59:60. Therefore, I am implementing a timescale which I've called UTR (UT Rubber), and it will kill two birds with one stone: 1. For as long as UTC remains status quo, with leap seconds, my UTR will exactly equal UTC at all times except around a leap second. At leap second time I will replace leaps with rubberization: instead of doing 23:59:60, there will be 10 seconds on the UTR timescale (labelled 23:59:50 through 23:59:59, inclusive) which will be 1.1 SI s long each, such that the UTR timescale will advance by 10 s over the course of 11 s of atomic time. The whole thing will be called a rubberization instance. 2. When/if the muggle/mainstream UTC stops being acceptable as a form of mean solar time (i.e., when DUT1 passes the 1.0 s mark and no leap second is inserted to correct for it), I will take the matters into my own hands and start issuing rubberization instances on the UTR timescale (previously matching IERS leap seconds) by my own authority as the Republic of Terra Calendar Keeper. You left out the most important requirements. 1) How acurate does this all need to be? Is 1/10 of a second good enough or is this all to run at the handful of nano seconds level? I am most definitely not looking for nanoseconds, but I'm hoping for something a little better than 100 ms. 1 ms is my rough accuracy target. 2) How is the time to be output or displayed? Are we driving an analog clock with sweep second hand or a time code generator? Two outputs: 1. The primary output of most direct usefulness will be Ethernet. I want my rubber duckie to run 4.3BSD-Quasijarus because that's my very own OS in which I have the greatest trust. The way I envision it, the golden UTR timescale will be maintained by one of the clocks in the specially modified 4.3BSD-Quasijarus kernel, and various user mode processes on the rubber duckie will export this timescale in various ways. I'll have a process that will accept time queries over Ethernet (both NTP and the older/simpler time protocol) and answer them with UTR time. This output is going to be the one of most direct usefulness: it will allow anyone of like mind to run his/her life on UTR instead of UTC by simply reconfiguring their ntpd to poll my rubber duckie (or their own copy thereof) instead of an official UTC NTP server. However, the NTP output is not expected to be the most accurate one. Around leap second time (be it an official IERS leap second or my own substitute after the former cease) the UTR timescale will suddenly speed up or slow down by 10%, then go back to SI second rate 10 s later: I don't expect any NTP client to be able to follow that except by getting out of sync and catching up afterward. The latter blemish
Re: [time-nuts] GPSDO for my rubber duckie
On Mon, Aug 1, 2011 at 6:18 PM, Michael Sokolov msoko...@ivan.harhan.org wrote: At the present moment I can satisfy my requirement simply by looking at a WWVB-synced wristwatch: WWVB transmits UTC, and OK this defines your require accuracy very well. ideally are required to be without 1/2 second per day of the WWVB time. Actually few of them are that good. There s a document on the WWV web site that explains it. But for your purposes then 1/10 of a second is good enough. I think you can do just fine without GPS and GPSDXO oscillators and the like. NTP over the Internet is an order of magnitude better then you need.Even if the Internet service is disconnected now and then. Your only remaining task is to write a function that transforms UTC time to your own desired time. Run that inside a loop and you are done.Zero total cost (assuming the internet connection is already paid for) 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] GPSDO for my rubber duckie
Another possible solution is to use a Rubidium stabilised oscillator like a LPRO which has been set to your preferred frequency. If my aged brain remembers my calculation correctly, it is spec'd to be accurate to one second in 30 years, so you might have to correct your clock every decade or so. cheers, Neville Michie ___ 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] GPSDO for my rubber duckie
The parameters you'll want for conversion between MCAT and mean solar time are given daily in the IERS bulletins: http://hpiers.obspm.fr/eop-pc/products/bulletins/bulletins.html By making use of these you should be able to do much better than the slightly inelegant leap second rubberization-over-10-seconds method you had proposed. Your rubber seconds should be smooth and continuous, to the limit of the IERS measurement accuracy. Good luck, Henry On Mon, Aug 1, 2011 at 12:23 PM, Michael Sokolov msoko...@ivan.harhan.org wrote: Hello time-nuts, I've been on this list for several years now and I've made a few little comments on occasion, but this will be my first real technical post. I desire to build a timekeeping apparatus which I have nicknamed the rubber duckie, or a Rubber Time Generator. As I've voiced very vigorously on the leapsecs list, I wish to live my personal life on a timescale that is anchored to Earth rotation via elastic (rubber) seconds rather than leap seconds or PHK/ITU-style total decoupling. I do not wish to go into the reasons for that in this thread - the leapsecs list would be better for that - but here I am soliciting technical advice with the actual implementation. In technical terms I envision a device (a physical piece of hardware) that takes MCAT (Muggle Consensus Atomic Time) as input and produces UTR (UT Rubber) as output. MCAT is my term that encompasses all of UTC, TAI, GPS time, other GNSS time etc, basically all the various timescales which produce their 1 PPS at exactly the same time but label their seconds differently. As a matter of practical implementation my choice of specific MCAT realization for Version 1 of my rubber duckie will probably be GPS. Thus what I am soliciting on this list is advice with choosing a good GPS receiver / GPSDO for my application, which is feeding MCAT input to my rubber duckie. My requirements are: * I want to be able to disable the leap second correction in the GPS receiver, i.e., have it output time such that I can add a constant 19 to it and get TAI. (Or TAPF = Temps Atomique Pedant-Free, which is defined to be identical with TAI in every respect except that it is free from the edict of though shalt not use TAI.) * I'm striving to move away from the Gregorian calendar wherever I can. Therefore, if the GPS receiver is trying to be user-friendly and convert the date part of GPS time into Gregorian format, I want to be able to disable that function. I want MJD numbers instead of Gregorian dates, or GPS week numbers / day-of-week / time-of-day. * I think I need a GPSDO rather than just a GPS receiver. The hardware design I have in mind for my rubber duckie is a custom PowerPC board on which I will run a specially modified and heavily stripped-down version of 4.3BSD-Quasijarus, an embedded PowerPC port thereof. In order to run a version of 4.3BSD-Quasijarus on my custom PowerPC board and make it do what I want (generate UTR from MCAT), I would like to implement a circuit on my board that generates an interrupt per millisecond. These millisecond interrupts need to be aligned with 1 PPS such that every 1000th millisecond interrupt also serves as an on-time mark for MCAT (TAI/UTC/GPS/etc) seconds. Someone please correct me if I'm missing some other simpler way, but it seems to me that in order to generate these 1 ms interrupts with the properties I require, I will need a 10 MHz input in addition to 1 PPS, hence the need for a GPSDO rather than just a GPS receiver. I envision my clock interrupt generation logic working as follows: * Starting at power-up boot, divide 10 MHz input by 1 and produce an interrupt every 1 ms. At this point these interrupts aren't aligned with anything, but they are good enough for the OS to boot. * The FPGA in which this circuit resides gets an acquire lock command from the software. It hunts for an external 1 PPS pulse, generates its own 1 ms interrupt at the same time (modulo a few cycles of 10 MHz for logic and synchronizer delays), and resets its divide-by-1 logic from there, such that all subsequent 1 ms interrupts will follow in proper sequence. * In the preceding description the external 1 PPS pulse is acted upon only once, and all subsequent 1 ms and 1 s timing is derived from 10 MHz. However, there will also be a sanity check circuit that will look for the external 1 PPS in the vicinity (+/- 1 ms maybe?) of the internally-derived 1000th 1 ms interrupt. If the internal and external 1 PPS signals disagree, signal an error indication to the software. The software will then declare the UTR output as possibly invalid and resync itself; the resync sequence will include telling the FPGA to resync itself to the external 1 PPS. In order for my clock interrupt generation circuit to work as I envision, the 10 MHz and 1 PPS signals going from the GPSDO to my rubber duckie will need to meet
Re: [time-nuts] GPSDO for my rubber duckie
Chris Albertson albertson.ch...@gmail.com wrote: I think you can do just fine without GPS and GPSDXO oscillators and the like. NTP over the Internet is an order of magnitude better then you need. No, I really don't want anything NTP-based. Or let's put it another way: part of my objective is to set up a stratum 1 NTP server that would serve my UTR timescale to the public Internet. By definition a stratum 1 NTP server does NOT use another NTP server as its reference. Look guys, I have thought it through and I really want to do it my way. Sure, it may be way overkill, but I still want to do it my way. The reason I have started this thread on time-nuts (rather than the leapsecs list for example) is not to argue philosophies, but to solicit advice on the choice of specific GPS receiver / GPSDO types. I'm still looking for that. Forget about my eccentric choice of output timescale and everything else in this thread. The part below is what I am soliciting advice for: I desire to build a circuit that generates an interrupt every millisecond, and have every 1000th interrupt correspond to the second boundary in official time scales such as UTC, TAI and GPS (which all agree on where the second boundaries should be). Forget for the moment why I want this circuit, let's say I just do. THIS is the part I am seeking advice on, nothing else. Do I need a plain GPS receiver or a GPSDO? From what I understand, non-DO GPS units only put out 1 PPS, no 10 MHz, right? Basically I would then have to take the 1 PPS input and somehow fill in the milliseconds in between. If I do it myself, it seems to me that I would be reinventing a GPSDO, but perhaps I'm wrong on that. I don't need the 1 PPS to be phase-locked to 10 MHz, instead I want the 10 MHz to be frequency-locked to 1 PPS. I don't care if there is no guaranteed phase relation between the two signals as long as *on average* there will be 10 million cycles of 10 MHz between successive 1 PPS pulses. Nothing bad will happen if any given interval between 1 PPS pulses features a few cycles too few or a few cycles too many on the 10 MHz, as long as there is no long-term frequency drift between the two signals. In other words, I want to be able to clock my circuit from the 10 MHz, catch the 1 PPS once, and then depend on every subsequent 1 PPS being within a certain fixed window of where I would expect it to be. Which GPSDO do you guys think would do this job best? Also what happens to the GPS receiver's serial port in a GPSDO configuration? A standard GPS receiver has a 1 PPS output and a serial port, right? The serial port transmits a message every second saying what actual time the next 1 PPS corresponds to, right? And one can send commands to that port to change the receiver's configuration, right? Such as switching between leap-second-corrected and non-LS-corrected output, right? What happens to this serial port in a GPSDO configuration? Does it pass through GPSDO firmware? How much direct access to the actual GPS receiver is still allowed, or none? These are the kind of things I'm wondering about; I don't need to be told to use NTP on a PC instead. MS ___ 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] GPSDO for my rubber duckie
Henry Hallam he...@pericynthion.org wrote: The parameters you'll want for conversion between MCAT and mean solar time are given daily in the IERS bulletins: http://hpiers.obspm.fr/eop-pc/products/bulletins/bulletins.html Yes, I know. By making use of these you should be able to do much better than the slightly inelegant leap second rubberization-over-10-seconds method you had proposed. Your rubber seconds should be smooth and continuous, to the limit of the IERS measurement accuracy. But that would be quite a bit harder. :-) I'll leave that as an exercise for Version 2.0; but I'll start with building 1.0 that does my simple rubberization. MS ___ 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.
