From dimitri at dotp.com Wed Nov 4 03:22:17 2015 From: dimitri at dotp.com (Dimitri.p) Date: Wed, 04 Nov 2015 00:22:17 -0800 Subject: [GPS_Standard] Self Test experiment with strange result Message-ID: I took the 10 Mhz output from the board, run it through a divider chain (74HC390s) to end up with 1Hz and used that to feed the 1PPS input . Montrol reports Avg frequency offset -3.29e-10 Std Dev 1.46e-08 Min -3.12e-08 Max 2.50e-08 These values are in the same neighborhood of what I get using the 1PPS from the GPS. On frequency counters when you measure the counter's own timebase you end up with 10 and as many zeroes as can fit on the display. I was expecting values in the e-12 (or better) neighborhood. The idea that there is a frequency "offset" when the 1PPS is derived from the same 10MHz being measured doesn't make much sense at the moment. Can anyone shed any light on this ? Dimitri Dimitri From ve2zaz at sympatico.ca Wed Nov 4 10:28:35 2015 From: ve2zaz at sympatico.ca (Bert, VE2ZAZ) Date: Wed, 4 Nov 2015 15:28:35 +0000 Subject: [GPS_Standard] Self Test experiment with strange result In-Reply-To: References: Message-ID: Hi Dimitri. My first thoughts are that this might be caused be the way the built-in 16-bit counter works. It is plausible that the counter could mis-behave when everything is absolutely synchronous. This is a condition that should not occur in real life, and averaging will do the work to clean this up... You should try something else. Turn off the FLL. Do manual computing of the average offset and see whether it correlates with the described behavior. This will isolate it to the counter behavior. Cheers, Bert, VE2ZAZ > Date: Wed, 4 Nov 2015 00:22:17 -0800 > To: gps_standard at mailman.qth.net > From: dimitri at dotp.com > Subject: Re: [GPS_Standard] Self Test experiment with strange result > > I took the 10 Mhz output from the board, run it through a divider > chain (74HC390s) to end up with 1Hz and used that to feed the 1PPS input . > > Montrol reports > Avg frequency offset -3.29e-10 > Std Dev 1.46e-08 > Min -3.12e-08 > Max 2.50e-08 > > These values are in the same neighborhood of what I get using the > 1PPS from the GPS. > > On frequency counters when you measure the counter's own timebase you > end up with 10 and as many zeroes as can fit on the display. > > I was expecting values in the e-12 (or better) neighborhood. > > The idea that there is a frequency "offset" when the 1PPS is derived > from the same 10MHz being measured doesn't make much sense at the moment. > > Can anyone shed any light on this ? > > > Dimitri > > > Dimitri > > > > ______________________________________________________________ > GPS_Standard mailing list > Home: http://mailman.qth.net/mailman/listinfo/gps_standard > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:GPS_Standard at mailman.qth.net > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html From dimitri at dotp.com Wed Nov 4 14:45:06 2015 From: dimitri at dotp.com (Dimitri.p) Date: Wed, 04 Nov 2015 11:45:06 -0800 Subject: [GPS_Standard] Self Test experiment with strange result In-Reply-To: References: Message-ID: Calculating the Average offset manually sounds like a good idea. I was hoping to do that from the logged serial data, I started logging the serial data, and my eye cought the two lines i pasted below: D|U|0201E|.|.|6805|000C|0000|0CA8|00 D|U|0201E|.|.|6800|000D|0000|0CA9|00 The sample frequency is 6805 and 6800 but the respective Frequency difference reported is 0000 Now as far as average offsets go, I'm pretty sure I don't know which values to use to calculate the average offset. At 07:28 AM 11/4/2015, Bert, VE2ZAZ wrote: >Hi Dimitri. > >My first thoughts are that this might be caused be the way the >built-in 16-bit counter works. It is plausible that the counter >could mis-behave when everything is absolutely synchronous. This is >a condition that should not occur in real life, and averaging will >do the work to clean this up... > >You should try something else. Turn off the FLL. Do manual computing >of the average offset and see whether it correlates with the >described behavior. This will isolate it to the counter behavior. > >Cheers, > >Bert, VE2ZAZ > > > > Date: Wed, 4 Nov 2015 00:22:17 -0800 > > To: gps_standard at mailman.qth.net > > From: dimitri at dotp.com > > Subject: Re: [GPS_Standard] Self Test experiment with strange result > > > > I took the 10 Mhz output from the board, run it through a divider > > chain (74HC390s) to end up with 1Hz and used that to feed the 1PPS input . > > > > Montrol reports > > Avg frequency offset -3.29e-10 > > Std Dev 1.46e-08 > > Min -3.12e-08 > > Max 2.50e-08 > > > > These values are in the same neighborhood of what I get using the > > 1PPS from the GPS. > > > > On frequency counters when you measure the counter's own timebase you > > end up with 10 and as many zeroes as can fit on the display. > > > > I was expecting values in the e-12 (or better) neighborhood. > > > > The idea that there is a frequency "offset" when the 1PPS is derived > > from the same 10MHz being measured doesn't make much sense at the moment. > > > > Can anyone shed any light on this ? > > > > > > Dimitri > > > > > > Dimitri > > > > > > > > ______________________________________________________________ > > GPS_Standard mailing list > > Home: http://mailman.qth.net/mailman/listinfo/gps_standard > > Help: http://mailman.qth.net/mmfaq.htm > > Post: mailto:GPS_Standard at mailman.qth.net > > > > This list hosted by: http://www.qsl.net > > Please help support this email list: http://www.qsl.net/donate.html From ve2zaz at sympatico.ca Wed Nov 4 15:02:56 2015 From: ve2zaz at sympatico.ca (Bert, VE2ZAZ) Date: Wed, 4 Nov 2015 20:02:56 +0000 Subject: [GPS_Standard] Self Test experiment with strange result In-Reply-To: References: , , Message-ID: Dimitri, Use the raw count hexadecimal 68xx. This is the counter reading for each 16 second window. Cheers, Bert, VE2ZAZ > Date: Wed, 4 Nov 2015 11:45:06 -0800 > To: ve2zaz at sympatico.ca; gps_standard at mailman.qth.net > From: dimitri at dotp.com > Subject: RE: [GPS_Standard] Self Test experiment with strange result > > Calculating the Average offset manually sounds like a good idea. > I was hoping to do that from the logged serial data, > I started logging the serial data, and my eye cought the two lines i > pasted below: > > D|U|0201E|.|.|6805|000C|0000|0CA8|00 > D|U|0201E|.|.|6800|000D|0000|0CA9|00 > > The sample frequency is 6805 and 6800 > but the respective Frequency difference reported is 0000 > > Now as far as average offsets go, I'm pretty sure I don't know which > values to use to calculate the average offset. > > > > > > > > > > > > > At 07:28 AM 11/4/2015, Bert, VE2ZAZ wrote: > >Hi Dimitri. > > > >My first thoughts are that this might be caused be the way the > >built-in 16-bit counter works. It is plausible that the counter > >could mis-behave when everything is absolutely synchronous. This is > >a condition that should not occur in real life, and averaging will > >do the work to clean this up... > > > >You should try something else. Turn off the FLL. Do manual computing > >of the average offset and see whether it correlates with the > >described behavior. This will isolate it to the counter behavior. > > > >Cheers, > > > >Bert, VE2ZAZ > > > > > > > Date: Wed, 4 Nov 2015 00:22:17 -0800 > > > To: gps_standard at mailman.qth.net > > > From: dimitri at dotp.com > > > Subject: Re: [GPS_Standard] Self Test experiment with strange result > > > > > > I took the 10 Mhz output from the board, run it through a divider > > > chain (74HC390s) to end up with 1Hz and used that to feed the 1PPS input . > > > > > > Montrol reports > > > Avg frequency offset -3.29e-10 > > > Std Dev 1.46e-08 > > > Min -3.12e-08 > > > Max 2.50e-08 > > > > > > These values are in the same neighborhood of what I get using the > > > 1PPS from the GPS. > > > > > > On frequency counters when you measure the counter's own timebase you > > > end up with 10 and as many zeroes as can fit on the display. > > > > > > I was expecting values in the e-12 (or better) neighborhood. > > > > > > The idea that there is a frequency "offset" when the 1PPS is derived > > > from the same 10MHz being measured doesn't make much sense at the moment. > > > > > > Can anyone shed any light on this ? > > > > > > > > > Dimitri > > > > > > > > > Dimitri > > > > > > > > > > > > ______________________________________________________________ > > > GPS_Standard mailing list > > > Home: http://mailman.qth.net/mailman/listinfo/gps_standard > > > Help: http://mailman.qth.net/mmfaq.htm > > > Post: mailto:GPS_Standard at mailman.qth.net > > > > > > This list hosted by: http://www.qsl.net > > > Please help support this email list: http://www.qsl.net/donate.html > From dimitri at dotp.com Wed Nov 4 21:08:53 2015 From: dimitri at dotp.com (Dimitri.p) Date: Wed, 04 Nov 2015 18:08:53 -0800 Subject: [GPS_Standard] Self Test experiment with strange result In-Reply-To: References: Message-ID: <28.8B.15212.14ABA365@cdptpa-oedge03> In attempting to calculate the average frequency offset , i hit the wall described below: A) If 6800 is 26624 , which equals 10000000 exactly and the next value up 6801 translates to 26625 which equals 10000000.0625 (using the formula 10000000 + (X - 26624) / 16 to convert the sample frequency to MHz) that's only a 6.25e-2 step increase. I dont' understand how montrol is able to calculate a min,max and average using what appear to be such "coarse steps". B) There is stil more mystery regarding the two sample lines below D|U|0201E|.|.|6805|000C|0000|0CA8|00 D|U|0201E|.|.|6800|000D|0000|0CA9|00 The sample frequency is 6805 and 6800 but the respective Frequency difference reported is 0000 What part of the magic I am missing ? Dimitri At 12:02 PM 11/4/2015, Bert, VE2ZAZ wrote: >Dimitri, > >Use the raw count hexadecimal 68xx. This is the counter reading for >each 16 second window. > >Cheers, > >Bert, VE2ZAZ > > > Date: Wed, 4 Nov 2015 11:45:06 -0800 > > To: ve2zaz at sympatico.ca; gps_standard at mailman.qth.net > > From: dimitri at dotp.com > > Subject: RE: [GPS_Standard] Self Test experiment with strange result > > > > Calculating the Average offset manually sounds like a good idea. > > I was hoping to do that from the logged serial data, > > I started logging the serial data, and my eye cought the two lines i > > pasted below: > > > > D|U|0201E|.|.|6805|000C|0000|0CA8|00 > > D|U|0201E|.|.|6800|000D|0000|0CA9|00 > > > > The sample frequency is 6805 and 6800 > > but the respective Frequency difference reported is 0000 > > > > Now as far as average offsets go, I'm pretty sure I don't know which > > values to use to calculate the average offset. > > > > > > > > > > > > > > > > > > > > > > > > > > At 07:28 AM 11/4/2015, Bert, VE2ZAZ wrote: > > >Hi Dimitri. > > > > > >My first thoughts are that this might be caused be the way the > > >built-in 16-bit counter works. It is plausible that the counter > > >could mis-behave when everything is absolutely synchronous. This is > > >a condition that should not occur in real life, and averaging will > > >do the work to clean this up... > > > > > >You should try something else. Turn off the FLL. Do manual computing > > >of the average offset and see whether it correlates with the > > >described behavior. This will isolate it to the counter behavior. > > > > > >Cheers, > > > > > >Bert, VE2ZAZ > > > > > > > > > > Date: Wed, 4 Nov 2015 00:22:17 -0800 > > > > To: gps_standard at mailman.qth.net > > > > From: dimitri at dotp.com > > > > Subject: Re: [GPS_Standard] Self Test experiment with strange result > > > > > > > > I took the 10 Mhz output from the board, run it through a divider > > > > chain (74HC390s) to end up with 1Hz and used that to feed the > 1PPS input . > > > > > > > > Montrol reports > > > > Avg frequency offset -3.29e-10 > > > > Std Dev 1.46e-08 > > > > Min -3.12e-08 > > > > Max 2.50e-08 > > > > > > > > These values are in the same neighborhood of what I get using the > > > > 1PPS from the GPS. > > > > > > > > On frequency counters when you measure the counter's own timebase you > > > > end up with 10 and as many zeroes as can fit on the display. > > > > > > > > I was expecting values in the e-12 (or better) neighborhood. > > > > > > > > The idea that there is a frequency "offset" when the 1PPS is derived > > > > from the same 10MHz being measured doesn't make much sense at > the moment. > > > > > > > > Can anyone shed any light on this ? > > > > > > > > > > > > Dimitri > > > > > > > > > > > > Dimitri > > > > > > > > > > > > > > > > ______________________________________________________________ > > > > GPS_Standard mailing list > > > > Home: http://mailman.qth.net/mailman/listinfo/gps_standard > > > > Help: http://mailman.qth.net/mmfaq.htm > > > > Post: mailto:GPS_Standard at mailman.qth.net > > > > > > > > This list hosted by: http://www.qsl.net > > > > Please help support this email list: http://www.qsl.net/donate.html > > From pete.zl2ik at gmail.com Thu Nov 5 00:21:39 2015 From: pete.zl2ik at gmail.com (Peter Mulhare) Date: Thu, 5 Nov 2015 18:21:39 +1300 Subject: [GPS_Standard] Self Test experiment with strange result In-Reply-To: <28.8B.15212.14ABA365@cdptpa-oedge03> References: <28.8B.15212.14ABA365@cdptpa-oedge03> Message-ID: <563ae768.6807430a.e0226.ffffd104@mx.google.com> Hi Dimitri Here is the Math: Counter counts for 16 seconds = 160 000 000 = 160 x 106 this equates Hex $xxxx6800 Counter counts for 16 seconds = 160 000 001 = 160.000001 x 106 this equates Hex $xxxx6801 Now Consider error in parts per million as +1 = 0.00000000625 = 6.25 x 10-9 = 6.25 parts in 109 = 6.25e-9 160 x 106 This is quite different to what you have worked out......not so course after all! Peter Mulhare ZL2iK From dimitri at dotp.com Thu Nov 5 14:47:49 2015 From: dimitri at dotp.com (Dimitri.p) Date: Thu, 05 Nov 2015 11:47:49 -0800 Subject: [GPS_Standard] Self Test experiment with strange result Message-ID: Thanks for the reply. Although it justifies the existence of "0x6800" , if we take 160000001 and divide it by 16 it results in 10000000.0625 Mhz. Now unless I am still missing something any change less that .0625 cannot be "seen" by the FLL. So my realization is in a "best" case scenario when the FLL displays 6800 the actual oscillator frequency is somewhere either exactly 10000000.00000000 or between plus or minus 0.06249 MHz And, correct me if I'm wrong, if indeed the Min Max display in Montrol is the ppm error the way you described, it will never be able to measure anything better than plus or minus 6.25e-9 Dimitri From w0ep at w0ep.us Thu Nov 5 16:33:57 2015 From: w0ep at w0ep.us (w0ep at w0ep.us) Date: Thu, 5 Nov 2015 15:33:57 -0600 Subject: [GPS_Standard] Self Test experiment with strange result In-Reply-To: References: Message-ID: Isn't that why one would integrate over multiple cycles? Sent from my android device. -----Original Message----- From: "Dimitri.p" To: gps_standard at mailman.qth.net Sent: Thu, 05 Nov 2015 1:47 PM Subject: Re: [GPS_Standard] Self Test experiment with strange result Thanks for the reply. Although it justifies the existence of "0x6800" , if we take 160000001 and divide it by 16 it results in 10000000.0625 Mhz. Now unless I am still missing something any change less that .0625 cannot be "seen" by the FLL. So my realization is in a "best" case scenario when the FLL displays 6800 the actual oscillator frequency is somewhere either exactly 10000000.00000000 or between plus or minus 0.06249 MHz And, correct me if I'm wrong, if indeed the Min Max display in Montrol is the ppm error the way you described, it will never be able to measure anything better than plus or minus 6.25e-9 Dimitri ______________________________________________________________ GPS_Standard mailing list Home: http://mailman.qth.net/mailman/listinfo/gps_standard Help: http://mailman.qth.net/mmfaq.htm Post: mailto:GPS_Standard at mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html From dimitri at dotp.com Fri Nov 6 16:47:13 2015 From: dimitri at dotp.com (Dimitri.p) Date: Fri, 06 Nov 2015 13:47:13 -0800 Subject: [GPS_Standard] Self Test experiment with strange result In-Reply-To: <563bc4c8.e15a420a.a08a5.6ddb@mx.google.com> References: <563bc4c8.e15a420a.a08a5.6ddb@mx.google.com> Message-ID: Now that I seem to have "Average Frequency Offset" seperated from "Average frequency offset ERROR" in my head I'll stop banging it against the wall :) Thanks ! Dimitri At 01:06 PM 11/5/2015, Peter Mulhare wrote: >Hi Dimitri > >What Montrol is giving you are Average Frequency >Offset, Standard Deviation, and Minimum Offset >and Maximum Offset. These are done in the >Current Cycle, the Previous Cycle, and the Accumulated Totals. > >If you reset Montrol completely ie quit the >program when the GPSDO is running and is stable >and locked, then reboot Montrol, and watch the >Average offset in the yellow Column for a while. > >Immediately Montrol starts there are no averages >and the Current Cycle Offset you will see are >the actual offset figures, the Accumulated value >will also exactly follow for a while but begin >to change less as the number of totals build up >over time. Once there are a reasonable amount >of completed cycles you will start to see the >average offset develop of all the cycles from Montrol switch on. > >You will notice that over a much longer time >that the figures in the Blue Column (Accumulated >Totals) will get closer and closer to the >Statistical Offset of the GPSDO. Because the >GPSDO is a Frequency Locked Loop, not a Phase >Locked Loop, the actual GPSDO frequency will >change slightly over time, this is because of >jitter in the 1pps from the GPS, due to various >factors, and also the tendency for the crystal >to wander slightly in Frequency, all these >errors accumulate over time and Montrol is >showing you, what the statistical error of the >GPSDO is (from a Statistical Bell Curve) at any >given time. It is not giving you at any time the Actual Frequency! > >Montrol is showing you 3 slightly different ways >to express the Statistical version of all the >offsets to date since Montrol was switched on. > >This is a simplistic explanation but I think >that it will explain it correctly for you. > >With regard to your last post that is correct it >is not able to read any better than 6.25 x >10-9. But remember that is the max offset above >& min offset below, which I would expect to be >greater than that. Mine is typical around 3.12 >x 10-8. It is not an average. And remember >that 6.25 x 10-9 is 6.25 parts in 1GHz! > >With regard to noise on the EFC line, I took the >precaution of using shielded audio cable and >only earthed the shield at the electronics end >and not at the Oscillator end. I also shielded >the 1pps line from the GPS, and earthed that at >the GPS end only. I?m using a 12Volt CIC >ST2145A double oven Oscillator, and an Adafruit >GPS on a small breakout board. The GPS has a >rated jitter of ??+10 nS rms. My system is >working as I would expect it to. I have >replaced the oscillator 3 times, twice with >Isotemp OCXO131-100, one of which went faulty, >and finally with the double oven CIC >ST2145A. To be honest there has not been much >difference statistically between all 3 >OCXO?s. I built the unit nearly 4 years ago. > >Pete Mulhare >ZL2iK > > > >-----Original Message----- >From: GPS_Standard >[mailto:gps_standard-bounces at mailman.qth.net] On Behalf Of Dimitri.p >Sent: Friday, November 6, 2015 08:48 >To: gps_standard at mailman.qth.net >Subject: Re: [GPS_Standard] Self Test experiment with strange result > >Thanks for the reply. >Although it justifies the existence of "0x6800" , if we take >160000001 and divide it by 16 it results >in 10000000.0625 Mhz. Now unless I am still >missing something any change less that .0625 cannot be "seen" by the FLL. >So my realization is in a "best" case scenario when the FLL displays >6800 the actual oscillator frequency is >somewhere either exactly 10000000.00000000 >or between plus or minus 0.06249 MHz > >And, correct me if I'm wrong, if indeed the >Min Max display in Montrol is the ppm error the >way you described, it will never be able to >measure anything better than plus or minus 6.25e-9 > > >Dimitri > From dimitri at dotp.com Sun Nov 8 02:41:51 2015 From: dimitri at dotp.com (Dimitri.p) Date: Sat, 07 Nov 2015 23:41:51 -0800 Subject: [GPS_Standard] Montrol Clear Current Stats button bug or feature ? Message-ID: Short version of the question is : Is clearing the current stats (yellow section) supposed to have the same effect as restarting Montrol fresh? Longer version: When clearing current stats for the Current Cycle, the Avg Frequency offset for the Current Cycle, seems to continue averaging from previous accumulated data as if the current stats were not cleared. For example if the average in the current cycle has deteriorated to -4.5e-04, even after hitting the Clear Current Stats button, the Avg frequency offset for the Current Cycle stays in the e-04 range. Quitting out of montrol and starting it up again, shows an Avg frequency offset for the Current Cycle in the e-08 / e-09 range. Montrol is version 4, April 2009 Dimitri From dimitri at dotp.com Sun Nov 8 15:09:20 2015 From: dimitri at dotp.com (Dimitri.p) Date: Sun, 08 Nov 2015 12:09:20 -0800 Subject: [GPS_Standard] Montrol Clear Current Stats button bug or feature ? In-Reply-To: <563fa864.89c4440a.1c16f.ffffbb3a@mx.google.com> References: <563f118a.a266440a.49dd5.722f@mx.google.com> <563fa864.89c4440a.1c16f.ffffbb3a@mx.google.com> Message-ID: <15.72.31082.0EBAF365@cdptpa-oedge01> I disabled the FLL following Bert's suggestion from another thread "You should try something else. Turn off the FLL. Do manual computing of the average offset and see whether it correlates with the described behavior. This will isolate it to the counter behavior." Which is what I did. The manual calculation is different from what Montrol displays (the 7 sample example) So here we are. Sometimes rabbit holes are connected! Dimitri At 11:54 AM 11/8/2015, you wrote: >Dimitri > >The problem is the FLL is UNLOCKED! The >readings from Montrol are meaningless >until the Frequency Locked loop is >Locked up. You must wait until that >happens. In fact you have it "disabled" >in the Parameters (Grey) Panel. >Attached is a screenshot of mine..... > >Pete >ZL2iK > > >-----Original Message----- >From: Dimitri.p >[mailto:dimitri at dotp.com] >Sent: Monday, November 9, 2015 02:59 >To: gps_standard at mailman.qth.net >Cc: Peter Mulhare >Subject: RE: [GPS_Standard] Montrol >Clear Current Stats button bug or >feature ? > >All I am talking about is the Current >stats- the yellow section and whether or >not it "resets" when hitting the "Clear >Current Stats" >button. It appears that it doesn't, >unless Montrol is restarted. > >Here is a screenshot of the incorrect >calculation on 7 samples > >Looking at 7 samples in the e-08 and >e-09 range, an average in the >e-04 looks wrong without even working >the numbers :) > > >and here is the manual version with the >worked numbers: >9999999.87500000000000000 >-1.25000000000000E-8 >9999999.62500000000000000 >-3.75000000000000E-8 >10000000.31250000000000000 >3.12500000000001E-8 >10000000.06250000000000000 >6.25000000000001E-9 >9999999.81250000000000000 >-1.87500000000000E-8 >9999999.87500000000000000 >-1.25000000000000E-8 >10000000.12500000000000000 >1.25000000000000E-8 >Number of Samples: 7 >Avg Freq Offset: -4.46428563445807E-9 >Min: -3.75000000000000E-8 >Max: 3.12500000000001E-8 > > >Dimitri > > >At 01:10 AM 11/8/2015, you wrote: > >Dimitri > > > >I just tried it on my Montrol to > >recheck, and No it does not clear All > >Stats (as a restart would) but the > >current cycle only, as I have always > >understood.. Mine was sitting on > >1.83e-10, and after clearing it came > >back 1.87e-08, however in the 16 cycles > >since I cleared it, now it shows > >3.29-10. On one of the earlier cycles > >it actually said 0 offset, I have only > >ever seen that a few times. > > > >To reset, sort of like a restart, you > >can clear the Accumulated Stats, but > >that does not clear the previous cycle > >or the Current cycle, but you would >lose > >all the historical data/Stats. It >would > >also clear the Number of Samples > >counter, but in MONTROL ONLY. The >GPSDO > >starts a fresh Sample Count ever time >it > >starts another Sample series. The > >actual total number comes from the (S) > >parameter in the Grey Parameter Panel. > > > >Neither Clear buttons have an effect on > >the state of what is going on in the > >GPSDO itself, the setup in the grey > >Parameter panel of Montrol controls how > >the GPSDO works. > > > >Pete > >ZL2iK > From mail at davekemplen.co.uk Fri Nov 6 06:00:12 2015 From: mail at davekemplen.co.uk (Dave Kemplen) Date: Fri, 06 Nov 2015 11:00:12 -0000 Subject: [GPS_Standard] Frequency Standard What do you want from it Message-ID: Hi All I have been following this with interest, The measurement of frequency is difficult and needs to be defined as what is wanted and is not necessarily just looking at a brief period of time. I found the attached PDF when I was building Bert's standard to get my head round the "what was I trying to achieve moment" It proved very useful, and helped me to to fully understand why we do what we do to measure frequency. This is the pdf Frequency Measurement etc.unitbv.ro/~olteanu/.../*Frequency*%20*Measurement*.pdf I hope it helps daveK From dimitri at dotp.com Sun Nov 8 08:58:47 2015 From: dimitri at dotp.com (Dimitri.p) Date: Sun, 08 Nov 2015 13:58:47 -0000 Subject: [GPS_Standard] Montrol Clear Current Stats button bug or feature ? In-Reply-To: <563f118a.a266440a.49dd5.722f@mx.google.com> References: <563f118a.a266440a.49dd5.722f@mx.google.com> Message-ID: All I am talking about is the Current stats- the yellow section and whether or not it "resets" when hitting the "Clear Current Stats" button. It appears that it doesn't, unless Montrol is restarted. Here is a screenshot of the incorrect calculation on 7 samples Looking at 7 samples in the e-08 and e-09 range, an average in the e-04 looks wrong without even working the numbers :) and here is the manual version with the worked numbers: 9999999.87500000000000000 -1.25000000000000E-8 9999999.62500000000000000 -3.75000000000000E-8 10000000.31250000000000000 3.12500000000001E-8 10000000.06250000000000000 6.25000000000001E-9 9999999.81250000000000000 -1.87500000000000E-8 9999999.87500000000000000 -1.25000000000000E-8 10000000.12500000000000000 1.25000000000000E-8 Number of Samples: 7 Avg Freq Offset: -4.46428563445807E-9 Min: -3.75000000000000E-8 Max: 3.12500000000001E-8 Dimitri At 01:10 AM 11/8/2015, you wrote: >Dimitri > >I just tried it on my Montrol to >recheck, and No it does not clear All >Stats (as a restart would) but the >current cycle only, as I have always >understood.. Mine was sitting on >1.83e-10, and after clearing it came >back 1.87e-08, however in the 16 cycles >since I cleared it, now it shows >3.29-10. On one of the earlier cycles >it actually said 0 offset, I have only >ever seen that a few times. > >To reset, sort of like a restart, you >can clear the Accumulated Stats, but >that does not clear the previous cycle >or the Current cycle, but you would lose >all the historical data/Stats. It would >also clear the Number of Samples >counter, but in MONTROL ONLY. The GPSDO >starts a fresh Sample Count ever time it >starts another Sample series. The >actual total number comes from the (S) >parameter in the Grey Parameter Panel. > >Neither Clear buttons have an effect on >the state of what is going on in the >GPSDO itself, the setup in the grey >Parameter panel of Montrol controls how >the GPSDO works. > >Pete >ZL2iK