[time-nuts] BBB DDMTD - analysis

Bob Camp kb8tq at n1k.org
Thu Oct 30 21:51:35 EDT 2014


Hi

How about a picture of the “as built” circuit? There may be something about the construction that’s the issue.

Bob

> On Oct 30, 2014, at 10:45 AM, Simon Marsh <subscriptions at burble.com> wrote:
> 
> Lots more pictures and data uploaded here:
> https://drive.google.com/folderview?id=0BzvFGRfj4aFkMFBtNWFSZVBKWkk&usp=sharing
> 
> In an effort to understand which component was responsible for my ~17us spikes I decided to go back to basics with just a single DFlop (AC74) on a breadboard; no BBB, just a couple of oscillators driving the data and clock pins (the microcrystal and 8663 in this case). I think I can hear Bob shaking his head at using a breadboard :) but the point was to change the parameters (even if it was for the worse) to determine what was causing the problem.
> 
> The first few pics (DFlop-unsync-floating-*) show the Q output, which was unconnected to anything other than the oscilloscope. They show a few glitches at the edge then a load of funky stuff going on later. Connecting Q to an input pin (DFlop-unsync-connected) cleared the problem suggesting that in this period, the DFlop output wasn't being driven and Q had been left floating.
> 
> What surprised me about these traces is not that strange stuff was happening at all, but just how long an interval it was happening for. I'd expected, say, tens of clock cycles (~1us maybe), but here the dflop is still reacting over 100us later. The period where the output was floating was just over 50us long.
> 
> The next few traces (DFlop-sync-*) show the output synchronised through the second DFlop of the AC74. The first few clearly show glitching bang on the 17us mark, revealing that the data I'd seen wasn't because of quantisation but because glitches were specifically occuring at those points. It also nicely ruled out the BBB as this wasn't connected.
> 
> The last few DFlop-sync-* traces show a variety of edge transition cases. What is becoming clear is that the set of transitions near an edge are _not_ a nice standard distribution as you might expect from simulation, so this is going to make the edge detection algorithm interesting.
> 
> After messing around with the AC dflop, I decided to try swapping to a slower part to see what impact this would have. I switched to an HC595 shift register, in part so I could also rule out my mess of wires between the sampling and synchronising flip flop as being the cause of the problem. The last couple of traces show an HC595 seeing exactly the same type of glitches as the DFlop.
> 
> Finally, I hooked the BBB back up and tried quite a few different combinations of parts and clocking techniques to see what impact they may have. I've included plots of the edge transition distribution of the AC74 dflop, HC595 shift register and AHC595 shift register for comparison.
> 
> Each of the profiles are slightly different, but they _all_ show glitching at ~17us increments. The final surprising bit is just how consistent this number is given the wide variety of different setups I've tried. I've changed practically most of the setup at some point or another and despite how hopeless by hardware layout has been, the transitions have always been occuring within one or two clock cycles every time (169-172 sample clocks).
> 
> To wrap up, despite the glitching, I managed to get noise down to reach about 7E-11 @ 1s which is pretty hopeful given it was botched up on a breadboard.
> 
> Cheers
> 
> 
> Simon
> 
> 
> 
> 
> _______________________________________________
> 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