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

Sat Oct 11 19:33:06 UTC 2014

Simon,

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.

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?

The glitches are to be expected and, as I noted, the absence of them on 
the negative to positive transition of my breadboarded set-up made me 
suspect the accuracy but also made it easy to get a "back of the 
envelop" noise floor number that should only get better, provide the 
de-glitch filter is robust.

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.

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.

bob

On 10/11/2014 11:17 AM, Simon Marsh wrote:
> In this case, it seems reasonable that these multiple transitions are 
> to be expected as there isn't any filtering that takes place in 
> hardware prior to samples being captured by the BBB. The equivalent of 
> the filtering/zero crossing detection takes place in software in the 
> edge detection routine.
>
> Cheers
>
>
> Simon
>
>
> On 11/10/2014 15:19, Bob Camp wrote:
>> Hi
>>
>> If you are looking at the low frequency beat note out of a mixer and 
>> seeing multiple transitions on an edge - you filtering or your 
>> limiter are not up to the task. In most cases it’s the filter, but it 
>> can be either.
>>
>> Bob
>>
>> On Oct 11, 2014, at 9:10 AM, Robert Darby <bobdarby at triad.rr.com> wrote:
>>
>>> Simon,
>>>
>>> Welcome to the tangential world.
>>>
>>> I'm sure the clean edge I saw was an aberration, perhaps analogous 
>>> to phase locking in oscillators; I don't think it's desirable 
>>> because common sense tells you that with imperfect clocks and small 
>>> phase differences there are bound to be some number of glitches at 
>>> each transition.  I did nothing specific to eliminate the glitches, 
>>> it just happened that the positive going transition was very clean 
>>> but there's no reason I am aware of to suggest that one transition 
>>> should be better in this respect than another. Perhaps the flip flop 
>>> I was using had a shorter set-up time on negative to positive 
>>> transitions than vice versa; the smaller the set-up time the more 
>>> likely one is to capture borderline events?
>>>
>>> I seem to recall that Didier Juges and Bruce Griffiths had some 
>>> discussions re DDMTD's (although I can't find it in the archives) 
>>> but in any event you could do far worse than dropping them a note 
>>> directly to ask them about their thoughts on the matter. I'm sorry I 
>>> can't provide any analysis of your data; just not in my skill set.
>>> Perhaps Marcus or TVB could comment.
>>>
>>> Bob Darby
>>>
>>> On 10/10/2014 3:46 PM, Simon Marsh wrote:
>>>> Bob,
>>>>
>>>> It's good to know someone else is trying this and it's not just me 
>>>> going off on a tangent somewhere. I'd be very interested in 
>>>> understanding how you'd set this up and how you'd got a nice clean 
>>>> rising edge.
>>>>
>>>> My understanding is that the 'glitches' occur because the clocks 
>>>> are being sampled at a higher resolution than the cycle to cycle 
>>>> noise inherent in both the clocks and the setup. Certainly, I don't 
>>>> expect any of the oscillators I have available to be perfectly 
>>>> stable at ~1E-12 resolution, I'm sure they are all over the place 
>>>> The clock phase noise shows up as fast transitions near the actual 
>>>> beat edge as the clocks wander backwards and forwards over a few 
>>>> cycles. I'm sure analysis of the glitches themselves would probably 
>>>> say quite a lot about the cycle to cycle noise.
>>>>
>>>> I've attached an example of the transitions near an edge for a 
>>>> random TCXO. The edge goes from 0 at the start to 1 at the end and 
>>>> shows noise over about 180 samples (@10mhz). This corresponds to 
>>>> about ± 5E-11. The crossing line of the zero & one counts is where 
>>>> the edge is measured from the software point of view.  ± 50ps 
>>>> sounds high to me, but I'm open to views as to whether that seems 
>>>> reasonable or just shows my shoddy setup ?
>>>>
>>>> For fun, also attached is plot of the transitions for a UBLOX8 GPS 
>>>> module outputing 10mhz. Compared to the TCXO that has about 10k 
>>>> transitions in a second's worth of data, the UBLOX module has over 
>>>> 1.3M (this is with a beat frequency of ~60hz). I think this is down 
>>>> to how the gps module is inserting/removing cycles to get 10mhz 
>>>> from its internal clock frequency (as has been discussed on here 
>>>> recently).
>>>>
>>>> Unfortunately, I don't have any expensive counters, that's part of 
>>>> my motivation for doing this, so I'm interested in ways that I can 
>>>> understand the noise floor.
>>>>
>>>> I tried passing one clock through a 74AC hex inverter and then 
>>>> measuring the phase between the inverted/non-inverted signals on 
>>>> the basis that this should be more or less constant and what I'd be 
>>>> measuring was noise. It's certainly a good way of measuring how 
>>>> long the wire was that I used to make the connection   This seems 
>>>> to yield an ADEV of 5.92E-11 @ 1 sec, plots also attached.
>>>>
>>>> Interestingly the phase seems to drift over the measurement 
>>>> interval, I'm open to suggestions on this, but guess this may be 
>>>> temperature related ? (open on bench, non-airconditioned etc)
>>>>
>>>> If the plots don't come through as attached, they are also on 
>>>> google drive here:
>>>>
>>>> https://drive.google.com/open?id=0BzvFGRfj4aFkSEdYV3lXcmZIVTA&authuser=0 
>>>>
>>>>
>>>> Cheers
>>>>
>>>>
>>>> Simon
>>>>
>>>> On 10/10/2014 02:01, Robert Darby wrote:
>>>>> Simon,
>>>>>
>>>>> I breadboaded a set-up in March using 74AC74's and two 10 MHz 
>>>>> Micro Crystal oscillators (5V square wave), one as the coherent 
>>>>> source and one as the 10Hz offset clock. I had no glitch filtering 
>>>>> as described in the article you cite (CERN's White Rabbit Project, 
>>>>> sub nanosecond timing over ethernet) but found the positive zero 
>>>>> crossing was very clean.  The negative crossing not so much; no 
>>>>> idea why one edge was clean and the other not. To ensure I only 
>>>>> measured the rising clock edge and not the noise on the falling 
>>>>> clock, I programmed ATiny's (digital 555?) to arm the D-flops only 
>>>>> after a period of continuous low states.
>>>>>
>>>>> In any event, the lash up, as measure by a 5370, produced a clean 
>>>>> linear noise floor of 8e-12 at 1s. I regret to note that's very 
>>>>> slightly better than my results from the Bill Riley DMTD device. 
>>>>> That's an indictment of my analog building skills, not his 
>>>>> design.  It's also nicely below a 5370 on it's own and needs only 
>>>>> a simple 10 MHz counter for output. The zero crossing detectors 
>>>>> for sine wave oscillator input will perhaps be more critical.
>>>>>
>>>>> This was encouraging enough that I thought I'd try to build an 
>>>>> FPGA version of the same. The DDMTD is temporarily on back burner 
>>>>> while I try to get a four channel 1ns resolution time tagger 
>>>>> running on the FPGA to use with the DMTD.  Almost there. I look 
>>>>> forward to hearing your results with the BBB; keep us posted.
>>>>>
>>>>> Bob Darby
>>>>
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts at 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 at 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 at 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 at febo.com
> To unsubscribe, go to 
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>