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

[Simon Marsh]

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