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
On 10/9/2014 1:34 AM, Andrew Rodland wrote:
Simon,
This is a fantastic idea and I have every intention of trying to
replicate it at home with tools on hand. Thanks for sharing, and I
hope you can show off some results.
On Wed, Oct 8, 2014 at 1:09 PM, Simon Marsh <subscripti...@burble.com> wrote:
I've been a lurker on time-nuts for a while, most of the discussion being
way over my head, but I thought there may be interest in some proof of
concept code I've written for simple digital hetrodyne mixing using just a
BeagleBone Black and an external dual D Flip Flop.
The idea is based on the following article which describes creating a
digital DMTD with an FPGA for clocks @ 125mhz:
http://www.ee.ucl.ac.uk/lcs/previous/LCS2011/LCS1136.pdf
My setup follows the same principle, but scaled down to 10mhz to make it as
simple as possible (and not require an FPGA).
The hardware side is just a 74AC74 dual flip flop to sample the input clocks
being tested. Instead of having a helper PLL for the mixer frequency, I
simply have a 3rd, de-tuned oscillator. The output from the two flip-flops
together with the mixer clock are fed to the BBB.
On the BBB, the approach is to do as little as possible in real time using a
PRU core, and then post-process on the ARM core afterwards.
The BBB PRU has a 16-bit, asynchronous, parallel, capture mode, where 16
GPIO pins can be latched based on an external clock (described in section
4.4.1.2.3.2 of the TRM for those interested). In this case, the external
clock is the mixer oscillator. All the PRU needs to do is wait for the
sample to take place, read the GPIOs and store the results in main memory.
The PRU is plenty fast enough to capture samples @10mhz and, in theory at
least, each PRU could sample up to 16 clocks simultaneously (depending on
whether the relevant GPIO pins were free).
Once the sampling is complete, the ARM core can process the results in its
own time, and this includes any more complicated algorithms for de-glitching
etc
The theoretical minimum time resolution depends on the beat frequency and is
described in the article, for example with a beat frequency of 50 hz the
minimum resolution is 50 / (10000000 - 50)*10000000 = ~5E-13. In practice
the available accuracy is determined by the stability of the mixer clock and
noise of the setup. The impact of this noise is described in the article as
glitching and there are some suggested ways for processing this out. I'm
trying this on an open bench, with basic oscillators, using pluggable
breadboard and lots of hanging wires, I'm not at risk of getting near the
theoretical limit quite yet :)
Note that the BBB itself has no impact on the accuracy or noise of the raw
data. Once the input is latched at the flip-flop, the only bit of critical
timing required is to ensure that samples can be captured fast enough and
that the flip-flop state is captured when it is stable (i.e. not
transitioning).
I make no excuses that this is very simplistic, and there are many, many
ways that it can (should!) be improved. For me the next steps will probably
be:
1) Get off the breadboard and focus a bit more on getting the signals to the
flip-flop with a 'reasonable' amount of noise.
2) Improve the PRU code so that it stores transitions and not just the raw
samples, this would offload a significant bit of work from the ARM core,
save a load of memory and allow continuous streaming of data (instead of the
current one shot approach).
3) Experimentation with different algorithms for processing the data on the
ARM.
I don't think anyone has posted a similar set up, so any feedback on whether
the approach is viable or I'm wasting my time are welcome.
I've posted the code to Google drive for anyone to take a look. It shouldn't
be too difficult to reproduce if someone wants to, but again please remember
it's just 'prove it can be done' code.
https://drive.google.com/open?id=0BzvFGRfj4aFkblAwcWxGNHdCSDg&authuser=0
Cheers
Simon
_______________________________________________
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.
