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 _______________________________________________ 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.
