Re: [time-nuts] Good references on holdover?
Hi Javier, As far as I understand in WR both references are synchronous. Why don't you try to track both references (or N references) simultanously? If you take care of the design, your performance should increase while locked and the transition from one reference to the other if you ever miss one should be smoother. Cheers, Pablo On Fri, Feb 6, 2015 at 10:21 AM, Javier Serrano javier.serrano.par...@gmail.com wrote: Dear all, We would like to start working on holdover performance for White Rabbit [1]. This is a new domain for us. Our main use case is a WR switch losing its reference because someone disconnects a fiber. We can have redundancy, but it will take some time for a switch to change over to another reference. During this time, the oscillator in that switch will be free-running. We want to minimize the phase drift during that interval, which we think should be a couple of seconds maximum. We have never worked on holdover, and I am wondering if we can do something smarter than the obvious feeding of some constant voltage to the VCXO, based on averaging during the locked state. Does anybody know of any good references on holdover? Thanks! Javier [1] http://www.ohwr.org/projects/white-rabbit/wiki ___ 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] Phase, One edge or two? (was Digital mixing with a D Flip Flop)
Hi Warren, I arrive a bit late to this discussion, but I hope I can help. I guess the reason for using only one edge is based on the fact that WR is originally designed to measure the phase between a decoded data clock and a system clock. The problem is that this decoded data clock is locked to the incoming data by means of a PFD in the Spartan6/Virtex6 GTP. The PFD normaly only looks at rising edges, so any change in the clock duty cycle will translate in a phase change in the falling edge and not in the rising edge. I am not sure this is really the case, but we certainly had this discussion at the time, but I don't remember if there was any real measurement made. Cheers, Pablo ___ 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] Phase, One edge or two? (was Digital mixing with a D Flip Flop)
...The problem is that this decoded data clock is locked to the incoming data by means of a PFD in the Spartan6/Virtex6 GTP. The PFD normaly only looks at rising edges, so any change in the clock duty cycle will translate in a phase change in the falling edge and not in the rising edge. I am not sure this is really the case, but we certainly had this discussion at the time, but I don't remember if there was any real measurement made. Well, I don't like correcting myself but this is not right. The PFD is only used in the TX path. In the RX path the clock is decoded using CDR using a VCO which operates at the 1.25Gb/s and then is divided down to 125, so the duty cycle problem is not really a big issue here. In any case it is the typical bug one tries to avoid when doing precise timing. Notice that in this case it would not have been a good idea to sample with the system clock falling edge to increase the performance. pablo ___ 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] Digital Mixing with a BeagleBone Black and D Flip Flop
The current implementation used in WR was developed by Tomasz Wlostowski in the frame of his MSc thesis, following the ideas of Pablo Alvarez which Bruce pointed to earlier. As you can see in Tomasz's dissertation [1], there was not a lot of investigation on optimal strategies for DDTMD noise. The precision at the time was deemed more than adequate. It is very timely that you bring up this subject now, because I hope to start looking at ways to optimize phase noise in WR in the coming months, and noise coming from the DDMTD phase detector is definitely something I want to look at. I will be very interested in your ideas and findings regarding optimal strategies for the de-glitcher. Hi Simon and Javier, I arrive late to this discussion but I would like to add my grain of salt. As Javier says there was not a detailed optimization of the DDMTD architecture as jitter was already limited by all the surrounding electronics. I would like to add that much of the noise rejection is due to the implementation of a median estimator for the incoming edge position respect to the slightly-offset oscillator. It is easy and fun to proof that this median estimator can be implemented with a counter counting the number of sampled zeros and a simple state machine state machine that places counter start in a safe zone. In fact, when you think it out, the most curious thing is that this algorithm is nothing more than a sort of generalization of the bang-bang architecture to measure phase offsets. Cheers, Pablo ___ 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] Low-long-term-drift clock for board levelintegration?
I would not fully trust NTP, and as already explained taking your GPS outside as a reference for just a while is not really going to help. But..why not using GPS inside the building? Some receivers are quite sensitive, so probably you will not need an external antenna to pick up a signal. Probably you may have to throw a cable from floor to floor, or place your antenna close to a window, but this is much simpler than installing an antenna on a roof. You will not get ns accuracy, but to make worse than 100us you will need a hell of a lot of reflections inside your building. Cheers, pablo ___ 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] Fast than light neutrino
Hi guys, I have uploaded a new version of the CTRI-Scope measurement. There was a typo on a number and several descriptions that has probably excited more than one person and that has triggered my stress to levels I did not know until now. Having said that, have a look at it again if you are interested. There have been many people looking at the result of the measurements. The idea behind this is informing how the measurement has been done, rather than having you discovering a bug. In any case, CERN measurements, hardware schematics and sources are open to any curious mind. We have created a separated list where we will continue posting news on the project. http://lists.ohwr.org/sympa/info/cngs-time-transfer Please, feel free to join it and send any questions, remarks and complains on this project. Best regards, pablo ___ 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] Fast than light neutrino
Well it seems there are some time-nuts looking. Here you have it, for the moment. *BCT, Beam Current Transformer *CCR, Cern's Control Room. *cfc-ccr-ctpps, The front end (a PC running SC5 linux) where we have installed the CTRI that logs the PPS comming from the PolarRx2e *cfc-hca4-saos12. The front end where we do the BCT logging, it has a CTRI and a DC110. *CS4000, A cesium clock by symmetricom *CTRI, control timing receiver, PCI format *CTSYN, Takes the 10MHz and PPS from the XLi and regenerates a 40MHz and a PPS *DC110, Acquiris Scope *HCA442, It is the hall where we have the CTRI tagging and the extraction kicker pulse and the DC110 logging the BCT signal. *PolarRx2e, A septentrio timing gps receiver *SPS, Super Proton Synchroton *XLi, A symmetricom gps receiver pablo ___ 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] Fast than light neutrino
We are adding more info to the wiki project. Please go directly to http://www.ohwr.org/projects/cngs-time-transfer/wiki/Wiki Cheers, pablo ___ 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] An (unknown?) nasty feature of the DDS principle for time nuts applications
Hi, The AD9850 has a 10bit DAC. If the AD9850 does not dither the 10bit ADC output the zero crossings for a 1MHz signal will have an aprox resolution of 2^-10*1us~1ns on average. If the lookup table feeding values to the dac has 10 address lines (just guessing, I do not see any anything on it on the datasheet), you will have an additional uncertainty of 1ns to the phase error. Adding these two we have the ~2ns Ulrich is measuring. What do you think? Pablo ___ 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] An (unknown?) nasty feature of the DDS principle for time nuts applications
I will answer to myself, as my previous email was unclear and buggy. Actually I was just doing some order of magnitude calculations which seem quite correct, but it is always better to dig bit more in the details. The whole idea is to find the waveform paths that will generate a zero crossing the most distant from the desired zero crossing. Spectral analysis is quite powerful for understanding the DDS general performance, but I believe that following the waveform path at every time instant gives an insight into the DDS behavior that is very hard to grasp with any other means. Going to the matter. As the 1MHz is slowly drifting the waveform will be stable for some time and not cleaned by a low pass filter. Now take the instant when the DAC is about to ouput zero but it is still generating one LSB. The error here will be 0.5LSBs In the zero crossing the sinewave slope is: delta(V)=2pi/T*delta(t) (T=1microsecond) For a 10bit dac we will have that 0.5LSB represent an error of: 2^-10=2pi/T*delta(t) -- delta(t)=2^-11/pi*T=0.15ns The AD9850 uses 14 bits to calculate the cosine function. In any case the 14bits truncation can provoke an aditional 1 bit error on the DAC output. This would mean an error on the zero crossing of 0.45ns. Peak to peak would be 0.9ns, which is smaller than 2ns pk-pk actually observed by Ulrich. So the order of magnitude is somehow correct, but there is still something (most likely a lot) missing in this analysis. Any ideas? Best regards pablo On Fri, Jan 28, 2011 at 2:47 PM, pablo alvarez pabloalvarezsanc...@gmail.com wrote: Hi, The AD9850 has a 10bit DAC. If the AD9850 does not dither the 10bit ADC output the zero crossings for a 1MHz signal will have an aprox resolution of 2^-10*1us~1ns on average. If the lookup table feeding values to the dac has 10 address lines (just guessing, I do not see any anything on it on the datasheet), you will have an additional uncertainty of 1ns to the phase error. Adding these two we have the ~2ns Ulrich is measuring. What do you think? Pablo ___ 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] DMTD mixer question
Hi, I have been looking at several Dual Mixer Time Difference designs. As far as I know the basic architecture is based on generating a tone with an small frequency offset respect to the nominal clocks frequency, analogue mixing of the clocks, low pass filtering, then a slow zero crossing detector and finally a time interval counter or time stamp unit. I have this naïf question: would not it be better and simpler to use directly an ECL D flip-flop as a mixer instead of an analogue one? I suppose analogue mixers are preferred because they provide with a better differential tempco, but using ECL logic can provide also with a good tempco. What is your experience? Cheers Pablo ___ 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] DMTD mixer question
thanks for the positive feedback, In xilinx fpgas, for example, the recovery time after a metastability issue is quite fast as reported in this paper http://www.xilinx.com/support/documentation/application_notes/xapp094.pdf The capture window of metastable state is 0.01fm (page 2). Probably this window is moving around a bit, but this 0.01fm sounds promising. In page 3 When granted 2 ns of extra settling delay, the problems caused by metastability are almost eliminated, as their MTBF exceeds millions of years. So we can just solve the glitch problem by adding a shift register as Bruce suggested. I think the major concern may be crosstalk, but using lvds or ecl logic and placing the IOs far away one from each other may help to reduce it a bit. Now a DMTD architecture can be almost completely based on a FPGA where some LVDS IOs would contain the D flip-flop mixers, with their clock input connected to the reference frequency and the D input to the clocks under test. The FPGA would contain a 32 bit free running counter clocked by the reference clock. Every time I detect a transition on my LVDS IOs the free running counter is latched and passed to a FIFO. Then the work can be passed to a data analysis program (of course through an LVDS serial link) to do all sort of funny calculations. I wonder how good this system could eventually be if we reduce crosstalk to a minimum. Pablo On Wed, Dec 3, 2008 at 9:01 PM, Bruce Griffiths [EMAIL PROTECTED] wrote: Lux, James P wrote: Cheers Pablo Pablo Flipflop mixers tend to produce glitches at the beat frequency transitions. A digital PFD in a PLL doesnt produce a beat frequency output when locked so such glitches arent a problem, I don't know that this is the case with modern PLL PFDs.. If only because glitches at the transitions would cause other problems, so there's an incentive to get rid of them. Jim Surely metastability may occur when the mixer flipflop D input transitions occur close to its active clock transitions? There is at least one patent (US5053651) that claims to eliminate such glitches in a digital mixer, however its output beat frequency is half the difference between the input frequencies. Bruce ___ 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] Fine delay generator
Thanks Tim and Bruce for your info! It is precious. By the way you will have all the schematics and sources will be on the web. I will keep you informed. 1) The HP5359A (and the 5370A/B) used a phase locked startable oscillator. The classic gated oscillator uses a delay line to determine the oscillator frequency. These are commercially available or you can build your own using an inverting gate and a length of coax or other delay line for higher performance. Perhaps the MC100EP196B could be useful an oscillator here. I could set a total delay of 10ns and try use the analog control input to tune the period. The phase could be measured with an extra TIM. 2) The ACAM TDC-GPX has linearity errors much larger than 10ps for short time intervals ( 120ns). However if the time interval can be guaranteed to exceed some minimum (120ns) an integral non linearity of around 10ps is possible. For longer time intervals the measurement jitter will be significant at the 10ps level. The ACAM TDC-GPX has an internal delay locked loop option that allows the internal delay step size to be locked to an external reference frequency. Another delay technique is to use a tapped chain of gates in an FPGA can be used to implement a fine delay. A DLL can be used to stabilise the delays. I have thought many times of implementing such a tapped delay line but always left it for another moment. It is just a bit anoying that ones has to fix the placement of the taps. On the other hand one could just let the router place your design and use later statistical code coverage to calibrate the design at startup. It may be interesting replicating the tapped delay lines. The resulting scale would be the intersection of the original codes. Another option is to use a pair of ADCs to simultaneously sample a quadrature pair of 10MHz sinewaves. Together with a dual phase synchroniser to sample a counter clocked at 10MHz, a resolution on the order of 10ps or so is possible with a range limited by the counter length. An LTC1407A-1 dual simultaneous sampling ADC allows sample rates up to 1.5MHz with adequate linearity if driven differentially. However an inverse tangent calculation is required for each measurement - this could easily be done in an FPGA within a few tens of nanosec. I have seen the paper you are refering to in your site. This method is not as easy as it seems at the end. You need to generate a perfect 200MHz sine and cosine. You need to monitor its amplitude and to obtain the maximum performance you need to have a good picture of the nonlinarities of both sine and cosine. Finally the LTC1407A-1 latency is similar to that of the AD9626. To avoid using a fine delay with a large range using a higher frequency (eg 40MHz or higher) local clock phase locked to 10MHz will reduce the required fine delay range significantly. Certainly, I will try use a clock as fast as possible. Surely it would be better to sampled the low pass filtered latched trigger transition with a pipeline ADC clocked at 100MHz or more. The threshold crossing time of the ADC input can then be calculated from the ADC samples (using WSK interpolation etc) provided there are sufficient samples taken during the transition. Thanks for suggesting the AD9446 and the WSK interpolation. I had thought of keeping a normalized waveform of the pulse rising edge stored in a RAM. By normalized I mean doing the starting points equal to -.5 and the final points equal to 0.5. I can try to autogenerate this waveform using a fine delay line and later use statistical code coverage to do a fine calibration. By the way I do not understand very well how do you use WSK interpolation. Normally you use it to find the amplitude level between two samples, but here we are trying to solve the inverse problem. We need to know at which moment the signal passed over a given threshold. How do you solve it? Pablo ___ 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] Fine delay generator
Dear nuts, I am designing a card that should be able to delay a trigger from 25ns up to several seconds in 10ps steps. The card will use an external 10MHz as frequency reference. I have thought of two architectures. One is a counter clocked by a keyed oscillator followed by a fine delay and the other is based on a Time interval meter (TIM), a counter clocked by a TCXO followed by a fine delay. Let me just explain a bit more about both options. 1. Keyed oscillator Counter + fine delay. The keyed oscillator starts oscillating phase allinged to the input trigger and frequency locked to the external 10MHz. This is a beautiful scheme, but sofar I have not found any comercial keyed oscillator or startable oscillator. Do you know of a design that could do the job? Keeping an stable oscillator phase and the frequency locked to an external reference at the same time is not an easy job. An example of module that does it is the V850 by highland: http://www.highlandtechnology.com/DSS/V850DS.html The fine delay can be implemented with a digital delay line such as ON's MC100EP196B or Micrel's SY89297U. http://www.onsemi.com/pub_link/Collateral/MC100EP196B-D.PDF http://www.micrel.com/page.do?page=/product-info/products/sy89297u.jsp A bad point is that the time interval between trigger's cannot be smaller than the generated delay. A very nice feature is that its monotonicity is garanteed by design. 2. Time interval meter + TCXO Counter + fine delay In this scheme I measure the trigger phase respect to the internal TCXO and calculate the corresponding fine delay that I have to add to the counter ouput. I expect the time interval measurement latency to be of the order of 200ns-300ns, so for small delays it would be necessary to use a separeted fine delay and multiplex the outputs. Locking the TCXO to the external 10MHz should not be a problem. For the TIM I could use a ACAM's TDC-GPX which offers 10ps resolution. http://www.acam-usa.com/Content/English/gpx/gpx_1.html As an analogue option I was thinking of latching the input trigger with a flip-flop, low pass filter it and sample it with a high speed ADC such as the AD9626. The TIM could be callibrated at the startup, but I do not have a feeling of how stable it can be. http://www.analog.com/en/analog-to-digital-converters/ad-converters/AD9626/products/product.html Generating the small fine delays from 25ns up to 300ns is perhaps the most diffucult one IMHO. I am not very sure if the classical scheme of integrator followed by a comparator can generate delays of up to 300ns with low jitter. On the other hand chaining 24 MC100EP196B to generate a 300ns delay seems a bit scary too... Thanks in advance for your comments Cheers Pablo ___ 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] PLL on FPGA
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY -Original Message- From: Magnus Danielson [mailto:[EMAIL PROTECTED] Sent: Monday, August 06, 2007 8:49 PM To: Pablo Alvarez Sanchez Cc: time-nuts@febo.com Subject: Re: [time-nuts] PLL on FPGA From: Pablo Alvarez Sanchez [EMAIL PROTECTED] Subject: RE: [time-nuts] PLL on FPGA Date: Mon, 6 Aug 2007 18:49:23 +0200 Message-ID: [EMAIL PROTECTED] Is your sample/message rate that of 8 kHz? My sampling rate is not constant. I wait until I detect a 3 ticks of the 500kHz clock and then start sampling. After 2048 samples I do an average (first order CIC) and pass this value to the PI. The PI operates at variable ratio of ~250Hz if there are no data or 125Hz if there are data. The fact of not having a regular trafic on the cable may also affect a bit to the final performance. The jitter I measured with a good scope is ~120ps between two modules for several minutes. Peak-to-Peak or RMS? For pure noise measures only use RMS values!!! This is RMS It is high then. You should be able to get better performance. Thanks for the info. This is really what I wanted to know. I will work on this point. What do you think I should be able to obtain? Do you think a bang-bang phase detector and setting a good reference point should do a better job? Cheers, Magnus Cheers Pablo ___ 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] PLL on FPGA
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY Hi Everybody, Thanks a lot for your help concerning the Ethernet question. It seems we will stick to a custom made timing network for the moment. In any case I would like to describe you the principles of the PLL we use in our timing system. **First of all our timing signal nowadays consists of a data stream Manchester encoded at 500kB/s (1MHz carrier). Data are always sent in packets of 4 bytes, with a preamble and codes violations at the beginning and the end to delimit the frames. Between frames we send a 500kHz clock to feed the pll. This the classic CERN timing signal that has been around since beginning of the 80s. **The phase detector is fully implemented in the FPGA. The PHD waits for at least 3 ticks of the 1MHz carrier to perform a measurement. This way I remove the intersymbol interference in more or less reasonable way. To do this measurement I use a counter clocked by an external 44.736MHz free running oscillator. Then I do an average of 2048 samples and pass it to a PI. I have put some logic in the PHD to saturate in the extreme values, this way I can have very small bandwidths without any lock-in problem. In theory if the 44.736MHz XO is uncorrelated with the 1MHZ then the noise introduced by it will be of NoisePHD~= (1/12)^.5*Txo/(Nsamples)^.5 ~22ns/3.4/(2048)^.5 ~140ps If you measure for one second then you get: NoisePHD1sec~22ns/12/(1e6)^.5~ 7ps (this is ~7e-12 in only one second, which is not too bad) This always relies on the uncorrelation of the 44.736MHz with the oscillators under test. I don't know if one can really assume this as a fact... In any case, I guess this can be used as cheap way to compare frequency standards. **The control is a typical PI. The output is connected to 16 bit DAC which drives a TCXO (cft-125 by CMAC). The bandwidth of the loop is ~2Hz. When the PLL reference signal is disconnected I pass to the DAC an averaged value of the TCXO frequency over ~16 sec The jitter I measured with a good scope is ~120ps between two modules for several minutes. The hold over I have obtained with the cft-125 is better than 5us for 30min (normally much better) Pablo ALVAREZ SANCHEZ CERN - AB Department CH-1211 Geneva 23 GSM : +41 (0)76 48 72191 Phone : +41 (0)22 76 78431 Fax : +41 (0)22 76 69318 Building : 864-1-A30 ___ 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] Timing on Ethernet
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY Dear timing colleges, At CERN we are considering the possibility of using Ethernet as a real time field bus. We may use IEEE 1588 to distribute precise UTC and Ethernet Powerlink or a similar home made product to guarantee real time. In order to have full control over the network we are thinking of designing our own hardware using FPGAs (including the physical interface). It looks like we will end by implementing 100Base-TX or 10Base-T rather than gigabit Ethernet, just because it looks much more robust and simpler to design. I am just a beginner in the Ethernet world. I have the following questions concerning the timing: 1) Two ways calibration performed in IEEE 1588 needs a symmetric path between nodes. In a presentation made by 'Timing Solutions', they say there is a 10% of asymmetry on the path for 100Base-TX. I guess this comes from the fact of using one pair for the go and a different pair for the return path. Do you have some figures for the two ways asymmetry on a single pair? http://ieee1588.nist.gov/2006%20IEEE1588%20Agenda/Stein_Sub-nanosecond%2 01588%20final.pdf 2) I was thinking of locking a PLL to the Ethernet carrier in order to minimize the jitter between modules. Is there a continuous clock or encoded signal between frames? If there is nothing specified between frames do you think one can send some kind of clock or may that provoke some perturbations on a standard PHY? Thanks for you attention Pablo - Pablo ALVAREZ SANCHEZ CERN - AB Department CH-1211 Geneva 23 GSM : +41 (0)76 48 72191 Phone : +41 (0)22 76 78431 Fax : +41 (0)22 76 69318 Building : 864-1-A30 ___ 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] Timing on Ethernet (Magnus Danielson)
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY First of all thanks a lot for your answers. For a facility like CERN, I think that normal cabel assymetries will be sufficiently low such that they would not require explicit handling, unless you have higher synchronisation demands, but in that case I would strongly suggest a different solution. You are right. Most of our aplications just demand ~1ms accuracy. Right now our requirement is only 1us accuracy, which is actually not so bad if you consider we have a 27Km accelaretor to monitor. But this is a long term project, so we have to try to do it as good as possible. I think ~1ns is nice goal. Looking at the IEEE 1588 while implementing in your own FPGA seems like an odd choice. It is an option, but you could fairly easy cook up something which fits your needs. It is not too hard actually. We may also connect to this network some foreing equipment like PLCs. Then IEEE 1588 would be quite helpful. The most important issue is what kind of performance do you need? Maximum time-errors? Not defined yet Stability requirements? What does this really mean? Free running drift if we unplug the cable. 1ms over 30 minutes is ok. But I would go for something like ~30us. Jitter between home made modules ~100ps rms Full UTC time or only UTC coordinated PPS? Full UTC. We use UTC to tag external events and for Post Mortem analysis. If there is anything wrong around the machine, a pulse is sent to our receivers and time tagged. With this we can reconstruct the situation that originated the problem. 10 MHz clock? Right now we use a 40MHz clock in our receivers. We can delays using this clock, or start counters with external clocks. There are several ways to hack Ethernet with diffrenent benefits. Cheers, Magnus Pablo ___ 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] Cs stability
Hi, I am curious about the total stability of Cs clocks. Normally producers give you an initial accuracy after 30 minutes of power on and a table with the Allan deviation for different measurement intervals. After that they give you the environmental and physical specifications. For the hp5071 you have: General environment Temperature Operating 0°C to 55°C Non-operating -40°C to 70°C Humidity 0 to 95%RH (45C max) Magnetic field dc, 55, 60Hz 0 to 2 gauss peak - any orientation Atmospheric pressure £1E-13 change in frequency for pressure down to 19kPa (equivalent to an altitude of 12.2km) Shock and vibration Mil-T-28800D, Type III, class 5 Hammer Blow Shock Test, Mil-S-901C, Grade A, Class 1, Type A Mile-STD, 167-1 (phase noise) EMI: Conducted and radiated emissions per CISPR 11/EN 55011, Group 1, Class A EMC: per MIL-STD-461C, Part 7, Class B dc magnetic field up to 7.8 Gauss My questions are: Are the Allan deviation specs also valid for all the environmental range, including shock and vibration, or only for lab conditions? In the article OBSERVATIONS ON STABILITY MEASUREMENTS OF COMMERCIAL ATOMIC CLOCKS, Pekka Eskelinen claims to have measured a phase temperature coefficient of 100ns/degree for commercial Cs clocks in 1999. http://ieeexplore.ieee.org/iel5/6762/18075/00840739.pdf (If you cannot read it I can try to send you a copy by email) Has any of you ever measured such a coefficient? Cheers Pablo ___ 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.
