Re: [time-nuts] GPSDO simulation tool
On 26/03/14 22:42, Tom Van Baak wrote: Did some home-work on third-degree PLL parameters, so now I know why I failed, as I never tried to do it right. One thing that Tom's simulator isn't doing is calculating the parameters for the PID for you, or backwards what characteristics you will get. Cheers, Magnus Magnus, et al, Still hoping some of you process control PID experts will contribute a couple lines of C code to the simulator. The gpsim1 ver=N parameter will select any one of many different algorithms. I believe no one algorithm is correct; the goal is simply to include as many as you can contribute so we can all play with them. Yes, now as the weekend finally reached me I can look at it again. I have looked at third degree PLLs again and if you know where you're poles should be going, then setting it up is trivial and stability can be guaranteed. Cheers, Magnus 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 simulation tool
On 24/03/14 07:12, Hal Murray wrote: mag...@rubidium.dyndns.org said: I did a temporary hack on the PID code to convert the D-term into I^2 term, by integrating the integrator output. First attempt was indeed quite resonant just to show that I was in the unsafe region. Backing down on the strength of the component sure did remove much of the resonance, but I did not see any appreciable improvement in filtering performance, so quick and dirty hacking isn't sufficient, darn. Maybe it isn't sufficient to make a great GPSDO, but it's more than sufficient to point out the advantages of Tom's simulation setup. Thanks Tom. Did some home-work on third-degree PLL parameters, so now I know why I failed, as I never tried to do it right. One thing that Tom's simulator isn't doing is calculating the parameters for the PID for you, or backwards what characteristics you will get. 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 simulation tool
Did some home-work on third-degree PLL parameters, so now I know why I failed, as I never tried to do it right. One thing that Tom's simulator isn't doing is calculating the parameters for the PID for you, or backwards what characteristics you will get. Cheers, Magnus Magnus, et al, Still hoping some of you process control PID experts will contribute a couple lines of C code to the simulator. The gpsim1 ver=N parameter will select any one of many different algorithms. I believe no one algorithm is correct; the goal is simply to include as many as you can contribute so we can all play with them. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
In message 514d.5090...@rubidium.dyndns.org, Magnus Danielson writes: Did some home-work on third-degree PLL parameters, so now I know why I failed, as I never tried to do it right. Once you get to third-order PLLs you need to start paying serious attention to rounding errors. In most cases using a double floating point format will do, but you have to make sure you don't loose precision to normalisation in your additions. I've had varying degress of success myself, and overall I'm not sure it really makes sense to fight the battles, unless you need really long hold-over times. -- 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 simulation tool
Hi 64 bit int’s with 128 bit intermediate results can do a pretty good job for most of this. Bob On Mar 26, 2014, at 6:47 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 514d.5090...@rubidium.dyndns.org, Magnus Danielson writes: Did some home-work on third-degree PLL parameters, so now I know why I failed, as I never tried to do it right. Once you get to third-order PLLs you need to start paying serious attention to rounding errors. In most cases using a double floating point format will do, but you have to make sure you don't loose precision to normalisation in your additions. I've had varying degress of success myself, and overall I'm not sure it really makes sense to fight the battles, unless you need really long hold-over times. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
mag...@rubidium.dyndns.org said: I did a temporary hack on the PID code to convert the D-term into I^2 term, by integrating the integrator output. First attempt was indeed quite resonant just to show that I was in the unsafe region. Backing down on the strength of the component sure did remove much of the resonance, but I did not see any appreciable improvement in filtering performance, so quick and dirty hacking isn't sufficient, darn. Maybe it isn't sufficient to make a great GPSDO, but it's more than sufficient to point out the advantages of Tom's simulation setup. Thanks Tom. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
On Sun, 23 Mar 2014 21:33:07 -0400, time-nuts-requ...@febo.com wrote: Message: 1 Date: Mon, 24 Mar 2014 00:48:01 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org To: time-nuts@febo.com Subject: Re: [time-nuts] GPSDO simulation tool Jim, On 23/03/14 16:00, Jim Miller wrote: To handle higher tau performance I think we want a higher degree loop. Cheers, Magnus Is a higher degree loop possible while maintaining stability? Commanding frequency while measuring phase is one pole, integrating the result of the phase comparison is a second pole and closing the loop will result in oscillation unless a zero is inserted (the P in PID). How would stability be maintained? A third degree PLL is stable if the pole-pair is suitably located. The second degree PLL is kind of hard to bring into self-oscillation while that is much easier with the third degree, so more care needs to go into it. When you think about it, putting an exponential averager just after the phase-detector (AVG1 in gpsim1) is in fact making the PLL a third degree, but since the time-constant needs to be constrained to be well below the loop time-constant for stability reasons it is in fact to avoid having the poles of this third-degree loop from deviating away into instability. I did a temporary hack on the PID code to convert the D-term into I^2 term, by integrating the integrator output. First attempt was indeed quite resonant just to show that I was in the unsafe region. Backing down on the strength of the component sure did remove much of the resonance, but I did not see any appreciable improvement in filtering performance, so quick and dirty hacking isn't sufficient, darn. I recall from an analysis of third-order PLLs read a few years ago that stability also depended on the amplitude of the signal to which the PLL was locking. This sensitivity made 3rd-order PLLs difficult to use as radio receivers, but for use as a timing-chain component one can always arrange to have adequate amplitude (and have a level detector to warn if amplitude isn't adequate). I always suspected that the old Symmetricom 1050A disciplined oscillator was a 3rd-order loop, but was never able to find anybody who knew. Joe Gwinn ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
On 23/03/14 06:56, Said Jackson wrote: Tom, In my experience one of the biggest GPSDO error sources in low-cost and even some higher end OCXOs is oscillator hysteresis. Which can change with operating temperature, operating time (crystal age) and even over crystal tilt. Does your OCXO model allow for hysteresis simulation? No, not really. He uses a quite crude model at this point. I think it is fair, as it aims to get the basic principles in such a way that one can fool around. For a more serious simulator it would be nice to have such behaviours modelled, but then it needs to be modelled with real oscillators behaviours and under the various stresses. That's a nice little topic for a series of articles in UFFC. It is very hard to discipline oscillators with hystereses and a good modeling tool would be helpful. I think good modeling isn't very easy either. Maybe it is possible to get a crude model to capture the basics good enough for simulation use. Most ocxo vendors don't even know about hysteresis or how to quantify it (and react with a deer in the headlight look when asked about it), but even levels of ppt to tens of ppt can wreak havoc due to the fact that the loop is always chasing the ocxo if sufficient hysteresis exists. Most sales-rep's don't have a clue, and even their market-oriented app-note-writes does not really have a clue. If you have data to illustrate things, I'm happy to look at it and see what I can learn. Temperature-induced hysteresis, which as far as I have read exists and matches my experience with drift of oscillators after start-up, sure puts a limit to how well TCXOs can perform relative to OCXOs. 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 simulation tool
To handle higher tau performance I think we want a higher degree loop. Cheers, Magnus Is a higher degree loop possible while maintaining stability? Commanding frequency while measuring phase is one pole, integrating the result of the phase comparison is a second pole and closing the loop will result in oscillation unless a zero is inserted (the P in PID). How would stability be maintained? Thanks jim ab3cv (newbie...) ___ 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 simulation tool
I agree.. Had a maybe weird thought. Computing power is now a trivial part of the problem, in that a Ras.Pi can be put to the task for $35 or so. In that case, PIDdling with time constants and such in a feedback loop with phase difference as the error signal is easily done, either in simulation, or for real, as you point out. So, since ADEV or one of its brothers is the measure of success of PIDdling, shouldn't the ADEV or brethren be in some way the error signal for the whole? For example, how about a TCGPSDO? put the whole thing in a first-order thermal enclosure, with power-over-ethernet being the only external wiring? Hope I'm at least making at least logical sense Don Tom Van Baak Hi Don, Yes, easy! And that's exactly the idea -- to take real inputs (or borrowed copies of real inputs), and a real software algorithm, and measure the virtual output to see how well your algorithm and tunable parameters work. Tweak parameters. Evolve the algorithm. Simmer until well done. Theoretically, after one builds the real GPSDO, using the same code or at least the same algorithm, the actual performance should nearly perfectly match the simulation. The difference, at least for me, is that I'd rather play with unix commands and C code on a PC, trying things out in a matter of minutes, than spend weeks slowly trying different things with a real GPSDO (which I've also done). In addition, I think gpsim1 makes a useful, almost interactive, teaching tool. Now, no simulation is perfect. But oscillators, dividers, 1PPS comparators, and DACs are not really that complicated. You are probably guessing that I'm working on gpsim2 which will allow simulation of phase and frequency jumps, varying GPS reception, power-up, cold-boot, warm-boot, holdover, thermal or mechanical shocks to the instrument, and other events that I see in real life. But let's let gpsim1 run its coarse before we worry about 2nd order effects. I'm very interested in alternative or enhanced algorithms that people come up with. The two algorithms now in gpsim1 and default tuning parameters are just something I threw together in a few minutes. /tvb - Original Message - From: Don Latham d...@montana.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, March 22, 2014 8:18 PM Subject: Re: [time-nuts] GPSDO simulation tool Hi Tom et.al. Isn't the simulator easily convertible to the real thing? That is, data inputs should be convertible somehow to data streams from physical devices? Don ___ 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. -- The power of accurate observation is commonly called cynicism by those who have not got it. -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
I agree.. Had a maybe weird thought. Computing power is now a trivial part of the problem, in that a Ras.Pi can be put to the task for $35 or so. In that case, PIDdling with time constants and such in a feedback loop with phase difference as the error signal is easily done, either in simulation, or for real, as you point out. So, since ADEV or one of its brothers is the measure of success of PIDdling, shouldn't the ADEV or brethren be in some way the error signal for the whole? For example, how about a TCGPSDO? put the whole thing in a first-order thermal enclosure, with power-over-ethernet being the only external wiring? Hope I'm at least making at least logical sense Don Tom Van Baak Hi Don, Yes, easy! And that's exactly the idea -- to take real inputs (or borrowed copies of real inputs), and a real software algorithm, and measure the virtual output to see how well your algorithm and tunable parameters work. Tweak parameters. Evolve the algorithm. Simmer until well done. Theoretically, after one builds the real GPSDO, using the same code or at least the same algorithm, the actual performance should nearly perfectly match the simulation. The difference, at least for me, is that I'd rather play with unix commands and C code on a PC, trying things out in a matter of minutes, than spend weeks slowly trying different things with a real GPSDO (which I've also done). In addition, I think gpsim1 makes a useful, almost interactive, teaching tool. Now, no simulation is perfect. But oscillators, dividers, 1PPS comparators, and DACs are not really that complicated. You are probably guessing that I'm working on gpsim2 which will allow simulation of phase and frequency jumps, varying GPS reception, power-up, cold-boot, warm-boot, holdover, thermal or mechanical shocks to the instrument, and other events that I see in real life. But let's let gpsim1 run its coarse before we worry about 2nd order effects. I'm very interested in alternative or enhanced algorithms that people come up with. The two algorithms now in gpsim1 and default tuning parameters are just something I threw together in a few minutes. /tvb - Original Message - From: Don Latham d...@montana.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, March 22, 2014 8:18 PM Subject: Re: [time-nuts] GPSDO simulation tool Hi Tom et.al. Isn't the simulator easily convertible to the real thing? That is, data inputs should be convertible somehow to data streams from physical devices? Don ___ 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. -- The power of accurate observation is commonly called cynicism by those who have not got it. -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
I agree.. Had a maybe weird thought. Computing power is now a trivial part of the problem, in that a Ras.Pi can be put to the task for $35 or so. In that case, PIDdling with time constants and such in a feedback loop with phase difference as the error signal is easily done, either in simulation, or for real, as you point out. So, since ADEV or one of its brothers is the measure of success of PIDdling, shouldn't the ADEV or brethren be in some way the error signal for the whole? For example, how about a TCGPSDO? put the whole thing in a first-order thermal enclosure, with power-over-ethernet being the only external wiring? Hope I'm at least making at least logical sense Don Tom Van Baak Hi Don, Yes, easy! And that's exactly the idea -- to take real inputs (or borrowed copies of real inputs), and a real software algorithm, and measure the virtual output to see how well your algorithm and tunable parameters work. Tweak parameters. Evolve the algorithm. Simmer until well done. Theoretically, after one builds the real GPSDO, using the same code or at least the same algorithm, the actual performance should nearly perfectly match the simulation. The difference, at least for me, is that I'd rather play with unix commands and C code on a PC, trying things out in a matter of minutes, than spend weeks slowly trying different things with a real GPSDO (which I've also done). In addition, I think gpsim1 makes a useful, almost interactive, teaching tool. Now, no simulation is perfect. But oscillators, dividers, 1PPS comparators, and DACs are not really that complicated. You are probably guessing that I'm working on gpsim2 which will allow simulation of phase and frequency jumps, varying GPS reception, power-up, cold-boot, warm-boot, holdover, thermal or mechanical shocks to the instrument, and other events that I see in real life. But let's let gpsim1 run its coarse before we worry about 2nd order effects. I'm very interested in alternative or enhanced algorithms that people come up with. The two algorithms now in gpsim1 and default tuning parameters are just something I threw together in a few minutes. /tvb - Original Message - From: Don Latham d...@montana.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, March 22, 2014 8:18 PM Subject: Re: [time-nuts] GPSDO simulation tool Hi Tom et.al. Isn't the simulator easily convertible to the real thing? That is, data inputs should be convertible somehow to data streams from physical devices? Don ___ 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. -- The power of accurate observation is commonly called cynicism by those who have not got it. -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
I agree.. Had a maybe weird thought. Computing power is now a trivial part of the problem, in that a Ras.Pi can be put to the task for $35 or so. In that case, PIDdling with time constants and such in a feedback loop with phase difference as the error signal is easily done, either in simulation, or for real, as you point out. So, since ADEV or one of its brothers is the measure of success of PIDdling, shouldn't the ADEV or brethren be in some way the error signal for the whole? For example, how about a TCGPSDO? put the whole thing in a first-order thermal enclosure, with power-over-ethernet being the only external wiring? Hope I'm at least making at least logical sense Don Tom Van Baak Hi Don, Yes, easy! And that's exactly the idea -- to take real inputs (or borrowed copies of real inputs), and a real software algorithm, and measure the virtual output to see how well your algorithm and tunable parameters work. Tweak parameters. Evolve the algorithm. Simmer until well done. Theoretically, after one builds the real GPSDO, using the same code or at least the same algorithm, the actual performance should nearly perfectly match the simulation. The difference, at least for me, is that I'd rather play with unix commands and C code on a PC, trying things out in a matter of minutes, than spend weeks slowly trying different things with a real GPSDO (which I've also done). In addition, I think gpsim1 makes a useful, almost interactive, teaching tool. Now, no simulation is perfect. But oscillators, dividers, 1PPS comparators, and DACs are not really that complicated. You are probably guessing that I'm working on gpsim2 which will allow simulation of phase and frequency jumps, varying GPS reception, power-up, cold-boot, warm-boot, holdover, thermal or mechanical shocks to the instrument, and other events that I see in real life. But let's let gpsim1 run its coarse before we worry about 2nd order effects. I'm very interested in alternative or enhanced algorithms that people come up with. The two algorithms now in gpsim1 and default tuning parameters are just something I threw together in a few minutes. /tvb - Original Message - From: Don Latham d...@montana.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, March 22, 2014 8:18 PM Subject: Re: [time-nuts] GPSDO simulation tool Hi Tom et.al. Isn't the simulator easily convertible to the real thing? That is, data inputs should be convertible somehow to data streams from physical devices? Don ___ 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. -- The power of accurate observation is commonly called cynicism by those who have not got it. -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
sorry! had a glitch and hit send too many times :-) -- The power of accurate observation is commonly called cynicism by those who have not got it. -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
Hi Unless you can include all the second and third order effects in your model, there will still be a lot to “learn” as you build your gizmo. Computing power is still impacted by garbage in / garbage out. Bob On Mar 23, 2014, at 12:07 PM, Don Latham d...@montana.com wrote: I agree.. Had a maybe weird thought. Computing power is now a trivial part of the problem, in that a Ras.Pi can be put to the task for $35 or so. In that case, PIDdling with time constants and such in a feedback loop with phase difference as the error signal is easily done, either in simulation, or for real, as you point out. So, since ADEV or one of its brothers is the measure of success of PIDdling, shouldn't the ADEV or brethren be in some way the error signal for the whole? For example, how about a TCGPSDO? put the whole thing in a first-order thermal enclosure, with power-over-ethernet being the only external wiring? Hope I'm at least making at least logical sense… Don Tom Van Baak Hi Don, Yes, easy! And that's exactly the idea -- to take real inputs (or borrowed copies of real inputs), and a real software algorithm, and measure the virtual output to see how well your algorithm and tunable parameters work. Tweak parameters. Evolve the algorithm. Simmer until well done. Theoretically, after one builds the real GPSDO, using the same code or at least the same algorithm, the actual performance should nearly perfectly match the simulation. The difference, at least for me, is that I'd rather play with unix commands and C code on a PC, trying things out in a matter of minutes, than spend weeks slowly trying different things with a real GPSDO (which I've also done). In addition, I think gpsim1 makes a useful, almost interactive, teaching tool. Now, no simulation is perfect. But oscillators, dividers, 1PPS comparators, and DACs are not really that complicated. You are probably guessing that I'm working on gpsim2 which will allow simulation of phase and frequency jumps, varying GPS reception, power-up, cold-boot, warm-boot, holdover, thermal or mechanical shocks to the instrument, and other events that I see in real life. But let's let gpsim1 run its coarse before we worry about 2nd order effects. I'm very interested in alternative or enhanced algorithms that people come up with. The two algorithms now in gpsim1 and default tuning parameters are just something I threw together in a few minutes. /tvb - Original Message - From: Don Latham d...@montana.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, March 22, 2014 8:18 PM Subject: Re: [time-nuts] GPSDO simulation tool Hi Tom et.al. Isn't the simulator easily convertible to the real thing? That is, data inputs should be convertible somehow to data streams from physical devices? Don ___ 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. -- The power of accurate observation is commonly called cynicism by those who have not got it. -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
On Sat, Mar 22, 2014 at 8:18 PM, Don Latham d...@montana.com wrote: Hi Tom et.al. Isn't the simulator easily convertible to the real thing? That is, data inputs should be convertible somehow to data streams from physical devices? Don This is a very common development method, not just with GSPDOs but with anything like say a couple robots I'm building. At first you simulate the physical hardware. I can write a function called GetMotorSpeed() and at first it simply always returns a constant 5.0 and that is good enough. Later I make it read a file and finally I make it read some hardware interface that connects to a sensor but the sensor is just a test fixture on my desk. Later I integrate the sensor in to the robot. I have a few sensors on my desk right new (sonar and IR distance sensors) Almost 100% of professional level work is done this way. At work I've seen this same method used for air defense missiles, radars and everything. At first you write the code and run it on a desktop computer because it is so easy to do, But as the software matures you need more and more realistic hardware until finally you are running one the actually target hardware on a real (inert) missile. Actually most projects keep the test environment with all the sensors on the desk connected with the rats nest of wires because you can test some scenarios and odd cases that are hard otherwise, like automated fault detection, cooling system failures, EMI problems and so on. It's a pretty common way to build stuff, the software begins it's life on a Linux or UNIX PC then eventually gets put into some tiny micro controller. When you make a change you first test on the PC before mooing the change down to the target environment. All that said a GPSDO can simple enough that yu can short cut this and go straight to the target hardware. But I think or hope we will see a more complex generation of GPSDO that have a LCD display, user interface and built-in network services. You can't short cut something like that. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
Jim wrote: Is a higher degree loop possible while maintaining stability? Sure. PLL control loops (and other feedback loops) are often designed out to fourth and fifth order. Very simply put, the requirement is that the loop must have a reasonable phase margin at the frequency where the gain reaches unity. For multiple open-loop poles (where this condition would not be met), the usual solution is to give back all but one pole by cancelling them with high-frequency zeroes. All of this can give useful improvements in loop gain at low- to mid-frequencies, at the cost of increased complexity and greater sensitivity to component tolerances. Best regards, Charles ___ 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 simulation tool
Jim, On 23/03/14 16:00, Jim Miller wrote: To handle higher tau performance I think we want a higher degree loop. Cheers, Magnus Is a higher degree loop possible while maintaining stability? Commanding frequency while measuring phase is one pole, integrating the result of the phase comparison is a second pole and closing the loop will result in oscillation unless a zero is inserted (the P in PID). How would stability be maintained? A third degree PLL is stable if the pole-pair is suitably located. The second degree PLL is kind of hard to bring into self-oscillation while that is much easier with the third degree, so more care needs to go into it. When you think about it, putting an exponential averager just after the phase-detector (AVG1 in gpsim1) is in fact making the PLL a third degree, but since the time-constant needs to be constrained to be well below the loop time-constant for stability reasons it is in fact to avoid having the poles of this third-degree loop from deviating away into unstability. I did a temporary hack on the PID code to convert the D-term into I^2 term, by integrating the integrator output. First attempt was indeed quite resonant just to show that I was in the unsafe region. Backing down on the strength of the component sure did remove much of the resonance, but I did not see any appreciable improvement in filtering performance, so quick and dirty hacking isn't sufficient, darn. 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 simulation tool
On 22/03/14 13:17, Tom Van Baak wrote: What's the best way to make an ADEV plot, other then using time lab? Timelab appears to be an MS Windows .exe file.I could write a script based on the definition of adev but I bet someone has already done this. Chris, John's TimeLab gives you much more than ADEV; the ability to display multiple data files and to pan/zoom/average the phase and frequency plots is really nice, especially for GPS 1PPS data. Surely someone on the list has a way to run his Windows program on a different OS. Still, if you don't want to use Stable32 or Plotter or TimeLab, that's no problem. I prefer scripts over GUI myself. I run it under Wine on my Debian Linux boxes. Works, but it could be better. 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 simulation tool
Yes I could run most any MS Windows software on my iMac. But running it is not the point. Closed source software like this is just a magic black box and you can't see how it works. The point is like this: Why build a GPSDO when you can simply buy a Thunderbolt, apply power and go?The same answers apply to software. You want to learn the issues involved, you want to modify it or use it in a different environment. Especially the last part, different environment. I'd like to have my GPSDO draw performance plots and some diagnostics on a little cell phone size LCD screen. On Sat, Mar 22, 2014 at 5:17 AM, Tom Van Baak t...@leapsecond.com wrote: What's the best way to make an ADEV plot, other then using time lab? Timelab appears to be an MS Windows .exe file.I could write a script based on the definition of adev but I bet someone has already done this. Chris, John's TimeLab gives you much more than ADEV; the ability to display multiple data files and to pan/zoom/average the phase and frequency plots is really nice, especially for GPS 1PPS data. Surely someone on the list has a way to run his Windows program on a different OS. Still, if you don't want to use Stable32 or Plotter or TimeLab, that's no problem. I prefer scripts over GUI myself. If it's just ADEV you want, use adev5.c (under www.leapsecond.com/tools/). You can run a GPSDO simulation and pipe the output to adev5 directly: gpsim1 gps-m12cns2.txt ocxo.dat | adev5 /a 0 5 For more sigma,tau points, try: gpsim1 gps-m12cns2.txt ocxo.dat | adev5 /a 0 5 0.1 Then use gnuplot or your favorite plot tool to make the log-log plot. As an example, attached are ADEV+MDEV examples for the M12+T and the mtk3339 GPS receivers, tau 10^0 to 10^5: gpsim1 gps-m12cns2.txt ocxo.dat | adev5 /am 0 5 .1 | gplot2.sh gpsim1 gps-mtk3339.txt ocxo.dat | adev5 /am 0 5 .1 | gplot2.sh /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. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
Not complaining. Just looking for open source tools to do the analysis before I write them myself. I figured someone must have done this. Found it in ../tools as you said. Thanks. Plotting is the easy part, any number of tools to do that, analysis is harder. I'm looking at your simulation software, thinking I could add a PID autotunner.Even using brute force search it could finish over night. Compared to the months it would take using real hardware. On Sat, Mar 22, 2014 at 1:00 PM, Tom Van Baak t...@leapsecond.com wrote: Hi Chris, I'm pretty sure John distributes complete source code to TimeLab as part of the installation. My source code is at www.leapsecond.com/tools There are also many open source plotting tools available. Not sure what you're complaining about, really. Please try using the GPSDO simulator and let's talk time frequency instead of open closed operating systems. Here's an example of what you can do -- varying the pre-filter from 1 to 1000 seconds. First, using the cute little Adafruit Ultimate GPS MTK3339 board: gpsim-22.gif Second, using the fancy CNS-II M12+T box: gpsim-23.gif Both with the same OCXO and same gpsim1 default P,I,D parameters. These plots would have taken weeks of data collection. Instead it took 20 seconds with the simulator. /tvb - Original Message - From: Chris Albertson albertson.ch...@gmail.com To: Tom Van Baak t...@leapsecond.com; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, March 22, 2014 11:56 AM Subject: Re: [time-nuts] GPSDO simulation tool Yes I could run most any MS Windows software on my iMac. But running it is not the point. Closed source software like this is just a magic black box and you can't see how it works. The point is like this: Why build a GPSDO when you can simply buy a Thunderbolt, apply power and go?The same answers apply to software. You want to learn the issues involved, you want to modify it or use it in a different environment. Especially the last part, different environment. I'd like to have my GPSDO draw performance plots and some diagnostics on a little cell phone size LCD screen. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
On Fri, 21 Mar 2014 14:55:34 -0700, Tom Van Baak wrote: Have a look and let me know what you think. The tool is gpsim1.c (Windows: gpsim1.exe) under: http://www.leapsecond.com/tools/ Nice tool Tom I just compiled it under linux. gcc gpsim1.c -lm -o gpsim1 I had to add min/max #define min( a, b ) ( ( a b) ? a : b ) #define max( a, b ) ( ( a b) ? a : b ) Just an info ... GCC complains about this line (my 109 , your 96) fprintf(stderr, %s: sample count (%lg) exceeds data counts (%lg, %lg) \n, Tool, n, gps_n, osc_n); ~/tmp/tvb-gpssim $ gcc gpsim1.c -lm -o gpsim1 gpsim1.c: In function ‘main’: gpsim1.c:109:9: warning: format ‘%lg’ expects argument of type ‘double’, but argument 5 has type ‘long int’ [-Wformat] gpsim1.c:109:9: warning: format ‘%lg’ expects argument of type ‘double’, but argument 6 has type ‘long int’ [-Wformat] ~/tmp/tvb-gpssim $ ~/tmp/tvb-gpssim $ Thanx for the nice tool CFO ___ 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 simulation tool
Hi Tom,
On 22/03/14 21:00, Tom Van Baak wrote:
Hi Chris,
I'm pretty sure John distributes complete source code to TimeLab as part of the
installation.
My source code is at www.leapsecond.com/tools
There are also many open source plotting tools available.
Not sure what you're complaining about, really.
Agree. Download and see what you get. I have not been upset so far, and
I sing the praise of open software on a regular basis. So just look.
Please try using the GPSDO simulator and let's talk time frequency instead of
open closed operating systems.
On that note.
Had to this code after the includes to compile in a Debian box, and yes,
I needed -lm flag naturally since pow needs it.
double min(double a, double b)
{
if (a b)
return b;
return a;
}
That's as far as I get:
./gpsim1 gps.dat osc.dat gpsdo.dat
** GPS 40 samples in file gps.dat
./gpsim1: open failed: osc.dat
Verified files, they are OK. Will have to take a look at the code
details, but nothing obvious.
Here's an example of what you can do -- varying the pre-filter from 1 to 1000
seconds.
First, using the cute little Adafruit Ultimate GPS MTK3339 board: gpsim-22.gif
Second, using the fancy CNS-II M12+T box: gpsim-23.gif
Both with the same OCXO and same gpsim1 default P,I,D parameters.
These plots would have taken weeks of data collection. Instead it took 20
seconds with the simulator.
I like the approach of doing a simulator. I have not had the time to try
it until today.
I think you should do a gpsim1.txt to describe the usage and options.
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 simulation tool
On 22/03/14 22:13, Magnus Danielson wrote:
Hi Tom,
On 22/03/14 21:00, Tom Van Baak wrote:
Hi Chris,
I'm pretty sure John distributes complete source code to TimeLab as
part of the installation.
My source code is at www.leapsecond.com/tools
There are also many open source plotting tools available.
Not sure what you're complaining about, really.
Agree. Download and see what you get. I have not been upset so far, and
I sing the praise of open software on a regular basis. So just look.
Please try using the GPSDO simulator and let's talk time frequency
instead of open closed operating systems.
On that note.
Had to this code after the includes to compile in a Debian box, and yes,
I needed -lm flag naturally since pow needs it.
double min(double a, double b)
{
if (a b)
return b;
return a;
}
That's as far as I get:
./gpsim1 gps.dat osc.dat gpsdo.dat
** GPS 40 samples in file gps.dat
./gpsim1: open failed: osc.dat
First thing you go blind on is the eyes. Spelling the file-name
correctly does it.
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 simulation tool
Many thanks Tom for an excellent tool and also the data you have provided. You don´t happen to have data for a non sawtooth corrected M12? Another question: how do you insert the options for ticres and dacbits? With “gpsim1 avg1=10 gps-mtk3339.txt ocxo.dat gpsdo.txt” I managed to get different prefiltering in the same way as you had in your graphs. But inserting dacbits=10 instead of avg1=10 gave an error for me. Lars ___ 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 simulation tool
On 23/03/14 02:06, Magnus Danielson wrote: Hi As follow-up on the previous message, where I varied the TIC resolution, let's vary the TIC averaging for the TIC resolution of 100 ns, which we know has some effect. The default TIC averaging is for 100 s, so I varied it for 1, 10, 100 and 1000 s. Low and behold, turns out that it does have an effect. See how the lower taus is pushed down for increasing taus. When we look at the phase plot we see that averaging somewhat dampens the effect of TIC-trapping besides that it obviously will filter noise out. My bad. It slightly worsens them, as it remembers them longer. 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 simulation tool
Hi Tom et.al. Isn't the simulator easily convertible to the real thing? That is, data inputs should be convertible somehow to data streams from physical devices? Don cfo On Fri, 21 Mar 2014 14:55:34 -0700, Tom Van Baak wrote: Have a look and let me know what you think. The tool is gpsim1.c (Windows: gpsim1.exe) under: http://www.leapsecond.com/tools/ Nice tool Tom I just compiled it under linux. gcc gpsim1.c -lm -o gpsim1 I had to add min/max #define min( a, b ) ( ( a b) ? a : b ) #define max( a, b ) ( ( a b) ? a : b ) Just an info ... GCC complains about this line (my 109 , your 96) fprintf(stderr, %s: sample count (%lg) exceeds data counts (%lg, %lg) \n, Tool, n, gps_n, osc_n); ~/tmp/tvb-gpssim $ gcc gpsim1.c -lm -o gpsim1 gpsim1.c: In function âmainâ: gpsim1.c:109:9: warning: format â%lgâ expects argument of type âdoubleâ, but argument 5 has type âlong intâ [-Wformat] gpsim1.c:109:9: warning: format â%lgâ expects argument of type âdoubleâ, but argument 6 has type âlong intâ [-Wformat] ~/tmp/tvb-gpssim $ ~/tmp/tvb-gpssim $ Thanx for the nice tool CFO ___ 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. -- The power of accurate observation is commonly called cynicism by those who have not got it. -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
Hi Don, Yes, easy! And that's exactly the idea -- to take real inputs (or borrowed copies of real inputs), and a real software algorithm, and measure the virtual output to see how well your algorithm and tunable parameters work. Tweak parameters. Evolve the algorithm. Simmer until well done. Theoretically, after one builds the real GPSDO, using the same code or at least the same algorithm, the actual performance should nearly perfectly match the simulation. The difference, at least for me, is that I'd rather play with unix commands and C code on a PC, trying things out in a matter of minutes, than spend weeks slowly trying different things with a real GPSDO (which I've also done). In addition, I think gpsim1 makes a useful, almost interactive, teaching tool. Now, no simulation is perfect. But oscillators, dividers, 1PPS comparators, and DACs are not really that complicated. You are probably guessing that I'm working on gpsim2 which will allow simulation of phase and frequency jumps, varying GPS reception, power-up, cold-boot, warm-boot, holdover, thermal or mechanical shocks to the instrument, and other events that I see in real life. But let's let gpsim1 run its coarse before we worry about 2nd order effects. I'm very interested in alternative or enhanced algorithms that people come up with. The two algorithms now in gpsim1 and default tuning parameters are just something I threw together in a few minutes. /tvb - Original Message - From: Don Latham d...@montana.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, March 22, 2014 8:18 PM Subject: Re: [time-nuts] GPSDO simulation tool Hi Tom et.al. Isn't the simulator easily convertible to the real thing? That is, data inputs should be convertible somehow to data streams from physical devices? Don ___ 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 simulation tool
Tom, In my experience one of the biggest GPSDO error sources in low-cost and even some higher end OCXOs is oscillator hysteresis. Which can change with operating temperature, operating time (crystal age) and even over crystal tilt. Does your OCXO model allow for hysteresis simulation? It is very hard to discipline oscillators with hystereses and a good modeling tool would be helpful. Most ocxo vendors don't even know about hysteresis or how to quantify it (and react with a deer in the headlight look when asked about it), but even levels of ppt to tens of ppt can wreak havoc due to the fact that the loop is always chasing the ocxo if sufficient hysteresis exists. Bye, Said Sent From iPhone On Mar 22, 2014, at 22:10, Tom Van Baak t...@leapsecond.com wrote: Hi Don, Yes, easy! And that's exactly the idea -- to take real inputs (or borrowed copies of real inputs), and a real software algorithm, and measure the virtual output to see how well your algorithm and tunable parameters work. Tweak parameters. Evolve the algorithm. Simmer until well done. Theoretically, after one builds the real GPSDO, using the same code or at least the same algorithm, the actual performance should nearly perfectly match the simulation. The difference, at least for me, is that I'd rather play with unix commands and C code on a PC, trying things out in a matter of minutes, than spend weeks slowly trying different things with a real GPSDO (which I've also done). In addition, I think gpsim1 makes a useful, almost interactive, teaching tool. Now, no simulation is perfect. But oscillators, dividers, 1PPS comparators, and DACs are not really that complicated. You are probably guessing that I'm working on gpsim2 which will allow simulation of phase and frequency jumps, varying GPS reception, power-up, cold-boot, warm-boot, holdover, thermal or mechanical shocks to the instrument, and other events that I see in real life. But let's let gpsim1 run its coarse before we worry about 2nd order effects. I'm very interested in alternative or enhanced algorithms that people come up with. The two algorithms now in gpsim1 and default tuning parameters are just something I threw together in a few minutes. /tvb - Original Message - From: Don Latham d...@montana.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, March 22, 2014 8:18 PM Subject: Re: [time-nuts] GPSDO simulation tool Hi Tom et.al. Isn't the simulator easily convertible to the real thing? That is, data inputs should be convertible somehow to data streams from physical devices? Don ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
Well done! Don On 03/21/2014 03:55 PM, Tom Van Baak wrote: Designing a GPSDO is a permanent topic of time-nuts, and always invites lots of opinions and methods. The net performance of a microcontroller-based GPSDO is mostly due to the following ingredients: - the stability of the OCXO (or TCXO or Rb or whatever the LO is) - the stability of the GPS 1PPS (including sawtooth correction, or not) - the disciplining algorithm itself, and user-settable configuration parameters or filtering - the finite resolution of the TIC or phase comparator - the finite resolution of the DAC/EFC Normally what happens is that someone spends weeks or months or even years working on each of these ingredients, measuring, comparing, tweaking, or maybe just hoping for the best. These measurements can take a lot of time, or be difficult to replicate. I have an alternative. It's a simple software tool which takes *real* GPS phase data, and *real* LO phase data, and a *real* GPSDO algorithm(s) -- along with optional resolution of the TIC and optional resolution of the DAC -- and then creates GPSDO phase data through *simulation*. You can then plot this virtual GPSDO phase data with Stable32 or Plotter or TimeLab or your favorite phase / frequency / stability tool. So instead of waiting hours and days to test your new filtering idea, or your new GPSDO algorithm, or to compare the effect of a 10 ns vs. 1 ns vs. 100 ps vs. 10 ps TIC, or to compare the effect a 10-bit vs. 16-bit vs. 24-bit DAC -- you just run the simulation on your PC and get an answer in a few seconds. Have a look and let me know what you think. The tool is gpsim1.c (Windows: gpsim1.exe) under: http://www.leapsecond.com/tools/ For this to work, one needs actual GPS data and actual LO data. I have a growing collection of sample data files here: http://www.leapsecond.com/pages/gpsdo-sim/ For example, if you run this command: gpsim1 gps-mtk3339.txt ocxo.dat gpsdo.txt and use TimeLab to plot these three files, you will get the attached plot. No solder, no instruments, no antenna, no waiting, no guessing. A complete 4-day simulation takes just 3 seconds (on my 10-year old laptop). Load the simulated phase data with 'L' in TimeLab and view phase, frequency, ADEV, MDEV, TDEV. Answer your GPSDO design questions in minutes instead of weeks. Try different parameters. Try different GPS boards. Try different oscillators. See if you can make the best ADEV. Try new disciplining algorithms. Make the PID more complex. Change the filtering. /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. ___ 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 simulation tool
Monumental... On Sat, Mar 22, 2014 at 12:25 AM, djl d...@montana.com wrote: Well done! Don On 03/21/2014 03:55 PM, Tom Van Baak wrote: Designing a GPSDO is a permanent topic of time-nuts, and always invites lots of opinions and methods. The net performance of a microcontroller-based GPSDO is mostly due to the following ingredients: - the stability of the OCXO (or TCXO or Rb or whatever the LO is) - the stability of the GPS 1PPS (including sawtooth correction, or not) - the disciplining algorithm itself, and user-settable configuration parameters or filtering - the finite resolution of the TIC or phase comparator - the finite resolution of the DAC/EFC Normally what happens is that someone spends weeks or months or even years working on each of these ingredients, measuring, comparing, tweaking, or maybe just hoping for the best. These measurements can take a lot of time, or be difficult to replicate. I have an alternative. It's a simple software tool which takes *real* GPS phase data, and *real* LO phase data, and a *real* GPSDO algorithm(s) -- along with optional resolution of the TIC and optional resolution of the DAC -- and then creates GPSDO phase data through *simulation*. You can then plot this virtual GPSDO phase data with Stable32 or Plotter or TimeLab or your favorite phase / frequency / stability tool. So instead of waiting hours and days to test your new filtering idea, or your new GPSDO algorithm, or to compare the effect of a 10 ns vs. 1 ns vs. 100 ps vs. 10 ps TIC, or to compare the effect a 10-bit vs. 16-bit vs. 24-bit DAC -- you just run the simulation on your PC and get an answer in a few seconds. Have a look and let me know what you think. The tool is gpsim1.c (Windows: gpsim1.exe) under: http://www.leapsecond.com/tools/ For this to work, one needs actual GPS data and actual LO data. I have a growing collection of sample data files here: http://www.leapsecond.com/pages/gpsdo-sim/ For example, if you run this command: gpsim1 gps-mtk3339.txt ocxo.dat gpsdo.txt and use TimeLab to plot these three files, you will get the attached plot. No solder, no instruments, no antenna, no waiting, no guessing. A complete 4-day simulation takes just 3 seconds (on my 10-year old laptop). Load the simulated phase data with 'L' in TimeLab and view phase, frequency, ADEV, MDEV, TDEV. Answer your GPSDO design questions in minutes instead of weeks. Try different parameters. Try different GPS boards. Try different oscillators. See if you can make the best ADEV. Try new disciplining algorithms. Make the PID more complex. Change the filtering. /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. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO simulation tool
What's the best way to make an ADEV plot, other then using time lab? Timelab appears to be an MS Windows .exe file.I could write a script based on the definition of adev but I bet someone has already done this. On Fri, Mar 21, 2014 at 4:25 PM, djl d...@montana.com wrote: Well done! Don On 03/21/2014 03:55 PM, Tom Van Baak wrote: Designing a GPSDO is a permanent topic of time-nuts, and always invites lots of opinions and methods. The net performance of a microcontroller-based GPSDO is mostly due to the following ingredients: - the stability of the OCXO (or TCXO or Rb or whatever the LO is) - the stability of the GPS 1PPS (including sawtooth correction, or not) - the disciplining algorithm itself, and user-settable configuration parameters or filtering - the finite resolution of the TIC or phase comparator - the finite resolution of the DAC/EFC Normally what happens is that someone spends weeks or months or even years working on each of these ingredients, measuring, comparing, tweaking, or maybe just hoping for the best. These measurements can take a lot of time, or be difficult to replicate. I have an alternative. It's a simple software tool which takes *real* GPS phase data, and *real* LO phase data, and a *real* GPSDO algorithm(s) -- along with optional resolution of the TIC and optional resolution of the DAC -- and then creates GPSDO phase data through *simulation*. You can then plot this virtual GPSDO phase data with Stable32 or Plotter or TimeLab or your favorite phase / frequency / stability tool. So instead of waiting hours and days to test your new filtering idea, or your new GPSDO algorithm, or to compare the effect of a 10 ns vs. 1 ns vs. 100 ps vs. 10 ps TIC, or to compare the effect a 10-bit vs. 16-bit vs. 24-bit DAC -- you just run the simulation on your PC and get an answer in a few seconds. Have a look and let me know what you think. The tool is gpsim1.c (Windows: gpsim1.exe) under: http://www.leapsecond.com/tools/ For this to work, one needs actual GPS data and actual LO data. I have a growing collection of sample data files here: http://www.leapsecond.com/pages/gpsdo-sim/ For example, if you run this command: gpsim1 gps-mtk3339.txt ocxo.dat gpsdo.txt and use TimeLab to plot these three files, you will get the attached plot. No solder, no instruments, no antenna, no waiting, no guessing. A complete 4-day simulation takes just 3 seconds (on my 10-year old laptop). Load the simulated phase data with 'L' in TimeLab and view phase, frequency, ADEV, MDEV, TDEV. Answer your GPSDO design questions in minutes instead of weeks. Try different parameters. Try different GPS boards. Try different oscillators. See if you can make the best ADEV. Try new disciplining algorithms. Make the PID more complex. Change the filtering. /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. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
