[time-nuts] Digital Mixing with a BeagleBone Black and D Flip Flop

EWKehren at aol.com EWKehren at aol.com
Sat Oct 11 19:10:19 UTC 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.
Bert Kehren.
 
 
In a message dated 10/9/2014 9:01:24 P.M. Eastern Daylight Time,  
bobdarby at triad.rr.com writes:

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  <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:
>>
>>  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 at 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 at 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 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_lists.febo.com mailing list