One way to somewhat decouple the channels cross-talk could be do delay one of them with a coax cable. This will make the cross-talk of the early channel "die out" pretty much before the next edge come. With two asynchronous sources you will sweep over the repeating pattern of cross-talk and if it is balanced, it will average out. However, there is no guarantee that it balances out perfectly. Cheers, Magnus On 12/27/2014 03:58 PM, Bob Camp wrote: > Hi > > (In reply to several posts. It’s easier for me this way) > > Ok, that’s good news !!! (and useful data) > > Your counter performance degraded a bit when you put in 5 db and not much when you put in 8 db. > > It’s also maybe *too* good news. I suspect that cross talk between the channels may be impacting your results. > > Next step is to try it with two independent sources and a bit more attenuation. When you try it with two sources, you need to attenuate first one source and then switch the attenuators to the other source. That will help you see if crosstalk from one channel is more of a problem than from the other channel. > > One parts hint: > > Cable TV attenuators are much cheaper than their fancy 50 ohm MIniCircuits cousins. They are also something you can pick up down at the corner electronics store. For this sort of testing they are perfectly fine to use. At this point in the testing the mismatch between 75 ohms and 50 ohms is not a big deal. You will need to adapt connectors, but you probably still will save money. > > ======= > > Op-amps that have enough bandwidth and performance for a high input impedance counter input are rare items. They also are not cheap. Often they come as some sort of current feedback part with low(er) input impedance. If you want your counter to work to 300 MHz, it should accept a 300 MHz square wave. That might mean passing the third or even the fifth harmonic of the square wave. An input channel with 900 or 1500 MHz bandwidth is quite a challenge. > > One very simple solution is to just grab a high speed comparator like the one used by Fluke / Pendulum (ADCMP565). Drive it directly with your input or clock. Make it your front end device. That’s not an ideal solution, but it will give you the bandwidth and a reasonable input impedance. It requires messy things like a negative supply or a “fake” ground (so would the op amp). It also has an ECL output that needs to be converted to match your FPGA ( hint: use the clock inputs, they are LVPECL compatible). Driving into the FPGA with a differential signal is probably needed to reduce crosstalk. > > No matter how you do it, input channels are *not* an easy thing to do properly. Even on commercial counters, they often are easy to fool. Designing one is only the start. Fully testing it is equally complex. > > ========= > > Do not underrate your skills in any way. You are doing far more on this project than any of the rest of the list members have done. We have talked and talked forever about these chips. We talk a lot about these ideas. We suggest lots of complex solutions to various possible problems (like the expensive comparator I suggested above). What we almost never do is actually build a counter. If we build something we don’t fully test it. I have never seen any list member share their results the way you have. I suspect that most of us (yes this includes me) are a bit to scared of the response. > > Please do not stop your work. Keep letting us know how it is going. This is very exciting !!! > > Bob > >> On Dec 27, 2014, at 8:22 AM, Li Ang <lllaaa@gmail.com> wrote: >> >> Hi Bob, >> Here is the data and test scheme. >> It does not show much difference. >> >> 2014-12-26 22:12 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >> > > _______________________________________________ > 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. >

Hi > On Dec 28, 2014, at 9:19 AM, Li Ang <lllaaa@gmail.com> wrote: > > Hi Bob, > I did some test according to your suggestions. DUT is a symmetricom x72 > rb oscillator. Also, I've tried signal generator as the DUT. R&S SMY01 is > not as good as HP8662A but that the best I've got. The signal geneator is > also using FE5650 as ref clock. > > According to my test with the TDC today, this unit is not producing very > stable data. > I don't have accurate pulse generator, so this is how I test the TDC: > 0) power the board with battery. > 1) use FPGA to generate time pulse: > reg [15:0] shift; > always @(posedge refclk10M) begin > shift <= {shift[14:0], sw_gate}; > end > assign tdc_start = shift[3]; > assign tdc_stop1 = shift[5]; > > 2) use MCU to pull down sw_gate, the FPGA sync it to refclk10M domain and > generate input signal for TDC. > > 3) use TDC to test the time betwen tdc_start and tdc_stop1 > > The result is in tdc_test.zip. number * 100ns = time between tdc_start and > tdc_stop1. (TDC highspeed clock is refclk10M/2). > > There 2 issues from the test: > 1) As we can see from the data, the number is around 1.98x not 2.00x. So > there is about 2ns delay between tdc_start and tdc_stop1 for this simple > test code. If it is from the PCB trace and something inside FPGA, this part > should be a constant value at certain temperature. So far all correct. If you are using Quartus, you can fire up the timing analyzer and take a look at what it guesses for timing / delay on the pulse. It is not a perfect number, but I’d bet it will confirm that the 2 ns does come from the FPGA. > I can calculate it by > measuring 2 cycles and 3 cylces. My current code has not implement this > part, it should provide some improvement. 2ns time error for 1s gate, that > is something. The delay probably is from the input / output fabric on the FPGA ( = output driver). The test you propose should demonstrate this. > 2) For a 90ps TDC, I think the result should be something like +-0.001 > cycle. But I get something like +-0.003 cycle. I do not know the reason for > now. Two reasonable *guesses* would be crosstalk and noise. 1) If there are any other clocks running around during this test, I’d see if they can be shut down. Things like an free running OCXO are good for this - they are easy to isolate. 2) Noise could be internal to the TDC. If it’s 90 ns at one sigma, then you will indeed see +’/- 3 X that (or more) depending on how long you watch it. At least by my math the one sigma on the data is 149 ps. That’s a bit over 90 ps, but not terribly far. Delaying the signals relative to each other (clock and output) as Magnus suggests in another post is probably a real good idea for sorting some of this out. Bob > > > > > 2014-12-27 22:58 GMT+08:00 Bob Camp <kb8tq@n1k.org>: > >> Hi >> >> (In reply to several posts. It’s easier for me this way) >> >> Ok, that’s good news !!! (and useful data) >> >> Your counter performance degraded a bit when you put in 5 db and not much >> when you put in 8 db. >> >> It’s also maybe *too* good news. I suspect that cross talk between the >> channels may be impacting your results. >> >> Next step is to try it with two independent sources and a bit more >> attenuation. When you try it with two sources, you need to attenuate first >> one source and then switch the attenuators to the other source. That will >> help you see if crosstalk from one channel is more of a problem than from >> the other channel. >> >> One parts hint: >> >> Cable TV attenuators are much cheaper than their fancy 50 ohm MIniCircuits >> cousins. They are also something you can pick up down at the corner >> electronics store. For this sort of testing they are perfectly fine to use. >> At this point in the testing the mismatch between 75 ohms and 50 ohms is >> not a big deal. You will need to adapt connectors, but you probably still >> will save money. >> >> ======= >> >> Op-amps that have enough bandwidth and performance for a high input >> impedance counter input are rare items. They also are not cheap. Often they >> come as some sort of current feedback part with low(er) input impedance. If >> you want your counter to work to 300 MHz, it should accept a 300 MHz square >> wave. That might mean passing the third or even the fifth harmonic of the >> square wave. An input channel with 900 or 1500 MHz bandwidth is quite a >> challenge. >> >> One very simple solution is to just grab a high speed comparator like the >> one used by Fluke / Pendulum (ADCMP565). Drive it directly with your input >> or clock. Make it your front end device. That’s not an ideal solution, but >> it will give you the bandwidth and a reasonable input impedance. It >> requires messy things like a negative supply or a “fake” ground (so would >> the op amp). It also has an ECL output that needs to be converted to match >> your FPGA ( hint: use the clock inputs, they are LVPECL compatible). >> Driving into the FPGA with a differential signal is probably needed to >> reduce crosstalk. >> >> No matter how you do it, input channels are *not* an easy thing to do >> properly. Even on commercial counters, they often are easy to fool. >> Designing one is only the start. Fully testing it is equally complex. >> >> ========= >> >> Do not underrate your skills in any way. You are doing far more on this >> project than any of the rest of the list members have done. We have talked >> and talked forever about these chips. We talk a lot about these ideas. We >> suggest lots of complex solutions to various possible problems (like the >> expensive comparator I suggested above). What we almost never do is >> actually build a counter. If we build something we don’t fully test it. I >> have never seen any list member share their results the way you have. I >> suspect that most of us (yes this includes me) are a bit to scared of the >> response. >> >> Please do not stop your work. Keep letting us know how it is going. This >> is very exciting !!! >> >> Bob >> >>> On Dec 27, 2014, at 8:22 AM, Li Ang <lllaaa@gmail.com> wrote: >>> >>> Hi Bob, >>> Here is the data and test scheme. >>> It does not show much difference. >>> >>> 2014-12-26 22:12 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >>> >> >> _______________________________________________ >> 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. >> > <1228.gif><1228.zip><tdc_test.zip>_______________________________________________ > 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.

