Keysight MXR 8 channel scope

[Wuerstchenhund]

The trigger rate and waveform update rate can be completely disconnected. They are not in any way equivalent. Keysight have to clarify this in their marketing material to avoid your sorts of misleading claims:

When reviewing the update rate process, it seems like trigger rate could be used interchangeably with update rate; however, some oscilloscopes will trigger multiple times while the data is being processed and ignore the newly triggered event, making the trigger rate different than the oscilloscope update rate. The faster the update rate, the more events are being captured and analyzed by the oscilloscope

Yes, this can happen on scopes with unlocked triggers when the processing time exceeds the re-arm time (I vaguely remember I saw this effect on the I think the HP 54700 Series, or might have been one of the early Infiniiums).

I doubt this is an issue for most scopes built after say this side of 2000, and I challenge you to find any A-brand scope which came out since 2010 which does that.

Waveform update rate is widely understood to be the number of acquisitions per second that are drawn to the screen.

Yes, on analog scopes. Not on digital scopes, though, where there is no correlation between the time and frequency a scope updates it's view of the signal and the time and frequency of screen updates (which usually happen at low rates like 60Hz). On DSOs, the update rate means therefore the rate of how many times per second a scope can update its waveform record.

Segmented mode in most scopes doesn't draw all the data to the screen as its assumed you will go back through them after the capture sequence is complete.

Indeed. Because the point of sequence mode is essentually to stretch the existing memory to capture repetitive events which are spaced too far out for a normal long acquisition. So the scope essentially runs a series of short acquisitions, but saving on processing time.

Its as stark as the difference between "filing" documents to the in-tray, or reading them.

Not sure what you're on about "filing documents" here.

Dumping acquisitions to memory without them being seen, is in no way comparable, to putting their information onto the screen in realtime. One is trivial, the other is resource intensive. Just as pushing through acquisition data without putting it to the screen is not comparable to drawing it there.

This is where you go wrong again.

In general, every event that is captured by the scope and ends up in acquisition memory is displayed. The excessive triggers KS was talking about happen during the blind time, not during acquisition.

There are some exceptions, though:

- Some scopes have some kind of 'pre-roll and 'post-roll' padding, i.e. they start their acuisition a short time before they actually capture data which is processed, and continue capturing for a short time after they stop acuiring data for processing. It's often a consequence of certain aspects of the scope's internal architecture. But this 'padding' is completely transparent and not visible to the user. So for all intends of purposes, the true acquisition period is what the user selected (the padding is, essentially, just a bit more dead-time).

- Some scopes, again like Keysight infiniVision scopes, perform a full memory capture as their last acquisition after pressing STOP or in SINGLE acquisition mode, thereby (depending on the timebase), acquiring excess data outside the displayed timeframe. This is outside normal operation (the scope must have been halted), and even the data outside the view is available for viewing.

- Some scopes can be set to use more acquisition memory than required to capture for the displayed timebase, resulting them to capture data which is outside the displayed view. This data is lost for viewing unless the scope is halted and the timebase changed, in which case the data of the last acuisition before the scope entered STOP mode becomes visible. This effect has recently been topic of an extensive discussion and I'm sure you agree with me that this is a niche situation which doesn't reflect any normal or recommended use.

- Tek's MDO Series (and it seems some other models such as the DPO Series) have a function called 'Auto'Magnify' where, when the user selects a short time base, they capture a long time base and present the user with a window representing the selected shorter timebase. This window can then be moved around to view the data that is outside the original selected timebase window, i.e. all the acquired data can be viewed. It's unique in a way that it presents a mode where in normal operation not every captured event immediately ends up on the screen. I am not aware of any other scopes which offer a similar function, so it's a slighty special case.

But for any normal operation (RUN mode) without any specific modes or use cases, every event which occurs during the effective acquisition period will be displayed.

You can keep pointing to a video of a scope showing an impressive trigger rate, there is no evidence its drawing or processing the data from those triggers. We could go to the manual for that scope, which nowhere claims anything other than a high trigger rate.

Why should they, after all the update rate isn't something that is high on the list of priorities for buyers of this class of scope.

