Hi This brings up the basic "how bad is it" question. Since the counter is fundamentally a 200 ps gizmo, a simple period measurement at 1 second will give you ~ 10 digits per second. That's with no magic multiple sample stuff at all. At an offset / noise / what ever state where the multiple sample stuff works 100%, you get ~ 12 digits per second. I doubt you ever get everything so "perfect" that you are down to 10 digits / second.
Bob On Mar 17, 2013, at 7:41 PM, Said Jackson <saidj...@aol.com> wrote: > Bob, > > Thats why the 53132A counter reduces the resolution to one digit less at that > frequency, and why we use an external divide by 2 for 10MHz measurements to > regain that digit. > > I wanted to be fair and compare apples to apples. If i use our 5Mhz input, > the 53132A will be even better. > > We are always measuring at the "deadzone" because our gpsdo's are phase > aligned via gps. But I can guarantee that the counter can differentiate > xE-011 difference in frequencies, as we measure at this level all the time... > > And I assume the zero offset error of the Sr-620 is also due to this deadzone > issue. > > Btw I was wrong the 53132A now sells for $999 on Ebay. The SR-620 is about > $1450. > > Bye > Said > > > > Sent From iPhone > > On Mar 17, 2013, at 16:22, Bob Camp <li...@rtty.us> wrote: > >> Hi >> >> Be very careful of what the 53132(1) reports with the ref out connected to >> the input. You are guaranteed to be in the "dead zone" on the counter when >> you do that. >> >> Bob >> >> On Mar 17, 2013, at 5:33 PM, saidj...@aol.com wrote: >> >>> Hi Volker, >>> >>> there are some issues here, first the worst case frequency systematic >>> uncertainty is 100ps for the 53132A, not 350ps as on the SRS unit or 500ps >>> as >>> you stated. So they are not the same, they are 3.5x different. >>> >>> From the Agilent manual: >>> >>> Systematic Uncertainty: >>> Agilent 53131A Agilent 53132A >>> tacc tacc >>> typical 100 ps 10 ps >>> worst case 300 ps 100 ps >>> >>> Notice the 10ps typical error, and 100ps worst case error. That compares >>> to a 100ps typical error for the SR-620 or 10x worse typically than the >>> 53132A. >>> >>> So we get 10x worse typically, and 3.5x less for the worst case - in my >>> opinion these units are not even in the same class. >>> >>> Now for practical matters, I just measured the SR-620 we have with a >>> randomly selected 53132A. Both connected to their own reference input. >>> 2-second >>> samples on both, and here are the results: >>> >>> The SR-620 shows a frequency error of -0.00203Hz consistently.That's >>> 2.03E-010. Within its specifications but making the unit useless to me. >>> >>> The 53132A showed an error of only 2E-012 to 8E-012. So about 25x better >>> accuracy! And the 53132A is showing 12 digits on the front panel as well >>> for >>> 2 second gate times at 10MHz. Nor does it require time-consuming and error >>> prone and annoying internal adjustments to achieve this. >>> >>> What's even more damming for the SRS unit: as I increased the sample size >>> (1s gate time is the max front panel selection, so I had to increase sample >>> size instead of gate time) the error stayed persistent independent of >>> sample size or thus measurement length. >>> >>> On the HP unit however, increasing the gate time made the error get smaller >>> and smaller, and at 10+ seconds gate time I got 13 digits of resolution >>> out of the unit, and an error of only 1E-012 at that point. >>> >>> So in summary, the SR-620 requires careful user adjustment of internal >>> adjustment points. I don't have time to do that, so sent it in and paid the >>> >>> $600+ or so (if I remember correctly) for the standard calibration fee they >>> >>> charge. I got a unit back with the error unchanged, which was the original >>> reason I sent it in to them in the first place. An error of 2E-010 makes >>> the >>> unit useless as we are in need of measuring xE-011 accurately. If I had >>> time to learn how to calibrate the unit myself, I may do so, but even then >>> you >>> showed a 2E-011 error on your carefully adjusted unit, whereas I measured >>> a 2 to 8E-012 error on a random non-adjusted 53132A unit here. Still about >>> 3x to 10x difference in performance. >>> >>> If someone is interested in a swap of a working 53132A with input-c option >>> for our SR-620 I would like to talk to you offline. I would even throw-in >>> an FEI Rubidium reference in that swap, even though the SRS' sell for about >>> >>> $2300, and the 53132A'a go for about $1400. >>> >>> bye, >>> Said >>> >>> >>> In a message dated 3/17/2013 13:02:46 Pacific Daylight Time, >>> ail...@t-online.de writes: >>> >>> >>> I just powered on my SR and looked for the offset, when the 10 MHz >>> reference is connected to the input (at a gate time of 1s without >>> further averaging). It shows an offset of 0 to 400uHz which should >>> represent a mean error of 2E-11, while the manual predicts an error of >>> about 1E-10 (as Said told us, and as my manual tells me). That's within >>> the spec. >>> >>> Unfortunately I don't have a 53132, but the manual of the HP predicts an >>> error of E-10 - just the same value as with the SR. >>> >>> >>> _______________________________________________ >>> 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. _______________________________________________ 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.
