[time-nuts] Digital Mixing with a BeagleBone Black and D Flip Flop
bobdarby at triad.rr.com
Thu Oct 9 21:01:06 EDT 2014
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
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.
On 10/9/2014 1:34 AM, Andrew Rodland wrote:
> 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 <subscriptions at 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:
>> 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
>> 188.8.131.52.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
>> 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
>> 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
>> 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
>> 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.
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> and follow the instructions there.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts