Re: [time-nuts] Framework for simulation of oscillators
Hi Tom, On 03/28/2016 04:25 AM, Tom Van Baak wrote: BTW: I discovered that Timelab stops processing after 10'000'000 datapoints, which is kind inconvenient when doing a long term measurment... Attila Kinali I've collected a day of TimeLab/TimePod data at tau 0.001 which is 86'400'000 datapoints. Should be no problem. Note Stable32 has a user-configurable limit (Conf -> Data -> Max_Data_File_Size). Or you can decimate during reading. My command line tools have no sample limit (well, just malloc() limited) and can be orders of magnitude faster than Stable32 or Timelab since they are batch and not GUI. But this begs the question -- what are you doing with 10M datapoints? Once you get beyond a couple of decades of data it's often better to compute statistics in segments and display all the segments of the whole as a time series. So, for example, don't compute a single stddev or ADEV number from the entire 10M data set. While this gives an apparently "more precise" measurement due to sampling, it will also hide key factors like trends, periodicity, spectral components, outliers, and glitches. Agree. You need to use a better tool for those systematics than ADEV is. MDEV and PDEV is even better at filtering out noise and give power estimates, which smoothes out it more, which thus just makes it harder to discover. The dynamic ADEV can help a litte. It is the diversity of plots, ADEV, FFT and phase-/frequency-plots (residue plots of some suitable matching model) which can help to unveil behaviors of interest. Swapping between MDEV and TDEV can at some times be illustrative. 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] Framework for simulation of oscillators
> > BTW: I discovered that Timelab stops processing after 10'000'000 datapoints, > > which is kind inconvenient when doing a long term measurment... > > I didn't know that. Good to know. Attila, wasn't this related to an invalid ':' character in the filename coming through from VirtualBox? Or is this issue different from the one we discussed in email last month? -- john, KE5FX Miles Design LLC ___ 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] Framework for simulation of oscillators
Hi > On Mar 27, 2016, at 9:23 PM, John Miles wrote: > >> BTW: I discovered that Timelab stops processing after 10'000'000 datapoints, >> which is kind inconvenient when doing a long term measurment... > > It had better not! :) Any steps to reproduce? > It’s never stopped here …. I routinely run over 10M points. Bob > -- john, KE5FX > Miles Design LLC > > ___ > 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] Framework for simulation of oscillators
Goddag Attila, On 03/28/2016 01:48 AM, Attila Kinali wrote: N'abend Magnus, On Tue, 22 Mar 2016 01:11:41 +0100 Magnus Danielson wrote: Yes, of course. Noise is generally not i.i.d. and thus one cannot use the same generator for more than one model in the same simulation. Oh.. and just to make things more complicated: Gaussian noise is not necessarily white (only if it's Gaussian distributed and i.i.d.). And noise with white spectrum is not necessarily Gaussian or i.i.d. (only if phase and amplitude noise are both white). Indeed. BTW. You are increasingly PhD damaged in your use of abbreviations without explaining them on first use, as you should. Oops.. sorry about that. i.i.d = independent, identically distributed. I.e. the samples have all the same probability density function, which does not change over time and does not depend on any previous samples. Indeed. You can have noise which at first look seems Gaussian, but isn't, as there is systematics hidden within it. For proper estimations the systematics needs to be separated from the random noise and both estimated without the effect of the other, as they then can scale significantly different depending on what question you ask about the system. For communications I use a scale factor of 14 for the Bit Error Rate (BER) of 1E-12 (the value of 14 is an approximation, but since you need margin on it, it's fine to get the right proportions). Another aspect is that noise which looks Gaussian at first look can hide other noises such as flicker etc. which only reveal itself for longer observations times. As we deal with oscillators, we have three or four noise-forms to deal with. Consider that you have an integrator for the oscillator, and a null due to the Q. Look at the Leeson model (Feb 1966), see also Enrico's book on phase noise. I don't see how the Q, beside acting as an integrator, will affect my system (keep in mind, the "loop" is non-linear). But I havent gone through the math here... Without going through Leeson in details, only the part of the spectrum being inside of the f/Q bandwidth will behave as integration for the noise inside the loop. Signals from the outside will integrate, after being low-pass filtered by the f/Q bandwidth. The oscillator is just like a loop. I think I get what are are hinting at, but I do not fully understand it. I guess we should discuss this next week in York. It's a loop with an integrator in it. Signals inside the loop and signals outside (being introduced into the loop) the loop will have different filtering effects on them. No big magic, but it is easier to show with paper and pen. Seems that my link to the Leeson paper got lost. Something according to those lines might be where your systems behavior can be explained. Well, we do not really have a deadband (save the TDC resolution and my guess is that the inherent noise in the system does a good job in decreasing this "deadband" as well). The long cycle time results rather in a small loop bandwidth. As we only measure one pulse per cycle, everything that happens between pulses averages out. Ie if we have any deadband like jitter behavior, we don't see it. Well, maybe not really, but what you have is kinda similar as the outermost will have a higher gain being pushed back and the more central will have weaker pull-in. The time between pulses is indeed a measure to loop time-constant/bandwidth. I just say the dead-band give similar pulses. We currently have a long term measurement running. And there are intermittent rises in "noise" of the node pair we are measuring. My assumption is that the order of the center frequencies of the oscillators changed, thus swapping two of the nodes in their pulse time order. When two nodes get close to eachother the algorithm switches between using nodes A & B and using nodes A & C. This can indeed be seen as a deadband behaviour. Yes. I meant it as somewhat of an analogy. Notice how each of your nodes makes independent choices and how a shift in such a choice will indirectly affect the other nodes through how the node will steer it's own oscillator. I'll look further into that behavior as soon as we have some simulation system running and I see more than one node pair. Can you record the TICs and the "selected TICs" (essentially 1 bit of if the TIC was selected or not in each min/max elimination round)? That would suffice to analyze the systems internal dynamics. External TIC measurements is only to evaluate the variances for an external viewer (which the system itself isn't really able to fully value, as the common mode variations isn't observeable). BTW: I discovered that Timelab stops processing after 10'000'000 datapoints, which is kind inconvenient when doing a long term measurment... I didn't know that. Good to know. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://ww
Re: [time-nuts] Framework for simulation of oscillators
I regularly acquire and process over 4x that number using a Timepod. Bruce On Monday, 28 March 2016 3:02 PM, John Miles wrote: > BTW: I discovered that Timelab stops processing after 10'000'000 datapoints, > which is kind inconvenient when doing a long term measurment... It had better not! :) Any steps to reproduce? -- john, KE5FX Miles Design LLC ___ 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] Framework for simulation of oscillators
> BTW: I discovered that Timelab stops processing after 10'000'000 datapoints, > which is kind inconvenient when doing a long term measurment... > > Attila Kinali I've collected a day of TimeLab/TimePod data at tau 0.001 which is 86'400'000 datapoints. Should be no problem. Note Stable32 has a user-configurable limit (Conf -> Data -> Max_Data_File_Size). Or you can decimate during reading. My command line tools have no sample limit (well, just malloc() limited) and can be orders of magnitude faster than Stable32 or Timelab since they are batch and not GUI. But this begs the question -- what are you doing with 10M datapoints? Once you get beyond a couple of decades of data it's often better to compute statistics in segments and display all the segments of the whole as a time series. So, for example, don't compute a single stddev or ADEV number from the entire 10M data set. While this gives an apparently "more precise" measurement due to sampling, it will also hide key factors like trends, periodicity, spectral components, outliers, and glitches. I'm not sure if you got your answer on synthetic data, but Stable32 has a data noise generator, where you get to specify alpha from -2 to +2. I created 1M samples of each of the 5 noise types and use those cached files as a noise reference. See also the 5 noise types in high-res here: http://www.leapsecond.com/pages/allan/Exploring_Allan_Deviation_v2.pdf http://www.leapsecond.com/pages/allan/ /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] Framework for simulation of oscillators
> BTW: I discovered that Timelab stops processing after 10'000'000 datapoints, > which is kind inconvenient when doing a long term measurment... It had better not! :) Any steps to reproduce? -- john, KE5FX Miles Design LLC ___ 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] Framework for simulation of oscillators
N'abend Magnus, On Tue, 22 Mar 2016 01:11:41 +0100 Magnus Danielson wrote: > > Yes, of course. Noise is generally not i.i.d. and thus one cannot use > > the same generator for more than one model in the same simulation. > > > > Oh.. and just to make things more complicated: Gaussian noise is not > > necessarily white (only if it's Gaussian distributed and i.i.d.). > > And noise with white spectrum is not necessarily Gaussian or i.i.d. > > (only if phase and amplitude noise are both white). > > Indeed. > > BTW. You are increasingly PhD damaged in your use of abbreviations > without explaining them on first use, as you should. Oops.. sorry about that. i.i.d = independent, identically distributed. I.e. the samples have all the same probability density function, which does not change over time and does not depend on any previous samples. > >> Consider that you have an integrator for the oscillator, and a null due > >> to the Q. Look at the Leeson model (Feb 1966), see also Enrico's book on > >> phase noise. > > > > I don't see how the Q, beside acting as an integrator, will affect my system > > (keep in mind, the "loop" is non-linear). But I havent gone through the > > math here... > > Without going through Leeson in details, only the part of the spectrum > being inside of the f/Q bandwidth will behave as integration for the > noise inside the loop. Signals from the outside will integrate, after > being low-pass filtered by the f/Q bandwidth. The oscillator is just > like a loop. I think I get what are are hinting at, but I do not fully understand it. I guess we should discuss this next week in York. > >> Something according to those lines might be where your systems behavior > >> can be explained. > > > > Well, we do not really have a deadband (save the TDC resolution and > > my guess is that the inherent noise in the system does a good job > > in decreasing this "deadband" as well). The long cycle time results > > rather in a small loop bandwidth. As we only measure one pulse per > > cycle, everything that happens between pulses averages out. Ie if we > > have any deadband like jitter behavior, we don't see it. > > Well, maybe not really, but what you have is kinda similar as the > outermost will have a higher gain being pushed back and the more central > will have weaker pull-in. The time between pulses is indeed a measure to > loop time-constant/bandwidth. > > I just say the dead-band give similar pulses. We currently have a long term measurement running. And there are intermittent rises in "noise" of the node pair we are measuring. My assumption is that the order of the center frequencies of the oscillators changed, thus swapping two of the nodes in their pulse time order. When two nodes get close to eachother the algorithm switches between using nodes A & B and using nodes A & C. This can indeed be seen as a deadband behaviour. I'll look further into that behavior as soon as we have some simulation system running and I see more than one node pair. BTW: I discovered that Timelab stops processing after 10'000'000 datapoints, which is kind inconvenient when doing a long term measurment... Attila Kinali -- Reading can seriously damage your ignorance. -- unknown ___ 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] Framework for simulation of oscillators
Hi, On 03/21/2016 10:52 PM, Attila Kinali wrote: Good evening On Sun, 20 Mar 2016 22:33:15 +0100 Magnus Danielson wrote: As you read the appendixes of ITU-T Rec. G.823, G.824 and G.825 they will not give very detailed information, but hints. The flicker noise model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article "Large Sample Simulation of Flicker Noise". So far I have seen three approaches to 1/f^a simulation: * filter in the time domain * filter in the frequency domain * simulate a random process with the right properties Barnes&Greenhall[1], Park&Muhammad&Roy[2] on which Brooker&Inggs[3] is based on fall into the first category. Kasdin[4] and Ashby[5] falls into category two (Kasdin also gives a nice overview of the problem space and the solutions applied there). From the third category, i've sofar only read Milotti[6]. Chuck Greenhall have a nice overview of methods for flicker noise, and goes in to some depth on it. If this simulation approach is sufficient for either of your efforts, or not, depends on what you try to capture. For instance, the oscillators performance have been idealized in assuming fully linear EFC, fully linear integrator of the crystal, assuming noise profile etc. This may or may not be sufficient. Inherent lowpass filtering may be important or not. The modeling of the EFC and temperature dependence is orthogonal to the noise modeling, AFAIK. And if I understand the physical properties of a crystal, resp. the oscillator correctly, they can be modeled completely independent without degrading the accuracy. Of course, noise on the EFC signal will have an influence on the crystal noise, and this noise can be of 1/f^a type itself as well. Depending on the tau of interest, temperature variations may or may not affect your plots. Noise on EFC will be filtered, and then integrated. 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] Framework for simulation of oscillators
On 03/21/2016 11:14 PM, Attila Kinali wrote: Good nat! On Sun, 20 Mar 2016 23:52:22 +0100 Magnus Danielson wrote: I'm currently using the code from Brooker and Inggs[1,2], but the code is quite convoluted and it will take me some time to extract it and get it working properly. (but then, it's the only piece of code that I found that does seem to be viable at all) Could not get to the article. Looking at the code, it honestly does not seem to be very different to that of Barnes&Greenhall. It is very similar in the approach. The only difference is that it uses a multirate filter chain with multiple gaussian noise sources instead of filtering just one. This and one additional trick make this numerically more efficient then the Barnes&Greenhall approach, especially when long simulation times with high accuracy are needed. I have been considering similar methods, fairly natural development for long-term stuff. You probably want a systematic effect model of phase, frequency and drift. Also a cubic frequency vs. temperature. All the properties needs to be different for each instance. Similarly, the flicker filter needs to be independent for each oscillator. What do you mean with "the flicker filter needs to be independent"? Each oscillator will get its own noise source, if you mean that. Yes. When you have a white noise-source, you can take all your samples from the same source. With non-white sources, you take white noise and filter it, that filtering mechanism holds a state, and if you need two or more independent sources, then that state would make the assumption of independent sources invalid. Yes, of course. Noise is generally not i.i.d. and thus one cannot use the same generator for more than one model in the same simulation. Oh.. and just to make things more complicated: Gaussian noise is not necessarily white (only if it's Gaussian distributed and i.i.d.). And noise with white spectrum is not necessarily Gaussian or i.i.d. (only if phase and amplitude noise are both white). Indeed. BTW. You are increasingly PhD damaged in your use of abbreviations without explaining them on first use, as you should. I am not sure yet, how to model the Q, or whether that actually needs to be modelled with anything else but the proper noise/stability characteristics and the low pass on the EFC. Consider that you have an integrator for the oscillator, and a null due to the Q. Look at the Leeson model (Feb 1966), see also Enrico's book on phase noise. I don't see how the Q, beside acting as an integrator, will affect my system (keep in mind, the "loop" is non-linear). But I havent gone through the math here... Without going through Leeson in details, only the part of the spectrum being inside of the f/Q bandwidth will behave as integration for the noise inside the loop. Signals from the outside will integrate, after being low-pass filtered by the f/Q bandwidth. The oscillator is just like a loop. The current plan is to implement an oscillator model that mimics the correct stability i'm seeing, then add EFC (first w/o low pass filtering). This should already work "properly" and give a first indication on how the system behaves. Then step by step add the non-idealities, like the low pass filter on the EFC, the high DNL of the TDC, the noise on the pulse output and the TDC input, ... until I get close to what we measure. Just being able to simulate the locking mechanism should be a good start. Then you should try to get it to simulate the noise-curves you're seeing. Not all noise curves. The high jitter is mostly due to the DNL (and thus lack of accuracy) of the TDC. Leaving this out will give me the imporovement of stability compared to the free running oscillator, but will be quite a bit better than with the TDC correctly modelled. TDC and noise is "interesting". The EFC measures you have done so far indicate that your steering essentially operates as if you do where doing something similar to charge-pump operation. Hmm.. can you elaborate a bit on why you think so? The correction pulse every now and then is how a charge-pump PLL operates. In between the corrections the oscillator coasts undiciplined with the filters state as memory. The 4046 charge-pump has a dead-band Ah.. Well, I have only ever used modern charge pump PLLs that don't have the dead band issue (or at least not to the extend to be annoying) :-) Depends on what you are doing. For some stuff it may be good enough. Something according to those lines might be where your systems behavior can be explained. Well, we do not really have a deadband (save the TDC resolution and my guess is that the inherent noise in the system does a good job in decreasing this "deadband" as well). The long cycle time results rather in a small loop bandwidth. As we only measure one pulse per cycle, everything that happens between pulses averages out. Ie if we have any deadband like jitter behavior, we don't see it. Well,
Re: [time-nuts] Framework for simulation of oscillators
Good nat! On Sun, 20 Mar 2016 23:52:22 +0100 Magnus Danielson wrote: > > I'm currently using the code from Brooker and Inggs[1,2], but the code > > is quite convoluted and it will take me some time to extract it and > > get it working properly. (but then, it's the only piece of code > > that I found that does seem to be viable at all) > > Could not get to the article. Looking at the code, it honestly does not > seem to be very different to that of Barnes&Greenhall. It is very similar in the approach. The only difference is that it uses a multirate filter chain with multiple gaussian noise sources instead of filtering just one. This and one additional trick make this numerically more efficient then the Barnes&Greenhall approach, especially when long simulation times with high accuracy are needed. > >> You probably want a systematic effect model of phase, frequency and > >> drift. Also a cubic frequency vs. temperature. All the properties needs > >> to be different for each instance. Similarly, the flicker filter needs > >> to be independent for each oscillator. > > > > What do you mean with "the flicker filter needs to be independent"? > > Each oscillator will get its own noise source, if you mean that. > > Yes. When you have a white noise-source, you can take all your samples > from the same source. With non-white sources, you take white noise and > filter it, that filtering mechanism holds a state, and if you need two > or more independent sources, then that state would make the assumption > of independent sources invalid. Yes, of course. Noise is generally not i.i.d. and thus one cannot use the same generator for more than one model in the same simulation. Oh.. and just to make things more complicated: Gaussian noise is not necessarily white (only if it's Gaussian distributed and i.i.d.). And noise with white spectrum is not necessarily Gaussian or i.i.d. (only if phase and amplitude noise are both white). > > I am not sure yet, how to model the Q, or whether that actually needs > > to be modelled with anything else but the proper noise/stability > > characteristics and the low pass on the EFC. > > Consider that you have an integrator for the oscillator, and a null due > to the Q. Look at the Leeson model (Feb 1966), see also Enrico's book on > phase noise. I don't see how the Q, beside acting as an integrator, will affect my system (keep in mind, the "loop" is non-linear). But I havent gone through the math here... > > The current plan is to implement an oscillator model that mimics the > > correct stability i'm seeing, then add EFC (first w/o low pass filtering). > > This should already work "properly" and give a first indication on how > > the system behaves. Then step by step add the non-idealities, like the > > low pass filter on the EFC, the high DNL of the TDC, the noise on the > > pulse output and the TDC input, ... until I get close to what we measure. > > Just being able to simulate the locking mechanism should be a good > start. Then you should try to get it to simulate the noise-curves you're > seeing. Not all noise curves. The high jitter is mostly due to the DNL (and thus lack of accuracy) of the TDC. Leaving this out will give me the imporovement of stability compared to the free running oscillator, but will be quite a bit better than with the TDC correctly modelled. > >> The EFC measures you have done so far indicate that your steering > >> essentially operates as if you do where doing something similar to > >> charge-pump operation. > > > > Hmm.. can you elaborate a bit on why you think so? > > The correction pulse every now and then is how a charge-pump PLL > operates. In between the corrections the oscillator coasts undiciplined > with the filters state as memory. The 4046 charge-pump has a dead-band Ah.. Well, I have only ever used modern charge pump PLLs that don't have the dead band issue (or at least not to the extend to be annoying) :-) > Something according to those lines might be where your systems behavior > can be explained. Well, we do not really have a deadband (save the TDC resolution and my guess is that the inherent noise in the system does a good job in decreasing this "deadband" as well). The long cycle time results rather in a small loop bandwidth. As we only measure one pulse per cycle, everything that happens between pulses averages out. Ie if we have any deadband like jitter behavior, we don't see it. Attila Kinali -- Reading can seriously damage your ignorance. -- unknown ___ 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] Framework for simulation of oscillators
Good evening On Sun, 20 Mar 2016 22:33:15 +0100 Magnus Danielson wrote: > As you read the appendixes of ITU-T Rec. G.823, G.824 and G.825 they > will not give very detailed information, but hints. The flicker noise > model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article "Large > Sample Simulation of Flicker Noise". So far I have seen three approaches to 1/f^a simulation: * filter in the time domain * filter in the frequency domain * simulate a random process with the right properties Barnes&Greenhall[1], Park&Muhammad&Roy[2] on which Brooker&Inggs[3] is based on fall into the first category. Kasdin[4] and Ashby[5] falls into category two (Kasdin also gives a nice overview of the problem space and the solutions applied there). >From the third category, i've sofar only read Milotti[6]. > If this simulation approach is sufficient for either of your efforts, or > not, depends on what you try to capture. For instance, the oscillators > performance have been idealized in assuming fully linear EFC, fully > linear integrator of the crystal, assuming noise profile etc. This may > or may not be sufficient. Inherent lowpass filtering may be important or > not. The modeling of the EFC and temperature dependence is orthogonal to the noise modeling, AFAIK. And if I understand the physical properties of a crystal, resp. the oscillator correctly, they can be modeled completely independent without degrading the accuracy. Of course, noise on the EFC signal will have an influence on the crystal noise, and this noise can be of 1/f^a type itself as well. Attila Kinali [1] "Large Sample Simulation of Flicker Noise", by Barnes and Greenhall, 1987 http://www.dtic.mil/dtic/tr/fulltext/u2/a495531.pdf And its correction: http://tycho.usno.navy.mil/ptti/1992papers/Vol%2024_44.pdf [2] "Efficient Modeling of 1/f^2 Noise Using Multirate Process", by Park, Muhammad, Roy, 2006 http://dx.doi.org/10.1109/TCAD.2005.855953 [3]"Efficient Generation of f^a Noise Sequences for Pulsed Radar Simulation", by Brooker, Inggs, 2010 http://dx.doi.org/10.1109/TAES.2010.5461653 [4] "Discrete Simulation of Colored Noise and Stochastic Processes and 1/f^a Power Law Noise Generation", by Kasdin, 1995 http://www.umbc.edu/photonics/Menyuk/Phase-Noise/kasdin_ProcIEEE_950501n.pdf [5] "Probability Distributions and Confidence Intervals for Simulated Power Law Noise", by Neil Ashby, 2015 http://dx.doi.org/10.1109/TUFFC.2013.006167 (open access) [6] "Exact numerical simulation of power-law noises", by Milotti, 2005 http://dx.doi.org/10.1103/PhysRevE.72.056701 -- Reading can seriously damage your ignorance. -- unknown ___ 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] Framework for simulation of oscillators
Hi Ulrich, Interesting article. Did you see Craig Nelsons article on building a mixer out of 2NA transistors? Cheers, Magnus On 03/21/2016 12:45 AM, ka2...@aol.com wrote: http://joerg-berkner.de/Fachartikel/pdf/2000_AKB_Berkner_1f_noise.pdf In a message dated 3/20/2016 5:33:21 P.M. Eastern Daylight Time, mag...@rubidium.se writes: Ulrich and Attila, As you read the appendixes of ITU-T Rec. G.823, G.824 and G.825 they will not give very detailed information, but hints. The flicker noise model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article "Large Sample Simulation of Flicker Noise". Be aware of Chuck's follow-up correction. Further, they model the amount of noise and add into the loop in place of the oscillator, which then has a normal PI-loop. Such a simulation can be done fairly efficiently considering that the oscillator and loop is very simple linear models of phase, not too different to what I proposed. For the stuff that Attila needs to simulate, some additional thought needs to go into how to simulate the effect he is seeing, but a fairly simple approach should be interesting to try out initially. The Barnes&Greenhall flicker generator builds on a filter-bank where the poles and nulls is placed such that they approximate the flicker noise slope of 1/tau. This is a generalized variant of Jim Barnes PhD work where he had fixed relations and where Chuck Greenhall have contributed significantly by providing means to setup the state of the filter such that the filter will act as a filter in equilibrium from start, rather than taking much time to converge, something which may introduce a bias into the measurement results. I have re-implemented their BASIC-code into C and run Chuck's original code along-side to verify (just to find where I did my mistake in converting it). If this simulation approach is sufficient for either of your efforts, or not, depends on what you try to capture. For instance, the oscillators performance have been idealized in assuming fully linear EFC, fully linear integrator of the crystal, assuming noise profile etc. This may or may not be sufficient. Inherent lowpass filtering may be important or not. I've done PLL simulations many times, in fixed integer, in floating point and in VHDL. It's always a challenge to model it right to the needs. Let me also have reader of this thread reminded of TvB's simulator for a GPSDO, which is interesting as it adds real GPS PPS data and real open loop oscillator data with a simple PLL oscillator core you can then tweak. Great fun in all it's simplicity and nice way to do reality check. I've done similar things with about the same code amount that have proved very useful. However, recall that whenever you make a model, you do it with assumptions for your particular problem, so some stuff will be left out and some will be particular to your problem. One guys model may be crap to another ones problem. There is a few tricks to be learned and a few things to recall to include. Cheers, Magnus On 03/20/2016 09:19 PM, ka2...@aol.com wrote: > I am interested in this topic too, thanks, Ulrich > In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight Time, > mag...@rubidium.dyndns.org writes: > >Attila, > > On 03/17/2016 10:56 AM, Attila Kinali wrote: > > Moin, > > > > Measurement we recently did showed some quite unexpected behaviour > > and I am trying to figure out where this comes from. For this > > I would like to simulate our system, which consists of multiple > > crystal oscillators that are coupled in a non-linear way (kind of > > a vector-PLL with a step transfer function) with a "loop bandwidth" > > of a few 10kHz. > > > > My goal is to simulate the noise properties of the crystal > oscillators > > both short term (in the 10us range) and long term (several 1000 > seconds) > > in a way that models reality closely (ie short term instability >is uncorrelated > > while long term instability is correlated through temp/humidity/...) > > > > As I am pretty sure not the first one to attempt something like this, > > I would like to ask whether someone has already some software >framework > > around for this kind of simulation? > > > > If not, does someone have pointers how to write realistic >oscillator models > > for this kind of short and long term simulation? > > It is a large field that you tries to cover. What you need to do is >actually find the model that models the behavior of your physical setup
Re: [time-nuts] Framework for simulation of oscillators
http://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=2270&context=etd In a message dated 3/20/2016 5:33:21 P.M. Eastern Daylight Time, mag...@rubidium.se writes: Ulrich and Attila, As you read the appendixes of ITU-T Rec. G.823, G.824 and G.825 they will not give very detailed information, but hints. The flicker noise model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article "Large Sample Simulation of Flicker Noise". Be aware of Chuck's follow-up correction. Further, they model the amount of noise and add into the loop in place of the oscillator, which then has a normal PI-loop. Such a simulation can be done fairly efficiently considering that the oscillator and loop is very simple linear models of phase, not too different to what I proposed. For the stuff that Attila needs to simulate, some additional thought needs to go into how to simulate the effect he is seeing, but a fairly simple approach should be interesting to try out initially. The Barnes&Greenhall flicker generator builds on a filter-bank where the poles and nulls is placed such that they approximate the flicker noise slope of 1/tau. This is a generalized variant of Jim Barnes PhD work where he had fixed relations and where Chuck Greenhall have contributed significantly by providing means to setup the state of the filter such that the filter will act as a filter in equilibrium from start, rather than taking much time to converge, something which may introduce a bias into the measurement results. I have re-implemented their BASIC-code into C and run Chuck's original code along-side to verify (just to find where I did my mistake in converting it). If this simulation approach is sufficient for either of your efforts, or not, depends on what you try to capture. For instance, the oscillators performance have been idealized in assuming fully linear EFC, fully linear integrator of the crystal, assuming noise profile etc. This may or may not be sufficient. Inherent lowpass filtering may be important or not. I've done PLL simulations many times, in fixed integer, in floating point and in VHDL. It's always a challenge to model it right to the needs. Let me also have reader of this thread reminded of TvB's simulator for a GPSDO, which is interesting as it adds real GPS PPS data and real open loop oscillator data with a simple PLL oscillator core you can then tweak. Great fun in all it's simplicity and nice way to do reality check. I've done similar things with about the same code amount that have proved very useful. However, recall that whenever you make a model, you do it with assumptions for your particular problem, so some stuff will be left out and some will be particular to your problem. One guys model may be crap to another ones problem. There is a few tricks to be learned and a few things to recall to include. Cheers, Magnus On 03/20/2016 09:19 PM, ka2...@aol.com wrote: > I am interested in this topic too, thanks, Ulrich > In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight Time, > mag...@rubidium.dyndns.org writes: > > Attila, > > On 03/17/2016 10:56 AM, Attila Kinali wrote: > > Moin, > > > > Measurement we recently did showed some quite unexpected behaviour > > and I am trying to figure out where this comes from. For this > > I would like to simulate our system, which consists of multiple > > crystal oscillators that are coupled in a non-linear way (kind of > > a vector-PLL with a step transfer function) with a "loop bandwidth" > > of a few 10kHz. > > > > My goal is to simulate the noise properties of the crystal > oscillators > > both short term (in the 10us range) and long term (several 1000 > seconds) > > in a way that models reality closely (ie short term instability > is uncorrelated > > while long term instability is correlated through temp/humidity/...) > > > > As I am pretty sure not the first one to attempt something like this, > > I would like to ask whether someone has already some software > framework > > around for this kind of simulation? > > > > If not, does someone have pointers how to write realistic > oscillator models > > for this kind of short and long term simulation? > > It is a large field that you tries to cover. What you need to do is > actually find the model that models the behavior of your physical setup. > > You need to have white and flicker noises, there is a few ways to get > the flicker coloring. I did some hacking of the setup, and ran tests > against Chuck Greenhalls original BASIC code. > > You probably want a systematic effect model of phase, frequency and > drift. Also a cubic frequency vs. temperature. All the properties needs > to be different for each instance. Similarly, the flicker filter needs > to be independent f
Re: [time-nuts] Framework for simulation of oscillators
http://joerg-berkner.de/Fachartikel/pdf/2000_AKB_Berkner_1f_noise.pdf In a message dated 3/20/2016 5:33:21 P.M. Eastern Daylight Time, mag...@rubidium.se writes: Ulrich and Attila, As you read the appendixes of ITU-T Rec. G.823, G.824 and G.825 they will not give very detailed information, but hints. The flicker noise model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article "Large Sample Simulation of Flicker Noise". Be aware of Chuck's follow-up correction. Further, they model the amount of noise and add into the loop in place of the oscillator, which then has a normal PI-loop. Such a simulation can be done fairly efficiently considering that the oscillator and loop is very simple linear models of phase, not too different to what I proposed. For the stuff that Attila needs to simulate, some additional thought needs to go into how to simulate the effect he is seeing, but a fairly simple approach should be interesting to try out initially. The Barnes&Greenhall flicker generator builds on a filter-bank where the poles and nulls is placed such that they approximate the flicker noise slope of 1/tau. This is a generalized variant of Jim Barnes PhD work where he had fixed relations and where Chuck Greenhall have contributed significantly by providing means to setup the state of the filter such that the filter will act as a filter in equilibrium from start, rather than taking much time to converge, something which may introduce a bias into the measurement results. I have re-implemented their BASIC-code into C and run Chuck's original code along-side to verify (just to find where I did my mistake in converting it). If this simulation approach is sufficient for either of your efforts, or not, depends on what you try to capture. For instance, the oscillators performance have been idealized in assuming fully linear EFC, fully linear integrator of the crystal, assuming noise profile etc. This may or may not be sufficient. Inherent lowpass filtering may be important or not. I've done PLL simulations many times, in fixed integer, in floating point and in VHDL. It's always a challenge to model it right to the needs. Let me also have reader of this thread reminded of TvB's simulator for a GPSDO, which is interesting as it adds real GPS PPS data and real open loop oscillator data with a simple PLL oscillator core you can then tweak. Great fun in all it's simplicity and nice way to do reality check. I've done similar things with about the same code amount that have proved very useful. However, recall that whenever you make a model, you do it with assumptions for your particular problem, so some stuff will be left out and some will be particular to your problem. One guys model may be crap to another ones problem. There is a few tricks to be learned and a few things to recall to include. Cheers, Magnus On 03/20/2016 09:19 PM, ka2...@aol.com wrote: > I am interested in this topic too, thanks, Ulrich > In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight Time, > mag...@rubidium.dyndns.org writes: > > Attila, > > On 03/17/2016 10:56 AM, Attila Kinali wrote: > > Moin, > > > > Measurement we recently did showed some quite unexpected behaviour > > and I am trying to figure out where this comes from. For this > > I would like to simulate our system, which consists of multiple > > crystal oscillators that are coupled in a non-linear way (kind of > > a vector-PLL with a step transfer function) with a "loop bandwidth" > > of a few 10kHz. > > > > My goal is to simulate the noise properties of the crystal > oscillators > > both short term (in the 10us range) and long term (several 1000 > seconds) > > in a way that models reality closely (ie short term instability > is uncorrelated > > while long term instability is correlated through temp/humidity/...) > > > > As I am pretty sure not the first one to attempt something like this, > > I would like to ask whether someone has already some software > framework > > around for this kind of simulation? > > > > If not, does someone have pointers how to write realistic > oscillator models > > for this kind of short and long term simulation? > > It is a large field that you tries to cover. What you need to do is > actually find the model that models the behavior of your physical setup. > > You need to have white and flicker noises, there is a few ways to get > the flicker coloring. I did some hacking of the setup, and ran tests > against Chuck Greenhalls original BASIC code. > > You probably want a systematic effect model of phase, frequency and > drift. Also a cubic frequency vs. temperature. All the properties needs > to be different for each instance. Similarly, the flicker filter needs > to be independent for
Re: [time-nuts] Framework for simulation of oscillators
Goder afton Attila, On 03/20/2016 10:20 PM, Attila Kinali wrote: God kväll Magnus, On Sun, 20 Mar 2016 20:43:00 +0100 Magnus Danielson wrote: If not, does someone have pointers how to write realistic oscillator models for this kind of short and long term simulation? It is a large field that you tries to cover. What you need to do is actually find the model that models the behavior of your physical setup. Yes, there is quite a bit I need to cover. I started out to put some stuff together yesterday, but I guess it will take me two or three weeks until i have something half way usable. You need to have white and flicker noises, there is a few ways to get the flicker coloring. I did some hacking of the setup, and ran tests against Chuck Greenhalls original BASIC code. I'm currently using the code from Brooker and Inggs[1,2], but the code is quite convoluted and it will take me some time to extract it and get it working properly. (but then, it's the only piece of code that I found that does seem to be viable at all) Could not get to the article. Looking at the code, it honestly does not seem to be very different to that of Barnes&Greenhall. Correction: The generalized method was Barnes&Jarvis (NBS TN604), where Greenhall presented a paper on init and then Barnes&Greenhall did an aggregated article at PTTI 19, with a correction in PTTI 24. You probably want a systematic effect model of phase, frequency and drift. Also a cubic frequency vs. temperature. All the properties needs to be different for each instance. Similarly, the flicker filter needs to be independent for each oscillator. What do you mean with "the flicker filter needs to be independent"? Each oscillator will get its own noise source, if you mean that. Yes. When you have a white noise-source, you can take all your samples from the same source. With non-white sources, you take white noise and filter it, that filtering mechanism holds a state, and if you need two or more independent sources, then that state would make the assumption of independent sources invalid. Similar enough things have been tried when simulating the jitter and wander in the G.823-825 specs. Thanks, i will have a look at those. ITU-T G.810-813 is also kind of interesting, with ITU-T G.810 in particular. There is a correction for G.810, as I reported a typo in one of the formulas. ITU-T G.701 can be also interesting to read and contemplate over alongside G.810. An aspect you need to include is the filtering properties of the EFC input, it acts like a low-pass filter, and the Q of the resonator is another catch-point. The low pass filter is easy to implement, and yes, this will be one of the first things i need to implement. One of our guesses is, that this low pass filtering helps us getting the high performance we saw. I think you should try that first, in a fairly linear model. It should help explain the locking at least, which is a good start. I am not sure yet, how to model the Q, or whether that actually needs to be modelled with anything else but the proper noise/stability characteristics and the low pass on the EFC. Consider that you have an integrator for the oscillator, and a null due to the Q. Look at the Leeson model (Feb 1966), see also Enrico's book on phase noise. I wonder how complex model you need to build before you have catched the characteristics you are after. The current plan is to implement an oscillator model that mimics the correct stability i'm seeing, then add EFC (first w/o low pass filtering). This should already work "properly" and give a first indication on how the system behaves. Then step by step add the non-idealities, like the low pass filter on the EFC, the high DNL of the TDC, the noise on the pulse output and the TDC input, ... until I get close to what we measure. Just being able to simulate the locking mechanism should be a good start. Then you should try to get it to simulate the noise-curves you're seeing. The EFC measures you have done so far indicate that your steering essentially operates as if you do where doing something similar to charge-pump operation. Hmm.. can you elaborate a bit on why you think so? The correction pulse every now and then is how a charge-pump PLL operates. In between the corrections the oscillator coasts undiciplined with the filters state as memory. The 4046 charge-pump has a dead-band which was very annoying as it was only as the phase coasted outside of the dead-band that a correction to go back occurred. The pulses you mentioned sounds like quite similar. For higher frequencies, they will be uncorrected, so only at about the rate of the corrections will the oscillators cooperate and lower the performance, and only the ones being outside of the limits will experience this push inwards. Something according to those lines might be where your systems behavior can be explained. Gardner would be a good reference. He was not so ke
Re: [time-nuts] Framework for simulation of oscillators
God kväll Magnus, On Sun, 20 Mar 2016 20:43:00 +0100 Magnus Danielson wrote: > > If not, does someone have pointers how to write realistic oscillator models > > for this kind of short and long term simulation? > > It is a large field that you tries to cover. What you need to do is > actually find the model that models the behavior of your physical setup. Yes, there is quite a bit I need to cover. I started out to put some stuff together yesterday, but I guess it will take me two or three weeks until i have something half way usable. > You need to have white and flicker noises, there is a few ways to get > the flicker coloring. I did some hacking of the setup, and ran tests > against Chuck Greenhalls original BASIC code. I'm currently using the code from Brooker and Inggs[1,2], but the code is quite convoluted and it will take me some time to extract it and get it working properly. (but then, it's the only piece of code that I found that does seem to be viable at all) > You probably want a systematic effect model of phase, frequency and > drift. Also a cubic frequency vs. temperature. All the properties needs > to be different for each instance. Similarly, the flicker filter needs > to be independent for each oscillator. What do you mean with "the flicker filter needs to be independent"? Each oscillator will get its own noise source, if you mean that. > Similar enough things have been tried when simulating the jitter and > wander in the G.823-825 specs. Thanks, i will have a look at those. > An aspect you need to include is the filtering properties of the EFC > input, it acts like a low-pass filter, and the Q of the resonator is > another catch-point. The low pass filter is easy to implement, and yes, this will be one of the first things i need to implement. One of our guesses is, that this low pass filtering helps us getting the high performance we saw. I am not sure yet, how to model the Q, or whether that actually needs to be modelled with anything else but the proper noise/stability characteristics and the low pass on the EFC. > I wonder how complex model you need to build before you have catched the > characteristics you are after. The current plan is to implement an oscillator model that mimics the correct stability i'm seeing, then add EFC (first w/o low pass filtering). This should already work "properly" and give a first indication on how the system behaves. Then step by step add the non-idealities, like the low pass filter on the EFC, the high DNL of the TDC, the noise on the pulse output and the TDC input, ... until I get close to what we measure. > The EFC measures you have done so far indicate that your steering > essentially operates as if you do where doing something similar to > charge-pump operation. Hmm.. can you elaborate a bit on why you think so? Attila Kinali [1] "Efficient Generation of f^a Noise Sequences for Pulsed Radar Simulation", by Brooker, Inggs, 2010 http://dx.doi.org/10.1109/TAES.2010.5461653 [2] http://rrsg.ee.uct.ac.za/fers/ -- Reading can seriously damage your ignorance. -- unknown ___ 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] Framework for simulation of oscillators
Thanks, Ulrich In a message dated 3/20/2016 5:33:21 P.M. Eastern Daylight Time, mag...@rubidium.se writes: Ulrich and Attila, As you read the appendixes of ITU-T Rec. G.823, G.824 and G.825 they will not give very detailed information, but hints. The flicker noise model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article "Large Sample Simulation of Flicker Noise". Be aware of Chuck's follow-up correction. Further, they model the amount of noise and add into the loop in place of the oscillator, which then has a normal PI-loop. Such a simulation can be done fairly efficiently considering that the oscillator and loop is very simple linear models of phase, not too different to what I proposed. For the stuff that Attila needs to simulate, some additional thought needs to go into how to simulate the effect he is seeing, but a fairly simple approach should be interesting to try out initially. The Barnes&Greenhall flicker generator builds on a filter-bank where the poles and nulls is placed such that they approximate the flicker noise slope of 1/tau. This is a generalized variant of Jim Barnes PhD work where he had fixed relations and where Chuck Greenhall have contributed significantly by providing means to setup the state of the filter such that the filter will act as a filter in equilibrium from start, rather than taking much time to converge, something which may introduce a bias into the measurement results. I have re-implemented their BASIC-code into C and run Chuck's original code along-side to verify (just to find where I did my mistake in converting it). If this simulation approach is sufficient for either of your efforts, or not, depends on what you try to capture. For instance, the oscillators performance have been idealized in assuming fully linear EFC, fully linear integrator of the crystal, assuming noise profile etc. This may or may not be sufficient. Inherent lowpass filtering may be important or not. I've done PLL simulations many times, in fixed integer, in floating point and in VHDL. It's always a challenge to model it right to the needs. Let me also have reader of this thread reminded of TvB's simulator for a GPSDO, which is interesting as it adds real GPS PPS data and real open loop oscillator data with a simple PLL oscillator core you can then tweak. Great fun in all it's simplicity and nice way to do reality check. I've done similar things with about the same code amount that have proved very useful. However, recall that whenever you make a model, you do it with assumptions for your particular problem, so some stuff will be left out and some will be particular to your problem. One guys model may be crap to another ones problem. There is a few tricks to be learned and a few things to recall to include. Cheers, Magnus On 03/20/2016 09:19 PM, ka2...@aol.com wrote: > I am interested in this topic too, thanks, Ulrich > In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight Time, > mag...@rubidium.dyndns.org writes: > > Attila, > > On 03/17/2016 10:56 AM, Attila Kinali wrote: > > Moin, > > > > Measurement we recently did showed some quite unexpected behaviour > > and I am trying to figure out where this comes from. For this > > I would like to simulate our system, which consists of multiple > > crystal oscillators that are coupled in a non-linear way (kind of > > a vector-PLL with a step transfer function) with a "loop bandwidth" > > of a few 10kHz. > > > > My goal is to simulate the noise properties of the crystal > oscillators > > both short term (in the 10us range) and long term (several 1000 > seconds) > > in a way that models reality closely (ie short term instability > is uncorrelated > > while long term instability is correlated through temp/humidity/...) > > > > As I am pretty sure not the first one to attempt something like this, > > I would like to ask whether someone has already some software > framework > > around for this kind of simulation? > > > > If not, does someone have pointers how to write realistic > oscillator models > > for this kind of short and long term simulation? > > It is a large field that you tries to cover. What you need to do is > actually find the model that models the behavior of your physical setup. > > You need to have white and flicker noises, there is a few ways to get > the flicker coloring. I did some hacking of the setup, and ran tests > against Chuck Greenhalls original BASIC code. > > You probably want a systematic effect model of phase, frequency and > drift. Also a cubic frequency vs. temperature. All the properties needs > to be different for each instance. Similarly, the flicker filter needs > to be independent for each oscillator. > > Similar enough things have been tried wh
Re: [time-nuts] Framework for simulation of oscillators
Ulrich and Attila, As you read the appendixes of ITU-T Rec. G.823, G.824 and G.825 they will not give very detailed information, but hints. The flicker noise model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article "Large Sample Simulation of Flicker Noise". Be aware of Chuck's follow-up correction. Further, they model the amount of noise and add into the loop in place of the oscillator, which then has a normal PI-loop. Such a simulation can be done fairly efficiently considering that the oscillator and loop is very simple linear models of phase, not too different to what I proposed. For the stuff that Attila needs to simulate, some additional thought needs to go into how to simulate the effect he is seeing, but a fairly simple approach should be interesting to try out initially. The Barnes&Greenhall flicker generator builds on a filter-bank where the poles and nulls is placed such that they approximate the flicker noise slope of 1/tau. This is a generalized variant of Jim Barnes PhD work where he had fixed relations and where Chuck Greenhall have contributed significantly by providing means to setup the state of the filter such that the filter will act as a filter in equilibrium from start, rather than taking much time to converge, something which may introduce a bias into the measurement results. I have re-implemented their BASIC-code into C and run Chuck's original code along-side to verify (just to find where I did my mistake in converting it). If this simulation approach is sufficient for either of your efforts, or not, depends on what you try to capture. For instance, the oscillators performance have been idealized in assuming fully linear EFC, fully linear integrator of the crystal, assuming noise profile etc. This may or may not be sufficient. Inherent lowpass filtering may be important or not. I've done PLL simulations many times, in fixed integer, in floating point and in VHDL. It's always a challenge to model it right to the needs. Let me also have reader of this thread reminded of TvB's simulator for a GPSDO, which is interesting as it adds real GPS PPS data and real open loop oscillator data with a simple PLL oscillator core you can then tweak. Great fun in all it's simplicity and nice way to do reality check. I've done similar things with about the same code amount that have proved very useful. However, recall that whenever you make a model, you do it with assumptions for your particular problem, so some stuff will be left out and some will be particular to your problem. One guys model may be crap to another ones problem. There is a few tricks to be learned and a few things to recall to include. Cheers, Magnus On 03/20/2016 09:19 PM, ka2...@aol.com wrote: I am interested in this topic too, thanks, Ulrich In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight Time, mag...@rubidium.dyndns.org writes: Attila, On 03/17/2016 10:56 AM, Attila Kinali wrote: > Moin, > > Measurement we recently did showed some quite unexpected behaviour > and I am trying to figure out where this comes from. For this > I would like to simulate our system, which consists of multiple > crystal oscillators that are coupled in a non-linear way (kind of > a vector-PLL with a step transfer function) with a "loop bandwidth" > of a few 10kHz. > > My goal is to simulate the noise properties of the crystal oscillators > both short term (in the 10us range) and long term (several 1000 seconds) > in a way that models reality closely (ie short term instability is uncorrelated > while long term instability is correlated through temp/humidity/...) > > As I am pretty sure not the first one to attempt something like this, > I would like to ask whether someone has already some software framework > around for this kind of simulation? > > If not, does someone have pointers how to write realistic oscillator models > for this kind of short and long term simulation? It is a large field that you tries to cover. What you need to do is actually find the model that models the behavior of your physical setup. You need to have white and flicker noises, there is a few ways to get the flicker coloring. I did some hacking of the setup, and ran tests against Chuck Greenhalls original BASIC code. You probably want a systematic effect model of phase, frequency and drift. Also a cubic frequency vs. temperature. All the properties needs to be different for each instance. Similarly, the flicker filter needs to be independent for each oscillator. Similar enough things have been tried when simulating the jitter and wander in the G.823-825 specs. An aspect you need to include is the filtering properties of the EFC input, it acts like a low-pass filter, and the Q of the resonator is another catch-point. I w
Re: [time-nuts] Framework for simulation of oscillators
I am interested in this topic too, thanks, Ulrich In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight Time, mag...@rubidium.dyndns.org writes: Attila, On 03/17/2016 10:56 AM, Attila Kinali wrote: > Moin, > > Measurement we recently did showed some quite unexpected behaviour > and I am trying to figure out where this comes from. For this > I would like to simulate our system, which consists of multiple > crystal oscillators that are coupled in a non-linear way (kind of > a vector-PLL with a step transfer function) with a "loop bandwidth" > of a few 10kHz. > > My goal is to simulate the noise properties of the crystal oscillators > both short term (in the 10us range) and long term (several 1000 seconds) > in a way that models reality closely (ie short term instability is uncorrelated > while long term instability is correlated through temp/humidity/...) > > As I am pretty sure not the first one to attempt something like this, > I would like to ask whether someone has already some software framework > around for this kind of simulation? > > If not, does someone have pointers how to write realistic oscillator models > for this kind of short and long term simulation? It is a large field that you tries to cover. What you need to do is actually find the model that models the behavior of your physical setup. You need to have white and flicker noises, there is a few ways to get the flicker coloring. I did some hacking of the setup, and ran tests against Chuck Greenhalls original BASIC code. You probably want a systematic effect model of phase, frequency and drift. Also a cubic frequency vs. temperature. All the properties needs to be different for each instance. Similarly, the flicker filter needs to be independent for each oscillator. Similar enough things have been tried when simulating the jitter and wander in the G.823-825 specs. An aspect you need to include is the filtering properties of the EFC input, it acts like a low-pass filter, and the Q of the resonator is another catch-point. I wonder how complex model you need to build before you have catched the characteristics you are after. The EFC measures you have done so far indicate that your steering essentially operates as if you do where doing something similar to charge-pump operation. 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] Framework for simulation of oscillators
Attila, On 03/17/2016 10:56 AM, Attila Kinali wrote: Moin, Measurement we recently did showed some quite unexpected behaviour and I am trying to figure out where this comes from. For this I would like to simulate our system, which consists of multiple crystal oscillators that are coupled in a non-linear way (kind of a vector-PLL with a step transfer function) with a "loop bandwidth" of a few 10kHz. My goal is to simulate the noise properties of the crystal oscillators both short term (in the 10us range) and long term (several 1000 seconds) in a way that models reality closely (ie short term instability is uncorrelated while long term instability is correlated through temp/humidity/...) As I am pretty sure not the first one to attempt something like this, I would like to ask whether someone has already some software framework around for this kind of simulation? If not, does someone have pointers how to write realistic oscillator models for this kind of short and long term simulation? It is a large field that you tries to cover. What you need to do is actually find the model that models the behavior of your physical setup. You need to have white and flicker noises, there is a few ways to get the flicker coloring. I did some hacking of the setup, and ran tests against Chuck Greenhalls original BASIC code. You probably want a systematic effect model of phase, frequency and drift. Also a cubic frequency vs. temperature. All the properties needs to be different for each instance. Similarly, the flicker filter needs to be independent for each oscillator. Similar enough things have been tried when simulating the jitter and wander in the G.823-825 specs. An aspect you need to include is the filtering properties of the EFC input, it acts like a low-pass filter, and the Q of the resonator is another catch-point. I wonder how complex model you need to build before you have catched the characteristics you are after. The EFC measures you have done so far indicate that your steering essentially operates as if you do where doing something similar to charge-pump operation. 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] Framework for simulation of oscillators
Moin, Measurement we recently did showed some quite unexpected behaviour and I am trying to figure out where this comes from. For this I would like to simulate our system, which consists of multiple crystal oscillators that are coupled in a non-linear way (kind of a vector-PLL with a step transfer function) with a "loop bandwidth" of a few 10kHz. My goal is to simulate the noise properties of the crystal oscillators both short term (in the 10us range) and long term (several 1000 seconds) in a way that models reality closely (ie short term instability is uncorrelated while long term instability is correlated through temp/humidity/...) As I am pretty sure not the first one to attempt something like this, I would like to ask whether someone has already some software framework around for this kind of simulation? If not, does someone have pointers how to write realistic oscillator models for this kind of short and long term simulation? Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson ___ 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] Framework for simulation of oscillators
On Thu, 17 Mar 2016 06:20:00 -0700 jimlux wrote: > On 3/17/16 2:56 AM, Attila Kinali wrote: > > > > > As I am pretty sure not the first one to attempt something like this, > > I would like to ask whether someone has already some software framework > > around for this kind of simulation? > > > > If not, does someone have pointers how to write realistic oscillator models > > for this kind of short and long term simulation? > > what do you want the output of the model to be? Samples of the sine > wave, time of each cycle, frequency at discrete intervals? I think the best thing would be to ouptut when each node sends a pulse. Which happens every n'th clock cycle of the oscillator and are in our current implementation 50us apart (aka 20kHz). The pulses from all nodes are closely synchronized (sub ns phase difference). I think for all practical purposes, we can replace the "high" frequency crystal oscillator by a "low" frequency one (at the rate of these pulses) that then drives the algorithm of the nodes (aka the PLL) I don't really care what happens between these pulses, as we currently cannot measure it. At a later stage of the project we might be able to do so, but for the moment, it's ok if we can correctly describe the behaviour at tau's between 50us and <10ks. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson ___ 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] Framework for simulation of oscillators
On 3/17/16 2:56 AM, Attila Kinali wrote: As I am pretty sure not the first one to attempt something like this, I would like to ask whether someone has already some software framework around for this kind of simulation? If not, does someone have pointers how to write realistic oscillator models for this kind of short and long term simulation? what do you want the output of the model to be? Samples of the sine wave, time of each cycle, frequency at discrete intervals? ___ 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.