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

Robert Darby bobdarby at triad.rr.com
Sat Oct 11 15:23:19 EDT 2014

Yeah, breaks my heart but I'm not real good (try real bad) at 
troubleshooting electronics (so why am i here?).

As I noted in my earlier post, the issue lies in my construction and 
lack of knowledge re electronic fundamentals. I have the greatest 
respect for Mr. Riley and I do not want my ineptitude to in any way 
reflect on his design.  All problems with my DMTD are of my making, not his.


On 10/11/2014 3:10 PM, Bert Kehren via time-nuts wrote:
> 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
>>> 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.
> _______________________________________________
> 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 mailing list