Hi, On 12/28/2014 09:35 PM, Bob Camp wrote: > Hi > > >> On Dec 28, 2014, at 9:19 AM, Li Ang <lllaaa@gmail.com> wrote: >> >> There 2 issues from the test: >> 1) As we can see from the data, the number is around 1.98x not 2.00x. So >> there is about 2ns delay between tdc_start and tdc_stop1 for this simple >> test code. If it is from the PCB trace and something inside FPGA, this part >> should be a constant value at certain temperature. > > So far all correct. If you are using Quartus, you can fire up the timing analyzer and take a look at what it guesses for timing / delay on the pulse. It is not a perfect number, but I’d bet it will confirm that the 2 ns does come from the FPGA. You might want to work with timing constraints. FPGA delays typically shifts with temperature and voltage. Also, routing distance. If you force locations of critical parts to be pinned down, the variations allowed in the routing for critical path may be steered, or you can pin it down even harder. That should help making delays from synthesis to synthesis stable. It's a painstaking job. As you go for better precision, the "freedom" of the FPGA will haunt you for stability and precision as timing stability in low ps numbers isn't really what they where aimed for. >> 2) For a 90ps TDC, I think the result should be something like +-0.001 >> cycle. But I get something like +-0.003 cycle. I do not know the reason for >> now. > > Two reasonable *guesses* would be crosstalk and noise. > > 1) If there are any other clocks running around during this test, I’d see if they can be shut down. Things like an free running OCXO are good for this - they are easy to isolate. > > 2) Noise could be internal to the TDC. If it’s 90 ns at one sigma, then you will indeed see +’/- 3 X that (or more) depending on how long you watch it. At least by my math the one sigma on the data is 149 ps. That’s a bit over 90 ps, but not terribly far. > > Delaying the signals relative to each other (clock and output) as Magnus suggests in another post is probably a real good idea for sorting some of this out. Cross-talk between start and stop channels, if this is an issue, is very easy to test using a power-splitter and two short coaxes and one slightly longer. Cross-talk comes either by capacitive cross-talk from one channel to the other, or through inductive common mode from say a power-pin. Both have been seen in actual hardware. Cross-talk from other signals, such as a clock should raise the noise, but if they have sufficient large beat-note with the signal, it can average out pretty good. For TICs, cross-talk as well as non-linearities from the internal reference is to be expected, but if this beats quick enough with the signal at hand, it should average out nicely. A highly reference-synchronous signal will hit about the same space in the ref cross-talk and non-linearities, so that helps. Anyway, using a 1 m longer coax gives you about 5 ns shift between start and stop. Oh, some counters use such a delay to make sure they can arm the stop-channel after the start-channel triggered. Cheers, Magnus

 According to my test with the TDC today, this unit is not producing very

Hi, Some quick statistic-processing. Histogram of your data: 1.979 0 1.980 2 1.981 46 1.982 173 1.983 523 1.984 1031 1.985 1301 1.986 1131 1.987 648 1.988 236 1.989 8 1.990 1 1.991 0 The total sample count is 5100 (wc -l only gives 5099 since there is a missing end of line, but word count is 5100). The average is about 1,985075 ns and it is reasonably gaussian, but with some systematics, notice how the slope is more abrupt on the higher end than the lower end. A quick and dirty spreadsheet gives me about 2,243 ps RMS jitter, which isn't all that bad. Yes, it will spread out to that 11 ps peak-to-peak jitter, but it is to be expected. It's pretty respectable for a home-built. Cheers, Magnus On 12/28/2014 03:19 PM, Li Ang wrote: > Hi Bob, > I did some test according to your suggestions. DUT is a symmetricom x72 > rb oscillator. Also, I've tried signal generator as the DUT. R&S SMY01 is > not as good as HP8662A but that the best I've got. The signal geneator is > also using FE5650 as ref clock. > > According to my test with the TDC today, this unit is not producing very > stable data. > I don't have accurate pulse generator, so this is how I test the TDC: > 0) power the board with battery. > 1) use FPGA to generate time pulse: > reg [15:0] shift; > always @(posedge refclk10M) begin > shift <= {shift[14:0], sw_gate}; > end > assign tdc_start = shift[3]; > assign tdc_stop1 = shift[5]; > > 2) use MCU to pull down sw_gate, the FPGA sync it to refclk10M domain and > generate input signal for TDC. > > 3) use TDC to test the time betwen tdc_start and tdc_stop1 > > The result is in tdc_test.zip. number * 100ns = time between tdc_start and > tdc_stop1. (TDC highspeed clock is refclk10M/2). > > There 2 issues from the test: > 1) As we can see from the data, the number is around 1.98x not 2.00x. So > there is about 2ns delay between tdc_start and tdc_stop1 for this simple > test code. If it is from the PCB trace and something inside FPGA, this part > should be a constant value at certain temperature. I can calculate it by > measuring 2 cycles and 3 cylces. My current code has not implement this > part, it should provide some improvement. 2ns time error for 1s gate, that > is something. > 2) For a 90ps TDC, I think the result should be something like +-0.001 > cycle. But I get something like +-0.003 cycle. I do not know the reason for > now. > > > > > > 2014-12-27 22:58 GMT+08:00 Bob Camp <kb8tq@n1k.org>: > >> Hi >> >> (In reply to several posts. It’s easier for me this way) >> >> Ok, that’s good news !!! (and useful data) >> >> Your counter performance degraded a bit when you put in 5 db and not much >> when you put in 8 db. >> >> It’s also maybe *too* good news. I suspect that cross talk between the >> channels may be impacting your results. >> >> Next step is to try it with two independent sources and a bit more >> attenuation. When you try it with two sources, you need to attenuate first >> one source and then switch the attenuators to the other source. That will >> help you see if crosstalk from one channel is more of a problem than from >> the other channel. >> >> One parts hint: >> >> Cable TV attenuators are much cheaper than their fancy 50 ohm MIniCircuits >> cousins. They are also something you can pick up down at the corner >> electronics store. For this sort of testing they are perfectly fine to use. >> At this point in the testing the mismatch between 75 ohms and 50 ohms is >> not a big deal. You will need to adapt connectors, but you probably still >> will save money. >> >> ======= >> >> Op-amps that have enough bandwidth and performance for a high input >> impedance counter input are rare items. They also are not cheap. Often they >> come as some sort of current feedback part with low(er) input impedance. If >> you want your counter to work to 300 MHz, it should accept a 300 MHz square >> wave. That might mean passing the third or even the fifth harmonic of the >> square wave. An input channel with 900 or 1500 MHz bandwidth is quite a >> challenge. >> >> One very simple solution is to just grab a high speed comparator like the >> one used by Fluke / Pendulum (ADCMP565). Drive it directly with your input >> or clock. Make it your front end device. That’s not an ideal solution, but >> it will give you the bandwidth and a reasonable input impedance. It >> requires messy things like a negative supply or a “fake” ground (so would >> the op amp). It also has an ECL output that needs to be converted to match >> your FPGA ( hint: use the clock inputs, they are LVPECL compatible). >> Driving into the FPGA with a differential signal is probably needed to >> reduce crosstalk. >> >> No matter how you do it, input channels are *not* an easy thing to do >> properly. Even on commercial counters, they often are easy to fool. >> Designing one is only the start. Fully testing it is equally complex. >> >> ========= >> >> Do not underrate your skills in any way. You are doing far more on this >> project than any of the rest of the list members have done. We have talked >> and talked forever about these chips. We talk a lot about these ideas. We >> suggest lots of complex solutions to various possible problems (like the >> expensive comparator I suggested above). What we almost never do is >> actually build a counter. If we build something we don’t fully test it. I >> have never seen any list member share their results the way you have. I >> suspect that most of us (yes this includes me) are a bit to scared of the >> response. >> >> Please do not stop your work. Keep letting us know how it is going. This >> is very exciting !!! >> >> Bob >> >>> On Dec 27, 2014, at 8:22 AM, Li Ang <lllaaa@gmail.com> wrote: >>> >>> Hi Bob, >>> Here is the data and test scheme. >>> It does not show much difference. >>> >>> 2014-12-26 22:12 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >>> >> >> _______________________________________________ >> 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.

 According to my test with the TDC today, this unit is not producing

