On Thu, Mar 4, 2010 at 6:04 PM, Paul Demorest <[email protected]> wrote: > Dan, > > I think a tone (or comb) whose phase is fixed wrt the 1pps is probably a > better measurement to make than sampling the 1pps itself. The "average over > lots of 1pps" could be an interesting thing to try, maybe in parallel with > the cal signal approach. We did something kinda similar in our S5-based > pulsar systems to measure these fractional clock cycle delays. Although if > what Dave said earlier is right, in this case the averaging method can't > recover the "power-up" ambiguity, so we'll always need a reference signal > coming through the ADC inputs to check against.
I solved this problem on a bunch of USRPs by injecting white noise and correlating it between all the receivers. Assuming you were already reasonably close to calibrated, the phase of the correlation is a straight line mod 2*pi, and by fitting it, I got an accuracy of about 0.01 samples with a small fraction of a second of data. In this case, with all clocks synchronous, 0.01 samples of uncertainty should be more than good enough. Of course, you'll have to use the analog inputs to do this. > > -Paul > > On Thu, 4 Mar 2010, Dan Werthimer wrote: > >> >> >> hi paul, >> >> regarding measuring 1 PPS, >> >> i think a calibration signal is best, (eg: inject 1 PPS into the adc >> input), but if you don't want to use a calibration signal, i think you can >> recover the 1 PPS sync input signal to about 10 nS RMS accuracy, perhaps >> down to 1 nS if you look at lots of samples of the 1 PPS signal. >> >> the fpga clock has jitter, tand the 1 PPS rise time changes, and the 1 PPS >> buffer amplifier on the adc board has a delay that drifts with temperature, >> and so do the adc and fpga's buffers for clock and sync. my guess is that >> these might add up to an uncertainty of a couple of nS depending on >> temperature. >> >> since you are measuring the 1 PPS input on all four phases of the fpga, >> you are essentially sampling 1 PPS at 800 Msps. if you are lucky, there >> will be enough jitter in the fpga clock (and if the cables are the right >> length) to produce a different 1 PPS arrival phase once in a while, so by >> making thousands of measurments of the 1 PPS, you can beet the timing >> uncertainty of 1/800MHz down by sqrt(Nmeasuments) until you hit the noise >> floor of about 2 nS. >> >> best wishes, >> >> dan >> >> >> >> On 3/4/2010 2:10 PM, Paul Demorest wrote: >>> >>> Dan and everyone, >>> >>> Thanks for the info, this discussion has been helpful. To put this all >>> into context, our application is a single-dish pulsar backend, not a >>> correlator. This means that absolute time (ideally at the few ns level) is >>> important, which is why we're talking about all this in the first place. It >>> also means we can't calibrate these delays astronomically. Probably >>> injecting a calibration signal with known phase is the way to go. >>> >>> -Paul >>> >>> On Thu, 4 Mar 2010, Dan Werthimer wrote: >>> >>>> >>>> >>>> hi jason, dave and paul, >>>> >>>> regarding syncing up one or two adc's with 1 PPS: >>>> >>>> at boot up, the iADC (also called ADC2x1000-8), yellow block >>>> software/gateware aligns two adc's that are plugged into roach or ibob. the >>>> code does this by sampling the relative phase of the two clocks that emerge >>>> from each adc (these clocks are generated internally in each adc, by >>>> dividing the sample clock by four); the code resets one of the adc's until >>>> the two adc clocks are lined up in phase. >>>> >>>> although it might be possible to crudely recover the phase of the 1PPS >>>> signal by looking at all four sync pulses, in practice, as you guys point >>>> out, it's better to calibrate this delay, best by looking at a known source >>>> on the sky, or possibly digitizing the 1 PPS by coupling it into the analog >>>> input and then finding it's edge in software using lots of samples. this is >>>> should be done everytime the system is powered up. >>>> >>>> >>>> dan >>>> >>>> >>>> >>>> On 3/4/2010 1:18 PM, Jason Manley wrote: >>>>> >>>>> The four sync lines are supposed to represent the ADC sample where the >>>>> sync was input (as Paul suggests). And this mostly does work, however, it >>>>> breaks when using two ADCs on one board, because the sample clock for the >>>>> second ADC's 1PPS is derived from the first ADC, not from that second ADC. >>>>> This is then a problem for correlator applications where you have two ADCs >>>>> in one IBOB where you can have an unknown phase on that second ADC. >>>>> >>>>> In reality, most people just "OR" the four sync outputs together, >>>>> resulting in an unknown phase difference which gets calibrated-out as Dave >>>>> suggests. >>>>> >>>>> Jason >>>>> >>>>> On 04 Mar 2010, at 12:46, Paul Demorest wrote: >>>>> >>>>>> On Thu, 4 Mar 2010, David MacMahon wrote: >>>>>> >>>>>>> >>>>>>> On Mar 4, 2010, at 11:52 , Paul Demorest wrote: >>>>>>> >>>>>>>> I have to ask.. if all four syncs are the same, why are there four >>>>>>>> of them? ;) >>>>>>> >>>>>>> Just to clarify, they represent the same signal sampled at (i.e. >>>>>>> registered using) four different phases (0/90/180/270) of the FPGA >>>>>>> clock. >>>>>>> >>>>>>> Or did you already know that and were just needling Dan? :-) >>>>>> >>>>>> No, I really was curious why there would be four copies of the same >>>>>> thing! >>>>>> >>>>>> To summarize your explanation Dave, the four syncs really do represent >>>>>> the input sync sampled on each of 4 ADC clocks. But there is also some >>>>>> uncertainty after each power-up that means sync0 doesn't necessarily >>>>>> match >>>>>> up with data0, etc. Is that right? >>>>>> >>>>>> -Paul >>>>>> >>>>> >>>>> >>>> >>>> >> > >
