[time-nuts] BeagleBone Black DDMTD update

Bob Camp kb8tq at n1k.org
Wed Oct 29 18:22:05 EDT 2014


Hi

It is not at all unusual for signals to be re-clocked when going into a micro. Often the documentation on this process is somewhere between vague and non-exsistant. 

Bob

> On Oct 29, 2014, at 4:15 PM, Simon Marsh <subscriptions at burble.com> wrote:
> 
> This is a fairly long post, at the top is a bit of description of of changes since my last posts and then around the middle is some description of the data thats attached. The data raises a few questions, and I'll put those in a separate post.
> 
> ---
> 
> In terms of hardware setup, I now have two 74ac14 schmitt triggers, one as a buffer for the reference/sampling clock and one as a buffer for the two test signals. These are followed by two 74ac595 shift registers to do the sampling and the whole thing is soldered on to a BBB proto cape. Whilst the cape isn't perfect, it is better than pluggable breadboard. The good news is that with all those changes I have glitches again, I've never been so happy to see noise :)
> 
> Mr Postman also delivered a nice mv89a and 8663, so these should act as better references. Along with the hardware, the software has been overhauled somewhat, to simplify, make it more modular and speed up some of the analysis.
> 
> The net result of these changes is shown in the attached ADEV plot, which shows the setup measuring a PWM signal from a second BBB and a Micro Crystal OCXO against the mv89a. Note that this isn't with the setup working as a DMTD, but simply using the hardware as two channels measured against the reference independently.
> 
> The ADEV is ok, but not great. In theory, the Micro Crystal OCXO should be good to 5E-11 @ 1s according to the data sheet, so in the OCXO plot, everything to the left of 10s is almost certainly measurement/setup problems rather than the oscillator itself. This shows I still have some work to do.
> 
> I've also included a closer look at the phase data, plotted with 3 simple edge detection algorithms (first edge, last edge and mean edge). Note that you can see visually the difference between first and last edge and this demonstrates the width of the period containing glitches; in this case somewhere around 1.5 - 2ns. Also obvious is that there is some periodicity to the phase data and that the 'last edge' algorithm appears to be a pretty poor choice as it is way noisier than the first edge.
> 
> --
> 
> So, on to more data and and a closer look at whats happening during the glitch periods.
> 
> Each of the graphs attached are histograms, covering approx 500k glitch periods around rising and falling edges in an hour of data of the Micro Crystal OCXO with mv89a reference. Both oscillators had their adjustment pins grounded and the offset was about 66hz between them.
> 
> There are 4 graphs showing distributions of:
> - lengths of each glitch period
> - how far each transition is from the start of each glitch period
> - zeros and ones from the start of each glitch period (for all edges) - red for zeros, green for ones
> - same as above but just for rising edges
> 
> The x axis is in units of reference clocks/samples (so ~100ns of real time, or a vernier of 6.6E-13 of the DUT signal depending on how you look at it) and 0 is the start of each glitch. The y axis is counting the total number of glitch periods.
> 
> As an example, looking at the distribution of glitch period lengths, shows the peak at around 2500 clocks/samples. 2500 * 6.6E-13 = 1.65ns which corresponds nicely with the difference between first and last edges seen in the phase data graph.
> 
> Cheers
> 
> 
> Simon
> 
> <ADEV.png><Glitch Period Lengths.PNG><Phase_CloseUp.png><Transitions Distribution.PNG><Zero-One Distribution (All Edges).PNG><Zero-One Distribution (Rising Edges).PNG>_______________________________________________
> 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 mailing list