Hi Magnus, The unit of these data is not ns but reference clock cycles (100ns). TDC_GP22 measures the time between the edge of tdc_start and tdc_stop1, then it measures the reference clock automaticly. The result you get from it is the ratio of them. 2014-12-29 19:58 GMT+08:00 Magnus Danielson <magnus@rubidium.dyndns.org>: > Hi, > > Some quick statistic-processing. > > Histogram of your data: > 1.979 0 > 1.980 2 > 1.981 46 > 1.982 173 > 1.983 523 > 1.984 1031 > 1.985 1301 > 1.986 1131 > 1.987 648 > 1.988 236 > 1.989 8 > 1.990 1 > 1.991 0 > > The total sample count is 5100 (wc -l only gives 5099 since there is a > missing end of line, but word count is 5100). > > The average is about 1,985075 ns and it is reasonably gaussian, but with > some systematics, notice how the slope is more abrupt on the higher end > than the lower end. A quick and dirty spreadsheet gives me about 2,243 ps > RMS jitter, which isn't all that bad. Yes, it will spread out to that 11 ps > peak-to-peak jitter, but it is to be expected. > > It's pretty respectable for a home-built. > > Cheers, > Magnus > > > On 12/28/2014 03:19 PM, Li Ang wrote: > >> Hi Bob, >> I did some test according to your suggestions. DUT is a symmetricom >> x72 >> rb oscillator. Also, I've tried signal generator as the DUT. R&S SMY01 is >> not as good as HP8662A but that the best I've got. The signal geneator is >> also using FE5650 as ref clock. >> >> According to my test with the TDC today, this unit is not producing >> very >> stable data. >> I don't have accurate pulse generator, so this is how I test the TDC: >> 0) power the board with battery. >> 1) use FPGA to generate time pulse: >> reg [15:0] shift; >> always @(posedge refclk10M) begin >> shift <= {shift[14:0], sw_gate}; >> end >> assign tdc_start = shift[3]; >> assign tdc_stop1 = shift[5]; >> >> 2) use MCU to pull down sw_gate, the FPGA sync it to refclk10M domain and >> generate input signal for TDC. >> >> 3) use TDC to test the time betwen tdc_start and tdc_stop1 >> >> The result is in tdc_test.zip. number * 100ns = time between tdc_start and >> tdc_stop1. (TDC highspeed clock is refclk10M/2). >> >> There 2 issues from the test: >> 1) As we can see from the data, the number is around 1.98x not 2.00x. So >> there is about 2ns delay between tdc_start and tdc_stop1 for this simple >> test code. If it is from the PCB trace and something inside FPGA, this >> part >> should be a constant value at certain temperature. I can calculate it by >> measuring 2 cycles and 3 cylces. My current code has not implement this >> part, it should provide some improvement. 2ns time error for 1s gate, that >> is something. >> 2) For a 90ps TDC, I think the result should be something like +-0.001 >> cycle. But I get something like +-0.003 cycle. I do not know the reason >> for >> now. >> >> >> >> >> >> 2014-12-27 22:58 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >> >> Hi >>> >>> (In reply to several posts. It’s easier for me this way) >>> >>> Ok, that’s good news !!! (and useful data) >>> >>> Your counter performance degraded a bit when you put in 5 db and not much >>> when you put in 8 db. >>> >>> It’s also maybe *too* good news. I suspect that cross talk between the >>> channels may be impacting your results. >>> >>> Next step is to try it with two independent sources and a bit more >>> attenuation. When you try it with two sources, you need to attenuate >>> first >>> one source and then switch the attenuators to the other source. That will >>> help you see if crosstalk from one channel is more of a problem than from >>> the other channel. >>> >>> One parts hint: >>> >>> Cable TV attenuators are much cheaper than their fancy 50 ohm >>> MIniCircuits >>> cousins. They are also something you can pick up down at the corner >>> electronics store. For this sort of testing they are perfectly fine to >>> use. >>> At this point in the testing the mismatch between 75 ohms and 50 ohms is >>> not a big deal. You will need to adapt connectors, but you probably still >>> will save money. >>> >>> ======= >>> >>> Op-amps that have enough bandwidth and performance for a high input >>> impedance counter input are rare items. They also are not cheap. Often >>> they >>> come as some sort of current feedback part with low(er) input impedance. >>> If >>> you want your counter to work to 300 MHz, it should accept a 300 MHz >>> square >>> wave. That might mean passing the third or even the fifth harmonic of the >>> square wave. An input channel with 900 or 1500 MHz bandwidth is quite a >>> challenge. >>> >>> One very simple solution is to just grab a high speed comparator like the >>> one used by Fluke / Pendulum (ADCMP565). Drive it directly with your >>> input >>> or clock. Make it your front end device. That’s not an ideal solution, >>> but >>> it will give you the bandwidth and a reasonable input impedance. It >>> requires messy things like a negative supply or a “fake” ground (so >>> would >>> the op amp). It also has an ECL output that needs to be converted to >>> match >>> your FPGA ( hint: use the clock inputs, they are LVPECL compatible). >>> Driving into the FPGA with a differential signal is probably needed to >>> reduce crosstalk. >>> >>> No matter how you do it, input channels are *not* an easy thing to do >>> properly. Even on commercial counters, they often are easy to fool. >>> Designing one is only the start. Fully testing it is equally complex. >>> >>> ========= >>> >>> Do not underrate your skills in any way. You are doing far more on this >>> project than any of the rest of the list members have done. We have >>> talked >>> and talked forever about these chips. We talk a lot about these ideas. We >>> suggest lots of complex solutions to various possible problems (like the >>> expensive comparator I suggested above). What we almost never do is >>> actually build a counter. If we build something we don’t fully test it. I >>> have never seen any list member share their results the way you have. I >>> suspect that most of us (yes this includes me) are a bit to scared of the >>> response. >>> >>> Please do not stop your work. Keep letting us know how it is going. This >>> is very exciting !!! >>> >>> Bob >>> >>> On Dec 27, 2014, at 8:22 AM, Li Ang <lllaaa@gmail.com> wrote: >>>> >>>> Hi Bob, >>>> Here is the data and test scheme. >>>> It does not show much difference. >>>> >>>> 2014-12-26 22:12 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >>>> >>>> >>> _______________________________________________ >>> 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. >

  According to my test with the TDC today, this unit is not producing

