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

Simon Marsh subscriptions at burble.com
Sat Oct 11 15:17:37 UTC 2014


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.




More information about the Time-nuts_lists.febo.com mailing list