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.