Hi M. welcome to the world of GPSDO optimization, one thing you will find is that there never is a time when there is no chance to improve something :) On the 1PPS sawtooth correction, the usual convention is for the following 1PPS. The easiest thing to do rather than trying to guess the GPS unit's behavior is to try it out on both pulses, and also try adding and subtracting the number from your raw phase measurement, then you get four streams of values, and it will be instantly obvious which one is the one that reduces the noise most. The other three will increase the noise over your raw, uncorrected measurements. On the DAC resolution, it depends on the OCXO control range, and the ADEV performance you want to achieve. For example if your OCXO has +/-2Hz control range, then a 16 bit DAC will only give you an LSB resolution of about 61 microhertz, or 6.1E-012 (4Hz divided by 2^16). This may or may not be acceptable to you. If your OCXO has a more typical +/-20Hz control range, then this would go up to 6.1E-011 per LSB, which will definitely affect your ADEV. Usually, GPSDO's use at least 20 bit control range due to this quantization effect. But in the end it may also be limited by your time-interval-counter resolution, because every tick in your counter will equal to so many steps in your DAC (depending on what gains you use for your loop prediction). Also, make sure to put filtering for errand pulses into your code, every GPS WILL generate an errand pulse from time to time in my experience, and these can be off by 10's of microseconds.. if you don't filter these properly, they will lead to jumps in your frequency. Hope that helps, Said In a message dated 9/14/2012 11:21:57 Pacific Daylight Time, g...@partiallystapled.com writes:
First off a technical question. I'm using a Trimble Resolution SMT as the pulse-per-second source. It sends a supplemental timing packet that contains an estimate of the quantization error in its pulse output. But the manual isn't clear on whether that applies to the next pulse or to the previous one. I've seen people correct the delay by using a programmable delay line which seems like it would only be possible if the measurement was for the next pulse. But on the other hand there is a "pulse was not generated" alarm that definitely applies to the previous (non)-pulse which suggests that maybe other fields refer exclusively to the previous pulse. I can handle either way since the pulses are timestamped asynchronously and can be post-processed at any time but from some preliminary data collection it's not clear which way it's meant to go. Does anyone know for sure whether the quantization error is for the next or preceding pulse? _______________________________________________ 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.