Hi Bill, I'm travelling at the moment, but I had another go just now and it has stopped wiping my details when I press the save button so hopefully that means it is fixed.
I must just have been unlucky and picked a glitchy day (this was at the end of last week). Though, now that I've downloaded NI-VISA and got that working I probably don't need to download tek-VISA. Best Regards, James -----Original Message----- From: Bill Byrom <t...@radio.sent.com> To: time-nuts <time-nuts@febo.com> Sent: Sun, 22 Mar 2015 20:28 Subject: Re: [time-nuts] ADEV noise floor vs counter gate time Was the website problem this past week? The main Tek US website was acting up for a while one day this week, but seems to be fine now. I have no insights on European access. -- Bill Byrom N5BB On Sun, Mar 22, 2015, at 07:10 AM, James via time-nuts wrote: > Hi Bill, > > Thanks for the pointers. > > I should say that my results reported so far have been with my older TTi > TF930 reciprocal counter, not with my FCA3100 which I have only just got > (it arrived a few days ago) and I'm in the process of writing software to > talk to it via the USB. > > I did discover the website, in fact I'd downloaded the manual before > buying the counter, and it is fortunate I did because the website for me > didn't work - I'm currently talking to Tek support about it. > > The problem is that to download software you must have your details > registered. Every time I register my details and press the "save" button > the site wipes all my details and returns to a blank form. When I try to > down load the software it then stops me and tells me to update my > details. I update my details and it blanks the form and so on... slightly > frustrating. I've tried both Firefox and IE. > > The other thing is that the manuals don't show on the European site (I'm > in the UK), you click on them but the download screen just shows a blank > line. I got round this by going to the international site and just > closing the screen asking me for my area rather than responding to it - I > had to do this several times. > > I have now downloaded NI-VISA and have managed to do a bit of talking to > the instrument over USB though I've not yet had time to do this properly. > > So in summary - I'm pleased with my counter but the Tek website for > Europe at least has some serious bugs which hopefully will be fixed soon. > The Tek support person I spoke to on the phone was helpful but she wasn't > in a position to fix the web site issues directly so has forwarded my > case to Tek IT. > > I intend repeating my TTi TF930 experiment with my FCA3100 when I've got > everything working ok and am looking forward to seeing the results. > > James > > > > > > > > -----Original Message----- > From: Bill Byrom <t...@radio.sent.com> > To: time-nuts <time-nuts@febo.com> > Sent: Sun, 22 Mar 2015 2:27 > Subject: Re: [time-nuts] ADEV noise floor vs counter gate time > > > Hi, James. I'm a Tektronix RF Application Engineer in Dallas and thought > I > would throw in a few points about your FCA3100 (if you haven't read up > on these > already): > > All Tektronix manuals and technical reference documents can > be > downloaded for no charge on our website (http://www.tek.com), but > some > items may require you to register and sign in. The detailed > specification > and performance verification document (document number > 077-0495-01) has many > details about the specifications, and is > at: > http://www.tek.com/frequency-counter-supplies/mca3027-manual/fca3000-and-fca3100-series-mca3000-series > > All > downloadable files for this product can be found in the list > at: > http://www.tek.com/search/apachesolr_search/fca3000 If you have a > used > counter, be sure you check the firmware version and update it if > needed. > > If your exact model is "FCA3000", you have a 300 MHz counter with 100 > ps > single-shot resolution. This counter has reciprocal counter features > (based > on a 10 ns main counter time resolution), but also uses 100 ps > RMS jitter > interpolation to determine edge location with an additional > X100 resolution. > When the initial edge of the signal you are measuring > is detected, the > interpolater resolves this edge with 100 ps resolution > relative to the internal > 10 ns clock. After the desired measurement > interval, the final edge is also > resolved with 100 ps resolution, and > the number of signal edges and > interpolated intitial-to-final time are > used to determine the frequency (for > example). The analog interpolation > circuit uses a constant current charging a > capacitor with a sampler and > A/D converter. Counting a 100 MHz signal, this > provides 12 digits of > resolution per second of measurement > interval. > > -- > Bill Byrom N5BB > > > > On Wed, Mar 18, 2015, at 05:49 PM, James > via time-nuts wrote: > > Hi Dave, > > > > Thanks for another detailed > response. > > > > I've now programmed a version of my code that attempts to > recover the > > raw data by trying different counts up and down from the nominal > and > > finding the one with the smallest rounding error. > > > > One problem is I > need to restrain the amount it goes up or down > > otherwise it finds erroneously > small or large numbers of cycles (+/- 2 > > is believable, more than that > isn't). > > > > As an experiment I then changed the data to match the "raw data". > This > > doesn't change the shape of the curve but it lowers it so it starts > > > below 10^-15! This is suspiciously good so I think I'm smoothing out > > changes > that are really there. > > > > Now that my new fca3100 has arrived I'm hoping to > find time to get > > measurements with it which should be proper time-stamped > ones and much > > more accurate - then I can compare the two. > > > > To answer > your question on ADEV aggregating values, and speaking as a > > total newbee > myself, the approach to different tau sizes is to > > aggregate all measurements > within a bin of size tau and average the > > frequencies (or average the time > differences and invert - for small > > variations it makes very little difference > as (1+delta)^-1 is 1-delta > > ignoring delta*delta terms). Then each term in the > Alan Variaton > > summation is the square of the difference between the > average > > frequency in adjacent bins. > > > > So with 1 second values at a tau of > 100 secs, 100 values in each cell > > are averaged whilst the 100 sec gate value > results just have a single > > value for each bin. But given that the counter > itself should be > > averaging there should be good agreement between the two - > hence my > > puzzlement. > > > > The fca3100 calculates ADEV directly so I'll have > a check on my code. > > > > James > > > > > > > > > > > > > > > > -----Original > Message----- From: Dave Martindale > > <dave.martind...@gmail.com> To: jpbridge > <jpbri...@aol.com> > > CC: Discussion of precise time and frequency > measurement > > <time-nuts@febo.com> Sent: Wed, 18 Mar 2015 15:22 Subject: > Re: > > [time-nuts] ADEV noise floor vs counter gate time > > > > > > > > The > counter always has a 1 count uncertainty in the timebase > > measurement, which > is a 2e-8 error with a 1 second gate time. If the > > value being displayed > starts with the digit 9, and 8 digits are > > displayed, then that translates to > +- 2 counts in the last place. But > > the measurements are synchronized to the > input signal, so it always > > measures an integer number of input cycles, and > there should be no > > comparable uncertainty in the input (other than some noise > in deciding > > exactly when the edge crosses the input threshold, which should > be > > tiny compared to the 20 ns timebase period). > > > > > > > > But that's > comparing the counter reading to the real world. My table > > was comparing the > displayed output to the likely raw measurements, and > > it seems to show that > the counter's internal math is being performed > > to the full 10 digits of > precision in the USB data, even when the gate > > time supports only 8 bits of > accuracy. That's good news because it > > allows you to know when you have > correctly guessed the input counts. > > > > > > > > > > When trying to calculate the > raw data from the reading, you do need to > > try an input count of 91 in > addition to 90 and 92. 91 did show up in > > the small sample of period-mode > measurements, even if it did not > > appear in any of the frequency-mode > measurements. > > > > > > > > > > I don't think the counter is doing "averaging", in > the sense of making > > multiple independent short-period measurements and then > averaging them > > for higher precision. Instead, it is just making one long > continuous > > measurement, sampling the signal periodically, and then > actually > > calculating frequency or period from two measurements separated by > an > > appropriate time. For a simplified example: > > > > > > > > > > Suppose the > counter generates a time stamp approximately every 1 > > second (always aligned > with the input signal active edge) and then > > stores the two pieces of raw data > (the current input cycle counter and > > the current timebase counter) in a small > memory buffer. The counters > > are never reset; they just need to be large > enough to never overflow > > twice within the longest input period allowed (1000 > s for the TF930). > > To display a frequency or period based on a 1 s gate time, > the counter > > simply subtracts two successive data records to get delta-input > and > > delta-timebase counts, then does its calculations based on those > > > deltas. To display a 10 second gate time measurement, the counter > > looks back > through its memory to find a time stamp about 10 seconds > > earlier than the > most recent measurement (with high input frequency, > > that will generally be 10 > measurements ago, but when measuring a > > signal with a 0.2 Hz frequency it's > only 2 measurements ago). For a > > 100 second gate time measurement, the count > er needs to find a saved > > time stamp that is about 100 seconds ago. Once it > has found the > > correct data record, it calculates the difference in input > and > > timebase counts between that one previous data record and the most > > > recent, and then calculates the displayed value from it. > > > > > > > > > > One > second later, the counter can calculate a new 100 s measurement, > > using the > new data point just captured and a different stored data > > point 100 seconds > ago. But 99 of the 100 seconds in the new gate > > period are shared with the old > gate period, so the displayed value is > > not likely to change very much simply > because 99% of the observation > > period is shared. > > > > > > > > > > Thus, every > displayed value is calculated from only 2 time-stamped > > measurements. The > longer gate time places those measurements further > > apart, reducing the > uncertainty due to the +- 1 clock of the timebase. > > Because the counters run > continuously without resetting, no clock > > edges are lost and a 100 s gate time > measurement has only 20 ns > > uncertainty in the whole 100 s period. Also, any > wander in the input > > frequency between those two measurements is invisible if > it cancels > > out over the gate time. So there is "averaging" in the sense that > the > > counter display always reflects what is happening on the scale of the > > > gate time, but it's not computing and then averaging multiple > numbers. > > > > > > > > > > I have not tried doing my own ADEV calculations, so I > can't say what > > it is about the shorter gate periods that make the oscillator > appear > > noisier than it really is. How does the ADEV calculation aggregate > a > > stream of short-time calculations into measurements for large tau > > > values? My intuition is this: If you just take readings from the > > counter with > a 1 s gate time, each reading has a 2e-8 uncertainty. If > > you average a bunch > of these readings, and the errors are independent, > > the accuracy should > improve by a factor of sqrt(N). But if you unwrap > > each reading into an > integer number of input and timebase cycles, you > > essentially have a series of > phase samples that can be added or > > subtracted without increasing the absolute > uncertainty. So when you > > combine 100 1 second measurements, you get a > relative accuracy that is > > 100 times better, not the sqrt(100) you'd get from > averaging. > > > > > > > > > > - Dave > > > > > > > > > > > > > > On Wed, Mar 18, 2015 at > 6:33 AM, <jpbri...@aol.com> wrote: > > > > Hi Dave, > > > > Interesting analysis. > The accuracy stated in the manual is ...+ 2 > > counts and though this relates to > the 50MHz clock, perhaps they use a > > similar algorithm for the input > frequency. > > > > I completed the 0.3 second measurements and the curve is > similar to 1 > > second but higher up (i.e. as you'd expect by extrapolation from > the > > behaviour of the other curves). > > > > My ADEV calculation is based on the > average frequency in each bin, the > > varying size of the bin should be > insignificant as long as it is not > > affecting the average value within the > bin. If the average frequency > > shifts by delta_F in one bin time step and the > first bin is delta_T > > short (as a fraction of one bin time step) then the > first frequency > > will be delta_T*delta_F low and the second bin perhaps that > much high > > but the key point is that it is the product of the two deltas so > it > > won't materially affect the accuracy of the calculation. At least I > > > think that is correct. > > > > Taking the worst possible case where the delta in > bin size always went > > the wrong way so every term in the Alan Variance sum was > multiplied by > > (1+2delta)^2 then the final Alan deviation might be (1 + 2 > delta) too > > big but as delta is of the order of 10E-8 or less this wouldn't > even > > register on the graphs. > > > > What I might try doing is programming your > approach into the code to > > try and get at the raw data - I only need to try > 88,90 and 92 as > > possible counts - though to be sure I'll try mean frequency > +- 5 say > > and then try and get the 50MHz clock values out as integers. What > I > > might also do is then do a least squares fit (linear regression) to > > get > the frequency over each bin and use the slope (this perhaps is > > what the > counter does internally - I don't know). > > > > I'd like to get to the bottom of > this if only to understand my > > counter better. > > > > > James > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > From: Dave Martindale > > <dave.martind...@gmail.com> > > > > > > To: jpbridge < > jpbri...@aol.com>; time-nuts < time-nuts@febo.com> > > Sent: Wed, 18 Mar 2015 > 1:26 Subject: Re: [time-nuts] ADEV noise floor > > vs counter gate > time > > > > > > > > I believe I see the pattern. As you figured out, you wouldn't > expect a > > single period to be a multiple of 20 ns; you expect the length of > > > (about) 90 periods to be an integer multiple of 50 ns, since that's > > what the > counter actually measures. Further, the measuring time isn't > > exactly 1 > second, it is an integer number of periods of the input > > frequency that makes > up at least 1 second. If the counting logic was > > all hardware, you would > expect to capture either 90 or 91 cycles of > > the input, depending on whether > the input frequency was slightly below > > or above 90 Hz respectively. > > > > I > built this table of your frequency data in Excel. Math is 64-bit > > floating > point, equivalent to about 16 decimal digits, so plenty > > accurate enough to > simulate this counter: > > > > Reading Input Count TB Count Rounded Frequency > Interval 90.00006359 92 > > 51111074.998 51111075 90.00006359 1.022221500 > 90.00007591 92 > > 51111068.002 51111068 90.00007591 1.022221360 89.99999640 > 90 > > 50000002.000 50000002 89.99999640 1.000000040 89.99998740 90 > > > 50000007.000 50000007 89.99998740 1.000000140 90.00006007 92 > > 51111076.997 > 51111077 90.00006007 1.022221540 89.99996040 90 > > 50000022.000 50000022 > 89.99996040 1.000000440 90.00008648 92 > > 51111061.999 51111062 90.00008648 > 1.022221240 90.00008472 92 > > 51111062.999 51111063 90.00008472 1.022221260 > 90.00011465 92 > > 51111046.001 51111046 90.00011465 1.022220920 90.00014459 > 92 > > 51111028.998 51111029 90.00014459 1.022220580 > > > > The first column is > your data. The second column is a guess about how > > many input cycles were > captured. The third column is the number of > > timebase cycles that have elapsed > since the previous reading, based on > > the first two columns. I hand-tweaked > the numbers in the second column > > until the number in the third column was > within 0.003 of an integer. > > The fact that I was always able to do this tells > me that my guess is > > probably correct, and the small residual (which is a few > parts in > > 1e-10) is due to the counter rounding the results to 10 digits. > The > > 4th column is the result of rounding the previous column to the > > > nearest integer. This is what I believe is the actual number of counts > > the > counter saw. The 5th column is a fresh calculation of frequency, > > based on the > integer number of input cycles in column 2 and the > > integer number of timebase > cycles in column 4. When the result is > > rounded to 10 digits, you can see it > matches the 10 digits that the > > counter provided back in column 1. > > > > > > > Oddly, the counter never captured 91 input cycles. If the input > > frequency was > a little higher than 90 Hz, it always measured at 92 > > cycles, even though 91 > cycles was well more than 1 s since the > > previous reading. I guess the > microprocessor running the counter only > > checks periodically (e.g. every 20 > ms) to see if the gate time has > > elapsed, and then latches the counts on the > next active edge of the > > input signal. > > > > So, I claim that with this small > sample, at least, we recovered the > > exact number of 20 ns periods between > samples, and the number of > > integer input cycles as well. Also notice the 6th > column. This is the > > actual sample interval, based on the number of elapsed > timebase > > counts. Note that the sample period is **not** exactly 1 second, > nor > > is it even close to a constant value, since some measurements are of > > > 90 cycles while others are of 92 cycles. Does your ADEV calculation > > algorithm > take into account the variable spacing of the input samples > > in time? If it > assumes they are regularly spaced (i.e. every 90 > > cycles) it may get confused > by this variable-spacing data. > > > > Now here is almost the same process applied > to your period data: > > > > Reading Input Count TB Count Rounded Period Interval > 0.01111107736 91 > > 50555401.988 50555402 0.01111107736 1.011108040 > 0.01111110130 92 > > 51111065.980 51111066 0.01111110130 1.022221320 > 0.01111110769 91 > > 50555539.990 50555540 0.01111110769 1.011110800 > 0.01111110435 92 > > 51111080.010 51111080 0.01111110435 1.022221600 > 0.01111110593 91 > > 50555531.982 50555532 0.01111110593 1.011110640 > 0.01111110022 90 > > 49999950.990 49999951 0.01111110022 0.999999020 > 0.01111114000 90 > > 50000130.000 50000130 0.01111114000 1.000002600 > 0.01111110000 90 > > 49999950.000 49999950 0.01111110000 0.999999000 > 0.01111110370 92 > > 51111077.020 51111077 0.01111110370 1.022221540 > > > > Again, > column 2 was hand-adjusted for each row to keep the third > > column close to an > integer. The residual errors here are larger, since > > the maximum rounding > error of 0.5 in the last place is a larger change > > relative to a 10-digit > value of 11111111 than it is to a value of > > 90000000, but all are still within > 0.02 of being an integer. This > > time, the counter grabbed measurements after > 90, 91, or 92 cycles. > > Again, after rounding the timebase count to an integer > and calculating > > a 10-digit period for display, the result always matched what > the > > counter output. Again, I think we know with high probability just how > > > many input and timebase cycles were counted for each measurement. > > > > I > adjusted column 2 by eye, while looking at the results of column 3, > > but that > process could be automated pretty easily (just not in Excel). > > As I tried 90, > 91, and 92 in sequence, there was always just one of > > those which gave a small > residual error. > > > > So I think your TF930 is making measurements and > accurately converting > > them to frequency or period, with a +- 20 ns > uncertainty for each > > measurement. Since it is a time-stamping counter, the > uncertainty in a > > 10 s or 100 s or 1000 s measurement time (assembled by > external > > software) is still only 20 ns. That's great, but to actually get > that > > accuracy over a long measurement time, you will need to determine and > > > add up the actual number of input counts and timebase counts. And you > > will > have to understand that the counter does not make measurements at > > constant or > near-constant intervals (e.g. every 90 cycles of input, > > without exception). > It gives you measurements whenever it gets around > > to measuring them. > > > > > Too bad there doesn't seem to be a way to get it to return the raw > > observed > data (input cycle count, timebase cycle count) instead of > > the frequency or > period derived from them. That would make it trivial > > to string together a > bunch of 1s measurements into arbitrarily long > > gate times. > > > > - > Dave > > > > > > On 17/03/2015 05:57, jpbri...@aol.com wrote: > > > > > > Hi > Dave, > > > > Thank you for your detailed response. > > > > I use the E? command > because it returns results at the gate time > > intervals rather than at the LCD > update rate (as you point out). I > > think that this is working correctly > because I get very different > > file sizes. > > > > The numbers are returned as > strings of 10 digits - here are some for 1 > > second gate: > > > > > > > > > > > 90.00006359e+0Hz > > 90.00007591e+0Hz > > 89.99999640e+0Hz > > 89.99998740e+0Hz > > > 90.00006007e+0Hz > > 89.99996040e+0Hz > > 90.00008648e+0Hz > > 90.00008472e+0Hz > > > 90.00011465e+0Hz > > 90.00014459e+0Hz > > > > I generally use the frequency mode > but I also tried time period and > > found I got the same curve in essence, which > was comforting in a way > > but showed it wasn't rounding in converting to > frequency. > > > > The numbers above, on my calculator at least don't exactly > match > > counts of 20 nanosecs. > > > > Here are some time period results: > > > > > 11.11107736e-3s > > 11.11110130e-3s > > 11.11110769e-3s > > 11.11110435e-3s > > > 11.11110593e-3s > > 11.11110022e-3s > > 11.11114000e-3s > > 11.11110000e-3s > > > 11.11110370e-3s > > > > Again they don't seem to be integer values of 20 nanosec > exactly, > > though quite close. For example > > 11.11107736E-3/20E-9 = > 555,553.868 555,554 x 20E-9 = 11.11108E-3 > > > > But I guess what it returns is > the ratio of counts within the gate. So > > 11.11107736E-3 period will occur 90 > times in a second (as it is > > slightly short) and so I should take the > ratio: > > > > 90 x 11.11107736E-3/20e-9 = 49,999,848.12 > > > > so still not quite > an integer but if I assume the count (of 50MHz > > periods) was 49,999,848 and > calculate one 90 th of it I get: > > > > 49,999,848 x 20E-9/90 = > 1.1111077333333 > > > > Still not exact agreement. I note that .12 is very close > to .125 or > > 1/8 but I don't know if that is significant. It is probable that > it > > rounds the ratio in binary and then converts to decimal to print > out. > > > > I've tried assuming 89 periods and 91 periods but still don't get > > > exact integer ratios. > > > > Anyway, as I get good agreement between period and > frequency > > measurements at 1 sec, I don't think that it is a rounding > issue. > > > > I do think it is a quantization issue down to the +/- 20 > nanosecs/gate > > time but I can't quite work it out. > > > > I'm currently doing a > run at 0.3 secs gate time and I'll see what sort > > of curve that > produces. > > > > Tomorrow I should receive my new Tek counter (I went for the > fca3100 > > in the end as I got a very good discount on an ex demo unit) and > > > that should give something to compare (once I've worked out how to > > program > it). > > > > James > > > > > > > > > > > > > > -----Original Message----- From: Dave > Martindale > > <dave.martind...@gmail.com> To: jpbridge <jpbri...@aol.com>; > > > Discussion of precise time and frequency measurement > > <time-nuts@febo.com> > Sent: Tue, 17 Mar 2015 0:27 Subject: Re: > > [time-nuts] ADEV noise floor vs > counter gate time > > > > > > > > > > How is the counter configured? Are you reading > period or frequency? > > Are you in "E?" (Every Result) mode, or "C?" (Continuous > Result) mode? > > The former should give you continuous but independent > measurements, > > while the latter gives heavily overlapped measurements. (For > example, > > with a 100 second gate time, you get one E output every 100 > seconds, > > which covers a different 100-second period than the previous > > > measurement. In C mode, you get one output every 2 seconds, each of > > which is > an estimate from 100 seconds of measurement, but 98 seconds > > of that data was > also part of the previous output and only 2 seconds > > of new data is > included). > > > > > > > > > > What does the data returned by the counter actually > look like? The > > manual implies that you always get 10 digits worth of result > (not > > including the exponent) regardless of gate time, but are the values > > > rounded for display in 7, 8, or 9 digits at the shorter gate times, or > > are > they a full 10 digits always? Given any particular value of > > frequency or > period you get, you should be able to reverse-calculate > > the number of whole > cycles of the input signal that the counter used > > as a gate time, and the > number of cycles of 50 MHz timebase that were > > counted in that period. Since > the counter doesn't have interpolators, > > both of these values should be > integers, and so the possible output > > values are a small subset of all > possible 10-digit values for the > > shorter gate times. > > > > > > > > For example, > if the difference frequency is exactly 90 Hz, the period > > between two "1 > second" measurements will be exactly 1 second, and the > > counter will record 90 > cycles of input and 5e7 cycles of timebase, > > exactly. In frequency mode, the > output should be 90.0 Hz exactly, and > > in period mode the output should be > 11.11111111 ms. Now suppose that > > the difference frequency is just a hair > slow, enough that 90 cycles of > > input spans 50,000,001 counts of the timebase. > The reported frequency > > should be 89.99999820 Hz and the reported period > should be 11.11111133 > > ms. With a 1 s gate time, no values between those are > possible unless > > the values are being rounded (or there is an error in the > calculation, > > which is always possible). Looked at another way, the > smallest > > possible change in the reported period is one timebase clock (20 > ns) > > divided by the number of input cycles in one gate time (90 for 1 > s). > > > > > > > > > > If the counter is rounding, you may be able to unambiguously > figure > > out what the actual inputs (cycles of input and cycles of timebase) > to > > the calculation were, and use that instead of the rounded value in > > your > calculations. Rounding may round up or down, but if the two > > oscillators are > stable enough the direction can be predominantly "up" > > or "down" for long > periods of time, adding a bias to the actual > > frequency or period you're > measuring. (I don't know what effect this > > bias would have on > ADEV). > > > > > > > > > > - Dave > > > > > > > > > > On Mon, Mar 16, 2015 at 10:15 AM, > James via time-nuts > > <time-nuts@febo.com> wrote: > > > > Hi All, > > > > I'm in > the process of getting a better counter, but at present I'm > > using my TTi > TF930 counter. > > > > For those who don't know it, it is a reciprocal counter > which should > > be continuous, it counts periods in terms of its internal 50MHz > clock > > which I've locked to an external 10MHz reference. > > > > There are 4 > gate times available, 0.3 secs, 1 sec, 10 secs and > > 100 secs. > > > > These > correspond to 7, 8, 9 and 10 digits. > > > > I've been experimenting with using a > single mixer (mini circuits ZAD+) > > along with a 1MHz low pass filter and > appropriate attenuators to > > measure Alan Deviation (using my own > software). > > > > My set up is a 10MHz reference source (MV89A which I've > approximately > > set using a 10kHz GPS signal). > > > > The reference is used as > the external reference for an Agilent 33522A > > arbitrary waveform > generator. > > > > The 33522A generates an 9.999910 MHz (10MHz - 90Hz) sine wave > at > > 300mVpp to the mixer and the mixer is also fed by the 10MHz > > reference > output of the 33522A via an attenuator to get it to > > roughly the same > level. > > > > The second output of the 33522A generates a 10MHz square wave as > a > > reference for the counter (the counter requires quite a high reference > > > signal and the reference out of the 33522A is too low a voltage to be > > used > directly). > > > > I initially ran this with a gate of 1 second and the > LOG10(ADEV) curve > > drops linearly vs LOG10(tau) but then curves back up again. > (I tried > > many variants such as using period rather than frequency and so > on.) > > > > But when I set the gate time to 10 seconds or 100 seconds then I > get > > both lower curves and ones that no longer curve upwards. > > > > The > attached pdf shows the three curves on the same graph. > > > > What puzzles me is > that the counter at longer gates is only averaging > > to get more digits so the > difference must come down to quantization in > > terms of the number of digits > that are passed to the computer over the > > USB/RS232 link. > > > > I find it > rather puzzling. > > > > James > > > > > > > > > > > > > > > _________________________________________________ > > 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. _______________________________________________ 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.