AnsweredAssumed Answered

MSOX3000 sample clock to trigger offset?

Question asked by MarkL on Oct 31, 2014
Latest reply on Nov 10, 2014 by MarkL

Like • Show 0 Likes0
Comment • 4

I'm trying to perform some waveform averaging of 900MHz signals on an external PC using an MSOX3104. I'm using a single channel so the scope is running at 5GS/s, and I'm downloading all 4M points in the raw record.

I've noticed that the downloaded waveform has a jitter of +/-100ps because it is referenced to the sample clock. This is not a surprise, but I can't figure out how to determine the trigger offset from the sample clock so that repeated acquisitions are aligned as best as possible.

The offset does not appear to be accounted for in the waveform preamble, which is where I would expect it.

I think the scope knows this offset because the display is clearly not jumping around by +/-100ps, but I can't find how to get the value via SCPI.

Any clues welcome; maybe I'm just looking in the wrong place for it.

Thanks...

No one else has this question

Outcomes

algoss

Oct 31, 2014 11:35 AM

There are 2 issues here:

- Trigger Jitter - every scope has some trigger jitter, meaning that the crossing won't go through the center of the screen, but close to it. Higher performance (and higher cost) scopes specify the trigger jitter, and work very hard to reduce it.

- Sample offset - The sampler is asynchronous to the trigger, so the sample closest to the trigger will never be right at 0ps, but up to 1 sample period away. That time offset should be available as the 6th field in the preamble, as the Xorigin. You can also get that from the WAV:XOR? query. Even that value will have some uncertainty, since the trigger interpolator isn't perfect.

Waveform averaging with scope data is a fine art, and not an easy thing to do. The above issues mean that you can't just say, for instance, "I'm going to take all of the first samples and average them, then the second samples..." You might need to interpolate and resample all of the waveforms to remove the time offsets before you average them.

Good Luck!

Al

Actions

MarkL @ algoss on Oct 31, 2014 3:09 PM

Hi Al,

Thanks for the speedy response.

My plan of attack is as you say, to resample and then average.

There's no trigger jitter spec I can find for the X3104, but based on eyeballing a fast edge it appears to be about an order of magnitude better than the sample interval. I can't turn off sin(x)/x interpolation, so there may be some artifacts from that too that's spreading out the crossing.

The Xorigin on this scope never changes from acquisition to acquisition, even though it's printed with plenty of precision (e.g., "-2.50000000E-009") to represent the offset from the trigger interpolator. Setting the delay _does_ affect the Xorigin, but once set it is static. In fact, nothing in the preamble changes in successive acquisitions, which is why I started looking in other places.

Maybe the trigger interpolator value is not available externally on this model? Or maybe it was mistakenly left out of Xorigin?

Actions

algoss

@ MarkL on Nov 3, 2014 6:30 AM

There are 2 solutions to your problem.

1) Use a better scope. The Infiniium scopes have many more capabilities, and are probably more suited to the measurements that you are trying to make.

2) Do your own interpolation and remove the trigger jitter before you do the averaging.

Al

Actions

MarkL @ algoss on Nov 10, 2014 7:18 PM

Had a chance to look at this a little more and it turns out the trigger interpolator offset is used in the calculation of which points are returned in a raw waveform (when the whole waveform is not being displayed).

By repositioning the trigger area to the first few points of the returned waveform, it's possible to continue decrementing the timebase position value by 20ps (the minimum delta allowed on the 3000X) until the first point falls off the returned waveform (i.e., the voltage value changes).

When that happens, you've found the interpolator offset to +/-20ps. Initial results are within these bounds, so trigger jitter appears to be very low.

Obviously this is all post processing on a single shot capture, which is then repeated as many times as needed.

The process is slow and admittedly a hack, but it will get me the data I was looking for. This particular measurement was in the category of "it would be great if we could do it", and it didn't really didn't justify an investment in a higher class scope.

But I would still suggest the interpolator value be added to a command somewhere. The scope knows this number and it should expose it for programs to use.

Thanks for your suggestions, Al. It got me thinking about this alternate approach.

Actions

4 Replies

algoss Oct 31, 2014 11:35 AM
Mark Correct
Correct Answer
There are 2 issues here:

- Trigger Jitter - every scope has some trigger jitter, meaning that the crossing won't go through the center of the screen, but close to it. Higher performance (and higher cost) scopes specify the trigger jitter, and work very hard to reduce it.

- Sample offset - The sampler is asynchronous to the trigger, so the sample closest to the trigger will never be right at 0ps, but up to 1 sample period away. That time offset should be available as the 6th field in the preamble, as the Xorigin. You can also get that from the WAV:XOR? query. Even that value will have some uncertainty, since the trigger interpolator isn't perfect.

Waveform averaging with scope data is a fine art, and not an easy thing to do. The above issues mean that you can't just say, for instance, "I'm going to take all of the first samples and average them, then the second samples..." You might need to interpolate and resample all of the waveforms to remove the time offsets before you average them.

Good Luck!

Al
Like • Show 0 Likes0
Actions
- MarkL @ algoss on Oct 31, 2014 3:09 PM
  Mark Correct
  Correct Answer
  Hi Al,
  
  Thanks for the speedy response.
  
  My plan of attack is as you say, to resample and then average.
  
  There's no trigger jitter spec I can find for the X3104, but based on eyeballing a fast edge it appears to be about an order of magnitude better than the sample interval. I can't turn off sin(x)/x interpolation, so there may be some artifacts from that too that's spreading out the crossing.
  
  The Xorigin on this scope never changes from acquisition to acquisition, even though it's printed with plenty of precision (e.g., "-2.50000000E-009") to represent the offset from the trigger interpolator. Setting the delay _does_ affect the Xorigin, but once set it is static. In fact, nothing in the preamble changes in successive acquisitions, which is why I started looking in other places.
  
  Maybe the trigger interpolator value is not available externally on this model? Or maybe it was mistakenly left out of Xorigin?
  Like • Show 0 Likes0
  Actions
  - algoss @ MarkL on Nov 3, 2014 6:30 AM
    Mark Correct
    Correct Answer
    There are 2 solutions to your problem.
    
    1) Use a better scope. The Infiniium scopes have many more capabilities, and are probably more suited to the measurements that you are trying to make.
    
    2) Do your own interpolation and remove the trigger jitter before you do the averaging.
    
    Al
    Like • Show 0 Likes0
    Actions
    - MarkL @ algoss on Nov 10, 2014 7:18 PM
      Mark Correct
      Correct Answer
      Had a chance to look at this a little more and it turns out the trigger interpolator offset is used in the calculation of which points are returned in a raw waveform (when the whole waveform is not being displayed).
      
      By repositioning the trigger area to the first few points of the returned waveform, it's possible to continue decrementing the timebase position value by 20ps (the minimum delta allowed on the 3000X) until the first point falls off the returned waveform (i.e., the voltage value changes).
      
      When that happens, you've found the interpolator offset to +/-20ps. Initial results are within these bounds, so trigger jitter appears to be very low.
      
      Obviously this is all post processing on a single shot capture, which is then repeated as many times as needed.
      
      The process is slow and admittedly a hack, but it will get me the data I was looking for. This particular measurement was in the category of "it would be great if we could do it", and it didn't really didn't justify an investment in a higher class scope.
      
      But I would still suggest the interpolator value be added to a command somewhere. The scope knows this number and it should expose it for programs to use.
      
      Thanks for your suggestions, Al. It got me thinking about this alternate approach.
      Like • Show 0 Likes0
      Actions

MSOX3000 sample clock to trigger offset?

Outcomes

Related Content

Recommended Content