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

[Simon Marsh]

On 11/10/2014 20:33, Robert Darby wrote:
> If I can rephrase your first post, you plan to capture the state 
> transitions along with their timing and subsequently post-process them 
> to determine the time from one zero-crossing to another. Each 
> zero-crossing is the sum of number of closely spaced state changes 
> (glitches) and some algorithm can be used to determine when the "real" 
> zero-crossing occurred.  Given the low speed of the clock, a deep 
> memory one bit data logger would suffice for each channel. 
> Alternately, you can store time tags for each state transition; the 
> time being measured in offset clock cycles.

Spot on, and indeed, the code I posted uses the one bit data logger 
idea. I intend to replace with time tagging to save some memory, save 
some ARM CPU time and enabling continuous logging.

> This reduces the device to an offset clock, analog to digital 
> conversion for sine wave inputs, at least two d-flops, and the BBB for 
> data capture and analysis. Correct?

Yes, exactly. Of course, it also needs a bunch of software to do the 
processing.

> Just as another thought, an FTDI asynchronous fifo can move 10 MB/s 
> and a synchronous fifo can move 60 MB/s. You could probably capture 
> the D-flop outputs directly through a USB port and process the byte 
> wide stream in real time. But that's what the BBB's going to do in any 
> case.

Interesting idea, but yes again, this is what I have the PRU on the BBB 
doing.

> As I mentioned, I want to try this in an fpga and the filter is the 
> only hard part there.   I'm thinking a state machine that first 
> establishes a stable low state, time tags the first positive 
> transition and then looks for some number of stable high states. With 
> a time tag at that point, it's easy to work back to the last positive 
> transition and establish the mean time.  I'm still trying to get my 
> head around how I can do the zero count filter but hopefully it will 
> come.  The reason the fpga is attractive is because a $40 Papilio 
> includes the D-Flops and is largely self contained.  Add a wing pad 
> with the input conversion and your beat clock and you're good to go.

I have a Papilio around somewhere too, but admit I find it easier 
messing around in software. Are you intending to output time stamped 
edges (or phase ?) from FPGA and then log/post-process somewhere else ?

I used the zero count method, but no doubt this was easier in C than it 
will be on an FPGA. The paper I linked to has some discussion on a few 
algorithms, and they think the zero count is better than a mean. I'm not 
one to argue with clever folks at CERN, but I think it will be 
interesting to see if I can get to the point of showing if there is 
actually a difference at my scale, or even whether there are some 
smarter approaches when having the luxury of implementing in software.

All I did was identify the first transition after a stable period and 
then count ones and zeros until ones > zeros. The only gotcha is that 
(by definition) the first transition after a bunch of zeros will always 
be a one so you have to make sure you count the next set of zeros before 
checking if ones > zeros (otherwise, of course, ones will always be > 
zero on the first transition). This also means you need to have a limit 
built in for when there are no glitches (i.e. no zeros arrive before you 
determine the number of ones means you are in a new stable period).

I'd be very interested at what you intend to do for the input 
conversion. Getting the signal squared up and delivered to the D-flop 
would seem to the hard part and where all the noise will be. Once you 
have a digital signal at the flip flop its downhill all the way.

>
> bob
>
[snipped]

Cheers


Simon