Also, this scope was equipped with a stronger 1.8GHz P-M processor instead of the stock 1.2GHz Celeron. The performance of X-Stream very much depends on the main processor (and its cache size), and the update rate was *a lot* lower with the stock Celeron, which always kept the CPU load at 100% almost constantly, ham-stringing performance in many other modes, too. I never understood why LeCroy skimped so much when it came to CPU power on the scopes, which after all rely on an architecture where the CPU is most critical. The 1.8GHz processor was later offered as an upgrade for that scope from LeCroy.

Also, on every 'real' LeCroy scope (i.e. which isn't just a rebadged variant of something else) every event which is captured in memory is displayed (if that channel display is active, of course, because you can acquire without having the channel displayed on screen). The scope in the video will show every event that occurs during the acuisition phase on the screen, as it's been one of LeCroy's design mottos since back when they were mostly serving the science market.

Why would they include a special waveform/second optimized mode if the normal mode could outperform it? Note the manufacturer claim, 8000wfms/second.

WaveStream is an analog scope like persistence mode which is a bit like Tek's FastAcq DPO mode, just without all the drawbacks (it runs at full sample rate (10GSa/s) and you can use all measurements and analysis tools on it, although they will only use the data of the last acquisition, not history data). As far as I remember it circumvents certain processing steps and pushes data directly to the main processor (also, don't forget that X-Stream uses data compression, so it doesn't have to transfer and process every sample which hasn't changed again and again like other scopes). I guess the idea was that if you wanted to do simple eye diagrams you'd just press one button and that's it.

I've seen the 'above 8k wfms/s) figure in early documents describing the technology (maybe around 2003/2004 time frame), later no numbers were given probably because the actual rate varied so much depending on the CPU and also on the software version (in earlier software versions the update rate was also quite inconsistent). Considering the dependencies, it was probably seen as futile to list max numbers and update them everytime the software improves or a faster CPU has been qualified for the scope, so why bother? LeCroy customers didn't seem to care much for update rates anyways, and for what it is WaveStream has been more than fast enough.

Considering that the WRXi and it's successors sold rather well, it doesn't seem they were wrong.

