Re: [time-nuts] HP 10811 Response I Replies
On 23/09/11 05:40, Richard (Rick) Karlquist wrote: On 9/22/2011 5:17 PM, ws at Yahoo wrote: Within minutes the frequency changed more than the spec For humidity to get thru something like that it takes weeks or more it does it at all. That fast of reaction, Sure sounds like some other effect like blowing a little air on the case or loading the osc output with water in the output cable etc, etc. I think it is safe to say the effect was not due to water inside, unless there was a hole. ws The effect we saw was like parts in 10^8 of something. Way too big to be related to output loading or air on the case. In any event, the air blowing on the case was constant during the test. We saw that when we didn't even try to seal the 10811 and also when we tried to seal it. Blowing on the case? Did you consider the increased cooling that higher humidity provides? 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
Interesting... one co-author, at least, is member of this list :) Regards, Javier El 23/09/2011 06:51, Jim Palfreyman escribió: For those of you who may be interested, here's the paper. http://arxiv.org/ftp/arxiv/papers/1109/1109.4897.pdf ___ 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] Fast than light neutrino
Well that's good Javier - at least we know the timing's good. Who? On Friday, 23 September 2011, Javier Herrero jherr...@hvsistemas.es wrote: Interesting... one co-author, at least, is member of this list :) Regards, Javier El 23/09/2011 06:51, Jim Palfreyman escribió: For those of you who may be interested, here's the paper. http://arxiv.org/ftp/arxiv/papers/1109/1109.4897.pdf http://arxiv.org/ftp/arxiv/papers/1109/1109.4897.pdf ___ 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] Fast than light neutrino
I was just wondering, what real use is the kind of accuracy most of the list members strive for, and there is the answer. On 9/23/2011 7:09 AM, Jim Palfreyman wrote: Well that's good Javier - at least we know the timing's good. Who? On Friday, 23 September 2011, Javier Herrerojherr...@hvsistemas.es wrote: Interesting... one co-author, at least, is member of this list :) Regards, Javier El 23/09/2011 06:51, Jim Palfreyman escribió: For those of you who may be interested, here's the paper. http://arxiv.org/ftp/arxiv/papers/1109/1109.4897.pdf http://arxiv.org/ftp/arxiv/papers/1109/1109.4897.pdf ___ 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. - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1410 / Virus Database: 1520/3913 - Release Date: 09/22/11 ___ 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
The other Javier in the list, Javier Serrano from CERN El 23/09/2011 13:09, Jim Palfreyman escribió: Well that's good Javier - at least we know the timing's good. Who? On Friday, 23 September 2011, Javier Herrerojherr...@hvsistemas.es wrote: Interesting... one co-author, at least, is member of this list :) Regards, Javier El 23/09/2011 06:51, Jim Palfreyman escribió: For those of you who may be interested, here's the paper. http://arxiv.org/ftp/arxiv/papers/1109/1109.4897.pdf http://arxiv.org/ftp/arxiv/papers/1109/1109.4897.pdf ___ 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. ___ 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
In message 4e7c6bb7.1020...@hvsistemas.es, Javier Herrero writes: BTW: Just something to think about: There are three quantities involved here, and most of the coverage and quite a lot of physicists overlook that: 1. Speed of neutrinos 2. Speed of photons 3. Constant 'c' From relativity. Until now the assumption have been that 2 = 3, but this is only an assumption, based on the fact that we had no measurements that said otherwise. If 1 3, as most press-coverage seems to posit, because they forgot the above is an assumption, then both the standardmodel and relativity is in trouble. If 3 = 1 2, then only the standard model is in trouble, relativity unaffected. -- 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] Fast than light neutrino
nr 2 = nr 3 is an assumption? I was thinking that it is a definition :) Regards, Javier El 23/09/2011 13:33, Poul-Henning Kamp escribió: In message4e7c6bb7.1020...@hvsistemas.es, Javier Herrero writes: BTW: Just something to think about: There are three quantities involved here, and most of the coverage and quite a lot of physicists overlook that: 1. Speed of neutrinos 2. Speed of photons 3. Constant 'c' From relativity. Until now the assumption have been that 2 = 3, but this is only an assumption, based on the fact that we had no measurements that said otherwise. If 1 3, as most press-coverage seems to posit, because they forgot the above is an assumption, then both the standardmodel and relativity is in trouble. If 3= 1 2, then only the standard model is in trouble, relativity unaffected. ___ 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
In message 4e7c7556.6090...@hvsistemas.es, Javier Herrero writes: nr 2 = nr 3 is an assumption? I was thinking that it is a definition :) No, not really. Maxwells equations talk about electromagnetic waves in empty space under the assumption that they have zero rest-mass, but we have never proved those waves to be photons, for instance by proving photons to have zero rest-mass. We have never been able to actually measure a rest-mass for the photon either, at best we have experimentally constrained it to be less than x * 10^-16 eV. Based on that everybody _assume_ that it is mathematically zero, and photons therefore identical to Maxwells EM-waves. But we do not actually have a proof of that, it is only an assumption. The neutrino was in a quite similar position until a few years go: My entire generation grew up with neutrinoes being mass-less just like photons and then we suddenly found out it probably wasn't mass-less. Mind you: My money is on experimental mistake, quite likely application of insufficient general relativity. But if the experiment holds up to scrutiny and is replicated, my money will not be on overrelativistic neutrinos, but on photons having rest-mass, because that would leave the theory of relativity standing and confine the damage to only the already somewhat troubled standard-model. -- 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] Fast than light neutrino
Quoted There are three quantities involved here, and most of the coverage and quite a lot of physicists overlook that: 1. Speed of neutrinos 2. Speed of photons 3. Constant 'c' From relativity. Until now the assumption have been that 2 = 3, but this is only an assumption, based on the fact that we had no measurements that said otherwise. If 1 3, as most press-coverage seems to posit, because they forgot the above is an assumption, then both the standardmodel and relativity is in trouble. If 3 = 1 2, then only the standard model is in trouble, relativity unaffected. -- This doesn't make sense. The speed of photons in a vacuum is well established to be c (speed of light). That is as close to scientific fact as there is. Neutrinos are well established to have a speed close to c. The problem is this is the second instance that i am aware of where they apparently arrive at a detector in an amount of time consistent with an apparent speed of slightly greater than c. The complicating factor here is they aren't really sure if neutrinos actually have mass. Therefore they may not need adhere to the mass portion of relativity and hence may be more like photons. They won't put forth ANY suppositions until they are sure they haven't made a mistake. ___ 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 - internal connections question
Well one point to add to all this. Some time-nuts are hams, some are not. You comment Used in hamshack suggests you are a ham. RF interference from your radios will be a problem. It can modulate the EFC and upset things. Granted it will normal up after a while. So do consider a metal box and do use shielded cables. Ground only one end of shield. Might want to consider beads on the rs 232 lines etc. Simply use good amateur radio design/construction techniques. By the way I have a VE2ZAZ system works quite well and for Amateur use is great. Regards Paul WB8TSL On Thu, Sep 22, 2011 at 5:25 AM, Attila Kinali att...@kinali.ch wrote: On Wed, 21 Sep 2011 18:36:43 -0500 Chris Howard ch...@elfpen.com wrote: Thanks! Would it do any good to have the control board, GPS, or anything else within its own shielded box? I'd put everything into one big metal box, but seperate the different submodules, probably shield them from each other. Please remember, that you are doing analog design on the EFC/OCXO side. This means that you have to have low noise levels where you handle these signals. This in turn means that you want to keep all digital electronics as far away from it as possible. Also think about a proper grounding scheme, as you connect the various submodules together, otherwise ground loops will introduce additional, hard to contain (and quite potent) noise. Attila Kinali -- WYSIWYG is not a solution, it is the problem, and until we get around to realizing that very few of us are competent to design fonts, styles, or layout (14-year-old girls who dot their i's with hearts excepted, of course, the exception that nails down the lid on the coffin), we're going to have to live with that crap. -- Stephen J. Turnbull in a discussion about word processors ___ 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] uses of time-nuttery Re: Fast than light neutrino
On 9/23/11 4:15 AM, Peter Gottlieb wrote: I was just wondering, what real use is the kind of accuracy most of the list members strive for, and there is the answer. I can give you some other day to day practical uses of what gets discussed on this list: - radio science in deep space exploration. At JPL we accurately measure the round trip propagation delay from earth to spacecraft and back, and from that, calculate radial velocity (accuracy of around 1 mm/s at Jupiter or Saturn). That lets you do precision orbit determination, which in turn, lets you infer the internal mass distribution of what you're orbiting around. Typical specs for gravity science measurement on Juno, launched a couple months ago, are ADEV1E-15 with tau of 1000 seconds. - testing of the equipment used in radio science (yep.. Sometimes I think we spend more time proving the box works than building the box) - GRACE and now, GRAIL, use precise timing to measure the distance between two orbiting satellites that fly in formation a short distance apart. The changes in distance allow even more information about the gravitational field. For GRAIL, the link between the spacecraft is at Ka-band, but there's also an X-band beacon back to earth from both spacecraft. All of it is driven by a pair of really high performance OCXOs in vacuum bottles. - Mars Science Laboratory (Curiosity) Landing Radar. This is a multi beam doppler Ka band radar used on the SkyCrane. We had to build a system to generate simulated returns for all 6 beams while executing a simulated landing profile (subsequently, modified to be machine in the loop). The pulses have to be timed to about 0.5 nanosecond, and are anywhere from 4 ns to several microseconds long. Just as for the radio science thing, testing this beast was a challenge. - Next May (launch gods willing), a software defined radio with a loadable GPS waveform will go up to ISS. It will be the first reprogrammable receiver in space to handle the L5 signal. That same radio will also be used to do time and frequency transfer experiments (funding gods willing) to basically build a GPSDO in space. That will demonstrate that it's possible to transfer high precision time/frequency from earth, to an orbiter, to a lander, where you don't have 100% visibility. - NASA just funded a $100M project to fly a trapped Mercury Ion atomic clock and to measure its performance in space (using an advanced state of the art GPS receiver). They may also do time transfer experiments. So, there's a huge number of practical applications of the topics of this list. Catching hyperluminal neutrinos is just another. ___ 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] seeking a time/clock software architecture
Here's topic that I hope will provoke some useful discussion (and maybe the problem has already been solved?) I'm working with a software defined radio (SDR) for spacecraft which conforms to a new architecture standard for such radios ( referred to as STRS) (and I'm also one of the authors of the standard, so I really do have to eat my own dogfood) The standard currently defines a time API with some simple features to set and get time, nominally defined in terms of a transformation from some base clock (i.e. there's a default transformation of the form reported time = k1 * raw clock + k2). In the current standard, time is carried around as 32 bit seconds + 32 bit nanoseconds (which is, at least familiar to most people, being similar to POSIX seconds + microseconds from gettimeofday()) A radio might have multiple oscillators/clocks (clock defined as oscillator and counter), with different stabilities and rates. There is typically hardware that allows taking a snapshot of one raw clock based on another (i.e. I could have a 66MHz clock divided by 66E6 that latches another 49 MHz clock). In some cases, the base oscillator of the clock or trigger event is a received radio signal (GPS 1pps or PN code epochs are one example. Internally derived carrier frequency offset of a received signal is another) In the following discussion, I've used raw clock to mean base oscillator +counter, and time to mean a number in some desired units that can be derived from a raw clock. Most of what I discuss below has been covered one way or another in the literature and on this list, but now I'm faced with putting it all into some form of recommended practice or defining an API. To the maximum extent possible, I'd love to adopt what people currently use (or what people WISH would be used). Here's what I'm looking for help, discussion, comments on. 1) I see the basic architectural model as having a base oscillator/counter (raw clock) followed by some transformation which gives you a time. Setting the time is really defining some parameter of that transformation. What sort of standards are there for defining the form of that transformation? Obviously, there's the straightforward polynomial, perhaps with some scaling factors to make the coefficients better conditioned (e.g. if I want seconds out, and I've got 66MHz ticks in, there's all those 66E6 factors running around). What other scheme might there be? 2) There is usually a need to have the output time synchronized to some external source of time and that external source may be of poorer quality than your internal oscillators. For example, I may have an atomic standard in my box, but I need to report time in terms of what I'm given by the spacecraft, which has a non-temperature compensated crystal that cyclically varies by 100ppm over a 100 minute time span. So my transformation needs to be adjusted all the time in response to (presumably) a series of at the tone, the time is hacks from my host. (imagine this as keeping the display on your cesium clock synchronized to the wind up alarm clock next to your bed) Is there a standard description of how to do this, or the framework within which it should be done? This is sort of like NTP (or PTP), but they tend to assume that the source of time hacks is better than the local clock. 3) For most applications, the output time needs to be continuous and, usually, monotonic, even in the face of rate and offset adjustments. What standard schemes are there for transitioning from one set of transformation parameters to another? In my current implementation, we have defined the transformation as a polynomial, and a transition is defined as a time (in the future) and a new set of polynomial coefficients. When you ask for time, if it's before the transition, you use the old set and if it's after, you use the new set. If you pick the coefficients and time correctly, you can get a seamless change (continuous to whatever order you want, as long as you have enough terms in the polynomial... sort of like cubic splines). Is some sort of piecewise linear/cubic spline scheme what we really want to do? Or is there a better way? 4) The operation of synchronizing a second time to a first time can be described as adjusting the transformation parameters of a second clock+transformation so that the output matches the output of a first clock+transformation. (no reason why the two clocks couldn't happen to be the same underlying clock, in which case it's trivially transformation2=transformation1) Is this a good definition? 5) What's a good way to report the uncertainty or error of a time (or the underlying raw clock or base oscillator)? I'm looking for an implementation or basis of an API here. It should accommodate some way to deal with statistical properties. At the simplest, one could report a instantaneous standard deviation/uncertainty or a bounding
Re: [time-nuts] seeking a time/clock software architecture
In message 4e7c9fa6.1000...@earthlink.net, Jim Lux writes: The standard currently defines a time API with some simple features to set and get time, nominally defined in terms of a transformation from some base clock (i.e. there's a default transformation of the form reported time = k1 * raw clock + k2). In the current standard, time is carried around as 32 bit seconds + 32 bit nanoseconds (which is, at least familiar to most people, being similar to POSIX seconds + microseconds from gettimeofday()) Take a look at FreeBSD's timecounters, what you are asking for sounds pretty much like what I did 15 years: http://phk.freebsd.dk/pubs/timecounter.pdf I used a 32.64 internal format, to avoid rounding errors, particularly in your k1 term. I'm headed for the US east-coast the next week, if we get anywhere near each other, I'd be happy to talk, shoot me an email: p...@freebsd.org -- 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] HP 10811 Response I Replies
I have made plots of the effects of everything I can find that effects the freq of a HP10811. Most things are much slower than minutes, more like an hour time constant, such as anything effecting the outside case's temperature OR the effect is much faster than minutes, things such as voltage and load changes. The only thing that I've seen that responds to instantaneous changes within minutes is the oven loop. If one assumed Rick's data is correct, then one likely cause of what was happing (not why it was happening) is that the oven set point temperature was changed. That is the ONLY thing I've seen that can cause that sort of freq change over that kind of time period. It does not take much, a degree or so change in the oven's set point could do it. If I saw a real plot of freq change with time, I could be more sure of the cause. But even if the exact reason is not known, This string does show, If you want the best from your 10811 then it is NOT a good idea to heat it up in an oven to near its limits and then dump in water. 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? If not just blowing with your mouth on theses sensitive points could cause this type of freq change. ws ** Within minutes the frequency changed more than the spec Rick For humidity to get thru something like that it takes weeks or more IF it does it at all. That fast of reaction, Sure sounds like some other effect like blowing a little air on the case or loading the osc output with water in the output cable etc, etc. I think it is safe to say the effect was not due to water inside, unless there was a hole. ws *** The effect we saw was like parts in 10^8 of something. Way too big to be related to output loading or air on the case. In any event, the air blowing on the case was constant during the test. We saw that when we didn't even try to seal the 10811 and also when we tried to seal it. Richard (Rick) Karlquist ** Blowing on the case? Did you consider the increased cooling that higher humidity provides? 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] Any thoughts on best rubidium?
I'm missing the PRS10 in this list. I have been wanting to buy one for a long time, but didn't because it has been a solution to no problem for all this time. But now I have bought a spectrum analyzer, a Rohde Schwarz FSIQ3, with tracking generator and lots of options. It would be nice to have a PRS10 as it's external reference. I already bought a Resolution-T timing GPS receiver to discipline it over the long term. But PRS10 standards are quite rare lately: I think I've seen only on eBay in the past year and prices have doubled since the time they showed up in numbers. And I'm starting to doubt if it will be worth the effort. My instrument has the B4 option, for low phase noise. The specifications of the internal reference are pretty good: Aging per day 1x10−9 Aging per year 2x10−7 Temperature drift (0°C to +50°C)8x10−8 Total error (per year) 2.5 x 10−7 No phase noise specifications on the internal reference are specified, but a plot for the instrument overall is (http://www.livingston-products.com/products/pdf/130413_1_en.pdf). I'm starting to wonder if connecting PRS10 as an external reference would actually improve overall accuracy, because it may introduce extra phase noise. And even if I've finally got one: How to tell it's an improvement without a reference? Any thoughts please? * EFRATOM 10MHZ LPRO-101 * FE-5680A * SLCR-101 * Efratom 10MHZ Rubidium FREQUENCY Standard FRS-C Is there any reason to chose one over another for the application I have? ___ 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] Faster than light neutrino
I checked my neutrino detector yesterday and detected some of those faster than light neutrions tomorrow ;-) ___ 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] Faster than light neutrino
I read this in the newspaper today. The author of course did not understand the science. If this result is confirmed it really changes things. but I'm more willing to bet they find some hidden error in the experiment. I hope they don't Physics needs to be shaken up. Now I wish I had taken classes like differential geometry and topology. My guess if this result holds is that neutrinos are taking a short cut and maybe don't see the curvature of space and take straight path, not noticing that there is gravity. On Fri, Sep 23, 2011 at 9:27 AM, Mark Sims hol...@hotmail.com wrote: I checked my neutrino detector yesterday and detected some of those faster than light neutrions tomorrow ;-) ___ 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] Faster than light neutrino
El 23/09/2011 18:40, Chris Albertson escribió: If this result is confirmed it really changes things. but I'm more willing to bet they find some hidden error in the experiment. I hope they don't Physics needs to be shaken up. Now I wish I had taken classes like differential geometry and topology. My guess if this result holds is that neutrinos are taking a short cut and maybe don't see the curvature of space and take straight path, not noticing that there is gravity. That would *really *shake the physics (and the concept of universe) :) Regards, Javier -- Javier Herrero Chief Technology Officer EMAIL: jherr...@hvsistemas.com HV Sistemas S.L. PHONE: +34 949 336 806 Los Charcones, 17 FAX: +34 949 336 792 19170 El Casar - Guadalajara - Spain WEB: http://www.hvsistemas.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] Any thoughts on best rubidium?
I think you are right, often the internal, free running osc will give you better results. You can use the GPS or rubidium to calibrate the internal one just before you need some more accurate absolute frequency measurements on the SA. It will depend on what measurement you are making, and whether phase noise or frequency accuracy is more important. For day to day use, the external ref will work, except when perhaps you need to look at very close skirts, where maybe the internal alone can give you lower noise. In most cases, you don't really need either (checking a filter, EMI, radio output, etc.) but a lot of thing in this list is because we can, not because we need. :-) Get a real clean, low phase noise 3rd signal, measure it using the internal and external osc, look at the skirts. They might even be the same, if the limit is elsewhere in the SA signal chain. Jose -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Robert Deliën Sent: Friday, September 23, 2011 9:25 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Any thoughts on best rubidium? I'm missing the PRS10 in this list. I have been wanting to buy one for a long time, but didn't because it has been a solution to no problem for all this time. But now I have bought a spectrum analyzer, a Rohde Schwarz FSIQ3, with tracking generator and lots of options. It would be nice to have a PRS10 as it's external reference. I already bought a Resolution-T timing GPS receiver to discipline it over the long term. But PRS10 standards are quite rare lately: I think I've seen only on eBay in the past year and prices have doubled since the time they showed up in numbers. And I'm starting to doubt if it will be worth the effort. My instrument has the B4 option, for low phase noise. The specifications of the internal reference are pretty good: Aging per day 1x10−9 Aging per year 2x10−7 Temperature drift (0°C to +50°C)8x10−8 Total error (per year) 2.5 x 10−7 No phase noise specifications on the internal reference are specified, but a plot for the instrument overall is (http://www.livingston-products.com/products/pdf/130413_1_en.pdf). I'm starting to wonder if connecting PRS10 as an external reference would actually improve overall accuracy, because it may introduce extra phase noise. And even if I've finally got one: How to tell it's an improvement without a reference? Any thoughts please? * EFRATOM 10MHZ LPRO-101 * FE-5680A * SLCR-101 * Efratom 10MHZ Rubidium FREQUENCY Standard FRS-C Is there any reason to chose one over another for the application I have? ___ 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] seeking a time/clock software architecture
On 9/23/11 8:35 AM, Poul-Henning Kamp wrote: Take a look at FreeBSD's timecounters, what you are asking for sounds pretty much like what I did 15 years: http://phk.freebsd.dk/pubs/timecounter.pdf I used a 32.64 internal format, to avoid rounding errors, particularly in your k1 term. I'm headed for the US east-coast the next week, if we get anywhere near each other, I'd be happy to talk, shoot me an email: p...@freebsd.org AH yes... I forgot to mention that phk's timecounter stuff has already been incorporated in our implementation (thanks Poul-Henning!) (and we truncate to match the API requirement of uint32 for the nanoseconds) For what it's worth, my implementation is using RTEMS as the base OS, but at this stage, I'm trying to define an architecture standard for others to use, with selected implementation standards as well (e.g. API or message formats) It's all the more complex stuff.. how does one represent a more sophisticated transformation? How does one represent changes in the transformation (either in a log file, or in a schedule for the future) so that one can reconstruct a time in the past, for instance. There's plenty of standards for how to represent time (in the space biz, we use CCSDS unsegmented time a lot), but the more abstract time management is sort of left up in the air. For instance, there's a standard/recommendation that says something along the lines of consider the time of the first bit in the message as the tone in the at the tone, the time is concept. And plenty of descriptions of various time scales (TAI, UTC, UT1, etc.) What I'd like to do is take the next step beyond what you promulgated with a representation of time and the conversion between count and time with a linear equation. I'd like to propose a standard description of a higher order model of time and the transformation between raw clock and time (in some agreed upon time scale). And I'd like to describe an architecture for manipulating this. e.g. when you set the time, at a simple level it means measuring the difference between what you have now and what you want and adjusting your transformation to match. ___ 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
In message 4e7cbca1.9010...@earthlink.net, Jim Lux writes: What I'd like to do is take the next step beyond what you promulgated with a representation of time and the conversion between count and time with a linear equation. I'd like to propose a standard description of a higher order model of time and the transformation between raw clock and time (in some agreed upon time scale). Ouch... That's one tough nut to generalize... Are you even sure it makes sense to generalize it ? 3. The only thing worse than generalizing from one example is generalizing from no examples at all. (From Gettys rules for X11) -- 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] Any thoughts on best rubidium?
On 9/23/11 10:04 AM, Jose Camara wrote: I think you are right, often the internal, free running osc will give you better results. You can use the GPS or rubidium to calibrate the internal one just before you need some more accurate absolute frequency measurements on the SA. It will depend on what measurement you are making, and whether phase noise or frequency accuracy is more important. For day to day use, the external ref will work, except when perhaps you need to look at very close skirts, where maybe the internal alone can give you lower noise. In most cases, you don't really need either (checking a filter, EMI, radio output, etc.) but a lot of thing in this list is because we can, not because we need. :-) Get a real clean, low phase noise 3rd signal, measure it using the internal and external osc, look at the skirts. They might even be the same, if the limit is elsewhere in the SA signal chain. One other thing is that some spectrum analyzers aren't really designed for low noise performance. Since the noise floor is often pretty high, the design of the whole RF chain (e.g. spur levels and such) might have assumed that lots of things would be hidden in the grass. If the analyzer is of the recent bring a band of RF down to an IF, sample and FFT it for fine resolution architecture, such things as the number of bits in the ADC and the cleanliness of the sampling clock might have been chosen based upon doing 1024 point transforms being displayed with 100dB dynamic range (10dB/div and 10 divisions). (not to mention the spectrum analyzer actually generating spurious signals. I ran across that one last year and thought I had an interference source, but, no, went back and checked the spec sheet and it said spurious are -80dBc, and sure enough, there it was at -82 dBc. And stories about the first LO coming back out through the input are legion.) ___ 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/23/11 10:13 AM, Poul-Henning Kamp wrote: In message4e7cbca1.9010...@earthlink.net, Jim Lux writes: What I'd like to do is take the next step beyond what you promulgated with a representation of time and the conversion between count and time with a linear equation. I'd like to propose a standard description of a higher order model of time and the transformation between raw clock and time (in some agreed upon time scale). Ouch... That's one tough nut to generalize... Are you even sure it makes sense to generalize it ? 3. The only thing worse than generalizing from one example is generalizing from no examples at all. (From Gettys rules for X11) Well, that *is* why I asked the assembled multitude... you might be right, but I'd hate to say it's not worth it and then have someone pop up and say but why don't we use XYZ standard And, if we don't want to standardize, it's always nice to explicitly say we are not specifying this deliberately and ANY implementation conforms to the standard (which means for interoperability, you can't assume that the other side is doing it a particular way, so you'd have to explicitly define an interface description). One aspect of why at least a standardized second order model would be nice is that it allows you to make smooth non-discontinuous changes in rate. the transformation from count to time would be discontinuous in rate of rate (i.e. it would go from zero, to something, to zero), but continuous in terms of rate. Even just promulgating a standard way of changing the transformation might be useful. For instance, That it occurs at a time defined in terms of the old transformation,and at that time, we use the new transformation. (this is like the daylight saving time sort of thing. At 2AM old time, it is instantly 1 AM new time) ___ 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/23/11 10:25 AM, Jim Lux wrote: One aspect of why at least a standardized second order model would be nice is that it allows you to make smooth non-discontinuous changes in rate. the transformation from count to time would be discontinuous in rate of rate (i.e. it would go from zero, to something, to zero), but continuous in terms of rate. The other thing that crops up all the time in the spacecraft world is that you're always taking into account the light time propagation delay between two ends of a link, which is varying fairly quickly. Since the problem of doing something like I want my signal to arrive at a particular time over there crops up a lot, as does the general I want to measure my oscillator against the one on that other spacecraft, something that provides a consistent computational framework (as opposed to specifically designed for the application) might be useful. For instance, GPS receivers have to do this calculation already, so the whole range/range rate estimation process is built in, in order to do the nav solution. Each implementation probably does it a different way, but at least the observables are reported in a standard way as RINEX (tailored to the needs of GPS, e.g carrier phase is measured in cycles) ___ 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
I'd like to propose a standard description of a higher order model of time and the transformation between raw clock and time (in some agreed upon time scale). A good time transform will let you transform between time scales at points in the far future and far past. For example what was the date on the Chinese calendar for Jan 11th in 1,500BC My point is that you may want to apply your transform on times not near the present. Two timescales can have different phase and rate. At any instant in time two real numbers are enough to transform the time from one system to another. A linear equation is enough but the rate might change over time. I think this means a second order polynomial. Next I think you must always define the range where the polynomial is valid. For example adding a leap second to one time scale invalidates the polynomial and makes you use another one So a general purpose API would need to look at the epoch to be transformed then select the correct polynomial. This amounts really to a table look up. But you need that to handle things like conversion from UTC to a computer's internal time. A computer's time can depend in silly things like the air conditioner in the room cycling 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] Any thoughts on best rubidium?
Hi Jim: Do you know how the HP/Agilent 4395A stacks up as a SA? I really like the true RMS power detection and the 1 Hz RBW (not video). http://www.home.agilent.com/agilent/product.jspx?id=100864:epsg:propageMode=OVpid=100864:epsg:prolc=engct=PRODUCTcc=USpselect=SR.PM-Search%20Results.Overview Have Fun, Brooke Clarke http://www.PRC68.com http://www.End2PartyGovernment.com/ Jim Lux wrote: On 9/23/11 10:04 AM, Jose Camara wrote: I think you are right, often the internal, free running osc will give you better results. You can use the GPS or rubidium to calibrate the internal one just before you need some more accurate absolute frequency measurements on the SA. It will depend on what measurement you are making, and whether phase noise or frequency accuracy is more important. For day to day use, the external ref will work, except when perhaps you need to look at very close skirts, where maybe the internal alone can give you lower noise. In most cases, you don't really need either (checking a filter, EMI, radio output, etc.) but a lot of thing in this list is because we can, not because we need. :-) Get a real clean, low phase noise 3rd signal, measure it using the internal and external osc, look at the skirts. They might even be the same, if the limit is elsewhere in the SA signal chain. One other thing is that some spectrum analyzers aren't really designed for low noise performance. Since the noise floor is often pretty high, the design of the whole RF chain (e.g. spur levels and such) might have assumed that lots of things would be hidden in the grass. If the analyzer is of the recent bring a band of RF down to an IF, sample and FFT it for fine resolution architecture, such things as the number of bits in the ADC and the cleanliness of the sampling clock might have been chosen based upon doing 1024 point transforms being displayed with 100dB dynamic range (10dB/div and 10 divisions). (not to mention the spectrum analyzer actually generating spurious signals. I ran across that one last year and thought I had an interference source, but, no, went back and checked the spec sheet and it said spurious are -80dBc, and sure enough, there it was at -82 dBc. And stories about the first LO coming back out through the input are legion.) ___ 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] quartz long-term drift
Tom Thanks and indeed worthy of actual print On Wed, Sep 21, 2011 at 8:50 PM, Magnus Danielson mag...@rubidium.dyndns.org wrote: On 09/20/2011 06:55 PM, Tom Van Baak wrote: I ran across a wonderful paper containing long-term (5 years!) measurements of quartz frequency drift. A good read for those of you making measurements, wondering about drift, retrace, stability, etc. www.mti-milliren.com/**MTIPapers/Ext_Aging_Perf_**Results.pdfhttp://www.mti-milliren.com/MTIPapers/Ext_Aging_Perf_Results.pdf Look at this page: http://www.ieee-uffc.org/**frequency_control/teaching.**asp?vig=vigaginghttp://www.ieee-uffc.org/frequency_control/teaching.asp?vig=vigaging The underlying article in reference 17 is recommended reading. http://www.ieee-uffc.org/**frequency_control/teaching.**asp?name=aginghttp://www.ieee-uffc.org/frequency_control/teaching.asp?name=aging In general, this is not a bad place to start: http://www.ieee-uffc.org/**frequency_control/teaching.asphttp://www.ieee-uffc.org/frequency_control/teaching.asp I seem to recall long term measurements in the Ballato book, but I can dig it up. Cheers, Magnus __**_ 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.
Re: [time-nuts] Fast than light neutrino
Fun to guess. Time must be running backwards. Or maybe they have negative mass. If truly faster than C, SOMETHING nonsensical must be true. Indeed.. How would they know where to have been tomorrow? ___ 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] Faster than light neutrino
On Fri, Sep 23, 2011 at 9:48 AM, Javier Herrero jherr...@hvsistemas.es wrote: El 23/09/2011 18:40, Chris Albertson escribió: If this result is confirmed it really changes things. but I'm more willing to bet they find some hidden error in the experiment. I hope they don't Physics needs to be shaken up. Now I wish I had taken classes like differential geometry and topology. My guess if this result holds is that neutrinos are taking a short cut and maybe don't see the curvature of space and take straight path, not noticing that there is gravity. That would *really *shake the physics (and the concept of universe) :) A common proof technique in math is to assume X is true then show if it is then 1=0 or some other condition we know is wrong. So therefore X is not true. That is what I was getting at. Assume C is not a hard speed limit. Then what must be true? I'm sure something we currently believe to be not true is implied by this. 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] Fast than light neutrino
I'm old enough to not pay much attention to these 'scientific breakthroughs' announced across the sports or comics page. Remember cold fusion? Often a 'scientist' gets drunk and spills out nonsense to a reporter barely catching up with the spelling of the buzzwords, and suddenly the Earth isn't flat anymore... I put $20 on 3 = 1 2, same as Poul, without having read the article. jose -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Chris Albertson Sent: Friday, September 23, 2011 10:17 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Fast than light neutrino On Fri, Sep 23, 2011 at 5:44 AM, Bill Dailey docdai...@gmail.com wrote: The complicating factor here is they aren't really sure if neutrinos actually have mass. Therefore they may not need adhere to the mass portion of relativity and hence may be more like photons. They won't put forth ANY suppositions until they are sure they haven't made a mistake. I think we all want these neutrinos to be faster than C (not just faster then photons) because it would be fun to live through a revolution in physics.A simple mis-calculation would be so boring. If I had to bet I'd bet on the boring error that was missed by 100 co-authors. I'd be happy to loose my bet. Can we assume for a minute the result is correct and they really are literally faster than C.What does it mean to be faster than C at this large macroscopic scale of kilometers Fun to guess. Time must be running backwards. Or maybe they have negative mass. If truly faster than C, SOMETHING nonsensical must be true. Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Fast than light neutrino
Worse yet, top posters will reply at the bottom and vice-versa !!! :-) -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of David VanHorn Sent: Friday, September 23, 2011 11:14 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Fast than light neutrino Fun to guess. Time must be running backwards. Or maybe they have negative mass. If truly faster than C, SOMETHING nonsensical must be true. Indeed.. How would they know where to have been tomorrow? ___ 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] seeking a time/clock software architecture
On 9/23/11 10:50 AM, Chris Albertson wrote: I'd like to propose a standard description of a higher order model of time and the transformation between raw clock and time (in some agreed upon time scale). A good time transform will let you transform between time scales at points in the far future and far past. For example what was the date on the Chinese calendar for Jan 11th in 1,500BC My point is that you may want to apply your transform on times not near the present. 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. Two timescales can have different phase and rate. At any instant in time two real numbers are enough to transform the time from one system to another. A linear equation is enough but the rate might change over time. I think this means a second order polynomial. ALmost certainly, if you want rate to be continuous. Next I think you must always define the range where the polynomial is valid. For example adding a leap second to one time scale invalidates the polynomial and makes you use another one So, how would one define that range, I'm thinking that it has to be in terms of the output of the transformation (i.e. in the target timescale). So a general purpose API would need to look at the epoch to be transformed then select the correct polynomial. Exactly This amounts really to a table look up. But you need that to handle things like conversion from UTC to a computer's internal time. A computer's time can depend in silly things like the air conditioner in the room cycling Exactly.. or the slow and majestic movement of the heavenly bodies. For instance, things in low earth orbit have fluctuations in temperature every revolution (say, around 90-100 minutes) on top of roughly weekly cycle (depending on the inclination) on top of an annual cycle. One doesn't necessarily need to model such a thing directly, but whatever scheme there is should accommodate this kind of change smoothly. Actually, the really annoying one is where I have a good clock that's stable, but I need to keep adjusting time to match someone else's terrible clock. Most clock disciplining/time propagation models assume your bad clock is following a better clock. ___ 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] Any thoughts on best rubidium?
On 9/23/11 10:54 AM, Brooke Clarke wrote: Hi Jim: Do you know how the HP/Agilent 4395A stacks up as a SA? I really like the true RMS power detection and the 1 Hz RBW (not video). http://www.home.agilent.com/agilent/product.jspx?id=100864:epsg:propageMode=OVpid=100864:epsg:prolc=engct=PRODUCTcc=USpselect=SR.PM-Search%20Results.Overview Not off hand.. I'm usually working at microwave frequencies and haven't used that particular one. All of those spectrum analyzers with 1 Hz RBW are almost certainly doing some sort of FFT, and I assume the sample clocks are controlled such that you can hook up to some sort of external reference with 1E-9 kinds of stability. The question might be whether the actual clock performance has good enough phase noise at 1 Hz offset to make the 1 Hz RBW meaningful. A -100dBc/Hz @ 1 Hz offset would be mighty impressive, no? In fact, the specsheet shows of -95dBc/Hz at 1-100kHz offset. The typical performance is better, of course, but still, it's about -90dBc/Hz at 100Hz offset. ___ 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
Maybe I've missed something but... have they tried this experiment with anything else than neutrinos? Or, is it possible to repeat the experiment with any other thing? OK, the neutrino is faster than light but the others? Can we test over the same distance, same detectors (or the appropriate detectors but in the same place)? More: are neutrinos supposed to travel from CERN to Gran Sasso via what? Is there a 730Km long empty pipe or they travel through earth, rocks, water and whatever they can find underground? For empty pipe I mean with scientific grade high vacuum, of course. On Fri, Sep 23, 2011 at 9:15 PM, Jose Camara camar...@quantacorp.comwrote: Worse yet, top posters will reply at the bottom and vice-versa !!! :-) -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of David VanHorn Sent: Friday, September 23, 2011 11:14 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Fast than light neutrino Fun to guess. Time must be running backwards. Or maybe they have negative mass. If truly faster than C, SOMETHING nonsensical must be true. Indeed.. How would they know where to have been tomorrow? ___ 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] Fast than light neutrino
Hi Azelio: Rock. Have Fun, Brooke Clarke http://www.PRC68.com http://www.End2PartyGovernment.com/ Azelio Boriani wrote: Maybe I've missed something but... have they tried this experiment with anything else than neutrinos? Or, is it possible to repeat the experiment with any other thing? OK, the neutrino is faster than light but the others? Can we test over the same distance, same detectors (or the appropriate detectors but in the same place)? More: are neutrinos supposed to travel from CERN to Gran Sasso via what? Is there a 730Km long empty pipe or they travel through earth, rocks, water and whatever they can find underground? For empty pipe I mean with scientific grade high vacuum, of course. On Fri, Sep 23, 2011 at 9:15 PM, Jose Camaracamar...@quantacorp.comwrote: Worse yet, top posters will reply at the bottom and vice-versa !!! :-) -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of David VanHorn Sent: Friday, September 23, 2011 11:14 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Fast than light neutrino Fun to guess. Time must be running backwards. Or maybe they have negative mass. If truly faster than C, SOMETHING nonsensical must be true. Indeed.. How would they know where to have been tomorrow? ___ 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. ___ 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
Hi again: What is the speed of light in rock? Have Fun, Brooke Clarke http://www.PRC68.com http://www.End2PartyGovernment.com/ Brooke Clarke wrote: Hi Azelio: Rock. Have Fun, Brooke Clarke http://www.PRC68.com http://www.End2PartyGovernment.com/ Azelio Boriani wrote: Maybe I've missed something but... have they tried this experiment with anything else than neutrinos? Or, is it possible to repeat the experiment with any other thing? OK, the neutrino is faster than light but the others? Can we test over the same distance, same detectors (or the appropriate detectors but in the same place)? More: are neutrinos supposed to travel from CERN to Gran Sasso via what? Is there a 730Km long empty pipe or they travel through earth, rocks, water and whatever they can find underground? For empty pipe I mean with scientific grade high vacuum, of course. On Fri, Sep 23, 2011 at 9:15 PM, Jose Camaracamar...@quantacorp.comwrote: Worse yet, top posters will reply at the bottom and vice-versa !!! :-) -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of David VanHorn Sent: Friday, September 23, 2011 11:14 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Fast than light neutrino Fun to guess. Time must be running backwards. Or maybe they have negative mass. If truly faster than C, SOMETHING nonsensical must be true. Indeed.. How would they know where to have been tomorrow? ___ 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. ___ 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] Fast than light neutrino
What is the speed of light in rock? C Don Dr. Don Latham AJ7LL Six Mile Systems LLP 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 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] Fast than light neutrino
Hi Don: I don't think so, see: http://en.wikipedia.org/wiki/Refractive_index Have Fun, Brooke Clarke http://www.PRC68.com http://www.End2PartyGovernment.com/ Don Latham wrote: What is the speed of light in rock? C Don Dr. Don Latham AJ7LL Six Mile Systems LLP 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 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] Fast than light neutrino
On 9/23/2011 3:23 PM, Brooke Clarke wrote: Hi again: What is the speed of light in rock? Outside of a cave the answer is C. Inside a cave, it's too dark to read my watch. (With apologies to Grocho Marx) ___ 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] Fast than light neutrino
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). The locations were know to plus or minus 20cm. Time was synced within a few ns using symmetricom cs gpsdo's near as I can tell. Sent from my iPhone ___ 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 9/23/11 1:23 PM, Brooke Clarke wrote: Hi again: What is the speed of light in rock? that's a really interesting question, because it's not like a EM wave propagating, where the dielectric constant is what you care about. OTOH, I suppose that since EM waves are also photons, there must be some sort of propagation constant. But what's the permittivity of rock at the frequency (energy) of a neutrino ___ 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
In message 4e7cdeb0.8070...@earthlink.net, Jim Lux writes: Actually, the really annoying one is where I have a good clock that's stable, but I need to keep adjusting time to match someone else's terrible clock. Most clock disciplining/time propagation models assume your bad clock is following a better clock. That is exactly what happens when you put an OCXO or Rb in a computer and run NTPD against a server across the internet :-) I still have a hard time drawing a boundary about this next level up, and maybe I'm misunderstanding you, so let me think out loud for a moment: Its pretty obvious that you can build a suitably general mathematical model that will cover anything you can expect to encounter: A polynomium of a dozen degrees will catch any PLL-like regulation pretty well, add a fourier series for periodic terms like your temperature variations and finally chop it into segments to correctly deal with discontinuities from power failuers or upsets. But isn't that so general that it becomes meaningless ? Determining two or three dozen Finagle constants doesn't sound like anything close to real-time to me, and it all hinges crucially on the mathematical model being expressive enough. Something like the SOHO unthaw would be a really tough challenge to model I think. The opposite approach is accept that clock-modelling is not the standardized operation, but representing the data to feed into the clock-modelling software should be a standard format, to facilitet model reuse. Some of that data is pretty obvious: Time series of clock offset estimates: When Which other clock Uncertainty of other clock Measured Offset Uncertainty of Measured Offset Craft orbital params XYZT, model gets to figure out what is nearby ? or Parametric model (in orbit about, ascending node...) And then it gets nasty: Vehicle Thermal balance model a function of: Vehicle configuation Vehicle orientation Nearby objects (sun, planets, moon) Wavelength Clock model: a function of: vehicle temperature, bus voltage gravity magnetic fields from craft vibration (micrometeorites, think: Hipparcos) clock age random clock internal events And the list probably goes on and on, until we come to individual component failure effects. Missing in this picture is the organizational boundaries: The mission data comes from one place, and the clock model or clock parameters are probably delivered by the manufacturer of the specific device? How many of these parameters you need to include will of course depend on the exact vehicle and mission requirements. There is a heck of a difference between a commercial geo-stationary comms satelite and Gravity Probe B and Gaia. One can always say put it in XML and hope for the best but that's not much of a standard, is it ? -- 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] Fast than light neutrino
Do quantum entanglement experiments with photons qualify? (Admittedly it's a different situation, but the coupling is apparently faster than c?) -Greg - Original Message - From: Azelio Boriani azelio.bori...@screen.it To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Friday, September 23, 2011 2:02 PM Subject: Re: [time-nuts] Fast than light neutrino Maybe I've missed something but... have they tried this experiment with anything else than neutrinos? Or, is it possible to repeat the experiment with any other thing? OK, the neutrino is faster than light but the others? Can we test over the same distance, same detectors (or the appropriate detectors but in the same place)? More: are neutrinos supposed to travel from CERN to Gran Sasso via what? Is there a 730Km long empty pipe or they travel through earth, rocks, water and whatever they can find underground? For empty pipe I mean with scientific grade high vacuum, of course. ___ 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
In message CAL8XPmO_T-R1y=qumswtunhdnme0seti+6xtdgww4jdvz2j...@mail.gmail.com , Azelio Boriani writes: More: are neutrinos supposed to travel from CERN to Gran Sasso via what? Via solid rock. Is there a 730Km long empty pipe [...] No, and you'd need one to actually try the same distance with photons. The complication is that the solid rock path is actually used as sort of a filter for the neutrinos, nothing else goes through 730km bedrock so if you see anything coming from that direction, you can be pretty certain that it is neutrinos. -- 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] seeking a time/clock software architecture
Seems like a lot of unknowns. You would have to have sensors monitoring the sensors. Do you lose too much by just maintaining a lifetime worst-case number, or maybe some kind of probability function? On 9/23/2011 3:45 PM, Poul-Henning Kamp wrote: And then it gets nasty: Vehicle Thermal balance model a function of: Vehicle configuation Vehicle orientation Nearby objects (sun, planets, moon) Wavelength Clock model: a function of: vehicle temperature, bus voltage gravity magnetic fields from craft vibration (micrometeorites, think: Hipparcos) clock age random clock internal events ___ 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
Date: Fri, 23 Sep 2011 14:51:26 +1000 From: Jim Palfreyman jim77...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: [time-nuts] Fast than light neutrino Message-ID: CALH-g5ZABVtfCR0=h3ywjtjc23kowwk59sf3_qcie0ig6_x...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 For those of you who may be interested, here's the paper. http://arxiv.org/ftp/arxiv/papers/1109/1109.4897.pdf The path is through 730 kilometers of solid rock, so only neutrinos will do. And neutrinos are the least understood of particles. If I read the article correctly, the neutrinos appear to travel 25 parts per million faster than C, which if true is still revolutionary. But while the result is quite significant in statistical terms (6 sigma), 25 ppm is pretty small, and could easily be caused by some subtle systemic error. One assumes *very* subtle, given that none of the ~100 coauthors could find it, and it won't have been for lack of trying. Now the world physics community is on the case, so it may not take all that long. Joe Gwinn ___ 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
Just a thought: would it be possible that the bedrock act as a negative-index composite material for neutrinos: that would make them faster than light, but since it's not in vacuum, they would still be politically correct ??? Jean-Louis - Original Message - From: Poul-Henning Kamp p...@phk.freebsd.dk To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Friday, September 23, 2011 8:49 PM Subject: Re: [time-nuts] Fast than light neutrino In message CAL8XPmO_T-R1y=qumswtunhdnme0seti+6xtdgww4jdvz2j...@mail.gmail.com , Azelio Boriani writes: More: are neutrinos supposed to travel from CERN to Gran Sasso via what? Via solid rock. Is there a 730Km long empty pipe [...] No, and you'd need one to actually try the same distance with photons. The complication is that the solid rock path is actually used as sort of a filter for the neutrinos, nothing else goes through 730km bedrock so if you see anything coming from that direction, you can be pretty certain that it is neutrinos. -- 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. ___ 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
As always, the answer is 'it depends'. :) Solid rock? Liquid rock? Gaseous rock? Plasma? :) Wavelength? A nice light rock like calcite it probably isn't too tough to measure. Si02 is pretty easy too, I'm sure. For classic basaltic or feldspathic rocks, I suspect you are going to need something well outside the visible spectrum. At least in the first two phases. Not to mention the issues in a non homogenous rock. Bob the GeologyPhysics major. On Fri, Sep 23, 2011 at 4:35 PM, Chris Howard ch...@elfpen.com wrote: On 9/23/2011 3:23 PM, Brooke Clarke wrote: Hi again: What is the speed of light in rock? Outside of a cave the answer is C. Inside a cave, it's too dark to read my watch. (With apologies to Grocho Marx) ___ 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] HP 10811 Response I Replies
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] seeking a time/clock software architecture
On Fri, Sep 23, 2011 at 12:32 PM, Jim Lux jim...@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. 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. 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] HP 10811 Response I Replies
Magnus Danielson wrote: On 23/09/11 05:40, Richard (Rick) Karlquist wrote: Blowing on the case? Did you consider the increased cooling that higher humidity provides? Cheers, Magnus Against, the frequency change we saw was considerably more than what we got from changing the temperature 50 degrees. 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
OK, thanks for your replies. So we have: neutrinos traveling through bedrock compared to photons/EM waves traveling through empty space. Neutrinos are 60nS early at the finish line, 730534m after the start. 60nS for light (in empty space) is 18m: are they sure where the start line is? The decay tube is 995m long and the starting point was determined by simulations, 18m is the 1% of 995m. On Fri, Sep 23, 2011 at 10:49 PM, Poul-Henning Kamp p...@phk.freebsd.dkwrote: In message CAL8XPmO_T-R1y= qumswtunhdnme0seti+6xtdgww4jdvz2j...@mail.gmail.com , Azelio Boriani writes: More: are neutrinos supposed to travel from CERN to Gran Sasso via what? Via solid rock. Is there a 730Km long empty pipe [...] No, and you'd need one to actually try the same distance with photons. The complication is that the solid rock path is actually used as sort of a filter for the neutrinos, nothing else goes through 730km bedrock so if you see anything coming from that direction, you can be pretty certain that it is neutrinos. -- 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. ___ 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
Maybe you have a bad joint in the tuning circuit and the humidity makes the actual tuning voltage vary. -John === Magnus Danielson wrote: On 23/09/11 05:40, Richard (Rick) Karlquist wrote: Blowing on the case? Did you consider the increased cooling that higher humidity provides? Cheers, Magnus Against, the frequency change we saw was considerably more than what we got from changing the temperature 50 degrees. 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. ___ 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
On 23/09/11 23:25, Rick Karlquist wrote: Magnus Danielson wrote: On 23/09/11 05:40, Richard (Rick) Karlquist wrote: Blowing on the case? Did you consider the increased cooling that higher humidity provides? Cheers, Magnus Against, the frequency change we saw was considerably more than what we got from changing the temperature 50 degrees. Which would not be well explained by that effect, true. 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/23/11 1:45 PM, Poul-Henning Kamp wrote: In message4e7cdeb0.8070...@earthlink.net, Jim Lux writes: Actually, the really annoying one is where I have a good clock that's stable, but I need to keep adjusting time to match someone else's terrible clock. Most clock disciplining/time propagation models assume your bad clock is following a better clock. That is exactly what happens when you put an OCXO or Rb in a computer and run NTPD against a server across the internet :-) I still have a hard time drawing a boundary about this next level up, and maybe I'm misunderstanding you, so let me think out loud for a moment: Its pretty obvious that you can build a suitably general mathematical model that will cover anything you can expect to encounter: A polynomium of a dozen degrees will catch any PLL-like regulation pretty well, add a fourier series for periodic terms like your temperature variations and finally chop it into segments to correctly deal with discontinuities from power failuers or upsets. But isn't that so general that it becomes meaningless ? Maybe, but not necessarily, and if you were to establish such a general form for converting timecount (clock) into time what would be a reasonable number of terms to limit it to? Maybe I can find my way through by considering the discontinuity problem. At some level, one likes to have time be continuous (i.e. some order derivative = 0). You'd also like to be able to compare two sets of data (derived from different clocks, but converted to a common time scale), so the clock to time transformation should make that possible at some level of granularity and continuity. Likewise, you'd like to be able to schedule an event to occur at two places (with different underlying clocks) at some time in the future, so the transformation from time to clock value when X needs to happen should be possible. Again, discontinuities would raise problems (the daylight saving time problem of having two 145AMs or no 230AM) So, it's not necessarily that one needs an arbitrary number of polynomial terms, but maybe a way to seamlessly blend segments with smaller numbers of terms (the cubic spline idea), and then some consistent method for describing it. Determining two or three dozen Finagle constants doesn't sound like anything close to real-time to me, and it all hinges crucially on the mathematical model being expressive enough. Exactly.. I think the uncertainty in those high order terms might be meaningless. But maybe one could think in terms of a hierarchical scheme.. A high level measurer/predictor that cranks out the current low order polynomial model based on whatever it decides to use (e.g. temperature, phase of the moon, rainfall) The scope of the time problem is in defining how one converts from raw clock (counts of an oscillator) to time (with a scale and epoch), but not how one might come up with the parameters for that conversion. (that's in the clock modeling domain) Likewise.. a synchronization scheme (e.g. NTP) is really an estimation problem, based on measurements and observations, and producing the transformation. The mechanics of how one comes up with the parameters is out of scope for the architecture, just that such a function can exist. Something like the SOHO unthaw would be a really tough challenge to model I think. The opposite approach is accept that clock-modelling is not the standardized operation, but representing the data to feed into the clock-modelling software should be a standard format, to facilitet model reuse. Exactly. The data feeding into the clock modeling process should be raw clock and time (e.g. if you get time hacks from an outside source, to match them against your clock, you either need to convert clock into the external time scale, or convert the external time scale into your internal clock scale). And (as you indicated below) a whole raft of other speculative inputs to the clock modeling (out of scope for the architecture..) The output would be some revised description of how to convert clock into time Some of that data is pretty obvious: Time series of clock offset estimates: When Which other clock Uncertainty of other clock Measured Offset Uncertainty of Measured Offset Craft orbital params XYZT, model gets to figure out what is nearby ? or Parametric model (in orbit about, ascending node...) And then it gets nasty: Vehicle Thermal balance model a function of: Vehicle configuation Vehicle orientation Nearby objects (sun, planets, moon) Wavelength Clock model: a function of: vehicle temperature, bus voltage gravity magnetic
Re: [time-nuts] Fast than light neutrino
At 04:23 PM 9/23/2011, Brooke Clarke wrote... What is the speed of light in rock? Well, for quartzite (fused quartz), it's c/1.4585. HTH! ___ 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/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. 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. Do you lose too much by just maintaining a lifetime worst-case number, or maybe some kind of probability function? Certainly one cannot do a worst-case number. Consider that you have two endpoints that need to be synchronized within 1 millisecond. This requires that the clocks at each end have known rate/offset to an accuracy of around 1ppm for 1000 second time span. Assuming that you have some magic means to measure this, you'd like to have a standard way to describe the rate and offset (so that you don't have as many formats as you do endpoints). 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? 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) 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) 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. ___ 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/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.) ___ 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
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 There is a standard for this but it's horrible and no one implements it completely or perfectly. http://www.wsmr.army.mil/RCCsite/Documents/124-11_TMATS%20Handbook/124-11%20TMATS%20Handbook.pdf Some of us have a better system than passing spread sheets or PDFs. I'm seeing consolidation to an type of XML based system. 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] seeking a time/clock software architecture
In message 4e7d0353.2040...@earthlink.net, Jim Lux writes: But as we move towards constellations of spacecraft with LONG light time to earth, that whole time correlation process needs to be done autonomously. So the process of converting local count to time in some universally agreed scale and back has to be done locally. Doesn't GR sort of make universally agreed scale a pretty interesting concept ? But more importantly, have you done any estimates of the precision/ required input ratio for this ? I would seriously look into broadcasting a usable time signal to the constellation of vehicles, to use as common reference, rather than have each of them attempt dead reckoning of their own clock to a paper timescale, which quickly runs into sensor input limitations. By broadcast I don't mean you have to build an antenna tower, there are plenty of suitable signals out there already. Presumably they are going to point an antenna back at earth, adding a small newtonian telescope with a long-IR sensor next to it, should give you a signal with a interestingly complex but mostly periodic waveform, which the vehicles in the constellation can use as conductors baton. Other candidates are Jupiters moons (always a favourite), pulsars (Probably needs to big antennae?) GRB's c. A pox on put it in XML.. As far as I'm concerned that's no better than saying put it in an ASCII text file. Well, it's easier to deal with newlines in strings in XML, but otherwise I fully agree :-) -- 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] seeking a time/clock software architecture
On 9/23/11 4:01 PM, Poul-Henning Kamp wrote: In message4e7d0353.2040...@earthlink.net, Jim Lux writes: But as we move towards constellations of spacecraft with LONG light time to earth, that whole time correlation process needs to be done autonomously. So the process of converting local count to time in some universally agreed scale and back has to be done locally. Doesn't GR sort of make universally agreed scale a pretty interesting concept ? But more importantly, have you done any estimates of the precision/ required input ratio for this ? It would be nice to be able to synchronize events between spacecraft to a few milliseconds over a time span of a day, without needing a special time signal during that time. Existing clocks, with very simple clock models can get this level of precision without too much trouble. The trick is smoothly adjusting when we DO get a fix. Within a given spacecraft, where there's no explicit need for tight time sync because of the instrument (e.g. if you're building an interferometer, some casual time scheme probably isn't going to get you there), microseconds over a time scale of seconds is probably good enough. (i.e. distributing a 1pps to everybody).. this is comparable to conventional laboratory practice with IRIG time code or 1pps. I would seriously look into broadcasting a usable time signal to the constellation of vehicles, to use as common reference, rather than have each of them attempt dead reckoning of their own clock to a paper timescale, which quickly runs into sensor input limitations. Yeah but that's the way we've been doing it for the last 50 years, so everyone is familiar with it. This newfangled thing of navigation constellations and broadcasting time references is just hard when you've got dedicated stovepipes to each spacecraft, each with their own message formats and time scales. Interoperate? Why should I spend my precious budget on helping YOU out? Buy your own darned USO in your own budget if you need good timing. grin By broadcast I don't mean you have to build an antenna tower, there are plenty of suitable signals out there already. Actually not. Consider the back side of the moon, or Mars, or Jupiter. In earth orbit, lots of sources (GPS, which is actually usable at the moon too, after a fashion) Presumably they are going to point an antenna back at earth, adding a small newtonian telescope with a long-IR sensor next to it, should give you a signal with a interestingly complex but mostly periodic waveform, which the vehicles in the constellation can use as conductors baton. Other candidates are Jupiters moons (always a favourite), pulsars (Probably needs to big antennae?) GRB'sc. Adding an optical anything is a tough sell (mass, power, complexity, alien to people used to RF, etc.). And in any case, if you're earth pointed for your comm link, then the signal from Earth can provide sync (it's how we do it now, granted in an ad hoc way). X-ray Pulsars are the distant future approach (X-NAV) but we're waiting for someone to make a suitable sensor. Jupiter's moons.. I heard a story at work that you can use an iPhone camera to see the moons a'la Galileo and hence can do time transfer by Newton's methods. (haven't tried it myself.. Jupiter isn't visible because of weather (night and morning low clouds and fog, which will be familiar to anyone in Southern California)) The general time transfer problem is to have a good clock on an orbiter (e.g. a relay orbiter around Mars like MRO or future s/c) and then be able to transfer time using that clock to a lander (e.g. a Mars rover) over a UHF link. There's no direct path from Earth to the rover, and, in fact, it doesn't have an antenna big enough. You might only be communicating with the orbiter once a week (or every few days). So you get the time on the orbiter lined up with earth time (TAI, typically) and then use the stable clock on the orbiter to transfer that time to the orbiter. A practical application for this is something like Mars Sample Return, where you want to launch a rocket with your 500g of precious Martian rocks and regolith into Mars orbit, where an orbiter can rendezvous with it and transfer the samples to a spacecraft that can send them back to Earth. You need to know where the orbiter is (fairly straight forward), where the rocket launch site is (not quite as straight forward), and figure out when to push the button for the rocket. The orbiter might not be in view of the rocket at launch time, and neither might be in view of earth, so you can't do a straight remote control.. it's all done by canned sequence. Since the orbiter is zooming along at a few km/second, a one second difference in launch time is a few km miss distance (which, in truth, isn't a huge deal.. we've already got to account for the tens of km uncertainty in the rocket's trajectory) Since mass on Martian surface is very
[time-nuts] Mystery Passive Maser Update 4
Update 4 of the Mystery Passive Maser Project is now available at: http://www.leapsecond.com/maser/ Enjoy! Corby Dawson 60-Year-Old Mom Looks 27 Mom Reveals Free Wrinkle Trick That Has Angered Doctors! http://thirdpartyoffers.juno.com/TGL3141/4e7d2d3f1296f7b1709st01duc ___ 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
Faster than in reggae but slower than in hip-hop. Brian -- From: Don Latham d...@montana.com Sent: Friday, September 23, 2011 1:26 PM To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: Re: [time-nuts] Fast than light neutrino What is the speed of light in rock? C Don Dr. Don Latham AJ7LL Six Mile Systems LLP 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 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.
[time-nuts] NERC TEC elimination update
Looks like they're going to talk about it again in December: http://www.nerc.com/page.php?cid=6%7C386 -- 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.
[time-nuts] Humor: ultra leap minutes
http://www.rhymeswithorange.com/2011/09/september-20-2011/ PS: If you are ever trying to explain DDS to a non geek, consider leap years. The 100 and 400 year corrections are making the adder wider and still wider. -- These are my opinions, not necessarily my employer's. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
