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

Bob Camp kb8tq at n1k.org
Sat Oct 11 20:11:57 UTC 2014


Hi

Your glitches are (in part) coming from the 20 MHz (10 + 10) component on the mixed signal. Since they have no direct relation to the beat note, filtering them after limiting is not a simple task. It is far easier to keep filter the signal pre-limit than to do so post limit.

The other component of the glitches is related to the limiting process. The paper by Collins is a good one to read for information on gain, bandwidth and the limiting process. Again, there is very little you can do “post limit” to sort things out.  None of the zero crossings you are getting may be “correct”. It’s not simply a process of picking one out of the group. 

——————

Some math:

You have two 10 MHz signals and a (say) 10 Hz beat note. You are looking for 1x10^-13. You get 1x10^-6 from the downconversion. You need to get 1x10^-7 out of the beat note. 

Put another way, 1x10^-13 at 10 MHz is 1x10^-5 Hz. 

If your beat note is 3 V p-p, it will cover 6V every 1/10 second. It’s about 1.2X faster than a triangle wave as it zero crosses (memory may be failing me here), so that makes it equal to a 7.2V triangle excursion. 

1x10^-6 of 7.2V is 7.2 microvolts. 

That’s how accurate your limiter / filter combination needs to be, pre-limiting. 

It can be in a fairly narrow bandwidth, so it’s not quite as daunting as a radio front end.

Since you have a very large signal, and very small noise, the normal “dithering will help me” effect of the noise can not be counted on. 

The thing you *want* to come up with is essentially a random signal (ADEV), so massive filtering will not do the trick either. 

Bob
 
On Oct 11, 2014, at 3:33 PM, Robert Darby <bobdarby at triad.rr.com> wrote:

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