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,
bobda...@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 <subscripti...@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@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@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@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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
