Simon,
If I can rephrase your first post, you plan to capture the state
transitions along with their timing and subsequently post-process them
to determine the time from one zero-crossing to another. Each
zero-crossing is the sum of number of closely spaced state changes
(glitches) and some algorithm can be used to determine when the "real"
zero-crossing occurred. Given the low speed of the clock, a deep memory
one bit data logger would suffice for each channel. Alternately, you can
store time tags for each state transition; the time being measured in
offset clock cycles.
This reduces the device to an offset clock, analog to digital conversion
for sine wave inputs, at least two d-flops, and the BBB for data capture
and analysis. Correct?
The glitches are to be expected and, as I noted, the absence of them on
the negative to positive transition of my breadboarded set-up made me
suspect the accuracy but also made it easy to get a "back of the
envelop" noise floor number that should only get better, provide the
de-glitch filter is robust.
Just as another thought, an FTDI asynchronous fifo can move 10 MB/s and
a synchronous fifo can move 60 MB/s. You could probably capture the
D-flop outputs directly through a USB port and process the byte wide
stream in real time. But that's what the BBB's going to do in any case.
As I mentioned, I want to try this in an fpga and the filter is the only
hard part there. I'm thinking a state machine that first establishes a
stable low state, time tags the first positive transition and then looks
for some number of stable high states. With a time tag at that point,
it's easy to work back to the last positive transition and establish the
mean time. I'm still trying to get my head around how I can do the zero
count filter but hopefully it will come. The reason the fpga is
attractive is because a $40 Papilio includes the D-Flops and is largely
self contained. Add a wing pad with the input conversion and your beat
clock and you're good to go.
bob
On 10/11/2014 11:17 AM, Simon Marsh wrote:
In this case, it seems reasonable that these multiple transitions are
to be expected as there isn't any filtering that takes place in
hardware prior to samples being captured by the BBB. The equivalent of
the filtering/zero crossing detection takes place in software in the
edge detection routine.
Cheers
Simon
On 11/10/2014 15:19, Bob Camp wrote:
Hi
If you are looking at the low frequency beat note out of a mixer and
seeing multiple transitions on an edge - you filtering or your
limiter are not up to the task. In most cases it’s the filter, but it
can be either.
Bob
On Oct 11, 2014, at 9:10 AM, Robert Darby <[email protected]> wrote:
Simon,
Welcome to the tangential world.
I'm sure the clean edge I saw was an aberration, perhaps analogous
to phase locking in oscillators; I don't think it's desirable
because common sense tells you that with imperfect clocks and small
phase differences there are bound to be some number of glitches at
each transition. I did nothing specific to eliminate the glitches,
it just happened that the positive going transition was very clean
but there's no reason I am aware of to suggest that one transition
should be better in this respect than another. Perhaps the flip flop
I was using had a shorter set-up time on negative to positive
transitions than vice versa; the smaller the set-up time the more
likely one is to capture borderline events?
I seem to recall that Didier Juges and Bruce Griffiths had some
discussions re DDMTD's (although I can't find it in the archives)
but in any event you could do far worse than dropping them a note
directly to ask them about their thoughts on the matter. I'm sorry I
can't provide any analysis of your data; just not in my skill set.
Perhaps Marcus or TVB could comment.
Bob Darby
On 10/10/2014 3:46 PM, Simon Marsh wrote:
Bob,
It's good to know someone else is trying this and it's not just me
going off on a tangent somewhere. I'd be very interested in
understanding how you'd set this up and how you'd got a nice clean
rising edge.
My understanding is that the 'glitches' occur because the clocks
are being sampled at a higher resolution than the cycle to cycle
noise inherent in both the clocks and the setup. Certainly, I don't
expect any of the oscillators I have available to be perfectly
stable at ~1E-12 resolution, I'm sure they are all over the place
The clock phase noise shows up as fast transitions near the actual
beat edge as the clocks wander backwards and forwards over a few
cycles. I'm sure analysis of the glitches themselves would probably
say quite a lot about the cycle to cycle noise.
I've attached an example of the transitions near an edge for a
random TCXO. The edge goes from 0 at the start to 1 at the end and
shows noise over about 180 samples (@10mhz). This corresponds to
about ± 5E-11. The crossing line of the zero & one counts is where
the edge is measured from the software point of view. ± 50ps
sounds high to me, but I'm open to views as to whether that seems
reasonable or just shows my shoddy setup ?
For fun, also attached is plot of the transitions for a UBLOX8 GPS
module outputing 10mhz. Compared to the TCXO that has about 10k
transitions in a second's worth of data, the UBLOX module has over
1.3M (this is with a beat frequency of ~60hz). I think this is down
to how the gps module is inserting/removing cycles to get 10mhz
from its internal clock frequency (as has been discussed on here
recently).
Unfortunately, I don't have any expensive counters, that's part of
my motivation for doing this, so I'm interested in ways that I can
understand the noise floor.
I tried passing one clock through a 74AC hex inverter and then
measuring the phase between the inverted/non-inverted signals on
the basis that this should be more or less constant and what I'd be
measuring was noise. It's certainly a good way of measuring how
long the wire was that I used to make the connection This seems
to yield an ADEV of 5.92E-11 @ 1 sec, plots also attached.
Interestingly the phase seems to drift over the measurement
interval, I'm open to suggestions on this, but guess this may be
temperature related ? (open on bench, non-airconditioned etc)
If the plots don't come through as attached, they are also on
google drive here:
https://drive.google.com/open?id=0BzvFGRfj4aFkSEdYV3lXcmZIVTA&authuser=0
Cheers
Simon
On 10/10/2014 02:01, Robert Darby wrote:
Simon,
I breadboaded a set-up in March using 74AC74's and two 10 MHz
Micro Crystal oscillators (5V square wave), one as the coherent
source and one as the 10Hz offset clock. I had no glitch filtering
as described in the article you cite (CERN's White Rabbit Project,
sub nanosecond timing over ethernet) but found the positive zero
crossing was very clean. The negative crossing not so much; no
idea why one edge was clean and the other not. To ensure I only
measured the rising clock edge and not the noise on the falling
clock, I programmed ATiny's (digital 555?) to arm the D-flops only
after a period of continuous low states.
In any event, the lash up, as measure by a 5370, produced a clean
linear noise floor of 8e-12 at 1s. I regret to note that's very
slightly better than my results from the Bill Riley DMTD device.
That's an indictment of my analog building skills, not his
design. It's also nicely below a 5370 on it's own and needs only
a simple 10 MHz counter for output. The zero crossing detectors
for sine wave oscillator input will perhaps be more critical.
This was encouraging enough that I thought I'd try to build an
FPGA version of the same. The DDMTD is temporarily on back burner
while I try to get a four channel 1ns resolution time tagger
running on the FPGA to use with the DMTD. Almost there. I look
forward to hearing your results with the BBB; keep us posted.
Bob Darby
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
