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 <[email protected]> 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 -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
