[time-nuts] Digital Mixing with a BeagleBone Black and D Flip Flop
subscriptions at burble.com
Sat Oct 11 18:06:11 EDT 2014
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
> 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
Interesting idea, but yes again, this is what I have the PRU on the BBB
> 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.
More information about the time-nuts