Re: [time-nuts] BeagleBone Black DDMTD update
Hi Simon, On 29/10/14 20:15, Simon Marsh 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. Do you have any code to share ? Or did I miss it ? All the Best Iain ___ 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.
Re: [time-nuts] BeagleBone Black DDMTD update
On 30/10/2014 07:12, Iain Young wrote: Hi Simon, On 29/10/14 20:15, Simon Marsh 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. Do you have any code to share ? Or did I miss it ? I'd posted the original proof of concept code, but not the more recent changes. I've uploaded the latest version here: https://drive.google.com/file/d/0BzvFGRfj4aFkVzhSM2xNMUI5QXM/view?usp=sharing This does come with a health warning though, as it's very much a work in progress. Capture and PRU code is ok, the analysis code has a framework but is still very much to do. Ironically, the proof of concept had better documentation There is a README in there from the original PoC about dependencies and how to set up the PRU. Building should be as easy as running the makefiles. To do a capture, you need to do something along the lines of: # run the capture program to get the data (with argument of where the PRU code is) capture/capture capture/capture.bin capture.out # run minmax on the data, the minmax output is used by edge detection to work out where the glitch periods are cat capture.out | process/minmax # run edge_detect, this will generate lots of files with all the data cat capture.out | process/edge_detect Note that the minmax and processing steps don't need to be run on the BBB, I capture to an NFS share and run the analysis on a more powerful box elsewhere. 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.
[time-nuts] BeagleBone Black DDMTD Update
original post had a lot of attachments, these have been uploaded here for viewing: https://drive.google.com/folderview?id=0BzvFGRfj4aFkMFBtNWFSZVBKWkkusp=sharing --- 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 ___ 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.
Re: [time-nuts] BeagleBone Black DDMTD update
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 subscripti...@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.pngGlitch Period Lengths.PNGPhase_CloseUp.pngTransitions Distribution.PNGZero-One Distribution (All Edges).PNGZero-One Distribution (Rising Edges).PNG___ 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. ___ 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.
Re: [time-nuts] BeagleBone Black DDMTD update
On 29/10/2014 22:22, Bob Camp wrote: 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 Yes, luckily the Sitra TRM has a nice clear diagram for the mechanism I use and the signals are re-clocked twice on their way in to the BBB (@100mhz for the OCP bus then @200mhz for the PRU). The timing at the BBB is not critical though, the signal is captured in the sampler @ 10mhz and the BBB has a shade under 100ns to read it before the next sample comes in. In initial testing, I had the BBB continuously sampling and had no problems keeping up @10mhz (I actually had to slow it down to make it work). 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.
Re: [time-nuts] BeagleBone Black DDMTD update
Hi In the case of a 1 ps aperture on the flip flop, and a 100 fs delta between samples, there are two simple things that might happen: 1) You get random garbage for 10 counts. 2) The flip flop “hangs up” for 10 counts. To know which one you are going to get, you would need a pretty good model of the flip flop. ——— If your reference signal has sub-harmonics in it, (it’s 5 MHz doubled to 10 for instance) then they will give you a “double edge” when viewed on a scope. A ten or twenty ps delta is not at all unusual in that case. If your edge rates are in the ns / volt range ( = it’s fast logic), and your ground plane is more than 30 mils from your leads, you will get things coupling here and there. If ground and power are not planes, you will get bounce. All of that will create odd outcomes on the flip flop. — If your bypassing is not short lead, and reasonable sized, the power pin will “drop” when an edge goes out. That’s even more true if you have a heavy load. When that happens, odd internal things can / will happen in the flip flop. —— Modern gates are designed to be surface mounted on a multi layer PC board with chip bypass. The further you get away from that “model” the more likely you are to have less than perfect behavior. You are after *very* good behavior …. Bob On Oct 29, 2014, at 6:50 PM, Simon Marsh subscripti...@burble.com wrote: On 29/10/2014 22:22, Bob Camp wrote: 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 Yes, luckily the Sitra TRM has a nice clear diagram for the mechanism I use and the signals are re-clocked twice on their way in to the BBB (@100mhz for the OCP bus then @200mhz for the PRU). The timing at the BBB is not critical though, the signal is captured in the sampler @ 10mhz and the BBB has a shade under 100ns to read it before the next sample comes in. In initial testing, I had the BBB continuously sampling and had no problems keeping up @10mhz (I actually had to slow it down to make it work). 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. ___ 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.
Re: [time-nuts] BeagleBone Black DDMTD update
kb...@n1k.org said: 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. Reclocking is almost required if you want to avoid metastability issues. There is often some documentation in the form of min high/low times. -- These are my opinions. I hate spam. ___ 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.
