Re: [time-nuts] GPSDO TC Damping
Dick, Sorry, Magnus, I didn't mean to put words in your mouth. No worries, I just did not want it to be raised to truth. I was remembering last Fall, when you suggested that people look at your ADEV plot and to be mindful of the of the bounding slopes of the curves. If I've mis-remembered the emphasis or the facts, I do apologize. I thought your argument then, as I remember it, was strong and valuable. Seems like it gave a good range of possible values to use for Tau in the measurements. Do not recall the particular discussion. A ref into the archives or date would be apprechiated. I probably won't go far beyond the capabilities of the TBolt, such as implementing a PID controller with dynamic control of variables using a microcontroller and LPGAys and writing my own software, but I love it when you talk that way. Sounds dangerous. :) I have been looking further into the variance, ADEV, MDEV and TDEV with respect to the effect of various dampings. It is becomming clear to me that the gain effect which can be attributed to damping will ripple over to all those measures. I have not had the time to convert this to a complete analysis, but I think I can do that. However, to give a partial answer to Bruce, I would like to point to a passage in Gardiner where the optimum damping for minimum flicker noise is being found, and that is for 1.14 rather than 0.5 which would be minimum noise bandwidth. Gardiner does not go into ADEV and friends, but does provide the refernces and gives an indication of convergance problems for flicker noise on variance, also indicating that this is a problem for further analysis. Using ADEV and friends in replacement analysis could be made analogously for other noise types and as it happends also work in cooperation with investigating the effect on various noisetypes. Regardless, it is an interesting little problem and I get to exercise the little grey and refresh my always failing abilities in integration. 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 TC
Bruce, Yes, but the bump comes from the increase gain around the resonance and spoils the OCXO/GPS cross-over. The simplified noise-bandwidth measure does not really comply here since they usually build on a simplified model of noise type (white noise - gaussian). A simple check in Gardiner provides both the generic integrating formula, simplified results and a graph showing the smae numbers that you give. Whilst the phase noise of a sawtooth corrected M12+T GPS timing receiver approximates white phase noise (at least for tau 1 day), this may not be so for the receiver used in the Thunderbolt. The phase noise of the OCXO certainly cannot be accurately modeled as white phase noise for large tau. As the PLL filters the noise of the OCXO and passes noise from the input side and the noise have several different components to it from either source. You can't really extrapolate direction the results of an asynchronous reciever such as the M12+T to that of a synchronous receiver such as the Thunderbolt. The time-solution of thunderbolt is used in replacement of the time-interval counter fluff slapped onto a PPS based receiver such as the M12+T. Also, the Thunderbolt enjoys a much quiter and stable reference than the M12+T which allows for narrower filters in the sat-tracking as the phasenoise is lower. Notice how the Thunderbolt can be configured for different uses, they are direct hints to what the tracking loops may do as it reduces the physical dynamics of position as well as inflicted G effects on the OCXO. With just two Thunderbolts and a reasonable TIC you can infact build a three-cornered hat. You have three clocks: GPS, OCXO1 and OCXO2 and the thunderbolts will measure GPS-OCXO1 and GPS-OCXO2 and the TIC will be able to measure the OCXO1-OCXO2. An interesting aspect of this is that when lockedup, the PPSes of the Thunderbolts will be confined into a rather small area. This arrangement will, as any other, give not the standalone OCXO noise when beeing steered, but it is not entierly lying for those longer taus. I rather beleive what ADEV, MDEV and TDEV experience in this context. Yes measurements are the key but if one doesnt have a suitable statistically independent low noise frequency reference it isnt possible to optimise the loop parameters for an individual GPSDO. True. However, I think there is still some more theoretical work to be done to give us better tools. These does not remove the need for measurements and I have never been foolish enougth to beleive so, but it could guide us in the right direction for selecting and steering our parameters. We could go back to the real integration formula, adapt it to various powers of f^-n noises and analyse it for the same set of PLL loop filters as analysed by Gardiner. Similarly we could cook up a simulation and do the ADEV, MDEV and TDEV measures. Traditional noise bandwidth measures can be calculated alongside. I am somewhat surprised that you missed the opportunity to correct me as I was giving the incorrect value for damping factor of a critically damped system. It is the square root of 1/2 and not 2, thus 0.7071 is the appropriate damping factor for critically damped systems. I had noted that your quoted damping factor was incorrect but I suspected that you would realise that. Actually according to Gardener critical damping factor is 1 ( minimum settling with no overshoot for a phase step). However a damping factor of 0.7071 is widely used. It is interesting to clear up why this difference exists. Could be critical is judged different for different applications. I am somewhat surprised that when we have been discussing the bandwidth of the PLLs and considering OCXOs being running with fairly high drift rate we have been assuming second degree loops. This form of acceleration requires third degree responses for proper handling, as being well documented in literature such as Gardiner. Going for third degree response the bandwidth of the loop can be (at least more freely) disconnected from tracking requirements due to drift rate. I only mentioned second order type II loops as the analysis is somewhat simpler and there is no indication from the number of tuning parameters for the Thunderbolt that a higher order loop is involved. My point was that regardless of implementation, second order type II loops seems to be the reference mark, which not necessarilly is a good one. Third order loops should be considered as it removes or reduces a type of problem and allows a more freer setting of parameters with less things to compromise between. When doing the loop in digital processing it is not that more expensive. There are re-tunable architectures which is being used in for instance GPS receivers which is not hard at all to use for both PI and PID controllers. Cheers, Magnus ___ time-nuts mailing
Re: [time-nuts] GPSDO TC
Hej Magnus Magnus Danielson wrote: Bruce, Yes, but the bump comes from the increase gain around the resonance and spoils the OCXO/GPS cross-over. The simplified noise-bandwidth measure does not really comply here since they usually build on a simplified model of noise type (white noise - gaussian). A simple check in Gardiner provides both the generic integrating formula, simplified results and a graph showing the smae numbers that you give. Whilst the phase noise of a sawtooth corrected M12+T GPS timing receiver approximates white phase noise (at least for tau 1 day), this may not be so for the receiver used in the Thunderbolt. The phase noise of the OCXO certainly cannot be accurately modeled as white phase noise for large tau. As the PLL filters the noise of the OCXO and passes noise from the input side and the noise have several different components to it from either source. You can't really extrapolate direction the results of an asynchronous reciever such as the M12+T to that of a synchronous receiver such as the Thunderbolt. The time-solution of thunderbolt is used in replacement of the time-interval counter fluff slapped onto a PPS based receiver such as the M12+T. Also, the Thunderbolt enjoys a much quiter and stable reference than the M12+T which allows for narrower filters in the sat-tracking as the phasenoise is lower. Notice how the Thunderbolt can be configured for different uses, they are direct hints to what the tracking loops may do as it reduces the physical dynamics of position as well as inflicted G effects on the OCXO. I wasn't attempting to do so. However the phase noise of the GPS receiver will still dominate for short tau whilst that of the OCXO is dominant for longer tau. With just two Thunderbolts and a reasonable TIC you can infact build a three-cornered hat. You have three clocks: GPS, OCXO1 and OCXO2 and the thunderbolts will measure GPS-OCXO1 and GPS-OCXO2 and the TIC will be able to measure the OCXO1-OCXO2. An interesting aspect of this is that when lockedup, the PPSes of the Thunderbolts will be confined into a rather small area. This arrangement will, as any other, give not the standalone OCXO noise when beeing steered, but it is not entierly lying for those longer taus. The 3 cornered hat technique only works well (even in the extended form where finite correlations between sources are included) when the noise of each of the 3 sources are comparable. That is this technique will only work well in the vicinity of the point where the GPS receiver and OCXO ADEVs crossover or equivalently near the drift corrected minimum of the ADEV as measured by the Thunderbolt when the OCXO is undisciplined. For shorter tau the GPS phase noise dominates. I rather beleive what ADEV, MDEV and TDEV experience in this context. Yes measurements are the key but if one doesnt have a suitable statistically independent low noise frequency reference it isnt possible to optimise the loop parameters for an individual GPSDO. True. However, I think there is still some more theoretical work to be done to give us better tools. These does not remove the need for measurements and I have never been foolish enougth to beleive so, but it could guide us in the right direction for selecting and steering our parameters. It would be helpful if the ADEV (and MDEV) plots for several Thunderbolts were plotted using the Thunderbolt's internal phase error measures obtained when the OCXO is undisciplined. This can easily be setup using the Trimble Thunderbolt Monitor program. We could go back to the real integration formula, adapt it to various powers of f^-n noises and analyse it for the same set of PLL loop filters as analysed by Gardiner. Similarly we could cook up a simulation and do the ADEV, MDEV and TDEV measures. Traditional noise bandwidth measures can be calculated alongside. I am somewhat surprised that you missed the opportunity to correct me as I was giving the incorrect value for damping factor of a critically damped system. It is the square root of 1/2 and not 2, thus 0.7071 is the appropriate damping factor for critically damped systems. I had noted that your quoted damping factor was incorrect but I suspected that you would realise that. Actually according to Gardener critical damping factor is 1 ( minimum settling with no overshoot for a phase step). However a damping factor of 0.7071 is widely used. It is interesting to clear up why this difference exists. Could be critical is judged different for different applications. The usual meaning of critical damping in a second order differential equation is for no overshoot to a step input. Thus critical probably isn't the appropriate term when optimising for other factors. Optimum damping for a particular criterion is perhaps better description. I am somewhat surprised that when
Re: [time-nuts] GPSDO TC
Hej Bruce, As the PLL filters the noise of the OCXO and passes noise from the input side and the noise have several different components to it from either source. You can't really extrapolate direction the results of an asynchronous reciever such as the M12+T to that of a synchronous receiver such as the Thunderbolt. The time-solution of thunderbolt is used in replacement of the time-interval counter fluff slapped onto a PPS based receiver such as the M12+T. Also, the Thunderbolt enjoys a much quiter and stable reference than the M12+T which allows for narrower filters in the sat-tracking as the phasenoise is lower. Notice how the Thunderbolt can be configured for different uses, they are direct hints to what the tracking loops may do as it reduces the physical dynamics of position as well as inflicted G effects on the OCXO. I wasn't attempting to do so. However the phase noise of the GPS receiver will still dominate for short tau whilst that of the OCXO is dominant for longer tau. Agreed. I'm just trying to keep various error sources separate here. The truncation noise isn't white noise one should recall. With just two Thunderbolts and a reasonable TIC you can infact build a three-cornered hat. You have three clocks: GPS, OCXO1 and OCXO2 and the thunderbolts will measure GPS-OCXO1 and GPS-OCXO2 and the TIC will be able to measure the OCXO1-OCXO2. An interesting aspect of this is that when lockedup, the PPSes of the Thunderbolts will be confined into a rather small area. This arrangement will, as any other, give not the standalone OCXO noise when beeing steered, but it is not entierly lying for those longer taus. The 3 cornered hat technique only works well (even in the extended form where finite correlations between sources are included) when the noise of each of the 3 sources are comparable. That is this technique will only work well in the vicinity of the point where the GPS receiver and OCXO ADEVs crossover or equivalently near the drift corrected minimum of the ADEV as measured by the Thunderbolt when the OCXO is undisciplined. For shorter tau the GPS phase noise dominates. Yes. I think it would be usefull to provide confidence intervals etc. to get a better feel of how good the measure is. As a reference measurement the thunderbolts could be driven into holdover. I think the thunderbolts keep reporting timing errors. True. However, I think there is still some more theoretical work to be done to give us better tools. These does not remove the need for measurements and I have never been foolish enougth to beleive so, but it could guide us in the right direction for selecting and steering our parameters. It would be helpful if the ADEV (and MDEV) plots for several Thunderbolts were plotted using the Thunderbolt's internal phase error measures obtained when the OCXO is undisciplined. This can easily be setup using the Trimble Thunderbolt Monitor program. Indeed. We should recall that the PLL locking fades over from the OCXO to the GPS (as received) noise at about the BW frequency/tau of the PLL. Finding the optimum crossover properties involves both balancing PLL bandwidth and damping. I had noted that your quoted damping factor was incorrect but I suspected that you would realise that. Actually according to Gardener critical damping factor is 1 ( minimum settling with no overshoot for a phase step). However a damping factor of 0.7071 is widely used. It is interesting to clear up why this difference exists. Could be critical is judged different for different applications. The usual meaning of critical damping in a second order differential equation is for no overshoot to a step input. Thus critical probably isn't the appropriate term when optimising for other factors. Optimum damping for a particular criterion is perhaps better description. Precisely. Critical damping is just a handy reference along the line, but should not be incorrectly interprented as optimum in some generic sense, there is several forms of optimum for different tasks. I think best ADEV or best TDEV might be more relevant here. My point was that regardless of implementation, second order type II loops seems to be the reference mark, which not necessarilly is a good one. Third order loops should be considered as it removes or reduces a type of problem and allows a more freer setting of parameters with less things to compromise between. When doing the loop in digital processing it is not that more expensive. There are re-tunable architectures which is being used in for instance GPS receivers which is not hard at all to use for both PI and PID controllers. Cheers, Magnus In particular the ability of a third order loop to track linear frequency drift can be very useful. Indeed, this is why I prefer them for this application. The last time I let my Thunderbolt OCXO free run there was a very
Re: [time-nuts] GPSDO TC
Magnus Danielson wrote: Hej Bruce, As the PLL filters the noise of the OCXO and passes noise from the input side and the noise have several different components to it from either source. You can't really extrapolate direction the results of an asynchronous reciever such as the M12+T to that of a synchronous receiver such as the Thunderbolt. The time-solution of thunderbolt is used in replacement of the time-interval counter fluff slapped onto a PPS based receiver such as the M12+T. Also, the Thunderbolt enjoys a much quiter and stable reference than the M12+T which allows for narrower filters in the sat-tracking as the phasenoise is lower. Notice how the Thunderbolt can be configured for different uses, they are direct hints to what the tracking loops may do as it reduces the physical dynamics of position as well as inflicted G effects on the OCXO. I wasn't attempting to do so. However the phase noise of the GPS receiver will still dominate for short tau whilst that of the OCXO is dominant for longer tau. Agreed. I'm just trying to keep various error sources separate here. The truncation noise isn't white noise one should recall. The GPS receiver's noise appears to be at least approximately white phase noise noise after sawtooth correction. With just two Thunderbolts and a reasonable TIC you can infact build a three-cornered hat. You have three clocks: GPS, OCXO1 and OCXO2 and the thunderbolts will measure GPS-OCXO1 and GPS-OCXO2 and the TIC will be able to measure the OCXO1-OCXO2. An interesting aspect of this is that when lockedup, the PPSes of the Thunderbolts will be confined into a rather small area. This arrangement will, as any other, give not the standalone OCXO noise when beeing steered, but it is not entierly lying for those longer taus. The 3 cornered hat technique only works well (even in the extended form where finite correlations between sources are included) when the noise of each of the 3 sources are comparable. That is this technique will only work well in the vicinity of the point where the GPS receiver and OCXO ADEVs crossover or equivalently near the drift corrected minimum of the ADEV as measured by the Thunderbolt when the OCXO is undisciplined. For shorter tau the GPS phase noise dominates. Yes. I think it would be usefull to provide confidence intervals etc. to get a better feel of how good the measure is. As a reference measurement the thunderbolts could be driven into holdover. I think the thunderbolts keep reporting timing errors. Yes, the Thunderbolt keeps measuring phase and frequency errors when the OCXO is unlocked. True. However, I think there is still some more theoretical work to be done to give us better tools. These does not remove the need for measurements and I have never been foolish enougth to beleive so, but it could guide us in the right direction for selecting and steering our parameters. It would be helpful if the ADEV (and MDEV) plots for several Thunderbolts were plotted using the Thunderbolt's internal phase error measures obtained when the OCXO is undisciplined. This can easily be setup using the Trimble Thunderbolt Monitor program. Indeed. We should recall that the PLL locking fades over from the OCXO to the GPS (as received) noise at about the BW frequency/tau of the PLL. Finding the optimum crossover properties involves both balancing PLL bandwidth and damping. I suspect that when more divergent processes than flicker phase noise dominate more damping is optimum. I had noted that your quoted damping factor was incorrect but I suspected that you would realise that. Actually according to Gardener critical damping factor is 1 ( minimum settling with no overshoot for a phase step). However a damping factor of 0.7071 is widely used. It is interesting to clear up why this difference exists. Could be critical is judged different for different applications. The usual meaning of critical damping in a second order differential equation is for no overshoot to a step input. Thus critical probably isn't the appropriate term when optimising for other factors. Optimum damping for a particular criterion is perhaps better description. Precisely. Critical damping is just a handy reference along the line, but should not be incorrectly interprented as optimum in some generic sense, there is several forms of optimum for different tasks. I think best ADEV or best TDEV might be more relevant here. My point was that regardless of implementation, second order type II loops seems to be the reference mark, which not necessarilly is a good one. Third order loops should be considered as it removes or reduces a type of problem and allows a more freer setting of parameters with less things to compromise between. When doing the loop in digital processing
Re: [time-nuts] GPSDO TC Damping
Maybe this should be the subject of a separate thread but to enable ordinary time-nuts to be able to test their ocxo's and gpsdo's for phase stability at home, what would it take as a minimum to be able to perform something like an ADEV test? This would enable us (the other half) to see the results of our experiments and tuning of the gear we have otherwise it is a lot like working blind. I appreciate that what is normally used is a counter which can continually timestamp a dut as opposed to a gated counter but what would be the cheapest way we could achieve this sort of setup? Thanks and 73, Steve 2009/1/9 Bruce Griffiths bruce.griffi...@xtra.co.nz: Richard Moore wrote: On Jan 8, 2009, at 2:46 PM, time-nuts-requ...@febo.com wrote: Message: 1 Date: Fri, 09 Jan 2009 10:28:35 +1300 From: Bruce Griffiths bruce.griffi...@xtra.co.nz Subject: Re: [time-nuts] GPSDO TC To: Discussion of precise time and frequency measurement time-nuts@febo.com Richard Moore wrote: On Jan 8, 2009, at 2:58 AM, time-nuts-requ...@febo.com wrote: Message: 6 Date: Thu, 08 Jan 2009 11:51:50 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org Subject: Re: [time-nuts] GPSDO time constant To: Tom Van Baak t...@leapsecond.com, Discussion of precise time and frequency measurement time-nuts@febo.com For ThunderBolt owners it is pretty straightforward to adjust the TC and damping, which is very nice. Use this oppertunity! So, Magnus (and Tom), what damping factor do you suggest for a TBolt? I'm running a verrry long TC now. If 1.2 is not actually critically damped, what value would be? Any guesses? BTW, I really like that plot of Tom's that tracks the oven and then gets better from the GPS... Dick Moore Richard As always, the problem is how do you know that the time constant you are using is anywhere near optimum? Bruce Well, like many here, I don't actually have the equipment, especially the reference std., to do these MDEV, ADEV and other analyses, so, since I use the GPSDO for a frequency standard and not for UTC, I thought I'd get the expert opinions. Magnus has several times indicated here that a TC laying somewhere in and around 100 to 1000 secs is probably optimum. When I enquired some time back about damping in the TBolt, the consensus seemed to be leave it at 1.2. I have, but it just seems to me that won't be optimum for a fixed- position, lab-located frequency standard -- at the moment, I'm leaning toward the 0.7to 1.0 area. Why, since it has been demonstrated that a damping factor of 1.2 is better than one of 0.7 for a particular Thunderbolt this would tend to indicate that adjusting the damping without good justification is somewhat foolhardy. If in fact the phase noise characteristics of your OCXO are similar toi the one in the Thunderbolt that Tom measured this would degrade the performance. With no way of measuring the effect of such adjustments you are just hoping that your particular Thunderbolt is similar to the one Tom measured. Thats not engineering its more like witchcraft. Tom's recent chart was quite helpful, especially the 1000 sec curve. Now, I hope that Tom or someone else follows up on the suggestion to track performance vs. damping factor. I do understand that the results for any one GPSDO don't *necessarily* translate to other devices, but they don't necessarily don't, either. At least for the TBolts a lot of us are playing with, one good example (like Tom's) may well put mine in a better ballpark than the ballpark the factory wants it to play in, given the factors that you all have described. Thx everyone for the comments. Look forward to the next round! Dick Moore The probability that you will improve the performance significantly without a means of measuring the resultant performance is fairly low. You will never know if either an improvement or a degradation in performance has occurred. The one saving grace being that the factory defaults can always be restored. Bruce ___ 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. -- Steve Rooke - ZL3TUV G8KVD JAKDTTNW Omnium finis imminet ___ 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 TC Damping
Dick, Well, like many here, I don't actually have the equipment, especially the reference std., to do these MDEV, ADEV and other analyses, so, since I use the GPSDO for a frequency standard and not for UTC, I thought I'd get the expert opinions. Magnus has several times indicated here that a TC laying somewhere in and around 100 to 1000 secs is probably optimum. I think you have misinterpreted my postings. I never claimed it was optimum, or at least never intended to. I think 100 secs is good for doing additional experiments with damping parameters. It would be interesting to see just how low the bulb may go. This only since it is obvious that it makes such a clear difference at 100 secs. It's a choice out of measurement and interpretation practicality, not optimum from a use perspective. If you consider my postings you would see that I rather promote the concept of adjusting the time constant dynamically to situations rather than say 1234.5678 seconds is the optimum. 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 TC
But you might show up early or late for dinner, which could have dire consequences. I don't think my wife would notice if I arrived a few hundred pico-seconds earlier or later!!! Dave ___ 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 TC
2009/1/9 David C. Partridge david.partri...@dsl.pipex.com: But you might show up early or late for dinner, which could have dire consequences. I don't think my wife would notice if I arrived a few hundred pico-seconds earlier or later!!! Wow! Your a lucky one! -- Steve Rooke - ZL3TUV G8KVD JAKDTTNW Omnium finis imminet ___ 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 TC Damping
On Jan 9, 2009, at 12:10 AM, time-nuts-requ...@febo.com wrote: Message: 4 Date: Fri, 09 Jan 2009 19:18:57 +1300 From: Bruce Griffiths bruce.griffi...@xtra.co.nz Subject: Re: [time-nuts] GPSDO TC Damping Well, like many here, I don't actually have the equipment, especially the reference std., to do these MDEV, ADEV and other analyses, so, since I use the GPSDO for a frequency standard and not for UTC, I thought I'd get the expert opinions. Magnus has several times indicated here that a TC laying somewhere in and around 100 to 1000 secs is probably optimum. When I enquired some time back about damping in the TBolt, the consensus seemed to be leave it at 1.2. I have, but it just seems to me that won't be optimum for a fixed- position, lab-located frequency standard -- at the moment, I'm leaning toward the 0.7to 1.0 area. Why, since it has been demonstrated that a damping factor of 1.2 is better than one of 0.7 for a particular Thunderbolt this would tend to indicate that adjusting the damping without good justification is somewhat foolhardy. If in fact the phase noise characteristics of your OCXO are similar toi the one in the Thunderbolt that Tom measured this would degrade the performance. With no way of measuring the effect of such adjustments you are just hoping that your particular Thunderbolt is similar to the one Tom measured. Thats not engineering its more like witchcraft. Tom's recent chart was quite helpful, especially the 1000 sec curve. Now, I hope that Tom or someone else follows up on the suggestion to track performance vs. damping factor. I do understand that the results for any one GPSDO don't *necessarily* translate to other devices, but they don't necessarily don't, either. At least for the TBolts a lot of us are playing with, one good example (like Tom's) may well put mine in a better ballpark than the ballpark the factory wants it to play in, given the factors that you all have described. Thx everyone for the comments. Look forward to the next round! Dick Moore The probability that you will improve the performance significantly without a means of measuring the resultant performance is fairly low. You will never know if either an improvement or a degradation in performance has occurred. The one saving grace being that the factory defaults can always be restored. Bruce Bruce, thx for the reminder -- my friend and mentor Paul W. Klipsch was fond of saying that You can't make what you can't measure 'cause you don't know when you've got it made! At the same time, all sorts of wonderful things have come about thru just fooling around. Again, I remark that for all the reasons Tom enumerated -- er, listed -- the manufacturer's choice of settings may not be the best choice for a particular use. When in a strange country, local enquiry is usually recommended. For GPSDOs, a strange country to me, what better place to enquire than here? Dick Moore ___ 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 TC Damping
On Jan 9, 2009, at 2:24 AM, time-nuts-requ...@febo.com wrote: Message: 2 Date: Fri, 09 Jan 2009 10:27:05 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org Subject: Re: [time-nuts] GPSDO TC Damping Dick, Well, like many here, I don't actually have the equipment, especially the reference std., to do these MDEV, ADEV and other analyses, so, since I use the GPSDO for a frequency standard and not for UTC, I thought I'd get the expert opinions. Magnus has several times indicated here that a TC laying somewhere in and around 100 to 1000 secs is probably optimum. I think you have misinterpreted my postings. I never claimed it was optimum, or at least never intended to. I think 100 secs is good for doing additional experiments with damping parameters. It would be interesting to see just how low the bulb may go. This only since it is obvious that it makes such a clear difference at 100 secs. It's a choice out of measurement and interpretation practicality, not optimum from a use perspective. If you consider my postings you would see that I rather promote the concept of adjusting the time constant dynamically to situations rather than say 1234.5678 seconds is the optimum. Cheers, Magnus Sorry, Magnus, I didn't mean to put words in your mouth. I was remembering last Fall, when you suggested that people look at your ADEV plot and to be mindful of the of the bounding slopes of the curves. If I've mis-remembered the emphasis or the facts, I do apologize. I thought your argument then, as I remember it, was strong and valuable. Seems like it gave a good range of possible values to use for Tau in the measurements. I probably won't go far beyond the capabilities of the TBolt, such as implementing a PID controller with dynamic control of variables using a microcontroller and LPGAys and writing my own software, but I love it when you talk that way. Best, Dick Moore ___ 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 TC Damping
Richard Moore wrote: On Jan 9, 2009, at 12:10 AM, time-nuts-requ...@febo.com wrote: Message: 4 Date: Fri, 09 Jan 2009 19:18:57 +1300 From: Bruce Griffiths bruce.griffi...@xtra.co.nz Subject: Re: [time-nuts] GPSDO TC Damping Well, like many here, I don't actually have the equipment, especially the reference std., to do these MDEV, ADEV and other analyses, so, since I use the GPSDO for a frequency standard and not for UTC, I thought I'd get the expert opinions. Magnus has several times indicated here that a TC laying somewhere in and around 100 to 1000 secs is probably optimum. When I enquired some time back about damping in the TBolt, the consensus seemed to be leave it at 1.2. I have, but it just seems to me that won't be optimum for a fixed- position, lab-located frequency standard -- at the moment, I'm leaning toward the 0.7to 1.0 area. Why, since it has been demonstrated that a damping factor of 1.2 is better than one of 0.7 for a particular Thunderbolt this would tend to indicate that adjusting the damping without good justification is somewhat foolhardy. If in fact the phase noise characteristics of your OCXO are similar toi the one in the Thunderbolt that Tom measured this would degrade the performance. With no way of measuring the effect of such adjustments you are just hoping that your particular Thunderbolt is similar to the one Tom measured. Thats not engineering its more like witchcraft. Tom's recent chart was quite helpful, especially the 1000 sec curve. Now, I hope that Tom or someone else follows up on the suggestion to track performance vs. damping factor. I do understand that the results for any one GPSDO don't *necessarily* translate to other devices, but they don't necessarily don't, either. At least for the TBolts a lot of us are playing with, one good example (like Tom's) may well put mine in a better ballpark than the ballpark the factory wants it to play in, given the factors that you all have described. Thx everyone for the comments. Look forward to the next round! Dick Moore The probability that you will improve the performance significantly without a means of measuring the resultant performance is fairly low. You will never know if either an improvement or a degradation in performance has occurred. The one saving grace being that the factory defaults can always be restored. Bruce Bruce, thx for the reminder -- my friend and mentor Paul W. Klipsch was fond of saying that You can't make what you can't measure 'cause you don't know when you've got it made! At the same time, all sorts of wonderful things have come about thru just fooling around. Again, I remark that for all the reasons Tom enumerated -- er, listed -- the manufacturer's choice of settings may not be the best choice for a particular use. When in a strange country, local enquiry is usually recommended. For GPSDOs, a strange country to me, what better place to enquire than here? Dick Moore ___ 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. Dick What does the plot of ADEV vs tau look like when the Thunderbolt OCXO is unlocked and one just logs the Thunderbolt's own measurements of the phase and frequency errors. It should exhibit a minimum at a value of certain value of tau. Setting the loop TC to somewhere near this vlue of Tau is perhaps a good start in the absence of any other data. No other equipment other than the Thunderbolt and a PC is required to do this. Bruce ___ 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 TC Damping
Mark Sims wrote: The good Lady Heather's GPS Disciplined Oscillator Controller Program calculates and plots (also writes the results to the log file) ADEV and OADEV of the Thunderbolt's reported error estimates. My comparison of these auto-ADEVs to the values generated from a Tek DC5010 counter showed they agreed within a factor of two. Note that the DC5010 was measuring the Thunderbolt 10 MHz signal against a 1 MHz cesium reference. The data had to be massaged some where the phase rolled over (the DC5010 counter has a 5 nsec or so bogus zone where the time interval is wrapping). The counter was set up to calculate time intervals over 10 seconds (to get picosecond resolution) so ADEVs below 10 seconds were not available. - What does the plot of ADEV vs tau look like when the Thunderbolt OCXO is unlocked and one just logs the Thunderbolt's own measurements of the phase and frequency errors. It should exhibit a minimum at a value of certain value of tau. _ 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. Mark Where these results obtained when the Thunderbolt OCXO was locked? Bruce ___ 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 TC
On Jan 8, 2009, at 2:58 AM, time-nuts-requ...@febo.com wrote: Message: 6 Date: Thu, 08 Jan 2009 11:51:50 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org Subject: Re: [time-nuts] GPSDO time constant To: Tom Van Baak t...@leapsecond.com, Discussion of precise time and frequency measurement time-nuts@febo.com For ThunderBolt owners it is pretty straightforward to adjust the TC and damping, which is very nice. Use this oppertunity! So, Magnus (and Tom), what damping factor do you suggest for a TBolt? I'm running a verrry long TC now. If 1.2 is not actually critically damped, what value would be? Any guesses? BTW, I really like that plot of Tom's that tracks the oven and then gets better from the GPS... Dick Moore ___ 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 TC
Dick, Richard Moore skrev: On Jan 8, 2009, at 2:58 AM, time-nuts-requ...@febo.com wrote: Message: 6 Date: Thu, 08 Jan 2009 11:51:50 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org Subject: Re: [time-nuts] GPSDO time constant To: Tom Van Baak t...@leapsecond.com, Discussion of precise time and frequency measurement time-nuts@febo.com For ThunderBolt owners it is pretty straightforward to adjust the TC and damping, which is very nice. Use this oppertunity! So, Magnus (and Tom), what damping factor do you suggest for a TBolt? I'm running a verrry long TC now. If 1.2 is not actually critically damped, what value would be? Any guesses? BTW, I really like that plot of Tom's that tracks the oven and then gets better from the GPS... Assuming that damping factors match classical analysis of damping, then the square root of 2 is the answer... 1.414 or there abouts. I would be more conservative than that. I would consider damping factors such as 3-4 or so. I have no support from measurements on GPSDOs but it is reasonable that the rise of gain at and near the PLL frequency we see for other systems will occur and result in similar effects even here. This gain raises the noise floor and amount of gain is directly coupled to the damping factor. It's just standard PLL stuff all over again. The only difference is that we view the result in ADEV or MDEV views. 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 TC
Magnus Danielson wrote: Dick, Richard Moore skrev: On Jan 8, 2009, at 2:58 AM, time-nuts-requ...@febo.com wrote: Message: 6 Date: Thu, 08 Jan 2009 11:51:50 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org Subject: Re: [time-nuts] GPSDO time constant To: Tom Van Baak t...@leapsecond.com, Discussion of precise time and frequency measurement time-nuts@febo.com For ThunderBolt owners it is pretty straightforward to adjust the TC and damping, which is very nice. Use this oppertunity! So, Magnus (and Tom), what damping factor do you suggest for a TBolt? I'm running a verrry long TC now. If 1.2 is not actually critically damped, what value would be? Any guesses? BTW, I really like that plot of Tom's that tracks the oven and then gets better from the GPS... Assuming that damping factors match classical analysis of damping, then the square root of 2 is the answer... 1.414 or there abouts. I would be more conservative than that. I would consider damping factors such as 3-4 or so. I have no support from measurements on GPSDOs but it is reasonable that the rise of gain at and near the PLL frequency we see for other systems will occur and result in similar effects even here. This gain raises the noise floor and amount of gain is directly coupled to the damping factor. It's just standard PLL stuff all over again. The only difference is that we view the result in ADEV or MDEV views. Cheers, Magnus Hej Magnus For a second order loop, the noise bandwidth is minimised for a fixed time constant by choosing a damping factor of 0.5. Using a damping factor of 1.414 increases the noise bandwidth by about 60%. Using a damping factor of 0.7071 only increases the loop noise bandwidth by about 6%. A damping factor of 0.3 increases the noise bandwidth by about 13%. Bruce ___ 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 TC
On Fri, 2009-01-09 at 10:28 +1300, Bruce Griffiths wrote: Richard Moore wrote: On Jan 8, 2009, at 2:58 AM, time-nuts-requ...@febo.com wrote: Message: 6 Date: Thu, 08 Jan 2009 11:51:50 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org Subject: Re: [time-nuts] GPSDO time constant To: Tom Van Baak t...@leapsecond.com,Discussion of precise time and frequency measurement time-nuts@febo.com For ThunderBolt owners it is pretty straightforward to adjust the TC and damping, which is very nice. Use this oppertunity! So, Magnus (and Tom), what damping factor do you suggest for a TBolt? I'm running a verrry long TC now. If 1.2 is not actually critically damped, what value would be? Any guesses? BTW, I really like that plot of Tom's that tracks the oven and then gets better from the GPS... Dick Moore Richard As always, the problem is how do you know that the time constant you are using is anywhere near optimum? Bruce So what is optimum... from control theory we learn, that with an even better model of your system, you can push performance to the edge! But you always loose robustness in doing that. So what is the implication of a to large TC here? Nothing going instable in the control loop? We are just following the freerunning OCXO curve past the point where GPS goes downhill? -- Björn ___ 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 TC
Björn Gabrielsson wrote: On Fri, 2009-01-09 at 10:28 +1300, Bruce Griffiths wrote: Richard Moore wrote: On Jan 8, 2009, at 2:58 AM, time-nuts-requ...@febo.com wrote: Message: 6 Date: Thu, 08 Jan 2009 11:51:50 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org Subject: Re: [time-nuts] GPSDO time constant To: Tom Van Baak t...@leapsecond.com,Discussion of precise time and frequency measurement time-nuts@febo.com For ThunderBolt owners it is pretty straightforward to adjust the TC and damping, which is very nice. Use this oppertunity! So, Magnus (and Tom), what damping factor do you suggest for a TBolt? I'm running a verrry long TC now. If 1.2 is not actually critically damped, what value would be? Any guesses? BTW, I really like that plot of Tom's that tracks the oven and then gets better from the GPS... Dick Moore Richard As always, the problem is how do you know that the time constant you are using is anywhere near optimum? Bruce So what is optimum... from control theory we learn, that with an even better model of your system, you can push performance to the edge! But you always loose robustness in doing that. So what is the implication of a to large TC here? Nothing going instable in the control loop? We are just following the freerunning OCXO curve past the point where GPS goes downhill? -- Björn Björn My point was that measurements are required to establish the optimum for each individual OCXO not just for a given OCXO model. Bruce ___ 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 TC
Bruce Griffiths skrev: Magnus Danielson wrote: Dick, Richard Moore skrev: On Jan 8, 2009, at 2:58 AM, time-nuts-requ...@febo.com wrote: Message: 6 Date: Thu, 08 Jan 2009 11:51:50 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org Subject: Re: [time-nuts] GPSDO time constant To: Tom Van Baak t...@leapsecond.com,Discussion of precise time and frequency measurement time-nuts@febo.com For ThunderBolt owners it is pretty straightforward to adjust the TC and damping, which is very nice. Use this oppertunity! So, Magnus (and Tom), what damping factor do you suggest for a TBolt? I'm running a verrry long TC now. If 1.2 is not actually critically damped, what value would be? Any guesses? BTW, I really like that plot of Tom's that tracks the oven and then gets better from the GPS... Assuming that damping factors match classical analysis of damping, then the square root of 2 is the answer... 1.414 or there abouts. I would be more conservative than that. I would consider damping factors such as 3-4 or so. I have no support from measurements on GPSDOs but it is reasonable that the rise of gain at and near the PLL frequency we see for other systems will occur and result in similar effects even here. This gain raises the noise floor and amount of gain is directly coupled to the damping factor. It's just standard PLL stuff all over again. The only difference is that we view the result in ADEV or MDEV views. Cheers, Magnus Hej Magnus For a second order loop, the noise bandwidth is minimised for a fixed time constant by choosing a damping factor of 0.5. Using a damping factor of 1.414 increases the noise bandwidth by about 60%. Using a damping factor of 0.7071 only increases the loop noise bandwidth by about 6%. A damping factor of 0.3 increases the noise bandwidth by about 13%. Yes, but the bump comes from the increase gain around the resonance and spoils the OCXO/GPS cross-over. The simplified noise-bandwidth measure does not really comply here since they usually build on a simplified model of noise type (white noise - gaussian). A simple check in Gardiner provides both the generic integrating formula, simplified results and a graph showing the smae numbers that you give. I rather beleive what ADEV, MDEV and TDEV experience in this context. We could go back to the real integration formula, adapt it to various powers of f^-n noises and analyse it for the same set of PLL loop filters as analysed by Gardiner. Similarly we could cook up a simulation and do the ADEV, MDEV and TDEV measures. Traditional noise bandwidth measures can be calculated alongside. I am somewhat surprised that you missed the opportunity to correct me as I was giving the incorrect value for damping factor of a critically damped system. It is the square root of 1/2 and not 2, thus 0.7071 is the appropriate damping factor for critically damped systems. I am somewhat surprised that when we have been discussing the bandwidth of the PLLs and considering OCXOs being running with fairly high drift rate we have been assuming second degree loops. This form of acceleration requires third degree responses for proper handling, as being well documented in literature such as Gardiner. Going for third degree response the bandwidth of the loop can be (at least more freely) disconnected from tracking requirements due to drift rate. Another aspect worth mentioning is that a pure PLL with a small bandwidth has a very long trackin period. Heuristics to use wider bandwidths or use frequency measure aided bootstrapping or a diffrential element (PID rather than PI regulator) which is equivalent to also feed a frequency error measurement into the loop will significantly aid the loop in quick lock-in. A Kalman filter approach is just along the same lines and when considered next to some more elaborate schemes of heuristic aided PLL seems to much simpler. While the Kalman filter approach isn't as optimum as claimed to be it is still a useful tool. 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 TC
On Fri, 2009-01-09 at 11:09 +1300, Bruce Griffiths wrote: [...snip... My point was that measurements are required to establish the optimum for each individual OCXO not just for a given OCXO model. Bruce Are those measurements possible to do in real time with only the GPSDO? -- Björn ___ 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 TC
Björn Gabrielsson wrote: On Fri, 2009-01-09 at 11:09 +1300, Bruce Griffiths wrote: [...snip... My point was that measurements are required to establish the optimum for each individual OCXO not just for a given OCXO model. Bruce Are those measurements possible to do in real time with only the GPSDO? -- Björn Björn Not really, however one can measure the relative ADEV as a function of tau for the free running OCXO and the timing receiver. There will be a broad minimum at some tau. The optimum time constant may lie somewhere in the vicinity of that minimum. Its probably impossible to do much better than that without a nice stable statistically independent (for all tau) frequency standard. Bruce ___ 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 TC
Can someone cure this fail message please? Thanks... Secure Connection Failed www.febo.com uses an invalid security certificate. The certificate is not trusted because it is self signed. The certificate is only valid for febo.com. The certificate expired on 11/11/2008 14:57. (Error code: sec_error_expired_issuer_certificate) * This could be a problem with the server's configuration, or it could be someone trying to impersonate the server. * If you have connected to this server successfully in the past, the error may be temporary, and you can try again later. Or you can add an exception… ___ 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 TC
Hej Magnus Magnus Danielson wrote: Bruce Griffiths skrev: Magnus Danielson wrote: Dick, Richard Moore skrev: On Jan 8, 2009, at 2:58 AM, time-nuts-requ...@febo.com wrote: Message: 6 Date: Thu, 08 Jan 2009 11:51:50 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org Subject: Re: [time-nuts] GPSDO time constant To: Tom Van Baak t...@leapsecond.com, Discussion of precise time and frequency measurement time-nuts@febo.com For ThunderBolt owners it is pretty straightforward to adjust the TC and damping, which is very nice. Use this oppertunity! So, Magnus (and Tom), what damping factor do you suggest for a TBolt? I'm running a verrry long TC now. If 1.2 is not actually critically damped, what value would be? Any guesses? BTW, I really like that plot of Tom's that tracks the oven and then gets better from the GPS... Assuming that damping factors match classical analysis of damping, then the square root of 2 is the answer... 1.414 or there abouts. I would be more conservative than that. I would consider damping factors such as 3-4 or so. I have no support from measurements on GPSDOs but it is reasonable that the rise of gain at and near the PLL frequency we see for other systems will occur and result in similar effects even here. This gain raises the noise floor and amount of gain is directly coupled to the damping factor. It's just standard PLL stuff all over again. The only difference is that we view the result in ADEV or MDEV views. Cheers, Magnus Hej Magnus For a second order loop, the noise bandwidth is minimised for a fixed time constant by choosing a damping factor of 0.5. Using a damping factor of 1.414 increases the noise bandwidth by about 60%. Using a damping factor of 0.7071 only increases the loop noise bandwidth by about 6%. A damping factor of 0.3 increases the noise bandwidth by about 13%. Yes, but the bump comes from the increase gain around the resonance and spoils the OCXO/GPS cross-over. The simplified noise-bandwidth measure does not really comply here since they usually build on a simplified model of noise type (white noise - gaussian). A simple check in Gardiner provides both the generic integrating formula, simplified results and a graph showing the smae numbers that you give. Whilst the phase noise of a sawtooth corrected M12+T GPS timing receiver approximates white phase noise (at least for tau 1 day), this may not be so for the receiver used in the Thunderbolt. The phase noise of the OCXO certainly cannot be accurately modeled as white phase noise for large tau. I rather beleive what ADEV, MDEV and TDEV experience in this context. Yes measurements are the key but if one doesnt have a suitable statistically independent low noise frequency reference it isnt possible to optimise the loop parameters for an individual GPSDO. We could go back to the real integration formula, adapt it to various powers of f^-n noises and analyse it for the same set of PLL loop filters as analysed by Gardiner. Similarly we could cook up a simulation and do the ADEV, MDEV and TDEV measures. Traditional noise bandwidth measures can be calculated alongside. I am somewhat surprised that you missed the opportunity to correct me as I was giving the incorrect value for damping factor of a critically damped system. It is the square root of 1/2 and not 2, thus 0.7071 is the appropriate damping factor for critically damped systems. I had noted that your quoted damping factor was incorrect but I suspected that you would realise that. Actually according to Gardener critical damping factor is 1 ( minimum settling with no overshoot for a phase step). However a damping factor of 0.7071 is widely used. I am somewhat surprised that when we have been discussing the bandwidth of the PLLs and considering OCXOs being running with fairly high drift rate we have been assuming second degree loops. This form of acceleration requires third degree responses for proper handling, as being well documented in literature such as Gardiner. Going for third degree response the bandwidth of the loop can be (at least more freely) disconnected from tracking requirements due to drift rate. I only mentioned second order type II loops as the analysis is somewhat simpler and there is no indication from the number of tuning parameters for the Thunderbolt that a higher order loop is involved. Another aspect worth mentioning is that a pure PLL with a small bandwidth has a very long trackin period. Heuristics to use wider bandwidths or use frequency measure aided bootstrapping or a diffrential element (PID rather than PI regulator) which is equivalent to also feed a frequency error measurement into the loop will significantly aid the loop in quick lock-in. A Kalman filter approach is just along the same lines and when
Re: [time-nuts] GPSDO TC
You can cure it by accepting the certificate... Since I'm not doing ecommerce from febo.com, I'm not willing to pay the hundred dollar plus per year fee for an official SSL certificate, and use a home-grown one, which is fine for stopping eavesdropping on the wire. It will give the self-signed error because, well, it is. :-) John Dave Ackrill said the following on 01/08/2009 05:46 PM: Can someone cure this fail message please? Thanks... Secure Connection Failed www.febo.com uses an invalid security certificate. The certificate is not trusted because it is self signed. The certificate is only valid for febo.com. The certificate expired on 11/11/2008 14:57. (Error code: sec_error_expired_issuer_certificate) * This could be a problem with the server's configuration, or it could be someone trying to impersonate the server. * If you have connected to this server successfully in the past, the error may be temporary, and you can try again later. ___ 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 TC
As always, the problem is how do you know that the time constant you are using is anywhere near optimum? Bruce So what is optimum... from control theory we learn, that with an even better model of your system, you can push performance to the edge! But you always loose robustness in doing that. Trouble is, we have many more variables and our set of goodness measurements are the ADEV and friends, which is much more troublesome to analyse than traditional variance and noise bandwidth values. The variance for a PLL is an integral over f multiplying the noise power function of f with the square of the amplitude response over f. It is traditional to simplify this by assume a white noise power N0 (V²/Hz) in which case the noise level creeps out of the integral (since it now is a variable independent of f) and the remaining integral is that of the squared amplitude response of the filter. This can then further be generalized to the noise bandwidth formula. Notice how we started from the variance measure, our traditional sigma value. We already know that it is insufficient to qualify the noise since the the f^-n noise powers does not converge on integration. Using derivate formulations like noise bandwidth those inherit the analysis problems. It even becomes hard achieving something similar as it now is a balance between different noise powers and filtering combines them in new interesting ways. I think we need to either do hard analysis or we notice the tendencies in measures and try to explain them in other general tendencies and knowledge and draw some simplified conclusions and get away with it. So what is the implication of a to large TC here? Nothing going instable in the control loop? We are just following the freerunning OCXO curve past the point where GPS goes downhill? For a second degree loop it would mean loosing lock or not be able to pull in properly. The actual problem is dynamics. Loop bandwidth will scale drift rate numbers with the square. 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 TC
So what is optimum... from control theory we learn, that with an even better model of your system, you can push performance to the edge! But you always loose robustness in doing that. One thing to remember: control theory is akin to a taxinomy which has only elephants and non elephants, in that sense that non-linear control theory is not widely taught and generally considered an evil to stay away from at all cost. Traditional PLL methods are inherently linear and consequently limited in what they can do, but you can achive suprisingly good results by combining a classical PLL with non-linear higher modes or mode switches. You can of course, in the absense of solid theory for what you are attempting, also get it horribly wrong, as in the NTP PLL :-) But the machine-control and robotics community has finally realized that to get machines to have the moves they have to abandon classical control theory, drop the poles and zeros of the plane and instead build physical predictive models. The first area to pick up on this big time were disk drive arm actuators, which are nowhere near a simple differential equation any more. And timekeeping lends itself well to experiment with this, not the least because getting it wrong doesn't smash anything valuable :-) For instance, one thing to think about in the context of GPSDO's is that in addition to the PPS signal, we also have all the other information. For intance it would make sense to loosen the PLL a bit when satellites enter and leave the solution, because that often moves the GPS signal a few nanoseconds abrubtly, which is enough to throw most PLLs into thinking you had a phase jump. There is also the complex 12h signal in most GPS receivers PPS, should that be notched out of the PLL so that it will not react to offsets that have a 12h period ? (obviously only in stationary applications.) So many things to try, so little time... 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 TC
-Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Poul-Henning Kamp Sent: Thursday, January 08, 2009 3:27 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] GPSDO TC And timekeeping lends itself well to experiment with this, not the least because getting it wrong doesn't smash anything valuable :-) But you might show up early or late for dinner, which could have dire consequences. For instance, one thing to think about in the context of GPSDO's is that in addition to the PPS signal, we also have all the other information. For intance it would make sense to loosen the PLL a bit when satellites enter and leave the solution, because that often moves the GPS signal a few nanoseconds abrubtly, which is enough to throw most PLLs into thinking you had a phase jump. This brings up an interesting question. A lot of the discussion here is about taking an off the shelf GPS receiver of one sort or another, and then putting something around it to improve the system. A goodly part of what's in the around it is essentially deconvolving (conceptually) the peculiarities of the receiver. These days, it's not that hard to build the RF section of a GPS receiver, and one can do the processing in an FPGA and attached CPU. Is there an open source signal processing chain (i.e. to acquire and track the PN codes, and generate the raw observables, and then to do the timing/nav solution)? If such a thing exists, or can be created, then you can do a fancier nav solution that explicitly accounts for all the satellites and weights them differently as they appear and disappear. Navsys sells a product that generates GPS signals by simulation and then you load them into a USRP and play them with Gnuradio. They also sell the receiver software. Here's a review of Matlab toolboxes: http://www.constell.org/Downloads/gpsmatlab.article.pdf Xilinx has an article: http://www.xilinx.com/publications/magazines/dsp_01/xc_pdf/p50-53_dsp-gps.pdf That describes a GPS receiver implemented using SystemGenerator, etc., but I suspect that they're not distributing the source code. There's this paper, too: http://old.gps.aau.dk/downloads/IONGNSS2005_BorreAkos_paper.pdf Here's someone who did it as a project in school: http://cegt201.bradley.edu/projects/proj2008/gps/ He tried to convert the Matlab from Akos, et al., to C++ There is also the complex 12h signal in most GPS receivers PPS, should that be notched out of the PLL so that it will not react to offsets that have a 12h period ? (obviously only in stationary applications.) So many things to try, so little time... Indeed... But hey.. Why not start hooking up a USRP or Xilinx Eval board.. Jim ___ 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 TC
Lux, James P skrev: -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Poul-Henning Kamp Sent: Thursday, January 08, 2009 3:27 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] GPSDO TC And timekeeping lends itself well to experiment with this, not the least because getting it wrong doesn't smash anything valuable :-) But you might show up early or late for dinner, which could have dire consequences. True. I was more expecting that when you get it wrong, GPS satellites starts falling from the sky, and they are pretty expensive things to smash flat into the atmosphere. For instance, one thing to think about in the context of GPSDO's is that in addition to the PPS signal, we also have all the other information. For intance it would make sense to loosen the PLL a bit when satellites enter and leave the solution, because that often moves the GPS signal a few nanoseconds abrubtly, which is enough to throw most PLLs into thinking you had a phase jump. This brings up an interesting question. A lot of the discussion here is about taking an off the shelf GPS receiver of one sort or another, and then putting something around it to improve the system. A goodly part of what's in the around it is essentially deconvolving (conceptually) the peculiarities of the receiver. These days, it's not that hard to build the RF section of a GPS receiver, and one can do the processing in an FPGA and attached CPU. Is there an open source signal processing chain (i.e. to acquire and track the PN codes, and generate the raw observables, and then to do the timing/nav solution)? If such a thing exists, or can be created, then you can do a fancier nav solution that explicitly accounts for all the satellites and weights them differently as they appear and disappear. I happens to have some VHDL code lying around. However, the digital front-end is not that much magic involved with. The real work is in the tracking-processing, for which I have some partial C code lying around and there is open source code available. If someone gives me a good RF frontend we could fool around some. Navsys sells a product that generates GPS signals by simulation and then you load them into a USRP and play them with Gnuradio. They also sell the receiver software. Here's a review of Matlab toolboxes: http://www.constell.org/Downloads/gpsmatlab.article.pdf Xilinx has an article: http://www.xilinx.com/publications/magazines/dsp_01/xc_pdf/p50-53_dsp-gps.pdf That describes a GPS receiver implemented using SystemGenerator, etc., but I suspect that they're not distributing the source code. There's this paper, too: http://old.gps.aau.dk/downloads/IONGNSS2005_BorreAkos_paper.pdf Here's someone who did it as a project in school: http://cegt201.bradley.edu/projects/proj2008/gps/ He tried to convert the Matlab from Akos, et al., to C++ We are a few that has a GNSS Sampler, which is basically a GPS frontend hooked to a USB chip and you do correlation etc in the computer. It is a bit of a challenge to get it to track in real time thought there are those that do that. There is also the complex 12h signal in most GPS receivers PPS, should that be notched out of the PLL so that it will not react to offsets that have a 12h period ? (obviously only in stationary applications.) So many things to try, so little time... Indeed... But hey.. Why not start hooking up a USRP or Xilinx Eval board.. Let's do that... some day. 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 TC
-Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Magnus Danielson Sent: Thursday, January 08, 2009 4:15 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] GPSDO TC If someone gives me a good RF frontend we could fool around some. Maxim MAX2741 L1 GPS receiver IC http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4323 MAX2741EVKIT is maybe available.. 2745 is another MAX2745EVKIT (not available for purchase) Maxim recommends: MAX2769 Universal GPS receiver but it's one of those request the data sheet parts.. Anyway, there's probably something out 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 TC Damping
On Jan 8, 2009, at 2:46 PM, time-nuts-requ...@febo.com wrote: Message: 1 Date: Fri, 09 Jan 2009 10:28:35 +1300 From: Bruce Griffiths bruce.griffi...@xtra.co.nz Subject: Re: [time-nuts] GPSDO TC To: Discussion of precise time and frequency measurement time-nuts@febo.com Richard Moore wrote: On Jan 8, 2009, at 2:58 AM, time-nuts-requ...@febo.com wrote: Message: 6 Date: Thu, 08 Jan 2009 11:51:50 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org Subject: Re: [time-nuts] GPSDO time constant To: Tom Van Baak t...@leapsecond.com, Discussion of precise time and frequency measurement time-nuts@febo.com For ThunderBolt owners it is pretty straightforward to adjust the TC and damping, which is very nice. Use this oppertunity! So, Magnus (and Tom), what damping factor do you suggest for a TBolt? I'm running a verrry long TC now. If 1.2 is not actually critically damped, what value would be? Any guesses? BTW, I really like that plot of Tom's that tracks the oven and then gets better from the GPS... Dick Moore Richard As always, the problem is how do you know that the time constant you are using is anywhere near optimum? Bruce Well, like many here, I don't actually have the equipment, especially the reference std., to do these MDEV, ADEV and other analyses, so, since I use the GPSDO for a frequency standard and not for UTC, I thought I'd get the expert opinions. Magnus has several times indicated here that a TC laying somewhere in and around 100 to 1000 secs is probably optimum. When I enquired some time back about damping in the TBolt, the consensus seemed to be leave it at 1.2. I have, but it just seems to me that won't be optimum for a fixed- position, lab-located frequency standard -- at the moment, I'm leaning toward the 0.7to 1.0 area. Tom's recent chart was quite helpful, especially the 1000 sec curve. Now, I hope that Tom or someone else follows up on the suggestion to track performance vs. damping factor. I do understand that the results for any one GPSDO don't *necessarily* translate to other devices, but they don't necessarily don't, either. At least for the TBolts a lot of us are playing with, one good example (like Tom's) may well put mine in a better ballpark than the ballpark the factory wants it to play in, given the factors that you all have described. Thx everyone for the comments. Look forward to the next round! Dick Moore ___ 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 TC Damping
Richard Moore wrote: On Jan 8, 2009, at 2:46 PM, time-nuts-requ...@febo.com wrote: Message: 1 Date: Fri, 09 Jan 2009 10:28:35 +1300 From: Bruce Griffiths bruce.griffi...@xtra.co.nz Subject: Re: [time-nuts] GPSDO TC To: Discussion of precise time and frequency measurement time-nuts@febo.com Richard Moore wrote: On Jan 8, 2009, at 2:58 AM, time-nuts-requ...@febo.com wrote: Message: 6 Date: Thu, 08 Jan 2009 11:51:50 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org Subject: Re: [time-nuts] GPSDO time constant To: Tom Van Baak t...@leapsecond.com,Discussion of precise time and frequency measurement time-nuts@febo.com For ThunderBolt owners it is pretty straightforward to adjust the TC and damping, which is very nice. Use this oppertunity! So, Magnus (and Tom), what damping factor do you suggest for a TBolt? I'm running a verrry long TC now. If 1.2 is not actually critically damped, what value would be? Any guesses? BTW, I really like that plot of Tom's that tracks the oven and then gets better from the GPS... Dick Moore Richard As always, the problem is how do you know that the time constant you are using is anywhere near optimum? Bruce Well, like many here, I don't actually have the equipment, especially the reference std., to do these MDEV, ADEV and other analyses, so, since I use the GPSDO for a frequency standard and not for UTC, I thought I'd get the expert opinions. Magnus has several times indicated here that a TC laying somewhere in and around 100 to 1000 secs is probably optimum. When I enquired some time back about damping in the TBolt, the consensus seemed to be leave it at 1.2. I have, but it just seems to me that won't be optimum for a fixed- position, lab-located frequency standard -- at the moment, I'm leaning toward the 0.7to 1.0 area. Why, since it has been demonstrated that a damping factor of 1.2 is better than one of 0.7 for a particular Thunderbolt this would tend to indicate that adjusting the damping without good justification is somewhat foolhardy. If in fact the phase noise characteristics of your OCXO are similar toi the one in the Thunderbolt that Tom measured this would degrade the performance. With no way of measuring the effect of such adjustments you are just hoping that your particular Thunderbolt is similar to the one Tom measured. Thats not engineering its more like witchcraft. Tom's recent chart was quite helpful, especially the 1000 sec curve. Now, I hope that Tom or someone else follows up on the suggestion to track performance vs. damping factor. I do understand that the results for any one GPSDO don't *necessarily* translate to other devices, but they don't necessarily don't, either. At least for the TBolts a lot of us are playing with, one good example (like Tom's) may well put mine in a better ballpark than the ballpark the factory wants it to play in, given the factors that you all have described. Thx everyone for the comments. Look forward to the next round! Dick Moore The probability that you will improve the performance significantly without a means of measuring the resultant performance is fairly low. You will never know if either an improvement or a degradation in performance has occurred. The one saving grace being that the factory defaults can always be restored. Bruce ___ 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.
