Magnus Danielson wrote:
On 12/28/2010 01:37 AM, John Miles wrote:
What GPIB data rate did you actually get for the 10 kHz trace?
When JohnM ran the same test on my 2070C it was closer to
0.74 s instead of 1.0 s. I'm wondering if you found a way to
get your DTS pacing more accurately.
Note that Magnus is running a very different test -- I was selecting 10K
averages with 10 MHz on both inputs and letting the counter's ~0.7-sec
processing overhead determine the tau0 interval, whereas he is feeding a
lower rate to the START channel so that the counter will average samples
taken at regular intervals within the tau0 period.
Actually, I ended up feeding a 10 kHz signal into the ARM1 input and
then let the 5 MHz sines hit the Ch1 and Ch2 inputs.
The 5 MHz + 7 dBm sine signal has a limited slew-rate, so this puts
some extra stress on the inputs compared to a slew-rate optimized
signal. However, all the involved counters gets the same signal.
I found that a +13dBm signal gives far lower trigger jitter in my 5370A,
even the effect of attenuating the input by 3dB is very noticeable.
Either add a buffer amp with a gain of about 6dB or use a pair of
2N3904s configured as an LTP diffamp with a gain of about 10 to
increase the input slew rate.
There appears to be no way to get the counter to average a burst of
successive samples between arming intervals, which is really what you
want.
Instead of arming measurement blocks (which the HP5372A can) you arm
each individual measurement. For this to be really useful you need an
arming controller.
The DTS 2070C can do 15000 samples per second. This is comparable to
the HP5372A, but in the high performance mode the HP5372A can do
measurements only 75 ns away while normal performance take 100 ns. The
time-saving done is about avoiding storing away the upper part of
counters into the 8192 long event memory.
JohnM -- is there a linear trend
removal option to TimeLab that works on the freq series just like
works on the time (phase) series?
Should be there.
Indirectly. If you want to flatten the frequency trace, you can
remove the
quadratic trend from the phase trace with ctrl-q.
A peculiar effect is that to make good readings for low-tau values I
need to trim the oscillators to be very near each other. Otherwise
there will be a polution of the lower taus compared to my selected
good plots. This polution and the slope is insensitive to any drift
rate compensation, so Hadamard analysis does not help.
This is likely caused by phase wrapping, which is incompatible with
averaging. The counter can't average readings like 96 97 98 99 ...
01 02 ns
and come out with anything meaningful. You'll have to use sample
size=1 if
your sources are likely to phase-wrap during the measurement.
Hmm. True. My reasoning to trim the oscillators close was to avoid
phase wrapping.
If I only could get the TS-105A to output data on the serial port as I
would expect it to do, it would be nice to be able to use that one as
a TimeLab source too. :)
Cheers,
Magnus
Bruce
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
