Re: [time-nuts] seeking a time/clock software architecture
On 24/09/11 00:13, Jim Lux wrote: On 9/23/11 2:00 PM, Chris Howard wrote: Seems like a lot of unknowns. You would have to have sensors monitoring the sensors. I think the clock model (insofar as variations in the oscillator) are outside the scope, as long as the effect of that variation can be represented cleanly. For example, with a simple 2 term linear model t = clock/rate + offset, you can describe the *effect* of a rate, and if the rate changes, the model changes. As long as you keep track of the rates and offsets you've used in the past, you can reconstruct what clock was for any t or vice versa. Which is more or less what calibration records is about. Infact, how all these measures are intended to be used to provide a corrected measure with uncertainty bounds is not very well covered in the papers. It's scattered around. As for the model at hand... the optimum 2-term model and its update log might not provide best performance with parameteres directly interchangeable with the optimum 3-term model. That being said, meaning that the phase error, frequency and drift does not provide a good source for phase error and frequency and vice versa. You might consider to standardise the models in order to provide the quality in interchange of measurements. You might require to have support for several models and essentially provide a frame-work standard for transporting model data. Interconnecting models might need additional tought. I need to think about that one. A clock model predictor might use all those factors to better estimate the rate. Having a high order polynomial model might let you not need to update the model parameters as often. That's a tradeoff the user could make: Do I use a 2 or 3 term clock to time transformation, and update it once a minute, or do I use a 20 term transformation, and update it once a month. A 20 term model requires fairly high precision and good rate measurements to become meaningfull. Irregular updates as such is not a problem, as long as you can induce precission into the system when needed. OK, so if you wanted an output from your Time API that gave you a estimated uncertainty of time (think like the accuracy estimates from GPS receivers), what would that look like? Estimated parameters: timeoffset, frequencyoffset, driftoffset Uncertainty matrix Just look in the manual of a better GPS and you essentially see the Kalman filter model and its parameters popping out. Do you give a 1 sigma number? What about bounding values? (e.g. the API returns the time is 12:21:03.6315, standard deviation of 1.5 millisecond, but guaranteed in the range 12:21:03 to 12:21:04) You do not want bounding values, noise forms makes it hard. one-sigma values help. In all this, I keep thinking Kalman filter (or the like). If you want a standard way of present numbers, you will have to build that ontop on standard models. It would be interesting to see what a combination of mutual synchronisation within a constellation and central synchronisation would yield. Your constellation would maintain contact with each other and pull eachother to some form of average time (according to arbitrary time-scale) and then use the earth link to provide long term corrections. A good mutual synchronisation strategy would allow the constellation to shrink and grow without falling completely appart. If you provide ranging mechanisms within the constellation path delays can naturally be compensated out of time. I would expect that a fancy implementation might return different uncertainties for different times in the future (e.g. I might say that I can schedule something with an accuracy of 1 millisecond in the next 10 minutes, but only within 30 milliseconds when it's 24 hours away) This is true, but if you need higher certainty at a particular time you can schedule a synchronisation event or two where uncertainties can be reduced. If you have the Kalman state and state-vector, you can run the predictor into the future. The mechanics of how one might come up with this uncertainty estimate are out of scope, but the semantics and format of how one reports it are in scope for the architecture. I think you will need to look at the clock models being used. It may be that the models all belong to Kalman types, but with different model sizes... but then someone needs a particle filter model... what if the IMU model is used... time and position. At least a survey over feasable models needs to be done to see what can be done. 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] seeking a time/clock software architecture
On 24/09/11 00:21, Jim Lux wrote: On 9/23/11 2:24 PM, Chris Albertson wrote: On Fri, Sep 23, 2011 at 12:32 PM, Jim Luxjim...@earthlink.net wrote: On 9/23/11 10:50 AM, Chris Albertson wrote: Yes, in the general case, but in the spacecraft case, I think we're more concerned about smoothness and such over time spans of days, maybe weeks and months. More about establishing time correlation between multiple radios/spacecraft in a constellation, for instance. I think better to have your system be usable in the real world and then the spacecraft to use real world standards when it can. If it can handle the ful general case then it will work in the spacecraft too. So Chinese lunar calenders are a good mental exercise. At any rate piece wise 2nd order polynomial will work in all cases I can think of because you can always make the pieces really small if need be to the point where it becomes a table look up. hmm.. 2nd order for time, or 2nd order for rate (3rd order for time). I keep thinking it would be nice to have the derivative of rate be continuous (although I confess I can't think of anything beyond gut feel for that). Maybe for all the common cases that's sufficient for a predict into the future for a reasonable time Spacecraft spend a fair amount of time on the ground in testing. People swap out parts. I work in telemetry and you should see the database of tens of thousands of polynomial functions that must be used to process data. from say a DeltaIV. It's not only clocks but dozens of sensors that get changed out in the months preceding launch. Yes.. And there's no standard form that I've been able to discern for how those polynomials are specified. It's vehicle/spacecraft/instrument/software tool specific. So if you're writing a program to handle it automatically, you need to code up something special each time. These days, we get telemetry calibration in forms like .pdf files generated from a word document, plots from Matlab, Excel spreadsheets in some unique form, various and sundry import/export files from whatever program they're using to process telemetry, and so forth. There was an effort a few years back to try and standardize mission data systems but I don't know that it ever really worked. The cost to write those custom ingest routines is small in the context of a $150M mission every couple or three years. (maybe there is a standard for this.. I know there is a IEEE standard for sensor calibration data.. I should take a look at it again.) Once you pulled data out of telemetry or whatever, putting it in XML form according to a DTD fitting your needs should not be too hard, and further processing should not take too much effort to extract data. Essentially what RINEX does, but without the XML wrapper. 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] HP5065A
Fellow time-nuts, I now have three 5065A in my lab (not all mine) and I can now conclude that the A15 PSU board C8, C9 and C10 caps has gone bad on all three. The only difference on the first one is that the process has not gone as far as to blown the caps, but two of the leads has began the process and turned dark purple on the upper half. Also, one of the caps have been replaced by a 220 uF cap at some time. I already have some fashinating photos of the two other boards lying around (on Facebook actually...). I've already stocked up on replacement caps so replacing them all will be my first priority. Another difference I've noted is that the last one in (Thursday to be exact, arrived with two cesiums from a fellow time-nut) proved much more modern. The A15 assembly does not even have the rectifier diodes on it, but it has been placed off-board. I think this is to provide better cooling and I seriously consider to modify the other two up to that standard. The rectifier diodes don't get sufficient cooling as it sits in its compartment, all sides but the top being closed and then only perforated holes for self-convection. Mounting the rectifiers onto the large aluminium frame would better cool them over time. Another surprice in the later 5065A is the 5061-106 retrofit, where the 105 oscillator is being replaced with a 10811 oscillator. Will be fun to compare against the older variants. Lack of time for lab duty and lack of space in lab is main obsticle right now, but it's fun with some progress at least. Once I got these three rubidiums of the actual bench, there is a bunch of cesiums to investigate. Need to come up with a suitable measurement rig for all this now. This morning I was considering the use of either one of my 5,55 MHz OCXOs or the 5,55 MHz out of the TS-105A rubidium (BNC on the back) to set up a DDMTD system with a bunch of channels. I start to need it for real now... 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] seeking a time/clock software architecture
On 9/24/11 1:58 AM, Magnus Danielson wrote: It would be interesting to see what a combination of mutual synchronisation within a constellation and central synchronisation would yield. Your constellation would maintain contact with each other and pull eachother to some form of average time (according to arbitrary time-scale) and then use the earth link to provide long term corrections. A good mutual synchronisation strategy would allow the constellation to shrink and grow without falling completely appart. If you provide ranging mechanisms within the constellation path delays can naturally be compensated out of time. Precisely so. I figure the whole synchronization/syntonization of an ensemble of clocks of varying quality with aperiod updates has probably been addressed in the literature in some way. I would expect that a fancy implementation might return different uncertainties for different times in the future (e.g. I might say that I can schedule something with an accuracy of 1 millisecond in the next 10 minutes, but only within 30 milliseconds when it's 24 hours away) This is true, but if you need higher certainty at a particular time you can schedule a synchronisation event or two where uncertainties can be reduced. If you have the Kalman state and state-vector, you can run the predictor into the future. That is what I was thinking. ___ 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] Fluke 207 vlf rcvr schematic please
Hello to the group I wonder if anyone might have the fluke 207 vlf manual. I am actually looking for the phase shifter board. I think it actually uses a regenerative divider from what I can tell and suspect the issues I see are at that point. Slightly off frequency 100hz. Which is actually pretty large. Thanks in advance Paul WB8TSL ___ 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] HP 10811 Response I Replies
Does your Mode B 10811 use a different xtral or same xtral, different frequency? What does Mode B do better, ... and worse? Why was it not used in the 10811? When trouble shooting a freq stability problem, usually the more data the better. What can really help to narrow down the cause or see the cause/effect, is to study a High Speed (100+ sps), High Resolution (1e-12) plot of the frequency change with time. That way one can see if the freq change is instantaneous or happens in steps, is the change monotonic, if there is a time constant to the freq change what is the TC's value and shape, is the freq change in fixed values or random noisy steps and now and if the freq returns to the original value. With a good freq plot, the source of the problem can often be narrow down to a single possible source. And the best tool that I know of for making that kind of plot is a TPLL-2.0 tester. Here is a freq plot that has nothing to do with the existing problem, It is just an example where a TPLL-1.0 freq plot is useful in identifying the source of some noise. http://www.febo.com/pipermail/time-nuts/attachments/20100615/e4c25279/attachment-0001.gif and another example showing a plot of purposely induced Noise that only a few instruments could even measure: http://www.thegleam.com/ke5fx/tpll/disturb_zoom.gif ws ** WarrenS wrote: I have to wonder if the unit being tested had its high impedance oven control points lifted off the PCB board and on Teflon standoffs like the production units? ws It was a production unit, no modifications whatsoever. The oven change is an interesting theory; I never thought of that. I have a mode B 10811 on hand that I could use to test that theory. Rick Karlquist N6RK ___ 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] HP 10811 Response I Replies
WarrenS wrote: Does your Mode B 10811 use a different xtral or same xtral, different frequency? What does Mode B do better, ... and worse? Why was it not used in the 10811? Mode B is the same crystal on a different frequency (about 10.95 MHz). It does not have a turnover and the tempco is much higher than mode C. It makes a very sensitive thermometer and is therefore useful for evaluating the oven. The reason is not used in a production 10811 is obviously that for timebase use, you definitely don't want a high tempco. Rick ___ 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] Fast than light neutrino
On Fri, Sep 23, 2011 at 10:38 PM, Bill Dailey docdai...@gmail.com wrote: The article is actually pretty fascinating regarding how it was all done. Light can't go through rock (very far), neither can most other particles (some farther than others). Neutrinos can pass through earth and the sun unimpeded. It is neat apparently they set up a fiber optic link to test the timing between the 2 locations (modeled the correct Length). Not quite. We used a traditional common view time transfer setup, using two Septentrio PolaRx2e receivers and two CS4000 Cesium clocks. Then the signals had to be sent from the GPS receiver locations to the extraction at CERN and to the cavern in Opera, and we did have to take care of fiber delays. More details here: http://dl.dropbox.com/u/13409775/cern-cal.pdf And for reference, the general paper here: http://arxiv.org/abs/1109.4897 Cheers, Javier ___ 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] seeking a time/clock software architecture
On 24/09/11 15:12, Jim Lux wrote: On 9/24/11 1:58 AM, Magnus Danielson wrote: It would be interesting to see what a combination of mutual synchronisation within a constellation and central synchronisation would yield. Your constellation would maintain contact with each other and pull eachother to some form of average time (according to arbitrary time-scale) and then use the earth link to provide long term corrections. A good mutual synchronisation strategy would allow the constellation to shrink and grow without falling completely appart. If you provide ranging mechanisms within the constellation path delays can naturally be compensated out of time. Precisely so. I figure the whole synchronization/syntonization of an ensemble of clocks of varying quality with aperiod updates has probably been addressed in the literature in some way. It has. I can dig up some references for you. The trivial essentially pulls the clocks towards each other. The more complex will include weighing. This problem has been beaten to death. NIST has made a line of publications on their A1 atomic scale and algorithms for it, including code actually. Mutual synchronisation has also been investigated in telecom situations. Essentially, if two clocks steer against each other they will lock half-wise. Common mode changes will still affect them but diffrential mode changes (including noise) will become somewhat reduced. I would expect that a fancy implementation might return different uncertainties for different times in the future (e.g. I might say that I can schedule something with an accuracy of 1 millisecond in the next 10 minutes, but only within 30 milliseconds when it's 24 hours away) This is true, but if you need higher certainty at a particular time you can schedule a synchronisation event or two where uncertainties can be reduced. If you have the Kalman state and state-vector, you can run the predictor into the future. That is what I was thinking. That would be fairly trivial. We should discuss filter models then. 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] Fast than light neutrino
On 24/09/11 18:15, Javier Serrano wrote: On Fri, Sep 23, 2011 at 10:38 PM, Bill Daileydocdai...@gmail.com wrote: The article is actually pretty fascinating regarding how it was all done. Light can't go through rock (very far), neither can most other particles (some farther than others). Neutrinos can pass through earth and the sun unimpeded. It is neat apparently they set up a fiber optic link to test the timing between the 2 locations (modeled the correct Length). Not quite. We used a traditional common view time transfer setup, using two Septentrio PolaRx2e receivers and two CS4000 Cesium clocks. Then the signals had to be sent from the GPS receiver locations to the extraction at CERN and to the cavern in Opera, and we did have to take care of fiber delays. More details here: http://dl.dropbox.com/u/13409775/cern-cal.pdf And for reference, the general paper here: http://arxiv.org/abs/1109.4897 I was about to ask for the specific papers of time calibrations, even if the overview presentation indicates that the verification steps I expect to be there have been done. Also the path calibrations needs to be described more in detail than in the paper. First thought was that someone forgot to compensate for GPS antenna cable delays. Do you have direct fiber between the locations? 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] Fluke 207 vlf rcvr schematic please
On 9/24/2011 9:39 AM, paul swed wrote: Hello to the group I wonder if anyone might have the fluke 207 vlf manual. I am actually looking for the phase shifter board. I think it actually uses a regenerative divider from what I can tell and suspect the issues I see are at that point. Slightly off frequency 100hz. Which is actually pretty large. Thanks in advance Paul WB8TSL ___ 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. Paul I have a fluke 207 and manual. I will look for it tomorrow. Getting it scanned might be a problem? Will let you know. Don wa9ylp ___ 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] 60 Hz timelapse
I finally built a timelapse movie of the 60 Hz clock + webcam experiment. It covers about a week, but there may be a gap or three. It's a 20 MB file (tested with VLC and mplayer). http://n5tnl.com/tec/timelapse_clock.mov I need to improve the lighting to eliminate the horrible shadow around the second hand, switch to LED lighting, add some delay to catch the radio clock at :00, and maybe overlay the cycle error graph. -- newell N5TNL ___ 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] Fluke 207 vlf rcvr schematic please
On 9/24/2011 9:39 AM, paul swed wrote: Hello to the group I wonder if anyone might have the fluke 207 vlf manual. I am actually looking for the phase shifter board. I think it actually uses a regenerative divider from what I can tell and suspect the issues I see are at that point. Slightly off frequency 100hz. Which is actually pretty large. Thanks in advance Paul WB8TSL ___ Paul I have a fluke 207 and manual. I will look for it tomorrow. Getting it scanned might be a problem? Will let you know. Don wa9ylp If you're in a hurry, you can buy the Fluke 207 manual from the following online vendors: https://www.ridgeequipment.com/store/manuals/search.php?query=Fluke+207 http://www.manualsplus.com Cheers David dgminala at mediacombb dot net ___ 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] Fluke 207 vlf rcvr schematic please
Everyone I want to thank you for your help. I was sent the snippet I needed and the 207 lives. Copying wwvb right now. Needs a bit more tlc like getting the phase accumulator working correctly. Annoying as they actually are. But the rcvr looks pretty hot. The chart recorders running now and making plots. Thanks again. Paul WB8TSL On Sat, Sep 24, 2011 at 10:13 PM, Dave M dgmin...@mediacombb.net wrote: On 9/24/2011 9:39 AM, paul swed wrote: Hello to the group I wonder if anyone might have the fluke 207 vlf manual. I am actually looking for the phase shifter board. I think it actually uses a regenerative divider from what I can tell and suspect the issues I see are at that point. Slightly off frequency 100hz. Which is actually pretty large. Thanks in advance Paul WB8TSL __**_ Paul I have a fluke 207 and manual. I will look for it tomorrow. Getting it scanned might be a problem? Will let you know. Don wa9ylp If you're in a hurry, you can buy the Fluke 207 manual from the following online vendors: https://www.ridgeequipment.**com/store/manuals/search.php?** query=Fluke+207https://www.ridgeequipment.com/store/manuals/search.php?query=Fluke+207 http://www.manualsplus.com Cheers David dgminala at mediacombb dot net __**_ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/** mailman/listinfo/time-nutshttps://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.
