On Sun, Sep 9, 2012, at 10:02 AM, Kent A. Reed wrote:
> > I had been idly noodling about an external auditing device which I could > connect to the output of whatever pulse generator I might want to > characterize, like a doctor using an EKG to look at my sinus rhythm. It > would continuously monitor pulse-to-pulse times and accumulate the data > for such purposes as a running "what's the worst that can happen" meter > like we have in the existing latency-test, stripchart displays like we > have in the existing latency-plot, binning the data on graphs like we > have in the osadl site, running ever-popular statistical > characterizations, whatever. > > Why do it? Because I get a lot of time to sit in waiting rooms and idly > noodle. One of the things I noodle about is the regularity or lack > thereof of our different pulse-generation schemes and the way we > currently "wing it" with our measurements. Once a researcher, always a > researcher. > > How to do it? Well, back when Richard Nixon was President, I would have > rigged up something that conceptually would consist of a discriminator > circuit to trigger on some criterion, say the 50-percent point on the > leading edge of the input pulses; the output of this circuit would gate > two counters alternately. Each counter would be counting the output of a > high-frequency clock. One would be counting when the other was being > read and reset. Ancillary circuitry would take care of error situations > like when the pulse train slowed (or stopped) to the point of causing > the current counter to overflow. > > Orders of magnitude: the fastest pulse train might be 100Kp/s (kilopulse > per second), or 10us/cycle.The clock would be 10 to 100 times faster, > say 1MHz to 10MHz. Assuming no range selection, if the slowest pulse > train to be considered were 1Kp/s, then with a 10MHz clock the largest > count would be about 10000, requiring the counters to be at least > 14-bits wide. Allowing for short-cycling, the fastest I'd have to read > and clear a counter would be about 5us. If I just blindly stored all the > samples, I'd accumulate roughly 2 gigabytes in 24 hours. Not long after Nixon was president, Tektronix had roughly the same idea, and called it the TVC-501. It is one of the TM500 series modular instruments. There are two counters just like you describe, taking turns counting. Their approach to handling the resulting data stream was clever. Each cycle of the input results in a number in a counter, representing a time interval. They subtract an adjustable offset from that number, then scale it and send it to a DAC. You connect the output to your scope. So the result is a waveform with a scale of 1uS, 10uS, 100uS, etc, all the way to 1 second per division. The offset value can be hundreds of divisions, so for example you can measure the period of a 100Hz square wave with resolution of 1uS per division. You can use whatever triggering capabilities your scope might have, but instead of looking at voltage, you are looking at time. The unit has two input connectors, and you can measure either the period of the A input, the pulse width on the A input, or the delay from the A input to the B input. Very nice for looking at things like the transient response of a PWM based regulator - because the time values look just like any other analog signal. I lucked out and got mine during a lab cleanup - nobody knew what it was or how to use it. I've seen them on ebay on rare occasions, for half a kilo-buck or more. In these days of inexpensive software based FPGA+USB oscilloscopes, I think it would be neat to see someone do roughly the same thing. They could leave out the DAC though - simply write the numbers from the counter to data memory as if they had come from a channel sampling ADC. With even a cheap FPGA it would be easy to have 100nS resolution, 10nS is not at all out of reach. -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