We have lots of LeCroy scopes (although no WRXi's or any of the older ones), and WaveStream was useful occasionally to show a colleague some instability or continuous changes in a signal. But I haven't seen seen it exactly been widely used.

Competitive comparisons have consistently found very poor updates rates for that model of scope:
https://www.tek.com/document/competitive/tektronix-mso-dpo4000-series-vs-lecroy-waverunner-xi-fact-sheet-0

"Competitive comparisons" have found all kind of nonsense which is, quite often, the result of (intentional?) mis-operation. I wouldn't trust them as far as I could throw their brand's heaviest scope.

The Waveform Update rate (which is identical with the Trigger Rate) is a measure of how many times a scope can update its waveform record.

You can keep trying to redefine industry standard terms to suit your misleading arguments, but we'll keep calling it out and pointing to that nonsense. Your emotive rubbish that follows on from that is you "standard" claims which are getting old.

Yeah, whatever bro. You keep swallowing that marketing stuff

Which means relying on excessively high update rates to capture rare events has roughly a 1 in 10 chance that your scope actually sees it.

Excessively high but still not high enough? Ok, you just want to say its a bad thing no matter if its a high number or a low number.

Math clearly isn't your strong point. Because if so you'd understand that even with 1 Billion wfms/s there would still be a blind time, and it would be close to 100%

The simple fact you can't understand is that if you have to rely on multiple acquisitions there will be a certain amount if blind time, simple as that. And because the blind time percentage actually increases with waveform update rate, a high update rate means the chance of your scope actually capturing the event goes down.

Which contradicts the idea that high waveform rates would be somehow useful to find rare events, especially when the uncertainty is so large.

Secondly, yes, you can certainly reduce the percentage the blind time presents in the wavform update cycle. You just have to increase the acquisition time, either by lowering the sample rate or by increasing the sample memory. Eventually, your blind time will be smaller than your acquisition time. But then your waveform rate will also have dropped like a rock. And, even when it's smaller, there is still a blind time where your scope will miss events between acquisition cycles.

There is no technical barrier to faster update rates than what is currently offered.

There certainly is, because an increase in update rate means a reduction in the update period (the time slice in which acquisition and blind time must fit), and even if there was no blind time (which, with scopes, there always is) there is still a hard limit in the time for the ADC to fill the dedicated sample memory.

There are commercial products (but not general purpose oscilloscopes) with zero blind time that guarantee they draw 100% of the samples to the histogram, on sustained XXGsa/s streams.

Yes, streaming digitizers. Which, actually, are digitizers, not scopes.

Updates rates are not fixed in stone and imply all the extra conditions you keep claiming they do.

Indeed, they are not set in stone, they are limited by simple math.

Which means relying on repeated updates to capture rare events is still a gamble, even your odds may have increased (e.g. 9 out of 10 chance your scope sees it). However, if you can increase the acuisition time to capture your period of interest in one acquisition, and then set a trigger for the event of interest, your the odds of your scope seeing the event will be 100%.

Assuming there is a single trigger which you can configure to catch the event. Great, you captured a single event.

You can capture as many events as you like, as long as they are not coming faster than the scope needs for a complete acquisition cycle with blind time (like on these rare events that, supposedly, high update rates are so good for).

You can keep falling back to this extreme position which claims everything is solvable with triggers, but its not true for all applications.

OK, name one. Describe a situation which you can only solve with a high update rate scopes and persistence mode.

 

Some of which require a statistical measure built from an eye diagram.

So how does this square with the fact that those scopes which are predominantly used for eye diagrams (like the various Infiniums, i.e. all the scopes which are offered with options for exact this application) have mostly max update rates in the few thousands?

 

[Sighound36]

Gentleman please, there are ladies present its only a scope  . Albeit the possibility of rather a good one 

[snoopy]

When using a scope for spectral work, what really matters is the size of sample memory, because the memory alone determines how large of spectral sample in time you can capture. Because as soon as the memory is full there will be a very long (in comparison) period where your instrument is completely blind before you can re-acquire data again.

Try viewing a composite video signal with a low acquisition rate scope or a scope with no DPO (ok I know, who looks at composite video signals these days but you get my drift ) What does the color burst look like to you ?

I'm not much into video stuff and may be missing something here, but what do you need a very high waveform update rate for with a signal which changes just some 25 or 30 times per second?

As a side note, CVBS video is still widely used, for example with vehicular cameras and DVRs. So it's not that no-one looks at CBVS signals anymore

Now view it on any Tek scope with DPO because I know how much you hate Tek scopes

I don't *hate* Tek scopes (and I do consider attaching emotions to specific brands as something juvenile), it's just my experience that, compared to what we can get from other brands, their digital scopes are simply sub-par (and have been for a long time).

And considering that Tek's scope sales have been declining for years, it appears that many other professional users agree.

You should try using the scopes for a change instead of speccing them in for other people to use. There is a big difference between using an instrument yourself and reading it's capabilities from the spec sheet I still have a color bar generator from my days of designing digital video electronics and repairing TV's. I can post the results from one of my Tek scopes if you like, with and without DPO on

cheers

[Wuerstchenhund]

I fixed your broken quoting. You're welcome

When using a scope for spectral work, what really matters is the size of sample memory, because the memory alone determines how large of spectral sample in time you can capture. Because as soon as the memory is full there will be a very long (in comparison) period where your instrument is completely blind before you can re-acquire data again.

Try viewing a composite video signal with a low acquisition rate scope or a scope with no DPO (ok I know, who looks at composite video signals these days but you get my drift ) What does the color burst look like to you ?

I'm not much into video stuff and may be missing something here, but what do you need a very high waveform update rate for with a signal which changes just some 25 or 30 times per second?

As a side note, CVBS video is still widely used, for example with vehicular cameras and DVRs. So it's not that no-one looks at CBVS signals anymore

Now view it on any Tek scope with DPO because I know how much you hate Tek scopes

I don't *hate* Tek scopes (and I do consider attaching emotions to specific brands as something juvenile), it's just my experience that, compared to what we can get from other brands, their digital scopes are simply sub-par (and have been for a long time).

And considering that Tek's scope sales have been declining for years, it appears that many other professional users agree.

You should try using the scopes for a change instead of speccing them in for other people to use. There is a big difference between using an instrument yourself and reading it's capabilities from the spec sheet

Not sure what you try to say, other than that you don't seem to have an answer my question above

I've certainly spent enough time in front of a scope, and had the pleasure (or displeasure) to quite a few different ones during the last three decades.

I still have a color bar generator from my days of designing digital video electronics and repairing TV's.

Good for you 

I can post the results from one of my Tek scopes if you like, with and without DPO on

I'm not sure what this should show us, other than that you seem to have no idea how much scopes have advanced since the days when analog scopes or repairing analog TVs was still a thing, but hey, I'm always up for a blast from the (distant) past 

I'd suggest you do this in a separate thread, though.

[nctnico]

Which means relying on repeated updates to capture rare events is still a gamble, even your odds may have increased (e.g. 9 out of 10 chance your scope sees it). However, if you can increase the acuisition time to capture your period of interest in one acquisition, and then set a trigger for the event of interest, your the odds of your scope seeing the event will be 100%.

The truth is somewhere in the middle. After all you can only set a trigger condition if you have enough information to setup the trigger condition correctly. In many real-life situations this isn't possible or by the time you have the information you already captured the anomaly so the whole point of setting up a trigger becomes moot. High waveform update rates aren't the answer either. IOW: you have to consider other ways to pick up an anomaly. For example by using things like color grading, reverse brightness, off-line analysis, etc. What is best depends highly on the situation. The more experience, the easier it becomes to pick the right method sooner than later.

[Someone]

Which means relying on repeated updates to capture rare events is still a gamble, even your odds may have increased (e.g. 9 out of 10 chance your scope sees it). However, if you can increase the acuisition time to capture your period of interest in one acquisition, and then set a trigger for the event of interest, your the odds of your scope seeing the event will be 100%.

The truth is somewhere in the middle. After all you can only set a trigger condition if you have enough information to setup the trigger condition correctly. In many real-life situations this isn't possible or by the time you have the information you already captured the anomaly so the whole point of setting up a trigger becomes moot. High waveform update rates aren't the answer either. IOW: you have to consider other ways to pick up an anomaly. For example by using things like color grading, reverse brightness, off-line analysis, etc. What is best depends highly on the situation. The more experience, the easier it becomes to pick the right method sooner than later.

Completely agree. It will be interesting to try out the RTSA and see if that can provide richer information than the time domain waveform for say (no-longer high speed) serial applications at XXXMHz or low GHz line rates. Keysight are pushing the convergence of both deep memory plus analysis suite, and high waveform rates in the MXR so you have both of those tools available in a single scope (as R&S have been doing already). Adding in RTSA as well might be another dimension, or just another half-baked idea, needs some testing and evaluation of it to find out what strengths and weaknesses it has.

[Someone]

The Waveform Update rate (which is identical with the Trigger Rate) is a measure of how many times a scope can update its waveform record.

You can keep trying to redefine industry standard terms to suit your misleading arguments, but we'll keep calling it out and pointing to that nonsense. Your emotive rubbish that follows on from that is you "standard" claims which are getting old.

Yeah, whatever bro. You keep swallowing that marketing stuff

Rather than trying to be internally misleading, the rest of us are discussing things using common understanding of language and terms. And will clarify them as needed.

Its as stark as the difference between "filing" documents to the in-tray, or reading them.

Not sure what you're on about "filing documents" here.

Dumping acquisitions to memory without them being seen, is in no way comparable, to putting their information onto the screen in realtime. One is trivial, the other is resource intensive. Just as pushing through acquisition data without putting it to the screen is not comparable to drawing it there.

This is where you go wrong again.

In general, every event that is captured by the scope and ends up in acquisition memory is displayed. The excessive triggers KS was talking about happen during the blind time, not during acquisition.

This is a good example of where you try and drive the misdirection. I keep making it very clear, putting acquisitions into memory where they can be looked at after the fact in a slower way, is in no way comparable to putting them on screen in a sustained manner.

Dumping acquisitions to a circular buffer, or just discarding them outright. Completely different to the waveforms/second update rate that counts the number of waveforms drawn to the screen.

Math clearly isn't your strong point. Because if so you'd understand that even with 1 Billion wfms/s there would still be a blind time, and it would be close to 100%

The simple fact you can't understand is that if you have to rely on multiple acquisitions there will be a certain amount if blind time, simple as that. And because the blind time percentage actually increases with waveform update rate, a high update rate means the chance of your scope actually capturing the event goes down.

You can imagine any sort of inappropriate or poor application of technology you like. There are sampling systems with 0% blind time, its possible. Trying to argue that higher waveform update rates under the same conditions is somehow a bad thing is bizarre. Yes, you can walk off the goalposts to some other new and different condition but thats not addressing the point, just adding more confusion.

There is no technical barrier to faster update rates than what is currently offered.

There certainly is, because an increase in update rate means a reduction in the update period (the time slice in which acquisition and blind time must fit), and even if there was no blind time (which, with scopes, there always is) there is still a hard limit in the time for the ADC to fill the dedicated sample memory.

It does not require these arbitrary changes to the conditions you insist on. A processing system can draw 2D histograms on a continuous basis with zero blind time, every sample that arrives can be processed and drawn to the display. I've designed and built such systems. Current scopes are limited because they have a processing time (the blind time) where they cannot accept new data, with more processing resources that time can be reduced to less than the sample rate and then there is 0% blind time.

You can keep falling back to this extreme position which claims everything is solvable with triggers, but its not true for all applications.

OK, name one. Describe a situation which you can only solve with a high update rate scopes and persistence mode.

Two examples:
Tuning termination and/or equalization on high speed serial streams. It can be hit with pathological patterns to try and examine corner cases, but PRBS and high update rates provide a wider coverage. And the characteristics can't be captured with a single trigger, or practically with a suite of triggers. Building the eye was annoying slow on older scopes, faster update rates allow quicker iterations/test time.

Tuning PLL loops. This is where the RTSA might be able to show richer information. But the key component again is seeing as many of the transitions as possible to check for outliers, and bring the tuning parameters to their optimal values. Its higher order things like the settling time or overshoot of the clock rate, that are difficult or impossible to describe as triggers.

Yes, you could make a deep memory capture and run analysis of that offline to extract the information. But realtime and using a human to interpret the results is faster. And while tuning you will be within the acceptable space but want to reach some margin away from failure. Hard pass/fail triggers are of no use.

Some of which require a statistical measure built from an eye diagram.

So how does this square with the fact that those scopes which are predominantly used for eye diagrams (like the various Infiniums, i.e. all the scopes which are offered with options for exact this application) have mostly max update rates in the few thousands?

That would be why this MXR scope, the topic of this thread, is interesting. It brings fast update rates to that class of scope, they publicise it clearly in the marketing material:

[Wuerstchenhund]

Which means relying on repeated updates to capture rare events is still a gamble, even your odds may have increased (e.g. 9 out of 10 chance your scope sees it). However, if you can increase the acuisition time to capture your period of interest in one acquisition, and then set a trigger for the event of interest, your the odds of your scope seeing the event will be 100%.

The truth is somewhere in the middle. After all you can only set a trigger condition if you have enough information to setup the trigger condition correctly.

There is always something you know. For example, you might know how the signal is supposed to look like.

I'm not saying you can trigger on everything with something like a DS105z but with a more advanced scope you should be able to trigger on pretty much anything.

In many real-life situations this isn't possible

I'd really like to see some examples of a signal where you can't trigger on a specific event. Because right now I can't think of any.

or by the time you have the information you already captured the anomaly so the whole point of setting up a trigger becomes moot.

That is certainly true, there's no point testing if you already got the information you need.

High waveform update rates aren't the answer either. IOW: you have to consider other ways to pick up an anomaly. For example by using things like color grading, reverse brightness, off-line analysis, etc. What is best depends highly on the situation. The more experience, the easier it becomes to pick the right method sooner than later.

My point is simply that using triggers to capture an event is the only way you can be sure that the event is actually captured, which puts the idea that a high update rate is required to capture rare events ad absurdum.

But I'm really curious as to cases a trigger would not work to capture an event. Examining such cases could certainly be an interesting discussion (preferrably in a separate thread).

[srce]

they publicise it clearly in the marketing material:

They're not exactly selling the S series well there in that comparison. They've ignored that on 2 channels it's 20GSa/s and 800Mpts. Also the jitter figures in the datasheets are lower for the S series 

[Someone]

they publicise it clearly in the marketing material:

They're not exactly selling the S series well there in that comparison. They've ignored that on 2 channels it's 20GSa/s and 800Mpts. Also the jitter figures in the datasheets are lower for the S series 

Ha ha, even comparing to their own product. But if it keeps the second hand prices down, no complaints?

[srce]

they publicise it clearly in the marketing material:

They're not exactly selling the S series well there in that comparison. They've ignored that on 2 channels it's 20GSa/s and 800Mpts. Also the jitter figures in the datasheets are lower for the S series 

Ha ha, even comparing to their own product. But if it keeps the second hand prices down, no complaints?

It's funny how they give it a green tick, even when they have listed higher figures for the other scopes too 

[nctnico]

Which means relying on repeated updates to capture rare events is still a gamble, even your odds may have increased (e.g. 9 out of 10 chance your scope sees it). However, if you can increase the acuisition time to capture your period of interest in one acquisition, and then set a trigger for the event of interest, your the odds of your scope seeing the event will be 100%.

The truth is somewhere in the middle. After all you can only set a trigger condition if you have enough information to setup the trigger condition correctly.

There is always something you know. For example, you might know how the signal is supposed to look like.

But that doesn't always help you. The signal might not be wrong but the data it represents may be wrong (think about an SPI or I2C bus). Especially when looking for intermittent problems you'll want to use a brute force method which catches as much information as possible because the cycle time is so long. A method which potentially catches both bad signal and bad data is most efficient but since you don't know either coming up with a trigger criterium is next to impossible. Deep memory (whether segmented or in one piece) helps a lot because you can likely also capture the cause (which is the interesting part) in one go. However the kind of problems I'm hinting at go way beyond repairing something relatively simple like a power supply. One of the problems I'm hunting right now is why a SoC is crashing on 1 board from a batch of 10. There is a myriad of possible causes (including software) and they need to be checked one by one. But this is getting off-topic.

[tv84]

But I'm really curious as to cases a trigger would not work to capture an event.

Let's not go OT here but i think, by definition, that can't happen. If you captured an event it's because there was a trigger (whatever kind it may be).

[nctnico]

But I'm really curious as to cases a trigger would not work to capture an event.

Let's not go OT here but i think, by definition, that can't happen. If you captured an event it's because there was a trigger (whatever kind it may be).

You have to define that a bit better. You can use a trigger as a filter (for example specific I2C addresses in order to prevent overfilling the memory) but setting a very specific trigger for an unknown event is next to impossible. In such cases you will be collecting a set of data which then needs to be processed in one way or another. Kind of like how they find fine gold. They first wash & seperate the big rocks and dirt and then seperate the gold from the mixture of fine sand and gold dust.

[Someone]

But I'm really curious as to cases a trigger would not work to capture an event.

Let's not go OT here but i think, by definition, that can't happen. If you captured an event it's because there was a trigger (whatever kind it may be).

There are things that are simply hard to define a trigger for, which is why masks and zone triggers came along. As mentioned previously a non-monotonic edge can be hard to catch with triggers. But triggering on events and capturing traces that only meet those criteria narrows what you are looking at. Some times that is exactly what you want, but other times it needs a larger picture of the signals in context.

Triggering is still important to correlate the waveforms against something, but you might want to measure the spread of a parameter like jitter in a serial signal with an embedded clock. The trigger is just getting the waveforms collected for another step of analysis. A brute force approach only using triggers would confirm the bounds of the jitter, but wouldn't identify spurs or odd distributions of the variations.

[tv84]

You have to define that a bit better. You can use a trigger as a filter (for example specific I2C addresses in order to prevent overfilling the memory) but setting a very specific trigger for an unknown event is next to impossible.

I understand that and totally agree with you both. As you refine such filtering, you're practically refining your "trigger" conditions. (My usage of the word trigger here was not bound by the specifics of a scope trigger.)

Software reversing is, most of the times, working with unknown trigger conditions that we must refine until we get the particular event we're looking for. 

[2N3055]

Well,  a non-monotonic edge can most of the time be caught with rise/fall time trigger, because non-monotonic edge will result in anomalous 10/90% rise time...
But that is just a side comment.

I agree with tv84 in principle. Many people here list their experience and techniques used, and argue who is and what is right, but in the end it all drills down to what you do.
There is a difference if you do R&D stuff, or you do repairs, or reverse engineer, or do production test...
Also what you do, RF, hi or low speed digital, mixed signal, communications, all of the above...
All of those will favor some instruments to others.
I know one thing thou: If you can make single instrument fill more than one role, that is useful.

It seems this instrument simply wants to be more universal instrument, hoping that customers will find new ways to use it....
It also will be nice digitizer front end for Keysight analysis software (VSA for instance)..

[snoopy]

I fixed your broken quoting. You're welcome

When using a scope for spectral work, what really matters is the size of sample memory, because the memory alone determines how large of spectral sample in time you can capture. Because as soon as the memory is full there will be a very long (in comparison) period where your instrument is completely blind before you can re-acquire data again.

Try viewing a composite video signal with a low acquisition rate scope or a scope with no DPO (ok I know, who looks at composite video signals these days but you get my drift ) What does the color burst look like to you ?

I'm not much into video stuff and may be missing something here, but what do you need a very high waveform update rate for with a signal which changes just some 25 or 30 times per second?

As a side note, CVBS video is still widely used, for example with vehicular cameras and DVRs. So it's not that no-one looks at CBVS signals anymore

Now view it on any Tek scope with DPO because I know how much you hate Tek scopes

I don't *hate* Tek scopes (and I do consider attaching emotions to specific brands as something juvenile), it's just my experience that, compared to what we can get from other brands, their digital scopes are simply sub-par (and have been for a long time).

And considering that Tek's scope sales have been declining for years, it appears that many other professional users agree.

You should try using the scopes for a change instead of speccing them in for other people to use. There is a big difference between using an instrument yourself and reading it's capabilities from the spec sheet

Not sure what you try to say, other than that you don't seem to have an answer my question above

I've certainly spent enough time in front of a scope, and had the pleasure (or displeasure) to quite a few different ones during the last three decades.

I still have a color bar generator from my days of designing digital video electronics and repairing TV's.

Good for you 

I can post the results from one of my Tek scopes if you like, with and without DPO on

I'm not sure what this should show us, other than that you seem to have no idea how much scopes have advanced since the days when analog scopes or repairing analog TVs was still a thing, but hey, I'm always up for a blast from the (distant) past 

I'd suggest you do this in a separate thread, though.

You just contradicted yourself and I have highlighted those contradictions in bold. I'm not sure what your agenda is here. You sound like some ex Tek employee who was shown the door long ago and have not got over it and so to get back at your ex employer you take any opportunity to slander their work anytime you can. Doesn't really help others looking for an objective point of view 

cheers

[Mr. Scram]

The first page of this thread was fun, wasn't it?

[jjoonathan]

Does anyone know if the paper is out on the 10 bit 16GS/s ADC in the UXR and MXR?

Actually, come to think of it, I'm not sure I've seen the Infiniium S ADC paper either. The last one I have in Zotero is the 90000 paper, "A 20 GSa/s 8b ADC with a 1 MB Memory in 0.18 mm CMOS". Or was the S series just that one (or two of them) configured for vertical interleaving?

[eplpwr]

The first page of this thread was fun, wasn't it?

Yes! There was a discussion about a newly released scope from Keysight with some quite interesting specs. 

[srce]

Does anyone know if the paper is out on the 10 bit 16GS/s ADC in the UXR and MXR?

Actually, come to think of it, I'm not sure I've seen the Infiniium S ADC paper either. The last one I have in Zotero is the 90000 paper, "A 20 GSa/s 8b ADC with a 1 MB Memory in 0.18 mm CMOS". Or was the S series just that one (or two of them) configured for vertical interleaving?

S series ADC was in 65nm, and 10bit.

[jjoonathan]

Aha! You're right -- I've tried tossing some of the parameters from the Infiniium S brochure and names from the 90000 paper into Google Scholar but haven't found the Infiniium S paper yet, so further leads would still be appreciated

[srce]

One question on the MXR: the brochure mentions Digital Down Conversion -- If I want to capture 1MHz of spectrum at 2.4 GHz and time correlate it to, say, a SPI bus, am I forced to sample the SPI bus at 5GS/s, burning through memory and Wfm/s? Or am I allowed to sample the DDC signal and SPI bus at a few MS/s?

Min DDC span is 40 MHz, and you can only view a signal as time domain or DDC (or RTSA, which uses DDC). so there is no time correlation. You'd have to use FFT like before.

Hmm. When I read this, I thought you just meant a single channel can't be viewed in both time domain and RTSA modes.

But it seems when the scope is in RTSA mode, there is no time domain functionality at all. That's a great shame.

Do you know if this is just a limitation of the current s/w or a fundamental h/w limitation?

[jusaca]

Anything new about this scope? I was waiting for one or the other of our favourite youtubers to get a unit to show it off, but up to now there is no stuff on youtube (except for the offical Keysight video).