Hi, Darn, not reading all the notes. Again. Well, in that case, scaling should be done... then you get average of 198,5075 ns and 149,8 ps RMS jitter, with 1,1 ns peak-to-peak. The jitter is okish then, but a little better would indeed be nice. Cheers, Magnus On 12/29/2014 01:55 PM, Li Ang wrote: > Hi Magnus, > The unit of these data is not ns but reference clock cycles (100ns). > TDC_GP22 measures the time between the edge of tdc_start and > tdc_stop1, then it measures the reference clock automaticly. The result you > get from it is the ratio of them. > > 2014-12-29 19:58 GMT+08:00 Magnus Danielson <magnus@rubidium.dyndns.org>: > >> Hi, >> >> Some quick statistic-processing. >> >> Histogram of your data: >> 1.979 0 >> 1.980 2 >> 1.981 46 >> 1.982 173 >> 1.983 523 >> 1.984 1031 >> 1.985 1301 >> 1.986 1131 >> 1.987 648 >> 1.988 236 >> 1.989 8 >> 1.990 1 >> 1.991 0 >> >> The total sample count is 5100 (wc -l only gives 5099 since there is a >> missing end of line, but word count is 5100). >> >> The average is about 1,985075 ns and it is reasonably gaussian, but with >> some systematics, notice how the slope is more abrupt on the higher end >> than the lower end. A quick and dirty spreadsheet gives me about 2,243 ps >> RMS jitter, which isn't all that bad. Yes, it will spread out to that 11 ps >> peak-to-peak jitter, but it is to be expected. >> >> It's pretty respectable for a home-built. >> >> Cheers, >> Magnus >> >> >> On 12/28/2014 03:19 PM, Li Ang wrote: >> >>> Hi Bob, >>> I did some test according to your suggestions. DUT is a symmetricom >>> x72 >>> rb oscillator. Also, I've tried signal generator as the DUT. R&S SMY01 is >>> not as good as HP8662A but that the best I've got. The signal geneator is >>> also using FE5650 as ref clock. >>> >>> According to my test with the TDC today, this unit is not producing >>> very >>> stable data. >>> I don't have accurate pulse generator, so this is how I test the TDC: >>> 0) power the board with battery. >>> 1) use FPGA to generate time pulse: >>> reg [15:0] shift; >>> always @(posedge refclk10M) begin >>> shift <= {shift[14:0], sw_gate}; >>> end >>> assign tdc_start = shift[3]; >>> assign tdc_stop1 = shift[5]; >>> >>> 2) use MCU to pull down sw_gate, the FPGA sync it to refclk10M domain and >>> generate input signal for TDC. >>> >>> 3) use TDC to test the time betwen tdc_start and tdc_stop1 >>> >>> The result is in tdc_test.zip. number * 100ns = time between tdc_start and >>> tdc_stop1. (TDC highspeed clock is refclk10M/2). >>> >>> There 2 issues from the test: >>> 1) As we can see from the data, the number is around 1.98x not 2.00x. So >>> there is about 2ns delay between tdc_start and tdc_stop1 for this simple >>> test code. If it is from the PCB trace and something inside FPGA, this >>> part >>> should be a constant value at certain temperature. I can calculate it by >>> measuring 2 cycles and 3 cylces. My current code has not implement this >>> part, it should provide some improvement. 2ns time error for 1s gate, that >>> is something. >>> 2) For a 90ps TDC, I think the result should be something like +-0.001 >>> cycle. But I get something like +-0.003 cycle. I do not know the reason >>> for >>> now. >>> >>> >>> >>> >>> >>> 2014-12-27 22:58 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >>> >>> Hi >>>> >>>> (In reply to several posts. It’s easier for me this way) >>>> >>>> Ok, that’s good news !!! (and useful data) >>>> >>>> Your counter performance degraded a bit when you put in 5 db and not much >>>> when you put in 8 db. >>>> >>>> It’s also maybe *too* good news. I suspect that cross talk between the >>>> channels may be impacting your results. >>>> >>>> Next step is to try it with two independent sources and a bit more >>>> attenuation. When you try it with two sources, you need to attenuate >>>> first >>>> one source and then switch the attenuators to the other source. That will >>>> help you see if crosstalk from one channel is more of a problem than from >>>> the other channel. >>>> >>>> One parts hint: >>>> >>>> Cable TV attenuators are much cheaper than their fancy 50 ohm >>>> MIniCircuits >>>> cousins. They are also something you can pick up down at the corner >>>> electronics store. For this sort of testing they are perfectly fine to >>>> use. >>>> At this point in the testing the mismatch between 75 ohms and 50 ohms is >>>> not a big deal. You will need to adapt connectors, but you probably still >>>> will save money. >>>> >>>> ======= >>>> >>>> Op-amps that have enough bandwidth and performance for a high input >>>> impedance counter input are rare items. They also are not cheap. Often >>>> they >>>> come as some sort of current feedback part with low(er) input impedance. >>>> If >>>> you want your counter to work to 300 MHz, it should accept a 300 MHz >>>> square >>>> wave. That might mean passing the third or even the fifth harmonic of the >>>> square wave. An input channel with 900 or 1500 MHz bandwidth is quite a >>>> challenge. >>>> >>>> One very simple solution is to just grab a high speed comparator like the >>>> one used by Fluke / Pendulum (ADCMP565). Drive it directly with your >>>> input >>>> or clock. Make it your front end device. That’s not an ideal solution, >>>> but >>>> it will give you the bandwidth and a reasonable input impedance. It >>>> requires messy things like a negative supply or a “fake” ground (so >>>> would >>>> the op amp). It also has an ECL output that needs to be converted to >>>> match >>>> your FPGA ( hint: use the clock inputs, they are LVPECL compatible). >>>> Driving into the FPGA with a differential signal is probably needed to >>>> reduce crosstalk. >>>> >>>> No matter how you do it, input channels are *not* an easy thing to do >>>> properly. Even on commercial counters, they often are easy to fool. >>>> Designing one is only the start. Fully testing it is equally complex. >>>> >>>> ========= >>>> >>>> Do not underrate your skills in any way. You are doing far more on this >>>> project than any of the rest of the list members have done. We have >>>> talked >>>> and talked forever about these chips. We talk a lot about these ideas. We >>>> suggest lots of complex solutions to various possible problems (like the >>>> expensive comparator I suggested above). What we almost never do is >>>> actually build a counter. If we build something we don’t fully test it. I >>>> have never seen any list member share their results the way you have. I >>>> suspect that most of us (yes this includes me) are a bit to scared of the >>>> response. >>>> >>>> Please do not stop your work. Keep letting us know how it is going. This >>>> is very exciting !!! >>>> >>>> Bob >>>> >>>> On Dec 27, 2014, at 8:22 AM, Li Ang <lllaaa@gmail.com> wrote: >>>>> >>>>> Hi Bob, >>>>> Here is the data and test scheme. >>>>> It does not show much difference. >>>>> >>>>> 2014-12-26 22:12 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >>>>> >>>>> >>>> _______________________________________________ >>>> time-nuts mailing list -- time-nuts@febo.com >>>> To unsubscribe, go to >>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>> and follow the instructions there. >>>> >>>> >>>> >>>> _______________________________________________ >>>> time-nuts mailing list -- time-nuts@febo.com >>>> To unsubscribe, go to https://www.febo.com/cgi-bin/ >>>> mailman/listinfo/time-nuts >>>> and follow the instructions there. >>>> >>> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/ >> mailman/listinfo/time-nuts >> and follow the instructions there. >> > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. >

According to my test with the TDC today, this unit is not producing

Hi > On Dec 29, 2014, at 7:55 AM, Li Ang <lllaaa@gmail.com> wrote: > > Hi Magnus, > The unit of these data is not ns but reference clock cycles (100ns). > TDC_GP22 measures the time between the edge of tdc_start and > tdc_stop1, then it measures the reference clock automaticly. The result you > get from it is the ratio of them. > > 2014-12-29 19:58 GMT+08:00 Magnus Danielson <magnus@rubidium.dyndns.org>: > >> Hi, >> >> Some quick statistic-processing. >> >> Histogram of your data: >> 1.979 0 >> 1.980 2 >> 1.981 46 >> 1.982 173 >> 1.983 523 >> 1.984 1031 >> 1.985 1301 >> 1.986 1131 >> 1.987 648 >> 1.988 236 >> 1.989 8 >> 1.990 1 >> 1.991 0 One way you can get a “chopped tail” like that is when a TDC runs out of range. That can happen either because there is a problem in the TDC or in other cases because there is a handoff problem between the FPGA and the TDC. I saw a lot of plots like this doing the Wave Union TDC stuff on an FPGA setup. Bob >> >> The total sample count is 5100 (wc -l only gives 5099 since there is a >> missing end of line, but word count is 5100). >> >> The average is about 1,985075 ns and it is reasonably gaussian, but with >> some systematics, notice how the slope is more abrupt on the higher end >> than the lower end. A quick and dirty spreadsheet gives me about 2,243 ps >> RMS jitter, which isn't all that bad. Yes, it will spread out to that 11 ps >> peak-to-peak jitter, but it is to be expected. >> >> It's pretty respectable for a home-built. >> >> Cheers, >> Magnus >> >> >> On 12/28/2014 03:19 PM, Li Ang wrote: >> >>> Hi Bob, >>> I did some test according to your suggestions. DUT is a symmetricom >>> x72 >>> rb oscillator. Also, I've tried signal generator as the DUT. R&S SMY01 is >>> not as good as HP8662A but that the best I've got. The signal geneator is >>> also using FE5650 as ref clock. >>> >>> According to my test with the TDC today, this unit is not producing >>> very >>> stable data. >>> I don't have accurate pulse generator, so this is how I test the TDC: >>> 0) power the board with battery. >>> 1) use FPGA to generate time pulse: >>> reg [15:0] shift; >>> always @(posedge refclk10M) begin >>> shift <= {shift[14:0], sw_gate}; >>> end >>> assign tdc_start = shift[3]; >>> assign tdc_stop1 = shift[5]; >>> >>> 2) use MCU to pull down sw_gate, the FPGA sync it to refclk10M domain and >>> generate input signal for TDC. >>> >>> 3) use TDC to test the time betwen tdc_start and tdc_stop1 >>> >>> The result is in tdc_test.zip. number * 100ns = time between tdc_start and >>> tdc_stop1. (TDC highspeed clock is refclk10M/2). >>> >>> There 2 issues from the test: >>> 1) As we can see from the data, the number is around 1.98x not 2.00x. So >>> there is about 2ns delay between tdc_start and tdc_stop1 for this simple >>> test code. If it is from the PCB trace and something inside FPGA, this >>> part >>> should be a constant value at certain temperature. I can calculate it by >>> measuring 2 cycles and 3 cylces. My current code has not implement this >>> part, it should provide some improvement. 2ns time error for 1s gate, that >>> is something. >>> 2) For a 90ps TDC, I think the result should be something like +-0.001 >>> cycle. But I get something like +-0.003 cycle. I do not know the reason >>> for >>> now. >>> >>> >>> >>> >>> >>> 2014-12-27 22:58 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >>> >>> Hi >>>> >>>> (In reply to several posts. It’s easier for me this way) >>>> >>>> Ok, that’s good news !!! (and useful data) >>>> >>>> Your counter performance degraded a bit when you put in 5 db and not much >>>> when you put in 8 db. >>>> >>>> It’s also maybe *too* good news. I suspect that cross talk between the >>>> channels may be impacting your results. >>>> >>>> Next step is to try it with two independent sources and a bit more >>>> attenuation. When you try it with two sources, you need to attenuate >>>> first >>>> one source and then switch the attenuators to the other source. That will >>>> help you see if crosstalk from one channel is more of a problem than from >>>> the other channel. >>>> >>>> One parts hint: >>>> >>>> Cable TV attenuators are much cheaper than their fancy 50 ohm >>>> MIniCircuits >>>> cousins. They are also something you can pick up down at the corner >>>> electronics store. For this sort of testing they are perfectly fine to >>>> use. >>>> At this point in the testing the mismatch between 75 ohms and 50 ohms is >>>> not a big deal. You will need to adapt connectors, but you probably still >>>> will save money. >>>> >>>> ======= >>>> >>>> Op-amps that have enough bandwidth and performance for a high input >>>> impedance counter input are rare items. They also are not cheap. Often >>>> they >>>> come as some sort of current feedback part with low(er) input impedance. >>>> If >>>> you want your counter to work to 300 MHz, it should accept a 300 MHz >>>> square >>>> wave. That might mean passing the third or even the fifth harmonic of the >>>> square wave. An input channel with 900 or 1500 MHz bandwidth is quite a >>>> challenge. >>>> >>>> One very simple solution is to just grab a high speed comparator like the >>>> one used by Fluke / Pendulum (ADCMP565). Drive it directly with your >>>> input >>>> or clock. Make it your front end device. That’s not an ideal solution, >>>> but >>>> it will give you the bandwidth and a reasonable input impedance. It >>>> requires messy things like a negative supply or a “fake” ground (so >>>> would >>>> the op amp). It also has an ECL output that needs to be converted to >>>> match >>>> your FPGA ( hint: use the clock inputs, they are LVPECL compatible). >>>> Driving into the FPGA with a differential signal is probably needed to >>>> reduce crosstalk. >>>> >>>> No matter how you do it, input channels are *not* an easy thing to do >>>> properly. Even on commercial counters, they often are easy to fool. >>>> Designing one is only the start. Fully testing it is equally complex. >>>> >>>> ========= >>>> >>>> Do not underrate your skills in any way. You are doing far more on this >>>> project than any of the rest of the list members have done. We have >>>> talked >>>> and talked forever about these chips. We talk a lot about these ideas. We >>>> suggest lots of complex solutions to various possible problems (like the >>>> expensive comparator I suggested above). What we almost never do is >>>> actually build a counter. If we build something we don’t fully test it. I >>>> have never seen any list member share their results the way you have. I >>>> suspect that most of us (yes this includes me) are a bit to scared of the >>>> response. >>>> >>>> Please do not stop your work. Keep letting us know how it is going. This >>>> is very exciting !!! >>>> >>>> Bob >>>> >>>> On Dec 27, 2014, at 8:22 AM, Li Ang <lllaaa@gmail.com> wrote: >>>>> >>>>> Hi Bob, >>>>> Here is the data and test scheme. >>>>> It does not show much difference. >>>>> >>>>> 2014-12-26 22:12 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >>>>> >>>>> >>>> _______________________________________________ >>>> time-nuts mailing list -- time-nuts@febo.com >>>> To unsubscribe, go to >>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>> and follow the instructions there. >>>> >>>> >>>> >>>> _______________________________________________ >>>> time-nuts mailing list -- time-nuts@febo.com >>>> To unsubscribe, go to https://www.febo.com/cgi-bin/ >>>> mailman/listinfo/time-nuts >>>> and follow the instructions there. >>>> >>> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/ >> mailman/listinfo/time-nuts >> and follow the instructions there. >> > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

  I did some test according to your suggestions. DUT is a symmetricom

  According to my test with the TDC today, this unit is not producing

