Re: [time-nuts] NIST time services
ja...@extremeoverclocking.com said: > If there was some sort of feature in NTP (maybe there already is???), or > even a separate program that could "test" a list of NTP servers to try and > pick the lowest latency, I think that could have a positive benefit on > better time transfer. The current ntp-dev is actually closer than you might expect. The pool command gets a bunch of servers via DNS. If one of them stops responding, it will get kicked out and replaced by another server. It's only SMOP to make it kick out the worst server every now and then. That should converge to at least N-1 good servers. (If you have N good ones, it will kick out the worse which might get replaced by a poor server. I suppose you could tweak the selection to require something like more than x% worse than the average or best or ... Simpler to ask for N+1 if you want N.) -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NIST time services
albertson.ch...@gmail.com said: > The assumption NTP makes is that you can judge the quality of a server by > the variance (of "jitter") in the time it reports. I think it's more complicated than that. I think it also includes the non-jitter part of the round trip time. NTP assumes the path is symmetric. Any constant asymmetry will turn into an apparent fixed offset. I think ntpd is smart enough to include that in it's calculations of the clock quality, but I don't understand the details. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Nav Receiver Sawtooth Correction?
b...@evoria.net said: > Thanks for the response. I've got a UT+ in the parts box. But that's not > the problem I'm trying to solve. I'm trying to make the best GPSDO that I > can make using a nav receiver at the moment. Call it an obsession if you > like. It's OK if I don't have corrections to the nanosecond for each PPS. > But I can see the nav receiver wandering around; especially on cloudy days, > (the antenna is in the attic, so that's about the best I can do for that) > and it just seems to me that I should be able to do a general correction for > nav position errors. Sorry if my naive posts are starting to get on > people's nerves. If I was doing something like that, I'd skip the samples where the location was outside a range rather than trying to correct. (even if the GPS marked them as "good") And maybe skip several samples each side of the ones out of range. If you have a good reference, you should be able to collect some data and see how it looks. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO control system
>> Does anybody have data on the drift of Rs or Cs? > Rule of thumb: ... Ah, thanks. But by "Rs and Cs" I meant plural or R/resistor and C/capacitor. I know they change a lot with temperature, but how much do they drift if the temperature is constant? -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
mag...@rubidium.dyndns.org said: > I did a temporary hack on the PID code to convert the D-term into I^2 term, > by integrating the integrator output. First attempt was indeed quite > resonant just to show that I was in the unsafe region. Backing down on the > strength of the component sure did remove much of the resonance, but I did > not see any appreciable improvement in filtering performance, so quick and > dirty hacking isn't sufficient, darn. Maybe it isn't sufficient to make a great GPSDO, but it's more than sufficient to point out the advantages of Tom's simulation setup. Thanks Tom. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NIST time services
It's not really stratum based. The clock selection algorithm is described here http://www.eecis.udel.edu/~mills/ntp/html/select.html Basically it "allows every clock that can logically contribute" That means with estimated error bounds that over lap. That with those not eliminated nTP applies a clustering algorithm to find the set of clocks that will contribute to the weighted average time http://www.eecis.udel.edu/~mills/ntp/html/cluster.html The weight is not based on Stratum but it might turn out that many time it looks like it does simply because the servers using GPS or atomic clocks are very stable and get weighted up. The weight is 1/(root distance) where root distance is computed from offset and jitter. Do NOT look at the "billboard" display. It would have you think NTP picks just one clock. It rarely does that. The bottom line is that when setting up NTP you want to get it many clocks and let it pick. You might even get it two GPS receivers or GPS and a Rb derived PPS and then five pool servers as backup. On Sun, Mar 23, 2014 at 5:07 PM, Magnus Danielson < mag...@rubidium.dyndns.org> wrote: > Jason, > > On 23/03/14 17:26, Jason Rabel wrote: > >> NTP is best used over the Internet. It was designed for unreliable data >>> links. >>> >> >> In the quest for expansion of NTP over the internet, one thing has always >> nagged me. >> >> You can find lists of servers and they will give a physical location >> along with other info about them... >> >> Big whoop... Often these servers tend to be tied to one backbone, so even >> if they are physically located in the same city as me, the >> packets still might have to travel thousands of miles just to switch >> networks. So what should be a 2ms delay has now become 20-40ms >> (or more)... Even if they have multiple backbones, packets coming in are >> not guaranteed to leave on the same network. The more a >> packet has to travel, the more uncertainty you build up... Yes NTP should >> still get you a reasonable time, but our quest is always >> for something better. >> >> If there was some sort of feature in NTP (maybe there already is???), or >> even a separate program that could "test" a list of NTP >> servers to try and pick the lowest latency, I think that could have a >> positive benefit on better time transfer. >> > > This hits straight into one of the problems with NTP. It tries to use the > highest stratum clock rather than best quality clock. A known trick is to > use a set of stratum 2 servers locally and only let local users connect to > those, and them have them peer between each other and to the same stratum 1 > clocks. This gives much better performance then letting the clients to use > the stratum 1 servers directly. > > The hop-count is good to avoid routing loops, but it is not a good > indicator of achieved quality. > > If we have decent intermediary, this would provide much better > performance. As fewer would query the top servers, the second level could > query them much more often, and better filter the result for the benefit of > performance. > > But that would break the basic assumptions of NTP, and you can't do that, > not that the protocol would object. > > Your general idea is however sound, and surely you can do stuff with > scripts. > > Cheers, > Magnus > > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. > -- 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 control system
Hi Charles, How do you lock your OCXO to the PRS10? Thanks, david I've lost track now of who it was, but someone asked if there was a better strategy than a GPS disciplined quartz oscillator or a GPS disciplined rubidium. My best standard uses an SRS PRS10 rubidium disciplined by GPS PPS at tau = VERY long (> ~12 hours), using the PRS10's internal PPS locking. The rubidium, in turn, disciplines my best OCXO at tau >300 seconds. So, for tau less than ~300 seconds the stability is determined by the OCXO; for tau greater than ~300 seconds and less than ~12 hours, the stability is determined by the rubidium; and for tau > ~12 hours, the stability is determined by GPS. I have found that this works very well. Note that the PRS10's digital PPS PLL has a bewildering array of adjustable parameters. One can easily get lost exploring different combinations. My advice is to keep it as simple as possible. Best regards, Charles ___ 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] Nav Receiver Sawtooth Correction?
Random noise or not, wouldn't a position error in a nav receiver cause a corresponding displacement of the 1PPS pulse? Also there's a bit more to it than just minor noise. It's probably multipath, or perhaps even jammers passing on the freeway about a mile away. Whatever the cause, take a look at this screen capture of "foxtrotgps" over about 40 minutes of elapsed time. The red is the GPS movement around my house that I periodically mention. I judge it to be about 15 ft on the diagonal. Sometimes it is much much worse. Likewise I would expect the 1PPS to move by that amount. http://www.evoria.net/AE6RV/Nav/NavWander.png Bob > > From: Chris Albertson >To: Bob Stewart ; Discussion of precise time and frequency >measurement >Sent: Sunday, March 23, 2014 9:24 PM >Subject: Re: [time-nuts] Nav Receiver Sawtooth Correction? > > >What you are seeing in position error is a random noise. There is no >pattern to it and it is not predictable. A sawtooth error is very >nice and regular looking. It's not "noisy" and can be predicted in >advance. Possition error is not at all like sawtooth. > >I think what you CAN do is look at the size of the error. Then you >adjust the gain on the loop control based of the measured error sigma. > > > > >On Sun, Mar 23, 2014 at 6:30 PM, Bob Stewart wrote: >> Hi Ignacio, >> >> Thanks for the response. I've got a UT+ in the parts box. But that's not >> the problem I'm trying to solve. I'm trying to make the best GPSDO that I >> can make using a nav receiver at the moment. Call it an obsession if you >> like. It's OK if I don't have corrections to the nanosecond for each PPS. >> But I can see the nav receiver wandering around; especially on cloudy days, >> (the antenna is in the attic, so that's about the best I can do for that) >> and it just seems to me that I should be able to do a general correction for >> nav position errors. Sorry if my naive posts are starting to get on >> people's nerves. >> >> Bob >> >> >> >> >>> >>> From: EB4APL >>>To: time-nuts@febo.com >>>Sent: Sunday, March 23, 2014 7:35 PM >>>Subject: Re: [time-nuts] Nav Receiver Sawtooth Correction? >>> >>> >>>Bob, >>> >>>The sawtooth is generated by the granularity of the GPS receiver clock >>>not being synchronous with the recovered PPS. The receiver program can >>>calculate the correction to be applied to the next PPS and outputs it in >>>a message, bu only in timing receivers, this is not a useful thing in >>>navigation receivers and I think that it cannot be calculated using the >>>satellites' position, it is a receiver "defect". >>>Why don't you buy a timing receiver? An used Motorola Encore M12+ >>>timing receiver can be bought by $35 or less (ebay items 290656401551 or >>>301131583613. The seller is a known Time Nuts supplier). An UT+ or GT+ >>>even for quite less. >>> >>>Regards, >>>Ignacio EB4APL >>> >>> >> ___ >> 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] Nav Receiver Sawtooth Correction?
What you are seeing in position error is a random noise. There is no pattern to it and it is not predictable. A sawtooth error is very nice and regular looking. It's not "noisy" and can be predicted in advance.Possition error is not at all like sawtooth. I think what you CAN do is look at the size of the error. Then you adjust the gain on the loop control based of the measured error sigma. On Sun, Mar 23, 2014 at 6:30 PM, Bob Stewart wrote: > Hi Ignacio, > > Thanks for the response. I've got a UT+ in the parts box. But that's not > the problem I'm trying to solve. I'm trying to make the best GPSDO that I > can make using a nav receiver at the moment. Call it an obsession if you > like. It's OK if I don't have corrections to the nanosecond for each PPS. > But I can see the nav receiver wandering around; especially on cloudy days, > (the antenna is in the attic, so that's about the best I can do for that) and > it just seems to me that I should be able to do a general correction for nav > position errors. Sorry if my naive posts are starting to get on people's > nerves. > > Bob > > > > >> >> From: EB4APL >>To: time-nuts@febo.com >>Sent: Sunday, March 23, 2014 7:35 PM >>Subject: Re: [time-nuts] Nav Receiver Sawtooth Correction? >> >> >>Bob, >> >>The sawtooth is generated by the granularity of the GPS receiver clock >>not being synchronous with the recovered PPS. The receiver program can >>calculate the correction to be applied to the next PPS and outputs it in >>a message, bu only in timing receivers, this is not a useful thing in >>navigation receivers and I think that it cannot be calculated using the >>satellites' position, it is a receiver "defect". >>Why don't you buy a timing receiver? An used Motorola Encore M12+ >>timing receiver can be bought by $35 or less (ebay items 290656401551 or >>301131583613. The seller is a known Time Nuts supplier). An UT+ or GT+ >>even for quite less. >> >>Regards, >>Ignacio EB4APL >> >> > ___ > 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] Nav Receiver Sawtooth Correction?
Hi Ignacio, Thanks for the response. I've got a UT+ in the parts box. But that's not the problem I'm trying to solve. I'm trying to make the best GPSDO that I can make using a nav receiver at the moment. Call it an obsession if you like. It's OK if I don't have corrections to the nanosecond for each PPS. But I can see the nav receiver wandering around; especially on cloudy days, (the antenna is in the attic, so that's about the best I can do for that) and it just seems to me that I should be able to do a general correction for nav position errors. Sorry if my naive posts are starting to get on people's nerves. Bob > > From: EB4APL >To: time-nuts@febo.com >Sent: Sunday, March 23, 2014 7:35 PM >Subject: Re: [time-nuts] Nav Receiver Sawtooth Correction? > > >Bob, > >The sawtooth is generated by the granularity of the GPS receiver clock >not being synchronous with the recovered PPS. The receiver program can >calculate the correction to be applied to the next PPS and outputs it in >a message, bu only in timing receivers, this is not a useful thing in >navigation receivers and I think that it cannot be calculated using the >satellites' position, it is a receiver "defect". >Why don't you buy a timing receiver? An used Motorola Encore M12+ >timing receiver can be bought by $35 or less (ebay items 290656401551 or >301131583613. The seller is a known Time Nuts supplier). An UT+ or GT+ >even for quite less. > >Regards, >Ignacio EB4APL > > ___ 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 control system
Hi …. and GPS has cyclic issues on a 24 / 48 hour basis …. Bob On Mar 23, 2014, at 8:58 PM, Tom Van Baak (lab) wrote: > Rule of thumb: > - really good OCXO have frequency drift rates of 1e-10 to 1e-11/day > - common Rb have frequency drift rates on the order of 1e-11/month > - Cs do not have frequency drift > - H-maser drift rates are 1e-15 to 1e-16/day > > /tvb (i5s) > >> On Mar 23, 2014, at 4:32 PM, Charles Steinmetz wrote: >> >> Hal wrote: >> >>> Does anybody have data on the drift of Rs or Cs? >> >> Tom has some data posted at leapsecond.com (for H-masers, too). >> >> John Miles has some at ke5fx.com. >> >> John Ackermann has some at febo.com. >> >> I encourage you to roam widely over all three sites -- you will be well >> rewarded. >> >> Best regards, >> >> Charles >> >> >> >> ___ >> 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 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 control system
Rule of thumb: - really good OCXO have frequency drift rates of 1e-10 to 1e-11/day - common Rb have frequency drift rates on the order of 1e-11/month - Cs do not have frequency drift - H-maser drift rates are 1e-15 to 1e-16/day /tvb (i5s) > On Mar 23, 2014, at 4:32 PM, Charles Steinmetz wrote: > > Hal wrote: > >> Does anybody have data on the drift of Rs or Cs? > > Tom has some data posted at leapsecond.com (for H-masers, too). > > John Miles has some at ke5fx.com. > > John Ackermann has some at febo.com. > > I encourage you to roam widely over all three sites -- you will be well > rewarded. > > Best regards, > > Charles > > > > ___ > 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] Nav Receiver Sawtooth Correction?
Bob, The sawtooth is generated by the granularity of the GPS receiver clock not being synchronous with the recovered PPS. The receiver program can calculate the correction to be applied to the next PPS and outputs it in a message, bu only in timing receivers, this is not a useful thing in navigation receivers and I think that it cannot be calculated using the satellites' position, it is a receiver "defect". Why don't you buy a timing receiver? An used Motorola Encore M12+ timing receiver can be bought by $35 or less (ebay items 290656401551 or 301131583613. The seller is a known Time Nuts supplier). An UT+ or GT+ even for quite less. Regards, Ignacio EB4APL On 21/03/2014 20:28, Bob Stewart wrote: I've gotten my PLL mostly working, but, since I'm using a nav receiver, it looks like I may want to see if I can do a poor-man's sawtooth correction based on GPS position changes. Has anyone done this or have a reference for a project that has? It would seem to me that only the East-West movements would be a factor, but I dunno. As a beginning, I was just going to plot lat and lon deltas from "gpsd" data to see what correlates to the phase error jumps I'm seeing, unless this path has already been tread. I don't expect the accuracy that would be afforded by a real timing receiver. Bob - AE6RV ___ ___ 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 control system
I've lost track now of who it was, but someone asked if there was a better strategy than a GPS disciplined quartz oscillator or a GPS disciplined rubidium. My best standard uses an SRS PRS10 rubidium disciplined by GPS PPS at tau = VERY long (> ~12 hours), using the PRS10's internal PPS locking. The rubidium, in turn, disciplines my best OCXO at tau >300 seconds. So, for tau less than ~300 seconds the stability is determined by the OCXO; for tau greater than ~300 seconds and less than ~12 hours, the stability is determined by the rubidium; and for tau > ~12 hours, the stability is determined by GPS. I have found that this works very well. Note that the PRS10's digital PPS PLL has a bewildering array of adjustable parameters. One can easily get lost exploring different combinations. My advice is to keep it as simple as possible. Best regards, Charles ___ 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] Equinox and sidereal time
On Sun, Mar 23, 2014 at 7:02 PM, Neville Michie wrote: > can anyone out there point me to a source > for the exact time of the equinoxes and solstices > I think you want this: http://aa.usno.navy.mil/data/docs/geocentric.php e.g. RA 0 is 2014 Mar 20 16:57:07.5 or RA 12 is 2014 Sep 23 02:29:08.5 ___ 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] NIST time services
Jason, On 23/03/14 17:26, Jason Rabel wrote: NTP is best used over the Internet. It was designed for unreliable data links. In the quest for expansion of NTP over the internet, one thing has always nagged me. You can find lists of servers and they will give a physical location along with other info about them... Big whoop... Often these servers tend to be tied to one backbone, so even if they are physically located in the same city as me, the packets still might have to travel thousands of miles just to switch networks. So what should be a 2ms delay has now become 20-40ms (or more)... Even if they have multiple backbones, packets coming in are not guaranteed to leave on the same network. The more a packet has to travel, the more uncertainty you build up... Yes NTP should still get you a reasonable time, but our quest is always for something better. If there was some sort of feature in NTP (maybe there already is???), or even a separate program that could "test" a list of NTP servers to try and pick the lowest latency, I think that could have a positive benefit on better time transfer. This hits straight into one of the problems with NTP. It tries to use the highest stratum clock rather than best quality clock. A known trick is to use a set of stratum 2 servers locally and only let local users connect to those, and them have them peer between each other and to the same stratum 1 clocks. This gives much better performance then letting the clients to use the stratum 1 servers directly. The hop-count is good to avoid routing loops, but it is not a good indicator of achieved quality. If we have decent intermediary, this would provide much better performance. As fewer would query the top servers, the second level could query them much more often, and better filter the result for the benefit of performance. But that would break the basic assumptions of NTP, and you can't do that, not that the protocol would object. Your general idea is however sound, and surely you can do stuff with scripts. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
Jim, On 23/03/14 16:00, Jim Miller wrote: To handle higher tau performance I think we want a higher degree loop. Cheers, Magnus Is a higher degree loop possible while maintaining stability? Commanding frequency while measuring phase is one pole, integrating the result of the phase comparison is a second pole and closing the loop will result in oscillation unless a zero is inserted (the P in PID). How would stability be maintained? A third degree PLL is stable if the pole-pair is suitably located. The second degree PLL is kind of hard to bring into self-oscillation while that is much easier with the third degree, so more care needs to go into it. When you think about it, putting an exponential averager just after the phase-detector (AVG1 in gpsim1) is in fact making the PLL a third degree, but since the time-constant needs to be constrained to be well below the loop time-constant "for stability reasons" it is in fact to avoid having the poles of this third-degree loop from deviating away into unstability. I did a temporary hack on the PID code to convert the D-term into I^2 term, by integrating the integrator output. First attempt was indeed quite resonant just to show that I was in the unsafe region. Backing down on the strength of the component sure did remove much of the resonance, but I did not see any appreciable improvement in filtering performance, so quick and dirty hacking isn't sufficient, darn. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Equinox and sidereal time
Go to The Astronomical Almanac: asa.usno.navy.mil --- Antonio A.S. Magalhaes. Em 2014-03-23 23:02, Neville Michie escreveu: Hi, can anyone out there point me to a source for the exact time of the equinoxes and solstices so that I can synchronise a sidereal clock? I assume that at some time the Universal Time we use is exactly the same as Sidereal time, and so a Sidereal clock could be set. I have a Tbolt producing 10MHz, and divide it with one of Tom's excellent PICDIV chips, to get sidereal seconds. I would like to be able to hear them ticking away as I follow a star with a theodolite, and check my local time and position. If I use published times for the equinox, to one minute, I only get about 0.2 second resolution. There is probably more to this than meets the eye, but where does one find out about it? 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. ___ 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 control system
On 24/03/14 00:08, Charles Steinmetz wrote: Chris wrote: 4) why use a PPS as the communications link from GPS to GPSDO? Generally, because that is the only precision timing output you get from a GPS unit. The models with a 10kHz output were prized by the "simple GPSDO" crowd precisely for the fact that the phase-locked 10kHz signal made the control loop much easier to design (or, made an analog loop *possible* to design). Can I find a way to move the OXCO into the guts of a GPS receiver. I don't know. Can you? That is essentially what the Thunderbolt does, and it brings with it the tremendous advantage that it removes the sawtooth error -- which is why some of us think so highly of that design. But now you are really down and dirty, designing your own GPS receiver. Are you competent (and, if so, willing) to do that? (You are very, very far from a "simple" GPSDO if you are considering this.) Honestly, I never understood why all timing receivers aren't designed that way. It seems to be such a superior way to do things that I'd have thought the other approaches would have died out once everybody knew about it. Even if Trimble has a patent, I can't imagine it would be that expensive to license. But even Trimble doesn't use it on all of their timing receivers. Anybody know why this scheme hasn't been used more widely? Is there something I'm missing? For the more expensive GPS receivers, they have been using OCXO, some even suspended OCXOs. Also, as an option you can connect an external clock for additional stability, and for some you can steer this clock. Many of the OEM GPS boards is just... el cheapo. So, you need to look beyond those to find other solutions. For a GPS receiver itself, it doesn't need a clock to be sharp on time, as most of them is designed to handle a clock at the wrong rate. What they however do is learn and compensate for phase and frequency errors. Also, the performance of the clock will affect the produced results, and ẃhen doing precision measures of code-phase for L1 and L2, the benefit is certainly there. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO control system
csteinm...@yandex.com said: > >Can I find a way to move the OXCO into the guts of a GPS receiver. > I don't know. Can you? That is essentially what the Thunderbolt does, and > it brings with it the tremendous advantage that it removes the sawtooth > error -- which is why some of us think so highly of that design. But now > you are really down and dirty, designing your own GPS receiver. Are you > competent (and, if so, willing) to do that? (You are very, very far from a > "simple" GPSDO if you are considering this.) I agree that it won't be simple, but it's likely to be within range of many of us, if not now, then soon. The SDR guys are doing lots of great work. I haven't looked at any of the details, but google gets several hits for >SDR GPS<. It would be interesting to investigate turning the software into timing mode and/or turning that into a GPSDO. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO control system
Hal wrote: Does anybody have data on the drift of Rs or Cs? Tom has some data posted at leapsecond.com (for H-masers, too). John Miles has some at ke5fx.com. John Ackermann has some at febo.com. I encourage you to roam widely over all three sites -- you will be well rewarded. Best regards, Charles ___ 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] Equinox and sidereal time
On Sunday, March 23, 2014, Neville Michie wrote: > Hi, > can anyone out there point me to a source > for the exact time of the equinoxes and solstices > so that I can synchronise a sidereal clock? Check the USNO's website. -- Brian Lloyd, WB6RQN/J79BPL 706 Flightline Drive Spring Branch, TX 78070 br...@lloyd.com +1.916.877.5067 ___ 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 control system
li...@rtty.us said: > If you have a source of noise that is not in your model *and* its > significant, then your model will not predict the outcome. Thats true if > its in or if its outside the loop bandwidth. Does anybody have data on the drift of Rs or Cs? In this context, is it significant? I assume it depends on the circuit involved. I'm just looking for the big picture. I expect any drift is lost in the noise if the temperature and such aren't stable. -- 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] Equinox and sidereal time
Hi, can anyone out there point me to a source for the exact time of the equinoxes and solstices so that I can synchronise a sidereal clock? I assume that at some time the Universal Time we use is exactly the same as Sidereal time, and so a Sidereal clock could be set. I have a Tbolt producing 10MHz, and divide it with one of Tom's excellent PICDIV chips, to get sidereal seconds. I would like to be able to hear them ticking away as I follow a star with a theodolite, and check my local time and position. If I use published times for the equinox, to one minute, I only get about 0.2 second resolution. There is probably more to this than meets the eye, but where does one find out about it? 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 control system
Chris wrote: 4) why use a PPS as the communications link from GPS to GPSDO? Generally, because that is the only precision timing output you get from a GPS unit. The models with a 10kHz output were prized by the "simple GPSDO" crowd precisely for the fact that the phase-locked 10kHz signal made the control loop much easier to design (or, made an analog loop *possible* to design). Can I find a way to move the OXCO into the guts of a GPS receiver. I don't know. Can you? That is essentially what the Thunderbolt does, and it brings with it the tremendous advantage that it removes the sawtooth error -- which is why some of us think so highly of that design. But now you are really down and dirty, designing your own GPS receiver. Are you competent (and, if so, willing) to do that? (You are very, very far from a "simple" GPSDO if you are considering this.) Honestly, I never understood why all timing receivers aren't designed that way. It seems to be such a superior way to do things that I'd have thought the other approaches would have died out once everybody knew about it. Even if Trimble has a patent, I can't imagine it would be that expensive to license. But even Trimble doesn't use it on all of their timing receivers. Anybody know why this scheme hasn't been used more widely? Is there something I'm missing? Best regards, Charles ___ 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] Aircraft ping timing
Hi While you would *think* that LTE and PCS signals would be locked to “something good”, that’s not always the case. If you decide to use something like this for timing, it’s best to check things out carefully. Symmetricom learned this the hard way on one of their boxes …. Bob On Mar 23, 2014, at 6:28 PM, nuts wrote: > > FR24 got a bit picky with their latest generation receiver since so > many of the first generation units "walked." What they have been doing > lately is giving them to flight schools, which are a bit more > responsible than your average schmuck. > > You can monitor any of these decoders with >> http://www.virtualradarserver.co.uk/ > > To keep this timing related. there is am open source program to > calibrate these DVB-T dongles based on LTE signals. > >> http://www.serverfault.sk/2012/10/lte-cell-scanner/ > > I got this running on Opensuse 12.3. I haven't run it lately. Due to > the bandwidth limit of the rtlsdr-, you can only scan the 700MHz LTE > signals (Verizon). > ___ > 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] Aircraft ping timing
FR24 got a bit picky with their latest generation receiver since so many of the first generation units "walked." What they have been doing lately is giving them to flight schools, which are a bit more responsible than your average schmuck. You can monitor any of these decoders with > http://www.virtualradarserver.co.uk/ To keep this timing related. there is am open source program to calibrate these DVB-T dongles based on LTE signals. > http://www.serverfault.sk/2012/10/lte-cell-scanner/ I got this running on Opensuse 12.3. I haven't run it lately. Due to the bandwidth limit of the rtlsdr-, you can only scan the 700MHz LTE signals (Verizon). ___ 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 control system
You are nine days too early. :) Tom - Original Message - From: "Chris Albertson" To: "Discussion of precise time and frequency measurement" Sent: Sunday, March 23, 2014 5:26 PM Subject: Re: [time-nuts] GPSDO control system I'm working on a GPSDO but with different goals. I want mine to be 1) very low cost, under $50 for everything if I can 2) No PCB required. 3) very easy to replicate by a first time builder 4) Easy to understand. The parts count is very low, no "exotic" parts and the software written very clearly so the code reads like the tutorial for a beginner. I started with Lars' Arduino based design and I've making slight mods. But shipping from China takes a month and I'm waiting on parts.I expect only 1E-11 level performance The next one I build I want to be different. I don't need yet another copy of an old design. 1) Can I combine two oscillator technologies to get the best of both? Perhaps phase lock an OCXO to a Rb and then discipline the Rb's frequency. 2) is there some good way to control the temperature of the entire assembly? Perhaps dunk the entire thing into a container of transformer oil? Or use thermal epoxy to connect all the critical parts to ONE common heat sink and then keep that at constant temperature. First I need some way to measure temperature very accurately. 3) are 10MHz crystals the most stable ones? I bet there is a sweat spot frequency that is better. Would 50MHz or 5Mhz be better? 4) why use a PPS as the communications link from GPS to GPSDO? Can I find a way to move the OXCO into the guts of a GPS receiver. That may mean I have to build a SDR based GPS receiver. But first the simple one. I'll post progress reports and photos On Sun, Mar 23, 2014 at 11:32 AM, wrote: Hi There are many issues when it comes to a GPSO. But what has to be first discussed what is it one wants to accomplish. Last year when we worked on the latest Shera GPSDO we always got better than 1E-11 with a unit lying on the bench with no enclosure or thermal management. Chasing elusive 1 E-13 and better, allow me to make a couple of comments. In order to get there, the total system has to be under review. Since I know nothing about writing programs I leave that to smarter people but be clear software and code will not do it by it self. The most critical part is the thermal management of the OCXO or Rb and if analog control is used the DAC.and if used its output amp. We are controlling the back plate of the M100 and FRK to within 0.01 C and the front 0.1 C. The DAC board and the temperature controller are on the front, Voltage regulators on the back. After extensive testing the LTC1655 is our preferred choice. Take a close look specs are great for this application and most important solderable. There are better DAC's out there but very expensive and I am not able to solder. 18 bits would be nicer but 16 bits are for Rb's usable. The DAC part has to have its own ground plane because ground loops can create noise and voltage changes it has to be tied as close and separate to the OCXO or Rb. No opto Isolation necessary as long as the controller and DAC are in the same box, sharing the same system ground. Input to the DAC can handle wide ground variations. Took me years to find that out. Absolute must how ever is opto isolation between GPS, controller and PC, again found out the hard way. The other part I like to touch on is the GPS input section. I am not a time nut but a frequency nut, but there has been so much talk in the past and more recently about sawtooth. I am disappointed but not surprised that no one has stepped up and offered a solution. The site has deteriorated to a lot of talk very little action. Right now there are still affordable and solderable DS1023's out there. Combined with a 12F629 or 12F1840 a sawtooth correction is possible for much less than $20. I bought last year four DIP and 10 in SOIC DS's average price below $ 5! Even though I had a very bad experience once with a Dutch so called time nut I am willing to make the following offer. For the right person I make a board, PIC and DS1023 available. Maybe I just missed it but I do not think that there is something out there readily available. Bert Kehren In a message dated 3/23/2014 9:02:59 A.M. Eastern Daylight Time, li...@rtty.us writes: Hi The real answer is always "that depends". 1) How much does the sensitivity of your OCXO change with a change in EFC? 1.4:1, 2:1, 4:1 (slope sensitivity not % linearity) 2) How quiet is your DAC compared to your OCXO? 3) How quiet is your reference compared to your OCXO? 4) How much do the DAC, reference, op-amps, resistors, capacitors, ... drift with time? 5) How much test time is enough? (hours, days, weeks ,.) 6) How good is the survey on your GPS this time? 7) How much does your room temperature impact your OCXO when you do this or that? 8) Is your room tem
Re: [time-nuts] HP Z3805A with 100+ns PPS Jumps
I will be eager to see responses to this. It is similar to the behavior I was seeing on my "tested" nortel unit that I purchased from the e-place. Tried a bunch of things, new antenna, higher antenna (even though my Z3801 worked fine on the old, before the Z3801 died) and different power supplies. Finally gave up & shut it off. Another time. Hoping to see some ideas . . . . . 73, Jim wb4...@amsat.org On 3/23/2014 3:45 PM, John Stuart wrote: I just bought my second HP Z3805 (this one has a 12 ch. receiver) and have been monitoring it with Ulrich Bangert's Z38XX software tool. Last week, and again today, the PPS output has had several sudden excursions of +- 100 ns or more. It appears that each jump is followed by a jump in the opposite direction a few hours later. I have inserted the following Z38XX graphs below: 1. Several PPS jumps from last night and early this morning. 2. Similar jumps from last week. 3. Oscilloscope measurement confirming PPS offset. Yellow trace = ThunderBolt PPS, Blue = HP Z3805A PPS Might I have a faulty HP Z3805A, or an erratic 10811-60165 DOCXO waking up from a long nap in China? John Stuart, KM6QX Lafayette, CA ___ 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. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO control system
I'm working on a GPSDO but with different goals. I want mine to be 1) very low cost, under $50 for everything if I can 2) No PCB required. 3) very easy to replicate by a first time builder 4) Easy to understand. The parts count is very low, no "exotic" parts and the software written very clearly so the code reads like the tutorial for a beginner. I started with Lars' Arduino based design and I've making slight mods. But shipping from China takes a month and I'm waiting on parts.I expect only 1E-11 level performance The next one I build I want to be different. I don't need yet another copy of an old design. 1) Can I combine two oscillator technologies to get the best of both? Perhaps phase lock an OCXO to a Rb and then discipline the Rb's frequency. 2) is there some good way to control the temperature of the entire assembly? Perhaps dunk the entire thing into a container of transformer oil? Or use thermal epoxy to connect all the critical parts to ONE common heat sink and then keep that at constant temperature. First I need some way to measure temperature very accurately. 3) are 10MHz crystals the most stable ones? I bet there is a sweat spot frequency that is better. Would 50MHz or 5Mhz be better? 4) why use a PPS as the communications link from GPS to GPSDO? Can I find a way to move the OXCO into the guts of a GPS receiver. That may mean I have to build a SDR based GPS receiver. But first the simple one. I'll post progress reports and photos On Sun, Mar 23, 2014 at 11:32 AM, wrote: > Hi > There are many issues when it comes to a GPSO. But what has to be first > discussed what is it one wants to accomplish. Last year when we worked on the > latest Shera GPSDO we always got better than 1E-11 with a unit lying on > the bench with no enclosure or thermal management. > Chasing elusive 1 E-13 and better, allow me to make a couple of comments. > In order to get there, the total system has to be under review. Since I > know nothing about writing programs I leave that to smarter people but be > clear software and code will not do it by it self. The most critical part is > the thermal management of the OCXO or Rb and if analog control is used the > DAC.and if used its output amp. We are controlling the back plate of the > M100 and FRK to within 0.01 C and the front 0.1 C. The DAC board and the > temperature controller are on the front, Voltage regulators on the back. > After extensive testing the LTC1655 is our preferred choice. Take a close > look specs are great for this application and most important solderable. > There are better DAC's out there but very expensive and I am not able to > solder. 18 bits would be nicer but 16 bits are for Rb's usable. The DAC part > has to have its own ground plane because ground loops can create noise and > voltage changes it has to be tied as close and separate to the OCXO or Rb. No > opto Isolation necessary as long as the controller and DAC are in the same > box, sharing the same system ground. Input to the DAC can handle wide > ground variations. Took me years to find that out. > Absolute must how ever is opto isolation between GPS, controller and PC, > again found out the hard way. > The other part I like to touch on is the GPS input section. I am not a > time nut but a frequency nut, but there has been so much talk in the past and > more recently about sawtooth. I am disappointed but not surprised that no > one has stepped up and offered a solution. The site has deteriorated to a lot > of talk very little action. Right now there are still affordable and > solderable DS1023's out there. Combined with a 12F629 or 12F1840 a sawtooth > correction is possible for much less than $20. I bought last year four DIP > and > 10 in SOIC DS's average price below $ 5! Even though I had a very bad > experience once with a Dutch so called time nut I am willing to make the > following offer. For the right person I make a board, PIC and DS1023 > available. > Maybe I just missed it but I do not think that there is something out there > readily available. > Bert Kehren > > > In a message dated 3/23/2014 9:02:59 A.M. Eastern Daylight Time, > li...@rtty.us writes: > > Hi > > The real answer is always "that depends". > > 1) How much does the sensitivity of your OCXO change with a change in EFC? > 1.4:1, 2:1, 4:1 (slope sensitivity not % linearity) > > 2) How quiet is your DAC compared to your OCXO? > > 3) How quiet is your reference compared to your OCXO? > > 4) How much do the DAC, reference, op-amps, resistors, capacitors, ... drift > with time? > > 5) How much test time is enough? (hours, days, weeks ,.) > > 6) How good is the survey on your GPS this time? > > 7) How much does your room temperature impact your OCXO when you do this > or that? > > 8) Is your room temperature representative of the real world? (is mine > like yours?) > > 9) Do you intend this gizmo to work over a temperature range? Did you test >
Re: [time-nuts] GPSDO simulation tool
Jim wrote: Is a higher degree loop possible while maintaining stability? Sure. PLL control loops (and other feedback loops) are often designed out to fourth and fifth order. Very simply put, the requirement is that the loop must have a reasonable phase margin at the frequency where the gain reaches unity. For multiple open-loop poles (where this condition would not be met), the usual solution is to "give back" all but one pole by cancelling them with high-frequency zeroes. All of this can give useful improvements in loop gain at low- to mid-frequencies, at the cost of increased complexity and greater sensitivity to component tolerances. Best regards, Charles ___ 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] NIST time services
On Sun, Mar 23, 2014 at 1:37 PM, Chris Albertson wrote: > Yes. If you modify NTP so that is does the same thing as PTP then it > will as good as PTP. That should be obvious. > I believe you misunderstand my point. ___ 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 control system
Hi If you have a source of “noise” that is not in your model *and* it’s significant, then your model will not predict the outcome. That’s true if it’s in or if it’s outside the loop bandwidth. Bob On Mar 23, 2014, at 2:27 PM, Hal Murray wrote: >> 4) How much do the DAC, reference, op-amps, resistors, capacitors, drift >> with time? > > Assuming constant temperature and supply voltage... > > What is the time scale for parts drifting? Is it very low frequency so well > within the loop bandwidth or is it jumps that will be hard to filter out? > > What happens if temperature or voltage is not constant? Are the changes > reasonably linear with temperature/voltage? > > -- > 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 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 control system
Hi There are many issues when it comes to a GPSO. But what has to be first discussed what is it one wants to accomplish. Last year when we worked on the latest Shera GPSDO we always got better than 1E-11 with a unit lying on the bench with no enclosure or thermal management. Chasing elusive 1 E-13 and better, allow me to make a couple of comments. In order to get there, the total system has to be under review. Since I know nothing about writing programs I leave that to smarter people but be clear software and code will not do it by it self. The most critical part is the thermal management of the OCXO or Rb and if analog control is used the DAC.and if used its output amp. We are controlling the back plate of the M100 and FRK to within 0.01 C and the front 0.1 C. The DAC board and the temperature controller are on the front, Voltage regulators on the back. After extensive testing the LTC1655 is our preferred choice. Take a close look specs are great for this application and most important solderable. There are better DAC's out there but very expensive and I am not able to solder. 18 bits would be nicer but 16 bits are for Rb's usable. The DAC part has to have its own ground plane because ground loops can create noise and voltage changes it has to be tied as close and separate to the OCXO or Rb. No opto Isolation necessary as long as the controller and DAC are in the same box, sharing the same system ground. Input to the DAC can handle wide ground variations. Took me years to find that out. Absolute must how ever is opto isolation between GPS, controller and PC, again found out the hard way. The other part I like to touch on is the GPS input section. I am not a time nut but a frequency nut, but there has been so much talk in the past and more recently about sawtooth. I am disappointed but not surprised that no one has stepped up and offered a solution. The site has deteriorated to a lot of talk very little action. Right now there are still affordable and solderable DS1023's out there. Combined with a 12F629 or 12F1840 a sawtooth correction is possible for much less than $20. I bought last year four DIP and 10 in SOIC DS's average price below $ 5! Even though I had a very bad experience once with a Dutch so called time nut I am willing to make the following offer. For the right person I make a board, PIC and DS1023 available. Maybe I just missed it but I do not think that there is something out there readily available. Bert Kehren In a message dated 3/23/2014 9:02:59 A.M. Eastern Daylight Time, li...@rtty.us writes: Hi The real answer is always “that depends”. 1) How much does the sensitivity of your OCXO change with a change in EFC? 1.4:1, 2:1, 4:1 …. (slope sensitivity not % linearity) 2) How quiet is your DAC compared to your OCXO? 3) How quiet is your reference compared to your OCXO? 4) How much do the DAC, reference, op-amps, resistors, capacitors, … drift with time? 5) How much test time is enough? (hours, days, weeks ,…..) 6) How good is the survey on your GPS this time? 7) How much does your room temperature impact your OCXO when you do this or that? 8) Is your room temperature representative of the real world? (is mine like yours?) 9) Do you intend this gizmo to work over a temperature range? Did you test that range? 10) Are you trying for best frequency or best time? Is your definition of time “GPS local time”? 11) Are there voltage drops on your real board? Do they change with anything? (or everything ?) 12) Does your controller generate spurs inside the control loop and modulate the output with them when tuned to an offset of x.xx Hz? 13) How do things respond to load changes or supply voltage changes? 14) Are the parts (OCXO, reference, dac, op amps …) responses to temperature, load, supply, tip, tune, linear / immediate or do they have artifacts that extend out over longer time periods? This is by no means a complete list. A lot of common GPS issues are notably absent. However, I’ve seen designs fail or fall short for problems related to every item on that list. Can you put this all in a model - sure. Did you put all this in the model .. .. Bob On Mar 23, 2014, at 5:06 AM, Bill Hawkins wrote: > An idea is struggling to take shape in my fevered brain. I'd like to > check some foundation assumptions. > > 1. The difficulty with disciplining a local oscillator to a GPS signal > is due to variations in the received GPS signal and the LO. > > 2. The variations occur slowly, as crystal aging, and quickly - perhaps > sawtooth or crystal crack propagation - and maybe something in between. > > 3. The gain of the system, in degrees of phase angle at 10 MHz (or > higher) per microvolt of control signal, is fairly constant in a > controlled environment. > > 4. The power supply for the device providing the control signal cannot > be
Re: [time-nuts] GPSDO control system
> 4) How much do the DAC, reference, op-amps, resistors, capacitors, drift with > time? Assuming constant temperature and supply voltage... What is the time scale for parts drifting? Is it very low frequency so well within the loop bandwidth or is it jumps that will be hard to filter out? What happens if temperature or voltage is not constant? Are the changes reasonably linear with temperature/voltage? -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NIST time services
On Sun, Mar 23, 2014 at 1:08 PM, Bob Camp wrote: > I suspect that what NIST is looking for is somebody in the cloud business > (Amazon, Google, Microsoft, IBM) to step up and mention that they have > 2,989,875 server racks scattered about the world and they would be happy to > run NTP on them for "free". (see fine print attached ) There's no mention of compensation in the solicitation for input however they do want some things that might or might not fit the business models of the large server companies: -) Traceable time. 0) 180 day hold-over in the absence of GPS (presumably with less than a microsend error). 1) Dedicated (low-latency) links to the UTC(NIST) ensemble 2) Notable oversight by NIST. 3) Geo dispersion. Point three may seem a no-brainer but it disqualifies Amazon if they're using only native infrastructure. It sounds like they want what they should have gotten from Certichron/USTiming but didn't. I suspect the best candidates would be someone like Hurricane or Equinix with the Level3s in the second tier. ___ 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 simulation tool
On Sat, Mar 22, 2014 at 8:18 PM, Don Latham wrote: > Hi Tom et.al. Isn't the simulator "easily" convertible to the real thing? > That is, data inputs should be convertible somehow to data streams from > physical devices? > Don This is a very common development method, not just with GSPDOs but with anything like say a couple robots I'm building. At first you simulate the physical hardware. I can write a function called "GetMotorSpeed()" and at first it simply always returns a constant "5.0" and that is good enough. Later I make it read a file and finally I make it read some hardware interface that connects to a sensor but the sensor is just a test fixture on my desk. Later I integrate the sensor in to the robot. I have a few sensors on my desk right new (sonar and IR distance sensors) Almost 100% of professional level work is done this way. At work I've seen this same method used for air defense missiles, radars and "everything". At first you write the code and run it on a desktop computer because it is so easy to do, But as the software matures you need more and more realistic hardware until finally you are running one the actually target hardware on a real (inert) missile. Actually most projects keep the test environment with all the sensors on the desk connected with the rats nest of wires because you can test some scenarios and odd cases that are hard otherwise, like automated fault detection, cooling system failures, EMI problems and so on. It's a pretty common way to build stuff, the software begins it's life on a Linux or UNIX PC then eventually gets put into some tiny micro controller. When you make a change you first test on the PC before mooing the change down to the target environment. All that said a GPSDO can simple enough that yu can short cut this and go straight to the target hardware. But I think or hope we will see a more complex generation of GPSDO that have a LCD display, user interface and built-in network services. You can't short cut something like that. -- 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] NIST time services
On Sat, Mar 22, 2014 at 6:34 PM, Paul wrote: > E.g. FSM says their NTP+PTP "servers" perform equally well using either > protocol. The trick is to use optimized NTP software and timestamping > hardware. Yes. If you modify NTP so that is does the same thing as PTP then it will as good as PTP. That should be obvious. NTP is modular and it is easy to write a new reference clock driver. So if I had time stamping network hardware, I'd want an NTP driver for it and would use it. But most network hardware lacks the feature. -- 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] NIST time services
On Sun, Mar 23, 2014 at 9:26 AM, Jason Rabel wrote: > If there was some sort of feature in NTP (maybe there already is???), or even > a separate program that could "test" a list of NTP > servers to try and pick the lowest latency, I think that could have a > positive benefit on better time transfer. Yes. This is exactly how NTP works. It constantly tests the servers and selects the "best" subset of available reference clocks. This will changes over time and it will change in real time. There is a rather complex algorithm. First the set of clocks is thinned down to what the code calls "true tickers", those are the clocks the generally agree with the rest of the clocks. Then from the clocks who are not "voted off the island" so to speak the time is computed using a kind of weighting. The assumption NTP makes is that you can judge the quality of a server by the variance (of "jitter") in the time it reports. So yes, the problem the problem and the solution you thought of was build into NTP about 30 years ago. It fact that is the whole point of it's being, to estimate the variance in round trip point times and use this to determine how much to weight the results. NOW, the key assumption NTP makes might be wrong and this is a large source of error. It assumes the one-way jitter is 1/2 the round trip jitter. If this is wrong it would give incorrect weight to a server. NTP will eventually settle on the best few servers it finds but continues to talk to all of them just because which are the "best" will change over time. A good example of this is a stratum 1 server that has a GPS connected. Almost certainly it will also connect to other NTP servers and get time from them as well as the GPS. Very quickly it will determine that the GPS has the "best" performance and will use that. But if you disconnect the GPS antenna it will very quickly find the next best source(s) of time. Another example is an "island network". Say you have five NTP servers that are interconnected so that they each get time from the other four. Normally they also use some Internet servers but when the Internet goes down NTP will find which of the local island servers has the most stable clock and those will cary the most weight in the calculation of "consensus time" which is a weighted time based on all "true tickers". -- 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] NIST time services
Hi You can (and many do) run through a list of servers with an NTP client and see what you get. It’s a bit of work, but you only do it once. ——— I suspect that what NIST is looking for is somebody in the cloud business (Amazon, Google, Microsoft, IBM) to step up and mention that they have 2,989,875 server racks scattered about the world and they would be happy to run NTP on them for “free”. (see fine print attached ….) Bob On Mar 23, 2014, at 12:26 PM, Jason Rabel wrote: >> NTP is best used over the Internet. It was designed for unreliable data >> links. > > In the quest for expansion of NTP over the internet, one thing has always > nagged me. > > You can find lists of servers and they will give a physical location along > with other info about them... > > Big whoop... Often these servers tend to be tied to one backbone, so even if > they are physically located in the same city as me, the > packets still might have to travel thousands of miles just to switch > networks. So what should be a 2ms delay has now become 20-40ms > (or more)... Even if they have multiple backbones, packets coming in are not > guaranteed to leave on the same network. The more a > packet has to travel, the more uncertainty you build up... Yes NTP should > still get you a reasonable time, but our quest is always > for something better. > > If there was some sort of feature in NTP (maybe there already is???), or even > a separate program that could "test" a list of NTP > servers to try and pick the lowest latency, I think that could have a > positive benefit on better time transfer. > > > > ___ > 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] NIST time services
> NTP is best used over the Internet. It was designed for unreliable data links. In the quest for expansion of NTP over the internet, one thing has always nagged me. You can find lists of servers and they will give a physical location along with other info about them... Big whoop... Often these servers tend to be tied to one backbone, so even if they are physically located in the same city as me, the packets still might have to travel thousands of miles just to switch networks. So what should be a 2ms delay has now become 20-40ms (or more)... Even if they have multiple backbones, packets coming in are not guaranteed to leave on the same network. The more a packet has to travel, the more uncertainty you build up... Yes NTP should still get you a reasonable time, but our quest is always for something better. If there was some sort of feature in NTP (maybe there already is???), or even a separate program that could "test" a list of NTP servers to try and pick the lowest latency, I think that could have a positive benefit on better time transfer. ___ 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 simulation tool
Hi Unless you can include all the second and third order effects in your model, there will still be a lot to “learn” as you build your gizmo. Computing power is still impacted by garbage in / garbage out. Bob On Mar 23, 2014, at 12:07 PM, Don Latham wrote: > I agree.. Had a maybe weird thought. Computing power is now a trivial part > of the "problem", in that a Ras.Pi can be put to the task for $35 or so. In > that case, PIDdling with time constants and such in a feedback loop with phase > difference as the error signal is easily done, either in simulation, or for > real, as you point out. So, since ADEV or one of its brothers is the measure > of success of PIDdling, shouldn't the ADEV or brethren be in some way the > error signal for the whole? For example, how about a TCGPSDO? put the whole > thing in a first-order thermal enclosure, with power-over-ethernet being the > only external wiring? > Hope I'm at least making at least logical sense… > > Don > Tom Van Baak >> Hi Don, >> >> Yes, easy! And that's exactly the idea -- to take real inputs (or borrowed >> copies of real inputs), and a real software algorithm, and measure the >> virtual >> output to see how well your algorithm and tunable parameters work. Tweak >> parameters. Evolve the algorithm. Simmer until well done. >> >> Theoretically, after one builds the real GPSDO, using the same code or at >> least the same algorithm, the actual performance should nearly perfectly >> match >> the simulation. >> >> The difference, at least for me, is that I'd rather play with unix commands >> and C code on a PC, trying things out in a matter of minutes, than spend >> weeks >> slowly trying different things with a real GPSDO (which I've also done). In >> addition, I think gpsim1 makes a useful, almost interactive, teaching tool. >> >> Now, no simulation is perfect. But oscillators, dividers, 1PPS comparators, >> and DACs are not really that complicated. You are probably guessing that I'm >> working on gpsim2 which will allow simulation of phase and frequency jumps, >> varying GPS reception, power-up, cold-boot, warm-boot, holdover, thermal or >> mechanical shocks to the instrument, and other events that I see in real >> life. >> >> But let's let gpsim1 run its coarse before we worry about 2nd order effects. >> I'm very interested in alternative or enhanced algorithms that people come up >> with. The two algorithms now in gpsim1 and default tuning parameters are just >> something I threw together in a few minutes. >> >> /tvb >> >> - Original Message - >> From: "Don Latham" >> To: "Discussion of precise time and frequency measurement" >> >> Sent: Saturday, March 22, 2014 8:18 PM >> Subject: Re: [time-nuts] GPSDO simulation tool >> >> >> Hi Tom et.al. Isn't the simulator "easily" convertible to the real thing? >> That is, data inputs should be convertible somehow to data streams from >> physical devices? >> Don >> >> >> >> ___ >> 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. >> >> > > > -- > "The power of accurate observation is commonly called cynicism by those who > have not got it." > -George Bernard Shaw > > > Dr. Don Latham AJ7LL > Six Mile Systems LLC > 17850 Six Mile Road > POB 134 > Huson, MT, 59846 > VOX 406-626-4304 > Skype: buffler2 > www.lightningforensics.com > www.sixmilesystems.com > > > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ 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 simulation tool
sorry! had a glitch and hit send too many times :-) -- "The power of accurate observation is commonly called cynicism by those who have not got it." -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
I agree.. Had a maybe weird thought. Computing power is now a trivial part of the "problem", in that a Ras.Pi can be put to the task for $35 or so. In that case, PIDdling with time constants and such in a feedback loop with phase difference as the error signal is easily done, either in simulation, or for real, as you point out. So, since ADEV or one of its brothers is the measure of success of PIDdling, shouldn't the ADEV or brethren be in some way the error signal for the whole? For example, how about a TCGPSDO? put the whole thing in a first-order thermal enclosure, with power-over-ethernet being the only external wiring? Hope I'm at least making at least logical sense Don Tom Van Baak > Hi Don, > > Yes, easy! And that's exactly the idea -- to take real inputs (or borrowed > copies of real inputs), and a real software algorithm, and measure the virtual > output to see how well your algorithm and tunable parameters work. Tweak > parameters. Evolve the algorithm. Simmer until well done. > > Theoretically, after one builds the real GPSDO, using the same code or at > least the same algorithm, the actual performance should nearly perfectly match > the simulation. > > The difference, at least for me, is that I'd rather play with unix commands > and C code on a PC, trying things out in a matter of minutes, than spend weeks > slowly trying different things with a real GPSDO (which I've also done). In > addition, I think gpsim1 makes a useful, almost interactive, teaching tool. > > Now, no simulation is perfect. But oscillators, dividers, 1PPS comparators, > and DACs are not really that complicated. You are probably guessing that I'm > working on gpsim2 which will allow simulation of phase and frequency jumps, > varying GPS reception, power-up, cold-boot, warm-boot, holdover, thermal or > mechanical shocks to the instrument, and other events that I see in real life. > > But let's let gpsim1 run its coarse before we worry about 2nd order effects. > I'm very interested in alternative or enhanced algorithms that people come up > with. The two algorithms now in gpsim1 and default tuning parameters are just > something I threw together in a few minutes. > > /tvb > > - Original Message - > From: "Don Latham" > To: "Discussion of precise time and frequency measurement" > > Sent: Saturday, March 22, 2014 8:18 PM > Subject: Re: [time-nuts] GPSDO simulation tool > > > Hi Tom et.al. Isn't the simulator "easily" convertible to the real thing? > That is, data inputs should be convertible somehow to data streams from > physical devices? > Don > > > > ___ > 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. > > -- "The power of accurate observation is commonly called cynicism by those who have not got it." -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
I agree.. Had a maybe weird thought. Computing power is now a trivial part of the "problem", in that a Ras.Pi can be put to the task for $35 or so. In that case, PIDdling with time constants and such in a feedback loop with phase difference as the error signal is easily done, either in simulation, or for real, as you point out. So, since ADEV or one of its brothers is the measure of success of PIDdling, shouldn't the ADEV or brethren be in some way the error signal for the whole? For example, how about a TCGPSDO? put the whole thing in a first-order thermal enclosure, with power-over-ethernet being the only external wiring? Hope I'm at least making at least logical sense Don Tom Van Baak > Hi Don, > > Yes, easy! And that's exactly the idea -- to take real inputs (or borrowed > copies of real inputs), and a real software algorithm, and measure the virtual > output to see how well your algorithm and tunable parameters work. Tweak > parameters. Evolve the algorithm. Simmer until well done. > > Theoretically, after one builds the real GPSDO, using the same code or at > least the same algorithm, the actual performance should nearly perfectly match > the simulation. > > The difference, at least for me, is that I'd rather play with unix commands > and C code on a PC, trying things out in a matter of minutes, than spend weeks > slowly trying different things with a real GPSDO (which I've also done). In > addition, I think gpsim1 makes a useful, almost interactive, teaching tool. > > Now, no simulation is perfect. But oscillators, dividers, 1PPS comparators, > and DACs are not really that complicated. You are probably guessing that I'm > working on gpsim2 which will allow simulation of phase and frequency jumps, > varying GPS reception, power-up, cold-boot, warm-boot, holdover, thermal or > mechanical shocks to the instrument, and other events that I see in real life. > > But let's let gpsim1 run its coarse before we worry about 2nd order effects. > I'm very interested in alternative or enhanced algorithms that people come up > with. The two algorithms now in gpsim1 and default tuning parameters are just > something I threw together in a few minutes. > > /tvb > > - Original Message - > From: "Don Latham" > To: "Discussion of precise time and frequency measurement" > > Sent: Saturday, March 22, 2014 8:18 PM > Subject: Re: [time-nuts] GPSDO simulation tool > > > Hi Tom et.al. Isn't the simulator "easily" convertible to the real thing? > That is, data inputs should be convertible somehow to data streams from > physical devices? > Don > > > > ___ > 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. > > -- "The power of accurate observation is commonly called cynicism by those who have not got it." -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
I agree.. Had a maybe weird thought. Computing power is now a trivial part of the "problem", in that a Ras.Pi can be put to the task for $35 or so. In that case, PIDdling with time constants and such in a feedback loop with phase difference as the error signal is easily done, either in simulation, or for real, as you point out. So, since ADEV or one of its brothers is the measure of success of PIDdling, shouldn't the ADEV or brethren be in some way the error signal for the whole? For example, how about a TCGPSDO? put the whole thing in a first-order thermal enclosure, with power-over-ethernet being the only external wiring? Hope I'm at least making at least logical sense Don Tom Van Baak > Hi Don, > > Yes, easy! And that's exactly the idea -- to take real inputs (or borrowed > copies of real inputs), and a real software algorithm, and measure the virtual > output to see how well your algorithm and tunable parameters work. Tweak > parameters. Evolve the algorithm. Simmer until well done. > > Theoretically, after one builds the real GPSDO, using the same code or at > least the same algorithm, the actual performance should nearly perfectly match > the simulation. > > The difference, at least for me, is that I'd rather play with unix commands > and C code on a PC, trying things out in a matter of minutes, than spend weeks > slowly trying different things with a real GPSDO (which I've also done). In > addition, I think gpsim1 makes a useful, almost interactive, teaching tool. > > Now, no simulation is perfect. But oscillators, dividers, 1PPS comparators, > and DACs are not really that complicated. You are probably guessing that I'm > working on gpsim2 which will allow simulation of phase and frequency jumps, > varying GPS reception, power-up, cold-boot, warm-boot, holdover, thermal or > mechanical shocks to the instrument, and other events that I see in real life. > > But let's let gpsim1 run its coarse before we worry about 2nd order effects. > I'm very interested in alternative or enhanced algorithms that people come up > with. The two algorithms now in gpsim1 and default tuning parameters are just > something I threw together in a few minutes. > > /tvb > > - Original Message - > From: "Don Latham" > To: "Discussion of precise time and frequency measurement" > > Sent: Saturday, March 22, 2014 8:18 PM > Subject: Re: [time-nuts] GPSDO simulation tool > > > Hi Tom et.al. Isn't the simulator "easily" convertible to the real thing? > That is, data inputs should be convertible somehow to data streams from > physical devices? > Don > > > > ___ > 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. > > -- "The power of accurate observation is commonly called cynicism by those who have not got it." -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
I agree.. Had a maybe weird thought. Computing power is now a trivial part of the "problem", in that a Ras.Pi can be put to the task for $35 or so. In that case, PIDdling with time constants and such in a feedback loop with phase difference as the error signal is easily done, either in simulation, or for real, as you point out. So, since ADEV or one of its brothers is the measure of success of PIDdling, shouldn't the ADEV or brethren be in some way the error signal for the whole? For example, how about a TCGPSDO? put the whole thing in a first-order thermal enclosure, with power-over-ethernet being the only external wiring? Hope I'm at least making at least logical sense Don Tom Van Baak > Hi Don, > > Yes, easy! And that's exactly the idea -- to take real inputs (or borrowed > copies of real inputs), and a real software algorithm, and measure the virtual > output to see how well your algorithm and tunable parameters work. Tweak > parameters. Evolve the algorithm. Simmer until well done. > > Theoretically, after one builds the real GPSDO, using the same code or at > least the same algorithm, the actual performance should nearly perfectly match > the simulation. > > The difference, at least for me, is that I'd rather play with unix commands > and C code on a PC, trying things out in a matter of minutes, than spend weeks > slowly trying different things with a real GPSDO (which I've also done). In > addition, I think gpsim1 makes a useful, almost interactive, teaching tool. > > Now, no simulation is perfect. But oscillators, dividers, 1PPS comparators, > and DACs are not really that complicated. You are probably guessing that I'm > working on gpsim2 which will allow simulation of phase and frequency jumps, > varying GPS reception, power-up, cold-boot, warm-boot, holdover, thermal or > mechanical shocks to the instrument, and other events that I see in real life. > > But let's let gpsim1 run its coarse before we worry about 2nd order effects. > I'm very interested in alternative or enhanced algorithms that people come up > with. The two algorithms now in gpsim1 and default tuning parameters are just > something I threw together in a few minutes. > > /tvb > > - Original Message - > From: "Don Latham" > To: "Discussion of precise time and frequency measurement" > > Sent: Saturday, March 22, 2014 8:18 PM > Subject: Re: [time-nuts] GPSDO simulation tool > > > Hi Tom et.al. Isn't the simulator "easily" convertible to the real thing? > That is, data inputs should be convertible somehow to data streams from > physical devices? > Don > > > > ___ > 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. > > -- "The power of accurate observation is commonly called cynicism by those who have not got it." -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
>To handle higher tau performance I think we want a higher degree loop. >Cheers, >Magnus Is a higher degree loop possible while maintaining stability? Commanding frequency while measuring phase is one pole, integrating the result of the phase comparison is a second pole and closing the loop will result in oscillation unless a zero is inserted (the P in PID). How would stability be maintained? Thanks jim ab3cv (newbie...) ___ 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] Aircraft ping timing
On Sun, Mar 23, 2014 at 3:37 AM, nuts wrote: > > Note that the ADS-B mentioned is just a fancy version of the > transponder that was turned off. > I guess it depends on your concept of what a transponder does. Yes, ADS-B does transmit in the same band as the standard transponder (1090MHz) but the function and content of the transmissions are very different. With the standard mode-A, mode-C, and mode-S system, the transponder only replies to interrogation, and then only replies with the 12-bit ID code (mode-A) or 12-bit ID code plus 12-bit altitude code (mode-C). Mode-S turns it into a two-way data link and adds a bit more more data (aircraft ID) to the reply. The key here is that, if nothing is sending an interrogation, the transponder is silent. The interrogating station must do the position determination based on distance and azimuth of the reply. In the case of ADS-B, the transponder is no longer just a transponder. It is a full transceiver with an application, ADS-B, sending unsolicited data. In this case the aircraft actively transmits its position and velocity data along with its ID. No interrogation is required. Anyone within range and with a receiver can pick up the signal and determine the location of the transmitting aircraft. This means it is possible for a receiver to collect this data passively. The major problem with ADS-B is that they came up with two systems and, rather than fight it out to determine which would win, they just adopted both systems. So we have ADS-B on 978MHz using a bit more sensible modulation and framing, and on 1090MHz using the older OOK pulse-code modulation (1090ES). And to add insult to injury, they have mandated that anything that flies at FL180 (18,000') or above (meaning all airliners) must use 1090ES. The transmission mode for 1090ES (extended squitter) is very inefficient. The signal is broad as a barn door due to the use of pulse code modulation using on-off keying. Each transmission requires 5 frames. The end result is that it isn't going to take a lot of airplanes transmitting in the same airspace before you saturate the channel. So you have two separate-and-incompatible ADS-B systems flying around. The FAA "solved" this problem by deploying a series of ground stations that will repeat ADS-B data from one channel onto the other. If a ground station detects transmissions on 978MHz, it will repeat them on 1090MHz and repeat transmissions from 1090MHz onto 978MHz, otherwise it is silent. This means that a receiver-only system is not guaranteed to see all traffic unless one has receivers for both bands. If an aircraft is to be completely autonomous for traffic detection, the aircraft must transmit and receive on both bands. Alternatively it can transmit and receive on 978 and rely on the ground stations to repeat the 1090ES traffic. Also, because of the capacity limitations of 1090ES, the FAA does not data link weather data on 1090ES. That is only available on 978MHz. So any aircraft wishing to avail itself of the ground-based weather radar data and ground weather reporting must have a receiver for 978MHz. Bottom line, ultimately every aircraft is essentially going to need both systems. (I'm sorry but the level of stupidity that led to the ADS-B design as it now stands just boggles my mind. You have to work at it in order to take something so conceptually simple and make it this brain-damaged.) -- Brian Lloyd, WB6RQN/J79BPL 706 Flightline Drive Spring Branch, TX 78070 br...@lloyd.com +1.916.877.5067 ___ 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 control system
Hi One thing that should be noted. Some of this stuff has zero impact at long tau. Some of it only has an impact at long tau. It might be easier to split a model into long and short versions to deal with this stuff. Getting the data is the next step. You can find app notes on some voltage references that show things like hysteresis, warmup and retrace. Getting the same data on DAC’s or resistors is a bit tough. If you use ceramic caps, you can find non-linear model data on them (sort of). Even with the data, turning it into something that fits in a model isn’t easy at all. When you find that your <2 ppm reference has >40 ppm of hysteresis, including that in the model might move up your list a bit…. Bob On Mar 23, 2014, at 10:02 AM, Magnus Danielson wrote: > On 23/03/14 14:02, Bob Camp wrote: >> Hi >> >> The real answer is always “that depends”. >> >> 1) How much does the sensitivity of your OCXO change with a change in EFC? >> 1.4:1, 2:1, 4:1 …. (slope sensitivity not % linearity) >> >> 2) How quiet is your DAC compared to your OCXO? >> >> 3) How quiet is your reference compared to your OCXO? >> >> 4) How much do the DAC, reference, op-amps, resistors, capacitors, … drift >> with time? >> >> 5) How much test time is enough? (hours, days, weeks ,…..) >> >> 6) How good is the survey on your GPS this time? >> >> 7) How much does your room temperature impact your OCXO when you do this or >> that? >> >> 8) Is your room temperature representative of the real world? (is mine like >> yours?) >> >> 9) Do you intend this gizmo to work over a temperature range? Did you test >> that range? >> >> 10) Are you trying for best frequency or best time? Is your definition of >> time “GPS local time”? >> >> 11) Are there voltage drops on your real board? Do they change with >> anything? (or everything ?) >> >> 12) Does your controller generate spurs inside the control loop and modulate >> the output with them when tuned to an offset of x.xx Hz? >> >> 13) How do things respond to load changes or supply voltage changes? >> >> 14) Are the parts (OCXO, reference, dac, op amps …) responses to >> temperature, load, supply, tip, tune, linear / immediate or do they have >> artifacts that extend out over longer time periods? >> >> This is by no means a complete list. A lot of common GPS issues are notably >> absent. However, I’ve seen designs fail or fall short for problems related >> to every item on that list. Can you put this all in a model - sure. Did you >> put all this in the model .. .. > > 15) As the AC shifts voltage, how does that change the power consumption in > the PSU and hence change the heating in or near your box? > > Cheers, > Magnus > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ 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 control system
On 23/03/14 14:02, Bob Camp wrote: Hi The real answer is always “that depends”. 1) How much does the sensitivity of your OCXO change with a change in EFC? 1.4:1, 2:1, 4:1 …. (slope sensitivity not % linearity) 2) How quiet is your DAC compared to your OCXO? 3) How quiet is your reference compared to your OCXO? 4) How much do the DAC, reference, op-amps, resistors, capacitors, … drift with time? 5) How much test time is enough? (hours, days, weeks ,…..) 6) How good is the survey on your GPS this time? 7) How much does your room temperature impact your OCXO when you do this or that? 8) Is your room temperature representative of the real world? (is mine like yours?) 9) Do you intend this gizmo to work over a temperature range? Did you test that range? 10) Are you trying for best frequency or best time? Is your definition of time “GPS local time”? 11) Are there voltage drops on your real board? Do they change with anything? (or everything ?) 12) Does your controller generate spurs inside the control loop and modulate the output with them when tuned to an offset of x.xx Hz? 13) How do things respond to load changes or supply voltage changes? 14) Are the parts (OCXO, reference, dac, op amps …) responses to temperature, load, supply, tip, tune, linear / immediate or do they have artifacts that extend out over longer time periods? This is by no means a complete list. A lot of common GPS issues are notably absent. However, I’ve seen designs fail or fall short for problems related to every item on that list. Can you put this all in a model - sure. Did you put all this in the model .. .. 15) As the AC shifts voltage, how does that change the power consumption in the PSU and hence change the heating in or near your box? Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
On 23/03/14 06:56, Said Jackson wrote: Tom, In my experience one of the biggest GPSDO error sources in low-cost and even some higher end OCXOs is oscillator hysteresis. Which can change with operating temperature, operating time (crystal age) and even over crystal tilt. Does your OCXO model allow for hysteresis simulation? No, not really. He uses a quite crude model at this point. I think it is fair, as it aims to get the basic principles in such a way that one can fool around. For a more serious simulator it would be nice to have such behaviours modelled, but then it needs to be modelled with real oscillators behaviours and under the various stresses. That's a nice little topic for a series of articles in UFFC. It is very hard to discipline oscillators with hystereses and a good modeling tool would be helpful. I think good modeling isn't very easy either. Maybe it is possible to get a crude model to capture the basics good enough for simulation use. Most ocxo vendors don't even know about hysteresis or how to quantify it (and react with a deer in the headlight look when asked about it), but even levels of ppt to tens of ppt can wreak havoc due to the fact that the loop is always chasing the ocxo if sufficient hysteresis exists. Most sales-rep's don't have a clue, and even their market-oriented app-note-writes does not really have a clue. If you have data to illustrate things, I'm happy to look at it and see what I can learn. Temperature-induced hysteresis, which as far as I have read exists and matches my experience with drift of oscillators after start-up, sure puts a limit to how well TCXOs can perform relative to OCXOs. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Aircraft ping timing
>Da: rmon...@bigpond.net.au >Data: 23/03/2014 10.58 > >For info MH370 did transmit ADS-B signals up to 17:21 UTC on 7 March when it >seems it was either switched off or disabled. You can still see the track >it took up to this time using the playback facility on Flight Radar 24 by >say starting at around 17:00 UTC on 7 March. The flight No on ADS-B is >slightly different and shows as MAS370 rather than MH370. Both are quoted on >Flight Radar 24 when you click on the aircraft to see its track. > >http://www.flightradar24.com/7.69,100.35/6 It seems to me that this has not yet been mentioned: Flightradar24 offers for free a Radcape ADS-B receiver (which includes a GPS receiver) provided that you have a good location and a continuous internet connection. The unit may work stand-alone and doesn't need a computer. Check if you may apply starting from here: http://www.flightradar24.com/increase-coverage Antonio I8IOV ___ 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 control system
Hi The real answer is always “that depends”. 1) How much does the sensitivity of your OCXO change with a change in EFC? 1.4:1, 2:1, 4:1 …. (slope sensitivity not % linearity) 2) How quiet is your DAC compared to your OCXO? 3) How quiet is your reference compared to your OCXO? 4) How much do the DAC, reference, op-amps, resistors, capacitors, … drift with time? 5) How much test time is enough? (hours, days, weeks ,…..) 6) How good is the survey on your GPS this time? 7) How much does your room temperature impact your OCXO when you do this or that? 8) Is your room temperature representative of the real world? (is mine like yours?) 9) Do you intend this gizmo to work over a temperature range? Did you test that range? 10) Are you trying for best frequency or best time? Is your definition of time “GPS local time”? 11) Are there voltage drops on your real board? Do they change with anything? (or everything ?) 12) Does your controller generate spurs inside the control loop and modulate the output with them when tuned to an offset of x.xx Hz? 13) How do things respond to load changes or supply voltage changes? 14) Are the parts (OCXO, reference, dac, op amps …) responses to temperature, load, supply, tip, tune, linear / immediate or do they have artifacts that extend out over longer time periods? This is by no means a complete list. A lot of common GPS issues are notably absent. However, I’ve seen designs fail or fall short for problems related to every item on that list. Can you put this all in a model - sure. Did you put all this in the model .. .. Bob On Mar 23, 2014, at 5:06 AM, Bill Hawkins wrote: > An idea is struggling to take shape in my fevered brain. I'd like to > check some foundation assumptions. > > 1. The difficulty with disciplining a local oscillator to a GPS signal > is due to variations in the received GPS signal and the LO. > > 2. The variations occur slowly, as crystal aging, and quickly - perhaps > sawtooth or crystal crack propagation - and maybe something in between. > > 3. The gain of the system, in degrees of phase angle at 10 MHz (or > higher) per microvolt of control signal, is fairly constant in a > controlled environment. > > 4. The power supply for the device providing the control signal cannot > be regulated to the accuracy required of the system, and so is a source > of variance. (Does anyone put the voltage reference device in the oven > with the crystal?) > > 5. The principle source of environmental variation is temperature. > Humidity and barometric pressure are not significant. This may not be > true of the received GPS signal due to atmospheric variations. > > 6. A digital computational device is available to calculate the control > signal from various measurements and previous values. > > 7. There are no supernatural forces at work, such as the experimenter > mentally influencing the results. :-) > > That's a start . . . > > Thanks for any replies. > > Bill Hawkins > > > > > ___ > 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 control system
Bill wrote: 1. The difficulty with disciplining a local oscillator to a GPS signal is due to variations in the received GPS signal and the LO. I'm not sure I'd call that "the difficulty" -- it is the task of a GPSDO to discipline the local oscillator *at time scales where the GPS is better than the oscillator*. The oscillator wanders, and the GPS signal has noise and jitter. The oscillator controls stability at small to medium tau, so improvements there require a better oscillator (nothing you do on the GPS side is going to improve overall stability below tau = 100 seconds or so). If you have an exceptionally stable oscillator, this will be true out to tau = 1000 or even beyond. 3. The gain of the system, in degrees of phase angle at 10 MHz (or higher) per microvolt of control signal, is fairly constant in a controlled environment. The gain function is a free parameter -- it can have pretty much any characteristic you desire, if you are sufficiently creative to realize it. In practice, of course, it will be constrained by the criteria for stability. 4. The power supply for the device providing the control signal cannot be regulated to the accuracy required of the system, and so is a source of variance. The control amplifier should have considerable PSRR, so this should not be a material source of error. The reference for any DAC in the system may contribute error. But that is all inside the control loop, which is driven by a phase comparator of one sort or another. Ultimately, the errors in the inputs (oscillator and GPS) and the phase comparator should dominate the overall performance (if not, you have left something on the table). 5. The principle source of environmental variation is temperature. Humidity and barometric pressure are not significant. This may not be true of the received GPS signal due to atmospheric variations. You will have to test the parts you propose to use to see if they are affected by humidity or barometric pressure. Some researchers have reported sensitivity to one or both for crystal oscillators and voltage references, among other parts. Except for the oscillator, GPS, and phase comparator, that is all inside the control loop. Best regards, Charles ___ 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] Aircraft ping timing
> > There is a newer system getting phased in: ADS-B > For info MH370 did transmit ADS-B signals up to 17:21 UTC on 7 March when it seems it was either switched off or disabled. You can still see the track it took up to this time using the playback facility on Flight Radar 24 by say starting at around 17:00 UTC on 7 March. The flight No on ADS-B is slightly different and shows as MAS370 rather than MH370. Both are quoted on Flight Radar 24 when you click on the aircraft to see its track. http://www.flightradar24.com/7.69,100.35/6 Regards Rex VK7MO ___ 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] Aircraft ping timing
From: nuts Note that the ADS-B mentioned is just a fancy version of the transponder that was turned off. I ran into your R Pi page about halfway in the process of doing my Beaglebone Black RTLSDR page. I have RTLSDR and dump1090 running on Angstrom Linux. I bought the GPS you suggested and will attempt to get NTP going with it, so expect a question or two off line. ;-) I wonder if your problem with the timing is related to the R Pi being nearly maxed out. The Beaglebone Black is about 4x the processing power of the R Pi, with dump1090 running at 30% CPU. Seems to me that MLAT is a function of the distance between receivers, At 0.5uS, the distance a radio wave travels is 150 meters. Throw in some error and worst case it, you are still talking less than a km. Good enough for MLAT considering the option is no location information. The flightradar24 decoders are using a Beaglebone Black with the "radar cape". That unit claims a 100MHz clock, so the timing resolution is 10ns. But my recollection is the GPSDO units only do around 100ns when the dust settles. The radarcape uses an FPGA, so it doesn't have the computer delay issue and is probably limited by the GPSDO accuracy. Personally for the cost, I'd take the 1km error from the DVB-T stick and call it a day. "Nuts", No problem with off-line questions - providing it's not already covered on the Web page! The Raspberry Pi is running at 35% CPU for decoding mode-S data, and 45% if you add mode-A/C data, so it doesn't appear to be maxed out - at least with the load here. Interesting that even with the extra CPU power of the BeagleBone Black you still see as high as 30% CPU. The author of the software once said that all the memory movement was the main CPU load, to which I asked whether using the DMA controllers might help, but apparently that's not easy to do, and the DMA registers are shared with other functions, IIRC. Malcolm Robb, the author, is very open to comments, though. It seems that the present software (either timing the reading the DVB-T stick or the Mlat processing) cannot produce "good enough" results from the DVB-T stick, something I don't quite understand. The method used is to compare the timings with aircraft of known position - as this may be off-topic there's are references here: http://www.coaa.co.uk/multilat.pdf http://planeplotter.pbworks.com/w/page/17117304/MLAT%20Introduction PlanePlotter does /not/ rely on the PC being synced to within fractions of a millisecond, as it uses relative timing with a quantisation interval determined by the receiver (50 ns for the SBS receiver, 500 ns for the DVB-T stick). The RadarCape with its GPS not only provides accurate absolute time (within 100 ns), but absolute position as well. Of course, it costs about a hundred times more than a DVB-T stick! 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.
[time-nuts] GPSDO control system
An idea is struggling to take shape in my fevered brain. I'd like to check some foundation assumptions. 1. The difficulty with disciplining a local oscillator to a GPS signal is due to variations in the received GPS signal and the LO. 2. The variations occur slowly, as crystal aging, and quickly - perhaps sawtooth or crystal crack propagation - and maybe something in between. 3. The gain of the system, in degrees of phase angle at 10 MHz (or higher) per microvolt of control signal, is fairly constant in a controlled environment. 4. The power supply for the device providing the control signal cannot be regulated to the accuracy required of the system, and so is a source of variance. (Does anyone put the voltage reference device in the oven with the crystal?) 5. The principle source of environmental variation is temperature. Humidity and barometric pressure are not significant. This may not be true of the received GPS signal due to atmospheric variations. 6. A digital computational device is available to calculate the control signal from various measurements and previous values. 7. There are no supernatural forces at work, such as the experimenter mentally influencing the results. :-) That's a start . . . Thanks for any replies. Bill Hawkins ___ 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] Aircraft ping timing
In message <20140323014515.0fffd232@linux-wh01>, nuts writes: >These salvage yards >knew the content of each bird down to a science, and thus know when to >start the process. We had an interesting event in Denmark related to that: Somebody hadn't heard about "Mag-Thor", and tried to drive a truckload of old military scrap through the radiation detection portal at a scrap-yard :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Aircraft ping timing
On Sat, 22 Mar 2014 06:58:22 -0700 (PDT) "J. Forster" wrote: > I'm not so sure it is worth much as parts, except possibly on the > black market. I believe the aircraft industry is big on tracking > every part, cradle to grave. After all an under spec bolt can cause a > very expensive crash. > > YMMV, > > -John > Well timing related (just barely), scraping an airplane is a function of the metals market. For those in southern Ca., KVCV (Southern California Logistics) is where they melt down the old planes. These salvage yards knew the content of each bird down to a science, and thus know when to start the process. If you slip them $20, they will let you tour the boneyard. Same goes for Mojave. ___ 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] Aircraft ping timing
On Sat, 22 Mar 2014 07:40:27 - "David J Taylor" wrote: > From: Hal Murray > > There is a newer system getting phased in: ADS-B > http://en.wikipedia.org/wiki/Automatic_dependent_surveillance-broadcast > > The plane broadcasts it's position and velocity every second. > > The SDR folks are having fun with it. With one of the USB TV > receiver gizmos > and a Raspberry Pi, you are limited by the height of your antenna vs > curvature of the earth. A friend with an antenna 20(?) feet up gets > planes out to several hundred miles. I don't know how far it will > work if you have an antenna on top of a hill. > http://www.rtl-sdr.com/adsb-aircraft-radar-with-rtl-sdr/ > == > > .. and by sharing this data on a central server you can overcome the > line-of-sight limitation: > > http://www.satsignal.eu/raspberry-pi/dump1090.html > > There is a further development which may be of interest to the more > mathematically oriented time-nuts, creating positions of aircraft > which do no send out their position with ADS-B but use earlier > responses. By comparing the timing of responses from aircraft which > do send position with those that don't you can multilaterate a > position for the position-less aircraft. This requires timing in the > receiver device to a level of about 100 nanoseconds, most often > achieved with a simple crystal oscillator (but which needs > calibration). In the DVB-T sticks the usable sampling rate is about > 2 MHz, and the resulting 500 microsecond resolution appears not to be > good enough for even a basic multilateration fix. > > If anyone is interested further or could help with suggestions on > improved accuracy with the DVB-T sticks, a suitable place would be > the Plane Plotter Yahoo group: > > http://groups.yahoo.com/group/planeplotter/ > > Cheers, > David Note that the ADS-B mentioned is just a fancy version of the transponder that was turned off. I ran into your R Pi page about halfway in the process of doing my Beaglebone Black RTLSDR page. I have RTLSDR and dump1090 running on Angstrom Linux. I bought the GPS you suggested and will attempt to get NTP going with it, so expect a question or two off line. ;-) I wonder if your problem with the timing is related to the R Pi being nearly maxed out. The Beaglebone Black is about 4x the processing power of the R Pi, with dump1090 running at 30% CPU. Seems to me that MLAT is a function of the distance between receivers, At 0.5uS, the distance a radio wave travels is 150 meters. Throw in some error and worst case it, you are still talking less than a km. Good enough for MLAT considering the option is no location information. The flightradar24 decoders are using a Beaglebone Black with the "radar cape". That unit claims a 100MHz clock, so the timing resolution is 10ns. But my recollection is the GPSDO units only do around 100ns when the dust settles. The radarcape uses an FPGA, so it doesn't have the computer delay issue and is probably limited by the GPSDO accuracy. Personally for the cost, I'd take the 1km error from the DVB-T stick and call it a 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.
