Re: [time-nuts] Logging the grid frequency....
On Thu, Feb 28, 2013 at 6:08 AM, Daniel Mendes wrote: > > Thanks for all the comments about this topic. They are much appreciated. > > About the difficulty of measuring every cycle with a conventional counter... > thanks for that info, seems that i´ll have to make my own measurement > hardware. I liked the idea of a time stamping counter it´s very doable > in a FPGA :) FPGA?? All you need is a standard PC with an RS232 port and a 6V transformers and you can use the pC normally while it is logging. Works at the microsecond level. Software is already available. Chris Albertson Redondo Beach, California ___ 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.
Re: [time-nuts] Logging the grid frequency....
Ok, it´s a relative measurement... now I understand your data. Thank you. Daniel Em 28/02/2013 20:03, Tom Van Baak (lab) escreveu: Yes, correct, sometimes the power line goes faster than 60 Hz in which case the zero-crossings occur before you "expect them"; so time error can be negative, on average, as often as it is positive. You cannot design a PLL that always expects phase error to be unidirectional. The data I provided is time error relative to an ideal 60 Hz; this data can be both positive and negative; and both gaining and losing, as well as both accelerating and decelerating. Welcome to the interesting world of time & frequency, even at 60 Hz. /tvb (iPhone4) On Feb 28, 2013, at 10:42 AM, Daniel Mendes wrote: Em 28/02/2013 13:37, Tom Van Baak escreveu: Daniel, I've placed two log files for you under http://leapsecond.com/pages/mains/ log1932.dat.gz -- timing of every 60 Hz zero-crossing (1.296 million samples) log97312.dat.gz -- timing of every 60th zero-crossing (21.6 thousand samples) Each represents 6 hours of collection time. Units are seconds (elapsed time), resolution is 100 ns, granularity is 400 ns. This data was collected with a picPET (http://leapsecond.com/pic) using an accurate 10 MHz reference. This isn´t very clear to me. First few lines say: 0.000 -0.029 -0.071 -0.064 0.027 -0.099 -0.176 Time went backwards? Daniel ___ 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.
Re: [time-nuts] GPSDO with a RaspberryPi
Javier: the 24bit counter is clocked only by the 10MHz and is running continuously, the PPS is the most important signal. The LSClock is the clock for the latch: this latch has to be clocked to shift out its content serially and has to be loaded with the PPS from the GPS (PPSReference). I see no other way to deal with this other than selecting the two clock sources for this latch/shifter. When the chip select (CSelect) line is high, the PPS is selected as a clock, when the CSelect is low (SPI trying to read) the SClockIN is selected as a clock. I know it is not a good practice to use gated clocks but at times it seems there is no way out and the CPLD is only 64 cells wide... On Thu, Feb 28, 2013 at 5:34 PM, Javier Serrano < javier.serrano.par...@gmail.com> wrote: > On Thu, Feb 28, 2013 at 1:26 AM, Azelio Boriani > wrote: > > First try at a simple GPSDO for the RaspberryPi. See here: > > http://www.c-c-i.com/exchange/for the file PiAutoTIC1.zip > > Nice project Azelio! Here are a few comments after a cursory look at the > VHDL: > > - Gated clocks (i.e. LSClock) are in general not a good idea. You can > split things in two: the serial link clocked by SClockIN and the > getting hold of the value of the counter in a separate process clocked > by PPSReference (or for a better option, see below). > > - In any case you will have to deal with metastability properly [1]. > Now you're clocking the 24-bit output of the counter (which is in the > Clk10MHz clock domain) with the PPSReference signal (after gates). It > would be better to synchronize the PPSReference input to Clk10MHz with > three FFs and a synchronous edge detector (i.e. PPSRising <= PPSRefd2 > and not PPSRefd3 inside a CLK10MHz clocked process). Then you can look > at the value of the counter when that 1-tick-wide Clk10MHz-synchronous > signal (PPSRising) goes to '1'. > > - The CMDReg process is another place where metastability can occur in > the current design. > > - Once you have reduced the number of clocks in your design you will > need to watch carefully every place where clock domains are crossed > and put synchronizers [1] in there. > > Cheers, > > Javier > > [1] I uploaded some useful references to http://www.ohwr.org/documents/22 > ___ > 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.
Re: [time-nuts] Logging the grid frequency....
Yes, correct, sometimes the power line goes faster than 60 Hz in which case the zero-crossings occur before you "expect them"; so time error can be negative, on average, as often as it is positive. You cannot design a PLL that always expects phase error to be unidirectional. The data I provided is time error relative to an ideal 60 Hz; this data can be both positive and negative; and both gaining and losing, as well as both accelerating and decelerating. Welcome to the interesting world of time & frequency, even at 60 Hz. /tvb (iPhone4) On Feb 28, 2013, at 10:42 AM, Daniel Mendes wrote: > Em 28/02/2013 13:37, Tom Van Baak escreveu: >> Daniel, >> >> I've placed two log files for you under http://leapsecond.com/pages/mains/ >> >> log1932.dat.gz -- timing of every 60 Hz zero-crossing (1.296 million samples) >> log97312.dat.gz -- timing of every 60th zero-crossing (21.6 thousand samples) >> >> Each represents 6 hours of collection time. Units are seconds (elapsed >> time), resolution is 100 ns, granularity is 400 ns. This data was collected >> with a picPET (http://leapsecond.com/pic) using an accurate 10 MHz reference. > > This isn´t very clear to me. First few lines say: > > 0.000 > > -0.029 > > -0.071 > > -0.064 > > 0.027 > > -0.099 > > -0.176 > > > Time went backwards? > > > Daniel > > > > > > ___ > 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.
Re: [time-nuts] Logging the grid frequency....
Em 28/02/2013 13:37, Tom Van Baak escreveu: Daniel, I've placed two log files for you under http://leapsecond.com/pages/mains/ log1932.dat.gz -- timing of every 60 Hz zero-crossing (1.296 million samples) log97312.dat.gz -- timing of every 60th zero-crossing (21.6 thousand samples) Each represents 6 hours of collection time. Units are seconds (elapsed time), resolution is 100 ns, granularity is 400 ns. This data was collected with a picPET (http://leapsecond.com/pic) using an accurate 10 MHz reference. This isn´t very clear to me. First few lines say: 0.000 -0.029 -0.071 -0.064 0.027 -0.099 -0.176 Time went backwards? Daniel ___ 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.
Re: [time-nuts] Logging the grid frequency....
On 2/28/2013 11:37 AM, time-nuts-requ...@febo.com wrote: About the difficulty of measuring every cycle with a conventional counter... thanks for that info, seems that i?ll have to make my own measurement hardware. I liked the idea of a time stamping counter it?s very doable in a FPGA:) At work we have a similar issue, where we need to measure the frequency of every cycle of a pulse train running from a few Khz to 100Khz. We built a dedicated data acquisition system that will do just this. It will actually measure 8 independent frequency chains and ship the data via USB to a PC. This is referred to a 200Mhz clock (~5nS resolution). It took took a while to finish to the thing, but managed to pack it into an CPLD clocked at 200Mhz. It also has 6 CH of analog input +/- 10V at 14bit resolution at up to 125Khz sample rate, just for extra stuff one might want to add in... Something like this is probably overkill for your application, but is possible to pack it all into one chip. If you were doing one channel, it'd be pretty simple to do. Dan ___ 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.
Re: [time-nuts] Logging the grid frequency....
Daniel, I've placed two log files for you under http://leapsecond.com/pages/mains/ log1932.dat.gz -- timing of every 60 Hz zero-crossing (1.296 million samples) log97312.dat.gz -- timing of every 60th zero-crossing (21.6 thousand samples) Each represents 6 hours of collection time. Units are seconds (elapsed time), resolution is 100 ns, granularity is 400 ns. This data was collected with a picPET (http://leapsecond.com/pic) using an accurate 10 MHz reference. This should be more than enough data to characterize the typical short-term noise and mid-term wander of the (US western) power grid. Of course, the power spectrum in Brazil will likely look different. I'd be interested in seeing your results. Thanks, /tvb - Original Message - From: "Daniel Mendes" To: "Discussion of precise time and frequency measurement" Sent: Thursday, February 28, 2013 6:08 AM Subject: Re: [time-nuts] Logging the grid frequency Thanks for all the comments about this topic. They are much appreciated. About the difficulty of measuring every cycle with a conventional counter... thanks for that info, seems that i´ll have to make my own measurement hardware. I liked the idea of a time stamping counter it´s very doable in a FPGA :) About the fact that 60Hz mains have a lot of noise... I knew that and that´s part of a PLL job (filter very fast noise), but unfortunately when doing this measurement job we can only use analog filters or else we´ll mess too much with the frequency... i´m using a transformer (to isolate and to give some inductance) with capacitors to make a low pass filter. The PLL design is a wide band type. Seems that frequency stays between 59,95Hz and 60,05Hz for 99,99% of the time... that´s an interesting point too. Daniel Em 22/02/2013 23:09, Bob Camp escreveu: > Hi > > A lot depends on what the real objective is. Is the loop supposed to transfer > all of the 60 Hz bumps and wiggles (wide band loop) or is it supposed to > ignore them (narrow band loop) ? Given that the starting point is 60 Hz wide > and narrow will be relative to that. > > Bob > > On Feb 22, 2013, at 7:44 PM, David wrote: > >> On Fri, 22 Feb 2013 15:16:37 -0800, "Tom Van Baak" >> wrote: >> There is a lot of noise on the line. I'm not sure if frequency makes sense on a cycle to cycle basis. >>> Hal, it might make sense since the OP is designing a PLL and wants to get a >>> feel for (short-term) frequency excursions. I would guess the whole point >>> of his experiment is to quantify this; not just say there is "a lot" or >>> "not much" noise over some number N of cycles. >>> >>> So that's why I posted the ADEV plot, which itself was based on timing >>> every zero-crossing (using a time-stamping counter, not a frequency >>> counter). >> I have been thinking about this problem on and off all day and would >> probably add a sampling phase detector driven by the output of the PLL >> or just use a sampling phase detector in the PLL loop. The sampling >> time can be adjusted independently of the PLL filtering within reason >> for whatever level of noise rejection in the measurement is desired. >> >> That would return the phase error on every cycle or even every half >> cycle. >> >> The whole thing of course could be implemented digitally but I like >> programming in solder. ___ 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.
Re: [time-nuts] GPSDO with a RaspberryPi
On Thu, Feb 28, 2013 at 1:26 AM, Azelio Boriani wrote: > First try at a simple GPSDO for the RaspberryPi. See here: > http://www.c-c-i.com/exchange/for the file PiAutoTIC1.zip Nice project Azelio! Here are a few comments after a cursory look at the VHDL: - Gated clocks (i.e. LSClock) are in general not a good idea. You can split things in two: the serial link clocked by SClockIN and the getting hold of the value of the counter in a separate process clocked by PPSReference (or for a better option, see below). - In any case you will have to deal with metastability properly [1]. Now you're clocking the 24-bit output of the counter (which is in the Clk10MHz clock domain) with the PPSReference signal (after gates). It would be better to synchronize the PPSReference input to Clk10MHz with three FFs and a synchronous edge detector (i.e. PPSRising <= PPSRefd2 and not PPSRefd3 inside a CLK10MHz clocked process). Then you can look at the value of the counter when that 1-tick-wide Clk10MHz-synchronous signal (PPSRising) goes to '1'. - The CMDReg process is another place where metastability can occur in the current design. - Once you have reduced the number of clocks in your design you will need to watch carefully every place where clock domains are crossed and put synchronizers [1] in there. Cheers, Javier [1] I uploaded some useful references to http://www.ohwr.org/documents/22 ___ 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.
Re: [time-nuts] Logging the grid frequency....
Thanks for all the comments about this topic. They are much appreciated. About the difficulty of measuring every cycle with a conventional counter... thanks for that info, seems that i´ll have to make my own measurement hardware. I liked the idea of a time stamping counter it´s very doable in a FPGA :) About the fact that 60Hz mains have a lot of noise... I knew that and that´s part of a PLL job (filter very fast noise), but unfortunately when doing this measurement job we can only use analog filters or else we´ll mess too much with the frequency... i´m using a transformer (to isolate and to give some inductance) with capacitors to make a low pass filter. The PLL design is a wide band type. Seems that frequency stays between 59,95Hz and 60,05Hz for 99,99% of the time... that´s an interesting point too. Daniel Em 22/02/2013 23:09, Bob Camp escreveu: Hi A lot depends on what the real objective is. Is the loop supposed to transfer all of the 60 Hz bumps and wiggles (wide band loop) or is it supposed to ignore them (narrow band loop) ? Given that the starting point is 60 Hz wide and narrow will be relative to that. Bob On Feb 22, 2013, at 7:44 PM, David wrote: On Fri, 22 Feb 2013 15:16:37 -0800, "Tom Van Baak" wrote: There is a lot of noise on the line. I'm not sure if frequency makes sense on a cycle to cycle basis. Hal, it might make sense since the OP is designing a PLL and wants to get a feel for (short-term) frequency excursions. I would guess the whole point of his experiment is to quantify this; not just say there is "a lot" or "not much" noise over some number N of cycles. So that's why I posted the ADEV plot, which itself was based on timing every zero-crossing (using a time-stamping counter, not a frequency counter). I have been thinking about this problem on and off all day and would probably add a sampling phase detector driven by the output of the PLL or just use a sampling phase detector in the PLL loop. The sampling time can be adjusted independently of the PLL filtering within reason for whatever level of noise rejection in the measurement is desired. That would return the phase error on every cycle or even every half cycle. The whole thing of course could be implemented digitally but I like programming in solder. ___ 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.
Re: [time-nuts] GPSDO with a RaspberryPi
The 24bit counter counts up to 999 then is reset to 0 to get a PPS out of a 10MHz clock. The most significant bit is high from 0x80 to 0x98967F, so that you have a 161.1392ms wide high pulse when driving the PPS output with the MSB. On Thu, Feb 28, 2013 at 1:28 PM, Herbert Poetzl wrote: > On Thu, Feb 28, 2013 at 01:26:17AM +0100, Azelio Boriani wrote: > > First try at a simple GPSDO for the RaspberryPi. See here: > > http://www.c-c-i.com/exchange/ for the file PiAutoTIC1.zip > > Thanks to Bob Smither for his file exchange site. > > Pardon my ignorance, but where does the 161ms PPS length > come from? > > 2^24 = 16777216 so with 50/100ns clock intervals, we > should either see 83.88ms or 167.77ms (typo?) > > Otherwise, nice project, thanks for sharing and thanks > for releasing it as open-source (btw, you might want > to use some license, like GPLv2 for that). > > Nitpick: the SI symbol for second is 's' not 'S', i.e. > lowercase instead of upper, because 'S' stands for > siemens (which is the SI unit of electric conductance) > > thanks, > Herbert > > > This project is completely open-source, VHDL and C sources are > > available. Can be implemented also with any uP but the C source > > must be heavily modified. > > ___ > > 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.
Re: [time-nuts] GPSDO with a RaspberryPi
On Thu, Feb 28, 2013 at 01:26:17AM +0100, Azelio Boriani wrote: > First try at a simple GPSDO for the RaspberryPi. See here: > http://www.c-c-i.com/exchange/ for the file PiAutoTIC1.zip > Thanks to Bob Smither for his file exchange site. Pardon my ignorance, but where does the 161ms PPS length come from? 2^24 = 16777216 so with 50/100ns clock intervals, we should either see 83.88ms or 167.77ms (typo?) Otherwise, nice project, thanks for sharing and thanks for releasing it as open-source (btw, you might want to use some license, like GPLv2 for that). Nitpick: the SI symbol for second is 's' not 'S', i.e. lowercase instead of upper, because 'S' stands for siemens (which is the SI unit of electric conductance) thanks, Herbert > This project is completely open-source, VHDL and C sources are > available. Can be implemented also with any uP but the C source > must be heavily modified. > ___ > 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.
Re: [time-nuts] FE-5680A DDS Board/PIC Code
On Thu, Feb 28, 2013 at 03:49:55AM +0100, Magnus Danielson wrote: > On 02/18/2013 10:32 PM, Herbert Poetzl wrote: >> [ lot of stuff zapped ] > It would be interesting if fractional resolution of the DDS > would be developed using the PHASE interface. > As PHASE ripples, a carry needs to be sent into the phase > accumulator of the AD9830, or alternatively fiddling the > frequency value would help. While continuously adjusting the phase (via PHASEx) would probably work, I was more thinking about changing the FREQx values, which contribute to the phase accumulator. IMHO this should give a much better result than the abrupt phase changes and thus a smoother output with less unwanted noise. One approach might be to set FREQ0 to the last value below the desired frequency and FREQ1 to the first value above (i.e. FREQ0 + 1) and then toggle FSELECT in a pattern to match the fractional part. FSELECT has a pipeline delay of 6 MCLK, but that doesn't matter much if you do micro adjustments and FSELECT can be changed at any time without causing any discontinuity. And the best part: FSELECT is a small cable soldered onto the AD9830 which can easily be rerouted to the PIC. But I haven't found the spare time to dig into yet ... best, Herbert > Anyway, good work! > Cheers, > Magnus > ___ > 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] Thunderbolt firmware to E-level ?
Something I saw in John Miles recent post on the TB thread leads me to ask if a regular TB can be upgraded to TB-E level firmaware, and if so is sensible to do so? Thanks Dave ___ 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.
