Tektronix Technical Forums are maintained by community involvement. Feel free to post questions or respond to questions by other members. Should you require a time-sensitive answer, please contact your local Tektronix support center here.

Fast Frame acquisition problem in DPO7254

DPO70000SX, DPO/MSO70000, DPO7000 Series, DPO/MSO5000 Series
Post Reply
BlackAdder
Posts: 1
Joined: July 16th, 2020, 11:56 am
Country: Spain

Fast Frame acquisition problem in DPO7254

Post by BlackAdder » July 16th, 2020, 12:06 pm

Hi,

I have a strange problem when using my Tektronix DPO7254 in Fast Frame mode to acquire data for a spectroscopy experiment. Hopefully somebody will have encountered something similar and will be able to give me some pointers. It is a little long to explain, so please bear with me.

In my current configuration, my experiment uses pulsed lasers that run at 10 Hz. My signals are generated by these pulses, detected by a photodiode and a transimpedance amplifier and then sent to the oscilloscope. They look like a more-or-less gaussian peak of 10ns FWHM. I am acquiring them in Fast Frame mode in order to dump them to the hard drive an later be able to process them in Matlab. It is very convenient for us because Matlab allows us to do quite a bit of postprocessing (apply frequency filters, remove "bad" traces...). Before this we used an analog integrator (a boxcar averager) to integrate the peaks electronically, so moving the acquisition system to the oscilloscope has been a big improvement.

A typical scan lasts anywhere between 10 and 20 minutes, so at an acquisition rate of 10 Hz I end up with roughly 6k to 15k frames depending on the scan. Each frame typically covers 200 ns with a 100 ps resolution, so 2k points per frame. The oscilloscope is triggered through the Aux in
port by a light pulse (via another fast photodiode) from the same laser that drives the experiment and generates the signal, so the timing of our signals is very accurate and our jitter low: the signals appear on the screen exactly in the same spot for every oscilloscope trace, with sub-ns precision. This is critical to us because the retrieval of the signals is based on integration of those peaks, so we have to know where they appear in order to place the integration gate properly.

Now, the problem: it seems that there is some sort of drift in the time scale of the oscilloscope while the Fast Frame acquisition is taking place, so that at the beginning the pulses appear at a certain spot in the oscilloscope trace (a certain time), lets say 150 ns, but towards the end of the acquisition the pulses have progressively *moved* significantly and now appear at a different time on the screen, let's say 130 ns (I can see this during the later processing with Matlab, since in FF the screen is frozen during the acquisition). Now, the first thing I thought was "triggering problem", but the triggering pulses are clean, show no varying delay, are properly terminated into 50 Ohm.... It is almost as if the oscilloscope was being triggered a litle later, a little later....in each frame, so that the signals appear earlier in the trace. After 10-15 minutes this drift amounts easily to 20 ns, a tenth of the total length of the frame and larger than the width of my signals... so that in post-processing they don't even fall within the integration gate (placed based on their initial positions).

I have checked and re-checked that the problem is not any "real" drift of the signals themselves with respect to the triggering signal... It is not. In fact, I have gone to the extent of using in parallel the old acquisition system (boxcar) and the new one (oscilloscope) with the same triggering and input signals, and have been able to verify that while the boxcar acquisition works fine (the signals don't move in time and are properly integrated) the same traces acquired by oscilloscope show these slowly drifting signals. Simply put, with every passing frame the oscilloscope is acquiring "by itself" a slightly more delayed time slice with respect to the triggering signal being provided.

One more nasty detail: the problem is intermittent. It only shows in one out of 5-6 scans, roughly.

Our electronic engineer has suggested a possible source for the problem: a drifting delay due to the use of the "horizontal delay" knob: our 200 ns traces start roughly 600 ns after the triggering signal arrives, and we adjust the beginning of these traces with the horizontal delay knob. It might be that the problem is a slow drift of this horizontal delay value. I have to say that I have never seen it in normal oscilloscope use (and the numerical value displayed by the oscilloscope remain the same before and after the FF acquisition), but I don't know if Fast Frame is different in this regard and might be affected by this drift.

I am still in the process of runnig more tests (for example, I am planning to use an external delay generator to delay my triggering signals by those 600 ns, so that I can avoid using the built-in horizontal delay of the oscilloscope and see if the situation improves), but if anyone has experienced similar problems and knows the origin, or has any ideas that I can try, I'd appreciate it enormously.

Thanks in advance and sorry about the long-winded explanations!

Post Reply

Return to “Windows Based Oscilloscopes”

Who is online

Users browsing this forum: No registered users and 1 guest