[time-nuts] Digital Mixing with a BeagleBone Black and D Flip Flop
EWKehren at aol.com
EWKehren at aol.com
Sat Oct 11 15:10:19 EDT 2014
Bob we are using digital mixers in some other applications but what
surprised me is your comment on the Riley DMTD. We have a couple of slightly
modified Riley's and see any where from 1.44 to 3.84 E-14 at 1 second. Bill also
sows data below 1 E-13 at 1 second. Presently looking at braking the 1
E-14 level at the same time reducing cost.
In a message dated 10/9/2014 9:01:24 P.M. Eastern Daylight Time,
bobdarby at triad.rr.com writes:
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>
>> I've been a lurker on time-nuts for a while, most of the discussion
>> 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
>> 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
>> simple as possible (and not require an FPGA).
>> The hardware side is just a 74AC74 dual flip flop to sample the input
>> 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
>> 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
>> 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
>> 126.96.36.199.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
>> The PRU is plenty fast enough to capture samples @10mhz and, in theory
>> least, each PRU could sample up to 16 clocks simultaneously (depending
>> whether the relevant GPIO pins were free).
>> Once the sampling is complete, the ARM core can process the results in
>> own time, and this includes any more complicated algorithms for
>> The theoretical minimum time resolution depends on the beat frequency
>> described in the article, for example with a beat frequency of 50 hz the
>> minimum resolution is 50 / (10000000 - 50)*10000000 = ~5E-13. In
>> the available accuracy is determined by the stability of the mixer
>> noise of the setup. The impact of this noise is described in the
>> 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
>> theoretical limit quite yet :)
>> Note that the BBB itself has no impact on the accuracy or noise of the
>> data. Once the input is latched at the flip-flop, the only bit of
>> timing required is to ensure that samples can be captured fast enough
>> 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
>> 1) Get off the breadboard and focus a bit more on getting the signals
>> flip-flop with a 'reasonable' amount of noise.
>> 2) Improve the PRU code so that it stores transitions and not just the
>> 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
>> current one shot approach).
>> 3) Experimentation with different algorithms for processing the data on
>> I don't think anyone has posted a similar set up, so any feedback on
>> 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
>> be too difficult to reproduce if someone wants to, but again please
>> 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
> and follow the instructions there.
time-nuts mailing list -- time-nuts at febo.com
To unsubscribe, go to
and follow the instructions there.
More information about the time-nuts