Hi Magnus, I'm not familar with error analysis and statistics, can you tell me how to calculate the jitter with my data? Can you tell me some articles or tutorials about the calculation that a time-nut usually use? I want to learn stuffs. :) Thanks. 2014-12-29 21:58 GMT+08:00 Magnus Danielson <magnus@rubidium.dyndns.org>: > Hi, > > Darn, not reading all the notes. Again. > > Well, in that case, scaling should be done... then you get average of > 198,5075 ns and 149,8 ps RMS jitter, with 1,1 ns peak-to-peak. > > The jitter is okish then, but a little better would indeed be nice. > > Cheers, > Magnus > > > On 12/29/2014 01:55 PM, Li Ang wrote: > >> Hi Magnus, >> The unit of these data is not ns but reference clock cycles (100ns). >> TDC_GP22 measures the time between the edge of tdc_start and >> tdc_stop1, then it measures the reference clock automaticly. The result >> you >> get from it is the ratio of them. >> >> 2014-12-29 19:58 GMT+08:00 Magnus Danielson <magnus@rubidium.dyndns.org>: >> >> Hi, >>> >>> Some quick statistic-processing. >>> >>> Histogram of your data: >>> 1.979 0 >>> 1.980 2 >>> 1.981 46 >>> 1.982 173 >>> 1.983 523 >>> 1.984 1031 >>> 1.985 1301 >>> 1.986 1131 >>> 1.987 648 >>> 1.988 236 >>> 1.989 8 >>> 1.990 1 >>> 1.991 0 >>> >>> The total sample count is 5100 (wc -l only gives 5099 since there is a >>> missing end of line, but word count is 5100). >>> >>> The average is about 1,985075 ns and it is reasonably gaussian, but with >>> some systematics, notice how the slope is more abrupt on the higher end >>> than the lower end. A quick and dirty spreadsheet gives me about 2,243 ps >>> RMS jitter, which isn't all that bad. Yes, it will spread out to that 11 >>> ps >>> peak-to-peak jitter, but it is to be expected. >>> >>> It's pretty respectable for a home-built. >>> >>> Cheers, >>> Magnus >>> >>> >>> On 12/28/2014 03:19 PM, Li Ang wrote: >>> >>> Hi Bob, >>>> I did some test according to your suggestions. DUT is a symmetricom >>>> x72 >>>> rb oscillator. Also, I've tried signal generator as the DUT. R&S SMY01 >>>> is >>>> not as good as HP8662A but that the best I've got. The signal geneator >>>> is >>>> also using FE5650 as ref clock. >>>> >>>> According to my test with the TDC today, this unit is not producing >>>> very >>>> stable data. >>>> I don't have accurate pulse generator, so this is how I test the >>>> TDC: >>>> 0) power the board with battery. >>>> 1) use FPGA to generate time pulse: >>>> reg [15:0] shift; >>>> always @(posedge refclk10M) begin >>>> shift <= {shift[14:0], sw_gate}; >>>> end >>>> assign tdc_start = shift[3]; >>>> assign tdc_stop1 = shift[5]; >>>> >>>> 2) use MCU to pull down sw_gate, the FPGA sync it to refclk10M domain >>>> and >>>> generate input signal for TDC. >>>> >>>> 3) use TDC to test the time betwen tdc_start and tdc_stop1 >>>> >>>> The result is in tdc_test.zip. number * 100ns = time between tdc_start >>>> and >>>> tdc_stop1. (TDC highspeed clock is refclk10M/2). >>>> >>>> There 2 issues from the test: >>>> 1) As we can see from the data, the number is around 1.98x not 2.00x. So >>>> there is about 2ns delay between tdc_start and tdc_stop1 for this simple >>>> test code. If it is from the PCB trace and something inside FPGA, this >>>> part >>>> should be a constant value at certain temperature. I can calculate it by >>>> measuring 2 cycles and 3 cylces. My current code has not implement this >>>> part, it should provide some improvement. 2ns time error for 1s gate, >>>> that >>>> is something. >>>> 2) For a 90ps TDC, I think the result should be something like +-0.001 >>>> cycle. But I get something like +-0.003 cycle. I do not know the reason >>>> for >>>> now. >>>> >>>> >>>> >>>> >>>> >>>> 2014-12-27 22:58 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >>>> >>>> Hi >>>> >>>>> >>>>> (In reply to several posts. It’s easier for me this way) >>>>> >>>>> Ok, that’s good news !!! (and useful data) >>>>> >>>>> Your counter performance degraded a bit when you put in 5 db and not >>>>> much >>>>> when you put in 8 db. >>>>> >>>>> It’s also maybe *too* good news. I suspect that cross talk between the >>>>> channels may be impacting your results. >>>>> >>>>> Next step is to try it with two independent sources and a bit more >>>>> attenuation. When you try it with two sources, you need to attenuate >>>>> first >>>>> one source and then switch the attenuators to the other source. That >>>>> will >>>>> help you see if crosstalk from one channel is more of a problem than >>>>> from >>>>> the other channel. >>>>> >>>>> One parts hint: >>>>> >>>>> Cable TV attenuators are much cheaper than their fancy 50 ohm >>>>> MIniCircuits >>>>> cousins. They are also something you can pick up down at the corner >>>>> electronics store. For this sort of testing they are perfectly fine to >>>>> use. >>>>> At this point in the testing the mismatch between 75 ohms and 50 ohms >>>>> is >>>>> not a big deal. You will need to adapt connectors, but you probably >>>>> still >>>>> will save money. >>>>> >>>>> ======= >>>>> >>>>> Op-amps that have enough bandwidth and performance for a high input >>>>> impedance counter input are rare items. They also are not cheap. Often >>>>> they >>>>> come as some sort of current feedback part with low(er) input >>>>> impedance. >>>>> If >>>>> you want your counter to work to 300 MHz, it should accept a 300 MHz >>>>> square >>>>> wave. That might mean passing the third or even the fifth harmonic of >>>>> the >>>>> square wave. An input channel with 900 or 1500 MHz bandwidth is quite a >>>>> challenge. >>>>> >>>>> One very simple solution is to just grab a high speed comparator like >>>>> the >>>>> one used by Fluke / Pendulum (ADCMP565). Drive it directly with your >>>>> input >>>>> or clock. Make it your front end device. That’s not an ideal solution, >>>>> but >>>>> it will give you the bandwidth and a reasonable input impedance. It >>>>> requires messy things like a negative supply or a “fake” ground (so >>>>> would >>>>> the op amp). It also has an ECL output that needs to be converted to >>>>> match >>>>> your FPGA ( hint: use the clock inputs, they are LVPECL compatible). >>>>> Driving into the FPGA with a differential signal is probably needed to >>>>> reduce crosstalk. >>>>> >>>>> No matter how you do it, input channels are *not* an easy thing to do >>>>> properly. Even on commercial counters, they often are easy to fool. >>>>> Designing one is only the start. Fully testing it is equally complex. >>>>> >>>>> ========= >>>>> >>>>> Do not underrate your skills in any way. You are doing far more on this >>>>> project than any of the rest of the list members have done. We have >>>>> talked >>>>> and talked forever about these chips. We talk a lot about these ideas. >>>>> We >>>>> suggest lots of complex solutions to various possible problems (like >>>>> the >>>>> expensive comparator I suggested above). What we almost never do is >>>>> actually build a counter. If we build something we don’t fully test >>>>> it. I >>>>> have never seen any list member share their results the way you have. I >>>>> suspect that most of us (yes this includes me) are a bit to scared of >>>>> the >>>>> response. >>>>> >>>>> Please do not stop your work. Keep letting us know how it is going. >>>>> This >>>>> is very exciting !!! >>>>> >>>>> Bob >>>>> >>>>> On Dec 27, 2014, at 8:22 AM, Li Ang <lllaaa@gmail.com> wrote: >>>>> >>>>>> >>>>>> Hi Bob, >>>>>> Here is the data and test scheme. >>>>>> It does not show much difference. >>>>>> >>>>>> 2014-12-26 22:12 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>> time-nuts mailing list -- time-nuts@febo.com >>>>> To unsubscribe, go to >>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>>> and follow the instructions there. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> time-nuts mailing list -- time-nuts@febo.com >>>>> To unsubscribe, go to https://www.febo.com/cgi-bin/ >>>>> mailman/listinfo/time-nuts >>>>> and follow the instructions there. >>>>> >>>>> _______________________________________________ >>>> >>> time-nuts mailing list -- time-nuts@febo.com >>> To unsubscribe, go to https://www.febo.com/cgi-bin/ >>> mailman/listinfo/time-nuts >>> and follow the instructions there. >>> >>> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/ >> mailman/listinfo/time-nuts >> and follow the instructions there. >> >> _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. >

   I did some test according to your suggestions. DUT is a symmetricom

   According to my test with the TDC today, this unit is not producing

Hi

On Dec 27, 2014, at 8:22 AM, Li Ang <lllaaa@gmail.com> wrote:

Hi, First I did a statistical histogram simply by counting how many times a particular delay measure occurred, thus creating "bins" of occurrence count for each value. I did this by doing grep 1.987 tdc_test.txt | wc -l 648 So, the 1.987 bin has a count of 648. I sent you the full histogram in the first reply. Then, I calculated the average delay by multiply each delay with the count of that delay, and then add these products to a sum, and divide by the total count (5100). Using this average, I then subtract that for the measure of each bin, thus getting the distance from the average. This difference is then squared, and multiplied with the count for it's bin-count. Again this is being summed, divided by the total count minus 1 (5099) to produce the variance, and square root produces the standard deviation. So far, it relative simple operations. These operations could be done directly on the sample-set, but the histogram is also good in that you can now see if it is unbalanced. One analysis you can do is to analyse how well the histogram matches up the expected Gaussian distribution bell for the noise you have. This can be done in several ways, but for a coarse set of bins like this, I think the best is to generate a matching Gaussian bin count from the bin positions, average and deviation. The difference with the actual bin count will then illustrate any major deviations. The trained eye will see deviation in the histogram anyway. However, to do this requires the erfc. Hope this have shown you enough of the "magic". But to assist you further, please find a spread-sheet of it attached. Notice that I scaled the values by 100 ns before further processing. Cheers, Magnus On 12/31/2014 01:03 PM, Li Ang wrote: > Hi Magnus, > I'm not familar with error analysis and statistics, can you tell me how > to calculate the jitter with my data? Can you tell me some articles or > tutorials about the calculation that a time-nut usually use? I want to > learn stuffs. :) > > Thanks. > > 2014-12-29 21:58 GMT+08:00 Magnus Danielson <magnus@rubidium.dyndns.org>: > >> Hi, >> >> Darn, not reading all the notes. Again. >> >> Well, in that case, scaling should be done... then you get average of >> 198,5075 ns and 149,8 ps RMS jitter, with 1,1 ns peak-to-peak. >> >> The jitter is okish then, but a little better would indeed be nice. >> >> Cheers, >> Magnus >> >> >> On 12/29/2014 01:55 PM, Li Ang wrote: >> >>> Hi Magnus, >>> The unit of these data is not ns but reference clock cycles (100ns). >>> TDC_GP22 measures the time between the edge of tdc_start and >>> tdc_stop1, then it measures the reference clock automaticly. The result >>> you >>> get from it is the ratio of them. >>> >>> 2014-12-29 19:58 GMT+08:00 Magnus Danielson <magnus@rubidium.dyndns.org>: >>> >>> Hi, >>>> >>>> Some quick statistic-processing. >>>> >>>> Histogram of your data: >>>> 1.979 0 >>>> 1.980 2 >>>> 1.981 46 >>>> 1.982 173 >>>> 1.983 523 >>>> 1.984 1031 >>>> 1.985 1301 >>>> 1.986 1131 >>>> 1.987 648 >>>> 1.988 236 >>>> 1.989 8 >>>> 1.990 1 >>>> 1.991 0 >>>> >>>> The total sample count is 5100 (wc -l only gives 5099 since there is a >>>> missing end of line, but word count is 5100). >>>> >>>> The average is about 1,985075 ns and it is reasonably gaussian, but with >>>> some systematics, notice how the slope is more abrupt on the higher end >>>> than the lower end. A quick and dirty spreadsheet gives me about 2,243 ps >>>> RMS jitter, which isn't all that bad. Yes, it will spread out to that 11 >>>> ps >>>> peak-to-peak jitter, but it is to be expected. >>>> >>>> It's pretty respectable for a home-built. >>>> >>>> Cheers, >>>> Magnus >>>> >>>> >>>> On 12/28/2014 03:19 PM, Li Ang wrote: >>>> >>>> Hi Bob, >>>>> I did some test according to your suggestions. DUT is a symmetricom >>>>> x72 >>>>> rb oscillator. Also, I've tried signal generator as the DUT. R&S SMY01 >>>>> is >>>>> not as good as HP8662A but that the best I've got. The signal geneator >>>>> is >>>>> also using FE5650 as ref clock. >>>>> >>>>> According to my test with the TDC today, this unit is not producing >>>>> very >>>>> stable data. >>>>> I don't have accurate pulse generator, so this is how I test the >>>>> TDC: >>>>> 0) power the board with battery. >>>>> 1) use FPGA to generate time pulse: >>>>> reg [15:0] shift; >>>>> always @(posedge refclk10M) begin >>>>> shift <= {shift[14:0], sw_gate}; >>>>> end >>>>> assign tdc_start = shift[3]; >>>>> assign tdc_stop1 = shift[5]; >>>>> >>>>> 2) use MCU to pull down sw_gate, the FPGA sync it to refclk10M domain >>>>> and >>>>> generate input signal for TDC. >>>>> >>>>> 3) use TDC to test the time betwen tdc_start and tdc_stop1 >>>>> >>>>> The result is in tdc_test.zip. number * 100ns = time between tdc_start >>>>> and >>>>> tdc_stop1. (TDC highspeed clock is refclk10M/2). >>>>> >>>>> There 2 issues from the test: >>>>> 1) As we can see from the data, the number is around 1.98x not 2.00x. So >>>>> there is about 2ns delay between tdc_start and tdc_stop1 for this simple >>>>> test code. If it is from the PCB trace and something inside FPGA, this >>>>> part >>>>> should be a constant value at certain temperature. I can calculate it by >>>>> measuring 2 cycles and 3 cylces. My current code has not implement this >>>>> part, it should provide some improvement. 2ns time error for 1s gate, >>>>> that >>>>> is something. >>>>> 2) For a 90ps TDC, I think the result should be something like +-0.001 >>>>> cycle. But I get something like +-0.003 cycle. I do not know the reason >>>>> for >>>>> now. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2014-12-27 22:58 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >>>>> >>>>> Hi >>>>> >>>>>> >>>>>> (In reply to several posts. It’s easier for me this way) >>>>>> >>>>>> Ok, that’s good news !!! (and useful data) >>>>>> >>>>>> Your counter performance degraded a bit when you put in 5 db and not >>>>>> much >>>>>> when you put in 8 db. >>>>>> >>>>>> It’s also maybe *too* good news. I suspect that cross talk between the >>>>>> channels may be impacting your results. >>>>>> >>>>>> Next step is to try it with two independent sources and a bit more >>>>>> attenuation. When you try it with two sources, you need to attenuate >>>>>> first >>>>>> one source and then switch the attenuators to the other source. That >>>>>> will >>>>>> help you see if crosstalk from one channel is more of a problem than >>>>>> from >>>>>> the other channel. >>>>>> >>>>>> One parts hint: >>>>>> >>>>>> Cable TV attenuators are much cheaper than their fancy 50 ohm >>>>>> MIniCircuits >>>>>> cousins. They are also something you can pick up down at the corner >>>>>> electronics store. For this sort of testing they are perfectly fine to >>>>>> use. >>>>>> At this point in the testing the mismatch between 75 ohms and 50 ohms >>>>>> is >>>>>> not a big deal. You will need to adapt connectors, but you probably >>>>>> still >>>>>> will save money. >>>>>> >>>>>> ======= >>>>>> >>>>>> Op-amps that have enough bandwidth and performance for a high input >>>>>> impedance counter input are rare items. They also are not cheap. Often >>>>>> they >>>>>> come as some sort of current feedback part with low(er) input >>>>>> impedance. >>>>>> If >>>>>> you want your counter to work to 300 MHz, it should accept a 300 MHz >>>>>> square >>>>>> wave. That might mean passing the third or even the fifth harmonic of >>>>>> the >>>>>> square wave. An input channel with 900 or 1500 MHz bandwidth is quite a >>>>>> challenge. >>>>>> >>>>>> One very simple solution is to just grab a high speed comparator like >>>>>> the >>>>>> one used by Fluke / Pendulum (ADCMP565). Drive it directly with your >>>>>> input >>>>>> or clock. Make it your front end device. That’s not an ideal solution, >>>>>> but >>>>>> it will give you the bandwidth and a reasonable input impedance. It >>>>>> requires messy things like a negative supply or a “fake” ground (so >>>>>> would >>>>>> the op amp). It also has an ECL output that needs to be converted to >>>>>> match >>>>>> your FPGA ( hint: use the clock inputs, they are LVPECL compatible). >>>>>> Driving into the FPGA with a differential signal is probably needed to >>>>>> reduce crosstalk. >>>>>> >>>>>> No matter how you do it, input channels are *not* an easy thing to do >>>>>> properly. Even on commercial counters, they often are easy to fool. >>>>>> Designing one is only the start. Fully testing it is equally complex. >>>>>> >>>>>> ========= >>>>>> >>>>>> Do not underrate your skills in any way. You are doing far more on this >>>>>> project than any of the rest of the list members have done. We have >>>>>> talked >>>>>> and talked forever about these chips. We talk a lot about these ideas. >>>>>> We >>>>>> suggest lots of complex solutions to various possible problems (like >>>>>> the >>>>>> expensive comparator I suggested above). What we almost never do is >>>>>> actually build a counter. If we build something we don’t fully test >>>>>> it. I >>>>>> have never seen any list member share their results the way you have. I >>>>>> suspect that most of us (yes this includes me) are a bit to scared of >>>>>> the >>>>>> response. >>>>>> >>>>>> Please do not stop your work. Keep letting us know how it is going. >>>>>> This >>>>>> is very exciting !!! >>>>>> >>>>>> Bob >>>>>> >>>>>> On Dec 27, 2014, at 8:22 AM, Li Ang <lllaaa@gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> Hi Bob, >>>>>>> Here is the data and test scheme. >>>>>>> It does not show much difference. >>>>>>> >>>>>>> 2014-12-26 22:12 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>> time-nuts mailing list -- time-nuts@febo.com >>>>>> To unsubscribe, go to >>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>>>> and follow the instructions there. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> time-nuts mailing list -- time-nuts@febo.com >>>>>> To unsubscribe, go to https://www.febo.com/cgi-bin/ >>>>>> mailman/listinfo/time-nuts >>>>>> and follow the instructions there. >>>>>> >>>>>> _______________________________________________ >>>>> >>>> time-nuts mailing list -- time-nuts@febo.com >>>> To unsubscribe, go to https://www.febo.com/cgi-bin/ >>>> mailman/listinfo/time-nuts >>>> and follow the instructions there. >>>> >>>> _______________________________________________ >>> time-nuts mailing list -- time-nuts@febo.com >>> To unsubscribe, go to https://www.febo.com/cgi-bin/ >>> mailman/listinfo/time-nuts >>> and follow the instructions there. >>> >>> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/ >> mailman/listinfo/time-nuts >> and follow the instructions there. >> > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. >

  The unit of these data is not ns but reference clock cycles

   I did some test according to your suggestions. DUT is a

   According to my test with the TDC today, this unit is not

