Re: [time-nuts] ADEV noise floor vs counter gate time
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 To: time-nuts 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 > To: time-nuts > 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 converte
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 > To: time-nuts > 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. > &
Re: [time-nuts] ADEV noise floor vs counter gate time
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 To: time-nuts 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 mea
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 > To: jpbridge > CC: Discussion of precise time and frequency measurement > 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 s
Re: [time-nuts] ADEV noise floor vs counter gate time
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 To: jpbridge CC: Discussion of precise time and frequency measurement 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 c
Re: [time-nuts] ADEV noise floor vs counter gate time
> > 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 > To: jpbridge ; time-nuts > 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: > > ReadingInput Count TB Count Rounded Frequency Interval > 90.6359925074.998507590.6359 > 1.01500 > 90.7591925068.002506890.7591 > 1.01360 > 89.9640905002.000500289.9640 > 1.00040 > 89.8740905007.000500789.8740 > 1.00140 > 90.6007925076.997507790.6007 > 1.01540 > 89.6040905022.000502289.6040 > 1.00440 > 90.8648925061.999506290.8648 > 1.01240 > 90.8472925062.999506390.8472 > 1.01260 > 90.00011465925046.001504690.00011465 > 1.00920 > 90.00014459925028.998502990.00014459 > 1.00580 > > 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
Re: [time-nuts] ADEV noise floor vs counter gate time
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 To: jpbridge ; time-nuts 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: ReadingInput Count TB Count Rounded Frequency Interval 90.6359925074.998507590.63591.01500 90.7591925068.002506890.75911.01360 89.9640905002.000500289.96401.00040 89.8740905007.000500789.87401.00140 90.6007925076.997507790.60071.01540 89.6040905022.000502289.60401.00440 90.8648925061.999506290.86481.01240 90.8472925062.999506390.84721.01260 90.00011465925046.001504690.000114651.00920 90.00014459925028.998502990.000144591.00580 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 col umn 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. ever
Re: [time-nuts] ADEV noise floor vs counter gate time
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.6359e+0Hz 90.7591e+0Hz 89.9640e+0Hz 89.8740e+0Hz 90.6007e+0Hz 89.6040e+0Hz 90.8648e+0Hz 90.8472e+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.0130e-3s 11.0769e-3s 11.0435e-3s 11.0593e-3s 11.0022e-3s 11.4000e-3s 11.e-3s 11.0370e-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.07733 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 To: jpbridge ; Discussion of precise time and frequency measurement 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 l
Re: [time-nuts] ADEV noise floor vs counter gate time
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.6359e+0Hz 90.7591e+0Hz 89.9640e+0Hz 89.8740e+0Hz 90.6007e+0Hz 89.6040e+0Hz 90.8648e+0Hz 90.8472e+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.0130e-3s 11.0769e-3s 11.0435e-3s 11.0593e-3s 11.0022e-3s 11.4000e-3s 11.e-3s 11.0370e-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.07733 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 To: jpbridge ; Discussion of precise time and frequency measurement 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. 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.9820 Hz and the reported period should be 11.1133 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 poss
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. 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.9820 Hz and the reported period should be 11.1133 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 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.10 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 unsubsc
