[time-nuts] GPSDO time constant
Here are ADEV plots and interesting results from a recent experiment on varying the time-constant of a GPSDO: http://www.leapsecond.com/pages/tbolt-tc/ There was a thread recently where Warren suggested that the loop time constant (TC) of GPSDO was less than ideal. He is correct. There are a couple of reasons for this, if I may guess. 1) Some GPSDO, like the surplus SmartClock designs from HP, were designed to meet spec even when S/A was still in effect. With the much greater wander in civilian GPS timing during those years, the TC needed to be less than what you can get away with today. 2) If you are a manufacturer and have a GPSDO spec to meet, you need to make sure the TC is valid for all OCXO that you ship, not just the average one. The way to do this is to be conservative and to ship the units with a TC that is short enough that even the parts on the lower end of the bell curve still meet your spec. The other alternative is to individually measure (days, weeks?) every OCXO and individually burn a default TC into each unit shipped. 3) Most commercial GPSDO need to work over a fairly wide temperature range. This might require a tighter TC. If the user has a more controlled environment they can probably tolerate a longer TC that what the manufacturer dare ship as a default. 4) A GPSDO should still work reliably in the face of phase or frequency jumps in the OCXO. Although the timing of these is not predictable, their typical magnitude is probably something that the designer can learn. The TC needs to be short enough so that the GPSDO gracefully handles these jumps. If one is too aggressive the GPSDO will wander out of spec instead of more closely tracking GPS. 5) I'm not sure it's possible to optimize for both time stability and frequency stability at the same time. A long TC will help avoid too sudden frequency changes in the GPSDO; a short TC will help the 1pps stay close to UTC. I suppose a GPSDO might be optimized more for one application than the other; this would affect the choice of default TC. 6) Most OCXO demonstrate much better drift rates after they have been in operation for weeks or months. The drift rate has a some impact on the choice of TC. It's probably not a good business model to ship a GPSDO with a TC optimized for how the unit might eventually run a year from now. It has to work out of the box. So this cause the default TC to be set shorter than ideal. 7) There may also be a SV, sky-view, or latitude dependence. Someone enjoying all 32 SV today, with a clear 360 degree view of the sky at mid-latitude will probably enjoy slightly better performance than someone a few years ago when there were less operational SV in orbit, or with mountain, forest, building obstructions, or at extreme latitudes. If you have much better than average reception you could probably move the TC out further. So for these reasons (more like guesses), it would not surprise me if most GPSDO have the TC set on the low side. Let me know if you have additional info on this topic. The good news is that if you, the time-nut, have the gear and the time to measure the stability of the OCXO in your GPSDO, and know your environment well, then you can probably safely lengthen the TC and achieve much better mid-term stability out of your GPSDO as shown in the plot above. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO time constant
In message b6f04190894a41eeaae0305a898a5...@pc52, Tom Van Baak writes: Here are ADEV plots and interesting results from a recent experiment on varying the time-constant of a GPSDO: http://www.leapsecond.com/pages/tbolt-tc/ Tom, part of the reason for the sub-optimally short default time constant is to be able to cope with worst-case specs of the oscillator. Even though they are pretty good, shifts in voltage, temperature and orientation does affect them. A very good example of this effect is the NTPD PLL, which uncritically belives otherwise unplausible good news, and lengthens the poll-period to 20 minutes and then refuses to accept that it did it wrong, until i thas seen three or four (= one hour) samples saying so, after which it breaks lock and starts over. In a lab setting, it makes sense to increase over the default time-constant, just remember that it impacts your loops ability to cope with for instance a 2g turnover. -- 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] GPSDO time constant
Tom Van Baak skrev: Here are ADEV plots and interesting results from a recent experiment on varying the time-constant of a GPSDO: http://www.leapsecond.com/pages/tbolt-tc/ There was a thread recently where Warren suggested that the loop time constant (TC) of GPSDO was less than ideal. He is correct. There are a couple of reasons for this, if I may guess. I particular liked that you tweaked the damping constant. If it is not scaled off the normal charts (it doesn't look like it) I think it is rather low damping factor and this infact does not supprise me at least to produce a definitive bump. Keeping it at 1.2 is still not critically damped but rather under-damped. I would love to see a few variants of measure at say tau = 100s but for various damping coefficients. By the looks of it, the bump can be attributed almost completely to resonance in the PLL loop, which is certainly not what we would like to see... adding to the noise response. 1) Some GPSDO, like the surplus SmartClock designs from HP, were designed to meet spec even when S/A was still in effect. With the much greater wander in civilian GPS timing during those years, the TC needed to be less than what you can get away with today. 2) If you are a manufacturer and have a GPSDO spec to meet, you need to make sure the TC is valid for all OCXO that you ship, not just the average one. The way to do this is to be conservative and to ship the units with a TC that is short enough that even the parts on the lower end of the bell curve still meet your spec. The other alternative is to individually measure (days, weeks?) every OCXO and individually burn a default TC into each unit shipped. With the end result being that noise specs would still vary between units. Also, if one unit was good at fab and gets pounded during shipping doesn't help either. 3) Most commercial GPSDO need to work over a fairly wide temperature range. This might require a tighter TC. If the user has a more controlled environment they can probably tolerate a longer TC that what the manufacturer dare ship as a default. 4) A GPSDO should still work reliably in the face of phase or frequency jumps in the OCXO. Although the timing of these is not predictable, their typical magnitude is probably something that the designer can learn. The TC needs to be short enough so that the GPSDO gracefully handles these jumps. If one is too aggressive the GPSDO will wander out of spec instead of more closely tracking GPS. All these 4 points really argue against the principle of choosing one TC to fit them all. Using suitable heuristics to adapt TC to conditions and recent history runtime will provide a much more dynamic fashion in which units would adapt to their performance and their environment. 5) I'm not sure it's possible to optimize for both time stability and frequency stability at the same time. A long TC will help avoid too sudden frequency changes in the GPSDO; a short TC will help the 1pps stay close to UTC. I suppose a GPSDO might be optimized more for one application than the other; this would affect the choice of default TC. Actually no, not really. If we remove the issues of hanging bridge, which the ThunderBolt effectively has since it steers it's timing clock, then another reason for shifting PPS is due to changing symmetry and when removing or adding a satellite from the chosen constellation (by tracking set or TRAIM selective set) the apparent receiver time will jump. In the meanwhile it may glide as the symmetry changes. Multipath can also aid in shifting position. So a shorter time constant does not render a closer rendition of UTC but rather a quicker follow of apparent time position of the receiver, which isn't quite the same thing. Thus, a longer time constants acts like an averaging of apparent time position. Another factor which plauges most single frequency receivers is that they can't correct for actual ionospheric delay. They run according to a parameterized model. There is a deviation between the actual and apparent delay and it is changing over time. Thus, using Rubidium or Caesium to steer local clock will allow for even greater time constants and thus greater averaging potential, as 1000 s is still kind of short. The conclusion is that the GPS receivers we use have many inherrent non-static error sources 6) Most OCXO demonstrate much better drift rates after they have been in operation for weeks or months. The drift rate has a some impact on the choice of TC. It's probably not a good business model to ship a GPSDO with a TC optimized for how the unit might eventually run a year from now. It has to work out of the box. So this cause the default TC to be set shorter than ideal. 7) There may also be a SV, sky-view, or latitude dependence. Someone enjoying all 32 SV today, with a clear 360 degree view of the sky at mid-latitude will probably enjoy slightly better performance
Re: [time-nuts] GPSDO time constant
Hej Magnus Magnus Danielson wrote: Tom Van Baak skrev: Here are ADEV plots and interesting results from a recent experiment on varying the time-constant of a GPSDO: http://www.leapsecond.com/pages/tbolt-tc/ There was a thread recently where Warren suggested that the loop time constant (TC) of GPSDO was less than ideal. He is correct. There are a couple of reasons for this, if I may guess. I particular liked that you tweaked the damping constant. If it is not scaled off the normal charts (it doesn't look like it) I think it is rather low damping factor and this infact does not supprise me at least to produce a definitive bump. Keeping it at 1.2 is still not critically damped but rather under-damped. I would love to see a few variants of measure at say tau = 100s but for various damping coefficients. By the looks of it, the bump can be attributed almost completely to resonance in the PLL loop, which is certainly not what we would like to see... adding to the noise response. 1) Some GPSDO, like the surplus SmartClock designs from HP, were designed to meet spec even when S/A was still in effect. With the much greater wander in civilian GPS timing during those years, the TC needed to be less than what you can get away with today. 2) If you are a manufacturer and have a GPSDO spec to meet, you need to make sure the TC is valid for all OCXO that you ship, not just the average one. The way to do this is to be conservative and to ship the units with a TC that is short enough that even the parts on the lower end of the bell curve still meet your spec. The other alternative is to individually measure (days, weeks?) every OCXO and individually burn a default TC into each unit shipped. With the end result being that noise specs would still vary between units. Also, if one unit was good at fab and gets pounded during shipping doesn't help either. 3) Most commercial GPSDO need to work over a fairly wide temperature range. This might require a tighter TC. If the user has a more controlled environment they can probably tolerate a longer TC that what the manufacturer dare ship as a default. 4) A GPSDO should still work reliably in the face of phase or frequency jumps in the OCXO. Although the timing of these is not predictable, their typical magnitude is probably something that the designer can learn. The TC needs to be short enough so that the GPSDO gracefully handles these jumps. If one is too aggressive the GPSDO will wander out of spec instead of more closely tracking GPS. All these 4 points really argue against the principle of choosing one TC to fit them all. Using suitable heuristics to adapt TC to conditions and recent history runtime will provide a much more dynamic fashion in which units would adapt to their performance and their environment. 5) I'm not sure it's possible to optimize for both time stability and frequency stability at the same time. A long TC will help avoid too sudden frequency changes in the GPSDO; a short TC will help the 1pps stay close to UTC. I suppose a GPSDO might be optimized more for one application than the other; this would affect the choice of default TC. Actually no, not really. If we remove the issues of hanging bridge, which the ThunderBolt effectively has since it steers it's timing clock, then another reason for shifting PPS is due to changing symmetry and when removing or adding a satellite from the chosen constellation (by tracking set or TRAIM selective set) the apparent receiver time will jump. In the meanwhile it may glide as the symmetry changes. Multipath can also aid in shifting position. So a shorter time constant does not render a closer rendition of UTC but rather a quicker follow of apparent time position of the receiver, which isn't quite the same thing. Thus, a longer time constants acts like an averaging of apparent time position. Another factor which plauges most single frequency receivers is that they can't correct for actual ionospheric delay. They run according to a parameterized model. There is a deviation between the actual and apparent delay and it is changing over time. Thus, using Rubidium or Caesium to steer local clock will allow for even greater time constants and thus greater averaging potential, as 1000 s is still kind of short. The conclusion is that the GPS receivers we use have many inherrent non-static error sources 6) Most OCXO demonstrate much better drift rates after they have been in operation for weeks or months. The drift rate has a some impact on the choice of TC. It's probably not a good business model to ship a GPSDO with a TC optimized for how the unit might eventually run a year from now. It has to work out of the box. So this cause the default TC to be set shorter than ideal. 7) There may also be a SV, sky-view, or latitude dependence. Someone enjoying all 32 SV
Re: [time-nuts] GPSDO time constant
Poul-Henning Kamp skrev: In message b6f04190894a41eeaae0305a898a5...@pc52, Tom Van Baak writes: Here are ADEV plots and interesting results from a recent experiment on varying the time-constant of a GPSDO: http://www.leapsecond.com/pages/tbolt-tc/ Tom, part of the reason for the sub-optimally short default time constant is to be able to cope with worst-case specs of the oscillator. Even though they are pretty good, shifts in voltage, temperature and orientation does affect them. A very good example of this effect is the NTPD PLL, which uncritically belives otherwise unplausible good news, and lengthens the poll-period to 20 minutes and then refuses to accept that it did it wrong, until i thas seen three or four (= one hour) samples saying so, after which it breaks lock and starts over. Isn't this more due to surrounding (obviously flawed) heuristics rather than the PLL? Interesting never the less. In a lab setting, it makes sense to increase over the default time-constant, just remember that it impacts your loops ability to cope with for instance a 2g turnover. Most labs would have issues with a 2g turnover. :) Flipping oscillators that runs is evil and should be avoided at all times. Should be in the rulebook for time-nuts. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO time constant
Hej Bruce, The good news is that if you, the time-nut, have the gear and the time to measure the stability of the OCXO in your GPSDO, and know your environment well, then you can probably safely lengthen the TC and achieve much better mid-term stability out of your GPSDO as shown in the plot above. Agreed. But also recall that long-term effects like frequency drift is pretty easy to measure with a GPS. It would not take too much research to figure out some suitable drift-TC relationship such that you could either just look the charts to find a good match or even apply them in real time steering. For ThunderBolt owners it is pretty straightforward to adjust the TC and damping, which is very nice. Use this oppertunity! How exactly can one measure the resultant performance or even select the optimum time constant and damping factor if one doesn't have a quieter reference? Can one really resort to some sort of N cornered hat? If time constants is allowed to be limited by frequency drift (regardless of its source) then you can use a long term drift estimate to control the time constant of the control loop. Essentially being an adaptive filter. It is still a gross oversimplification, but may still be a handy one. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO time constant
In message 4965dece.3060...@xtra.co.nz, Bruce Griffiths writes: Hej Magnus Magnus Danielson wrote: How exactly can one measure the resultant performance or even select the optimum time constant and damping factor if one doesn't have a quieter reference? Can one really resort to some sort of N cornered hat? I experimented with that, and you can actually get pretty far with simpler standalone means such as periodograms of zero crossings. My theory behind this is that the noise (of all kinds) is basically gaussian or other symmetric distributions. Consequently, the offset between your oscillator and the reference should also have a symmetric distribution of sign, subject to well known random paradoxes like the fact that repeatedly rolling 6 with dice doesn't prove you cheat, you might just be very very lucky. I have not fully developed this lead, and would welcome others to experiement and improve on it, it takes more patience and stability than my lap can muster when it must also work for my salary. The way I autotune the timeconstant of the PLL in NTPns is based on this lack of zero-crossings of the offset from the reference input: The first sign that a PLL has been torqued to hard is that the reference input is not able to steer the oscillator adequately and you can detect this very early, by monitoring how long runs you have where the offset from the reference stays the same sign: the runs on one side will get longer and more frequent than on the other side. You can also tell that the timeconstant is too short, because the runs are not long enough, indicating that the PLL follows the reference signal more aggresively than it need. Look in the main/pllmath.c file of NTPns to see my current implementation. (http://phk.freebsd.dk/phkrel/). One of my NTP servers use the same GPS PPS to steer the PRS10 Rb and for the NTP data feed, so the NTPns should obviously end up with a zero frequency error, since the PRS10 takes care of that. Consequently the PLL keeps stretching the timeconstant of the software PLL, until it had identified a 2e-18 rounding error in the frequency estimation code in the kernel. The third order code on the other hand, does not seem to do me much good yet, but maybe I simply don't have good enough kit for that to be dominant. The experiements I would propose requires that you can get hold of the reference/oscillator difference signal somehow, and then what you want to do is simply record runs of these values for various timeconstants and damping factors. The run them through a statistical package, or possibly even the DIEHARD tests, and see how different timeconstants score, the ones where the offset looks most random are optimal. Have fun :-) Poul-Henning -- 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] GPSDO time constant
Poul-Henning Kamp skrev: In message 4965dc62.9070...@rubidium.dyndns.org, Magnus Danielson writes: In a lab setting, it makes sense to increase over the default time-constant, just remember that it impacts your loops ability to cope with for instance a 2g turnover. Most labs would have issues with a 2g turnover. :) Flipping oscillators that runs is evil and should be avoided at all times. Should be in the rulebook for time-nuts. Correct, but it is perfectly normal behaviour for telecom techs who remodel installations while running, so the products must cope with it. True. Very true. The only thing which to some degree prohibits that is to make them monolithic. You are not entierly safe even with monolithic racks. Ericsson created a rack system in which the bottom of the rack was actually forming a closed container with the floor. Hook up compressed air to the nossle and the rack was floating, and hand-pushing the rack into position was no trouble, pull the plugg and it would sit tight on the floor again. That way they could shift in their racks while running, making cut-over time go down to zero. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO time constant
In message 4965e869.4090...@rubidium.dyndns.org, Magnus Danielson writes: Ericsson created a rack system in which the bottom of the rack was actually forming a closed container with the floor. We had that at one place I worked, except it was two small dogs you attached front and back a standard 19 rack. Trouble was that you had to wash the floor first, or the dust would blow all over the place. -- 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] GPSDO time constant
Hi Magnus, all depends - in an aircraft you have 6g+ turn-overs :) We make a version of our FireFly-II GPSDO with ultra-low-g sensitivity and ruggedization, that one you can run in a back-pack while doing skating-tricks on a ramp and you won't see much change in frequency. A bit more pricey on that OCXO of course. Most standard oscillators will have about 1-2ppb change after a turn-over. I have seen some that actually change the Crystal temperature when turned over, so you can see the initial frequency change due to gravity, then you see the operating current change, and the frequency slowly drift away as the temperature of the crystal is changed. Bad. Very bad. bye, Said In a message dated 1/8/2009 09:29:41 Pacific Standard Time, bro...@pacific.net writes: Magnus Danielson wrote: . . . Most labs would have issues with a 2g turnover. :) Flipping oscillators that runs is evil and should be avoided at all times. Should be in the rulebook for time-nuts. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO time constant
I mentioned in another post that I picked up a couple of militarized FTS-4100 fly-away Cs units. These have an option installed that adds an accelerometer to the OCXO; it's supposed to reduce G sensitivity by at least an order of magnitude. John saidj...@aol.com wrote: Hi Magnus, all depends - in an aircraft you have 6g+ turn-overs :) We make a version of our FireFly-II GPSDO with ultra-low-g sensitivity and ruggedization, that one you can run in a back-pack while doing skating-tricks on a ramp and you won't see much change in frequency. A bit more pricey on that OCXO of course. Most standard oscillators will have about 1-2ppb change after a turn-over. I have seen some that actually change the Crystal temperature when turned over, so you can see the initial frequency change due to gravity, then you see the operating current change, and the frequency slowly drift away as the temperature of the crystal is changed. Bad. Very bad. bye, Said In a message dated 1/8/2009 09:29:41 Pacific Standard Time, bro...@pacific.net writes: Magnus Danielson wrote: . . . Most labs would have issues with a 2g turnover. :) Flipping oscillators that runs is evil and should be avoided at all times. Should be in the rulebook for time-nuts. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO time constant
-Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Magnus Danielson Sent: Thursday, January 08, 2009 9:51 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] GPSDO time constant Hi Brooke, So you didn't check out your HP gravity field wrapping mirror? Those are SO handy. :) Cheers, Magnus I think that division got sold off when it became Agilent. ___ 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 time constant
Poul-Henning Kamp skrev: In message 4965e869.4090...@rubidium.dyndns.org, Magnus Danielson writes: Ericsson created a rack system in which the bottom of the rack was actually forming a closed container with the floor. We had that at one place I worked, except it was two small dogs you attached front and back a standard 19 rack. I never seen it myself, so you have more correct info. I go back from something told to me way back in time, so details got a bit fuzzy. Trouble was that you had to wash the floor first, or the dust would blow all over the place. You also have some rather high requirements on the floor quality, it needs to be fairly flat as well. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO time constant
Lux, James P skrev: -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Magnus Danielson Sent: Thursday, January 08, 2009 9:51 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] GPSDO time constant Hi Brooke, So you didn't check out your HP gravity field wrapping mirror? Those are SO handy. :) Cheers, Magnus I think that division got sold off when it became Agilent. I beleive ILM picked them up. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO time constant
-Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Magnus Danielson Sent: Thursday, January 08, 2009 11:19 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] GPSDO time constant Poul-Henning Kamp skrev: In message 4965e869.4090...@rubidium.dyndns.org, Magnus Danielson writes: Ericsson created a rack system in which the bottom of the rack was actually forming a closed container with the floor. We had that at one place I worked, except it was two small dogs you attached front and back a standard 19 rack. I never seen it myself, so you have more correct info. I go back from something told to me way back in time, so details got a bit fuzzy. Trouble was that you had to wash the floor first, or the dust would blow all over the place. You also have some rather high requirements on the floor quality, it needs to be fairly flat as well. When I worked in the special effects business, we used to use these all the time to move heavy stuff around. It actually doesn't require a real flat floor (1 cm grooves aren't a big issue). Think about them as small hovercraft. It also doesn't take much air pressure to lift things (large area * small pressure). For instance, folks build small hovercraft using electric leaf blowers as the pressurization fan to support a disk some 1.2m in diameter which will easily support a couple people. The lift pads we used were about 30cm in diameter. 1 psi (7kPa) lifts about 50kg. Moving around 1 ton things with 4 pads wasn't unusual. The rougher the floor, the more airflow you need. ___ 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 time constant
Lux, James P wrote: When I worked in the special effects business, we used to use these all the time to move heavy stuff around. It actually doesn't require a real flat floor (1 cm grooves aren't a big issue). Think about them as small hovercraft. It also doesn't take much air pressure to lift things (large area * small pressure). For instance, folks build small hovercraft using electric leaf blowers as the pressurization fan to support a disk some 1.2m in diameter which will easily support a couple people. The lift pads we used were about 30cm in diameter. 1 psi (7kPa) lifts about 50kg. Moving around 1 ton things with 4 pads wasn't unusual. The rougher the floor, the more airflow you need. James, Do you have any web sites that show such a contration using leaf blowers ? thanks, BillWB6BNQ ___ 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 time constant
On Thu, Jan 8, 2009 at 11:36 AM, WB6BNQ wb6...@cox.net wrote: Do you have any web sites that show such a contration using leaf blowers ? mythbusters -- GDB has a 'break' feature; why doesn't it have 'fix' too? ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO time constant
Google Leaf blower hovercraft and you'll get dozens of useful hits. Here's a real old link: http://amasci.com/amateur/hovercft.html -Original Message- James, Do you have any web sites that show such a contration using leaf blowers ? thanks, BillWB6BNQ ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] GPSDO time constant
In the world of precision scales you can often beat the many of the manufactures specs by an order of magnitude by adjusting and calibrating the scale in the exact location and orientation where it will be used (and not moving it or afterwards). Some of the adjustments involve moving rather crudely threaded mechanical adjustments the equivalent of a few wavelengths of light. There is no way to actually make the adjustments other than trial and error... move it enough times and it will eventually wind up in the right place... and hysteresis and backlash are a bitch... The alignment spec for the color monitor in the HP16500 logic analyzers says to face the unit to the west when adjusting it (but they don't say which end to point west). Also some of the adjustments are on the bottom of the monitor and others are on the side. You usually make the adjustments with the unit on its side... but nobody ever runs the unit in that orientation. I've heard that the xtal oscillator cal procedure for some HP test equipment says that the instrument should be in the same position as when it's operating. For heavy rack equipment that means you lay on a mechanics creeper when making the adjustment rather than flipping the instrument 90 degrees on a bench. _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 ___ 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.