Hi

On Dec 27, 2014, at 8:22 AM, Li Ang <lllaaa@gmail.com> wrote:

Hi Magnus Thanks for the detailed information. btw, I've found an easier way to get histogram : sort tdc_test.txt | uniq -c 2014-12-31 23:37 GMT+08:00 Magnus Danielson <magnus@rubidium.dyndns.org>: > Hi, > > First I did a statistical histogram simply by counting how many times a > particular delay measure occurred, thus creating "bins" of occurrence count > for each value. I did this by doing > > grep 1.987 tdc_test.txt | wc -l > 648 > > So, the 1.987 bin has a count of 648. > I sent you the full histogram in the first reply. > > Then, I calculated the average delay by multiply each delay with the count > of that delay, and then add these products to a sum, and divide by the > total count (5100). > > Using this average, I then subtract that for the measure of each bin, thus > getting the distance from the average. This difference is then squared, and > multiplied with the count for it's bin-count. Again this is being summed, > divided by the total count minus 1 (5099) to produce the variance, and > square root produces the standard deviation. > > So far, it relative simple operations. > > These operations could be done directly on the sample-set, but the > histogram is also good in that you can now see if it is unbalanced. > > One analysis you can do is to analyse how well the histogram matches up > the expected Gaussian distribution bell for the noise you have. This can be > done in several ways, but for a coarse set of bins like this, I think the > best is to generate a matching Gaussian bin count from the bin positions, > average and deviation. The difference with the actual bin count will then > illustrate any major deviations. The trained eye will see deviation in the > histogram anyway. However, to do this requires the erfc. > > Hope this have shown you enough of the "magic". But to assist you further, > please find a spread-sheet of it attached. > > Notice that I scaled the values by 100 ns before further processing. > > Cheers, > Magnus > > > On 12/31/2014 01:03 PM, Li Ang wrote: > >> Hi Magnus, >> I'm not familar with error analysis and statistics, can you tell me >> how >> to calculate the jitter with my data? Can you tell me some articles or >> tutorials about the calculation that a time-nut usually use? I want to >> learn stuffs. :) >> >> Thanks. >> >> 2014-12-29 21:58 GMT+08:00 Magnus Danielson <magnus@rubidium.dyndns.org>: >> >> Hi, >>> >>> Darn, not reading all the notes. Again. >>> >>> Well, in that case, scaling should be done... then you get average of >>> 198,5075 ns and 149,8 ps RMS jitter, with 1,1 ns peak-to-peak. >>> >>> The jitter is okish then, but a little better would indeed be nice. >>> >>> Cheers, >>> Magnus >>> >>> >>> On 12/29/2014 01:55 PM, Li Ang wrote: >>> >>> Hi Magnus, >>>> The unit of these data is not ns but reference clock cycles >>>> (100ns). >>>> TDC_GP22 measures the time between the edge of tdc_start and >>>> tdc_stop1, then it measures the reference clock automaticly. The result >>>> you >>>> get from it is the ratio of them. >>>> >>>> 2014-12-29 19:58 GMT+08:00 Magnus Danielson <magnus@rubidium.dyndns.org >>>> >: >>>> >>>> Hi, >>>> >>>>> >>>>> Some quick statistic-processing. >>>>> >>>>> Histogram of your data: >>>>> 1.979 0 >>>>> 1.980 2 >>>>> 1.981 46 >>>>> 1.982 173 >>>>> 1.983 523 >>>>> 1.984 1031 >>>>> 1.985 1301 >>>>> 1.986 1131 >>>>> 1.987 648 >>>>> 1.988 236 >>>>> 1.989 8 >>>>> 1.990 1 >>>>> 1.991 0 >>>>> >>>>> The total sample count is 5100 (wc -l only gives 5099 since there is a >>>>> missing end of line, but word count is 5100). >>>>> >>>>> The average is about 1,985075 ns and it is reasonably gaussian, but >>>>> with >>>>> some systematics, notice how the slope is more abrupt on the higher end >>>>> than the lower end. A quick and dirty spreadsheet gives me about 2,243 >>>>> ps >>>>> RMS jitter, which isn't all that bad. Yes, it will spread out to that >>>>> 11 >>>>> ps >>>>> peak-to-peak jitter, but it is to be expected. >>>>> >>>>> It's pretty respectable for a home-built. >>>>> >>>>> Cheers, >>>>> Magnus >>>>> >>>>> >>>>> On 12/28/2014 03:19 PM, Li Ang wrote: >>>>> >>>>> Hi Bob, >>>>> >>>>>> I did some test according to your suggestions. DUT is a >>>>>> symmetricom >>>>>> x72 >>>>>> rb oscillator. Also, I've tried signal generator as the DUT. R&S SMY01 >>>>>> is >>>>>> not as good as HP8662A but that the best I've got. The signal geneator >>>>>> is >>>>>> also using FE5650 as ref clock. >>>>>> >>>>>> According to my test with the TDC today, this unit is not >>>>>> producing >>>>>> very >>>>>> stable data. >>>>>> I don't have accurate pulse generator, so this is how I test the >>>>>> TDC: >>>>>> 0) power the board with battery. >>>>>> 1) use FPGA to generate time pulse: >>>>>> reg [15:0] shift; >>>>>> always @(posedge refclk10M) begin >>>>>> shift <= {shift[14:0], sw_gate}; >>>>>> end >>>>>> assign tdc_start = shift[3]; >>>>>> assign tdc_stop1 = shift[5]; >>>>>> >>>>>> 2) use MCU to pull down sw_gate, the FPGA sync it to refclk10M domain >>>>>> and >>>>>> generate input signal for TDC. >>>>>> >>>>>> 3) use TDC to test the time betwen tdc_start and tdc_stop1 >>>>>> >>>>>> The result is in tdc_test.zip. number * 100ns = time between tdc_start >>>>>> and >>>>>> tdc_stop1. (TDC highspeed clock is refclk10M/2). >>>>>> >>>>>> There 2 issues from the test: >>>>>> 1) As we can see from the data, the number is around 1.98x not 2.00x. >>>>>> So >>>>>> there is about 2ns delay between tdc_start and tdc_stop1 for this >>>>>> simple >>>>>> test code. If it is from the PCB trace and something inside FPGA, this >>>>>> part >>>>>> should be a constant value at certain temperature. I can calculate it >>>>>> by >>>>>> measuring 2 cycles and 3 cylces. My current code has not implement >>>>>> this >>>>>> part, it should provide some improvement. 2ns time error for 1s gate, >>>>>> that >>>>>> is something. >>>>>> 2) For a 90ps TDC, I think the result should be something like +-0.001 >>>>>> cycle. But I get something like +-0.003 cycle. I do not know the >>>>>> reason >>>>>> for >>>>>> now. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2014-12-27 22:58 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >>>>>> >>>>>> Hi >>>>>> >>>>>> >>>>>>> (In reply to several posts. It’s easier for me this way) >>>>>>> >>>>>>> Ok, that’s good news !!! (and useful data) >>>>>>> >>>>>>> Your counter performance degraded a bit when you put in 5 db and not >>>>>>> much >>>>>>> when you put in 8 db. >>>>>>> >>>>>>> It’s also maybe *too* good news. I suspect that cross talk between >>>>>>> the >>>>>>> channels may be impacting your results. >>>>>>> >>>>>>> Next step is to try it with two independent sources and a bit more >>>>>>> attenuation. When you try it with two sources, you need to attenuate >>>>>>> first >>>>>>> one source and then switch the attenuators to the other source. That >>>>>>> will >>>>>>> help you see if crosstalk from one channel is more of a problem than >>>>>>> from >>>>>>> the other channel. >>>>>>> >>>>>>> One parts hint: >>>>>>> >>>>>>> Cable TV attenuators are much cheaper than their fancy 50 ohm >>>>>>> MIniCircuits >>>>>>> cousins. They are also something you can pick up down at the corner >>>>>>> electronics store. For this sort of testing they are perfectly fine >>>>>>> to >>>>>>> use. >>>>>>> At this point in the testing the mismatch between 75 ohms and 50 ohms >>>>>>> is >>>>>>> not a big deal. You will need to adapt connectors, but you probably >>>>>>> still >>>>>>> will save money. >>>>>>> >>>>>>> ======= >>>>>>> >>>>>>> Op-amps that have enough bandwidth and performance for a high input >>>>>>> impedance counter input are rare items. They also are not cheap. >>>>>>> Often >>>>>>> they >>>>>>> come as some sort of current feedback part with low(er) input >>>>>>> impedance. >>>>>>> If >>>>>>> you want your counter to work to 300 MHz, it should accept a 300 MHz >>>>>>> square >>>>>>> wave. That might mean passing the third or even the fifth harmonic of >>>>>>> the >>>>>>> square wave. An input channel with 900 or 1500 MHz bandwidth is >>>>>>> quite a >>>>>>> challenge. >>>>>>> >>>>>>> One very simple solution is to just grab a high speed comparator like >>>>>>> the >>>>>>> one used by Fluke / Pendulum (ADCMP565). Drive it directly with your >>>>>>> input >>>>>>> or clock. Make it your front end device. That’s not an ideal >>>>>>> solution, >>>>>>> but >>>>>>> it will give you the bandwidth and a reasonable input impedance. It >>>>>>> requires messy things like a negative supply or a “fake” ground (so >>>>>>> would >>>>>>> the op amp). It also has an ECL output that needs to be converted to >>>>>>> match >>>>>>> your FPGA ( hint: use the clock inputs, they are LVPECL compatible). >>>>>>> Driving into the FPGA with a differential signal is probably needed >>>>>>> to >>>>>>> reduce crosstalk. >>>>>>> >>>>>>> No matter how you do it, input channels are *not* an easy thing to do >>>>>>> properly. Even on commercial counters, they often are easy to fool. >>>>>>> Designing one is only the start. Fully testing it is equally complex. >>>>>>> >>>>>>> ========= >>>>>>> >>>>>>> Do not underrate your skills in any way. You are doing far more on >>>>>>> this >>>>>>> project than any of the rest of the list members have done. We have >>>>>>> talked >>>>>>> and talked forever about these chips. We talk a lot about these >>>>>>> ideas. >>>>>>> We >>>>>>> suggest lots of complex solutions to various possible problems (like >>>>>>> the >>>>>>> expensive comparator I suggested above). What we almost never do is >>>>>>> actually build a counter. If we build something we don’t fully test >>>>>>> it. I >>>>>>> have never seen any list member share their results the way you >>>>>>> have. I >>>>>>> suspect that most of us (yes this includes me) are a bit to scared of >>>>>>> the >>>>>>> response. >>>>>>> >>>>>>> Please do not stop your work. Keep letting us know how it is going. >>>>>>> This >>>>>>> is very exciting !!! >>>>>>> >>>>>>> Bob >>>>>>> >>>>>>> On Dec 27, 2014, at 8:22 AM, Li Ang <lllaaa@gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>>> Hi Bob, >>>>>>>> Here is the data and test scheme. >>>>>>>> It does not show much difference. >>>>>>>> >>>>>>>> 2014-12-26 22:12 GMT+08:00 Bob Camp <kb8tq@n1k.org>: >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> >>>>>>> time-nuts mailing list -- time-nuts@febo.com >>>>>>> To unsubscribe, go to >>>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>>>>> and follow the instructions there. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> time-nuts mailing list -- time-nuts@febo.com >>>>>>> To unsubscribe, go to https://www.febo.com/cgi-bin/ >>>>>>> mailman/listinfo/time-nuts >>>>>>> and follow the instructions there. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>> >>>>>> time-nuts mailing list -- time-nuts@febo.com >>>>> To unsubscribe, go to https://www.febo.com/cgi-bin/ >>>>> mailman/listinfo/time-nuts >>>>> and follow the instructions there. >>>>> >>>>> _______________________________________________ >>>>> >>>> time-nuts mailing list -- time-nuts@febo.com >>>> To unsubscribe, go to https://www.febo.com/cgi-bin/ >>>> mailman/listinfo/time-nuts >>>> and follow the instructions there. >>>> >>>> _______________________________________________ >>>> >>> time-nuts mailing list -- time-nuts@febo.com >>> To unsubscribe, go to https://www.febo.com/cgi-bin/ >>> mailman/listinfo/time-nuts >>> and follow the instructions there. >>> >>> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/ >> mailman/listinfo/time-nuts >> and follow the instructions there. >> >> > _______________________________________________ > 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. >