[time-nuts] Digital Mixing with a BeagleBone Black and D Flip Flop
Robert Darby
bobdarby at triad.rr.com
Sat Oct 11 19:23:19 UTC 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.
bob
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
>>> 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.
>
> _______________________________________________
> 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