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