The unlocked Rigols do not perform like good 100 MHz oscilloscopes should

That's complete rubbish. An unlocked Rigol behaves exactly like a DS1104Z (which is a good oscilloscope).

We have discussed this before and I have pointed out two examples from different users which have the same problem. That may not seem like enough but it was *all* of the users who actually ran the needed test.

The hacked ones display symptoms of non-linearity on fast edges which varies depending on vertical sensitivity. 5+ nanoseconds of overload recovery after a fast edge is not consistent with the 3.5 nanosecond transition time of a 100MHz oscilloscope. This is likely related to the bandwidth measurements which vary significantly at different vertical sensitivities presumably due to insufficient full power bandwidth. In an operational amplifier, this would be due to slew rate limiting which produces the same problem. In this case I suspect one of the amplifier stages is being driven into saturation or cutoff by the fast edge which is not quite surprising given what we know of the design from Dave.

What is unknown is if the DS1104Z 100MHz model and unhacked DS1054Z 50MHz model display the same behavior. The DS1054Z should not because of its 50MHz bandwidth limit. Maybe Rigol selects or grades the DS1104Z for proper operation but if it displays the same problem, then it also does not operate like a good 100MHz oscilloscope.

So when I say that the hacked 50MHz DS1054Z does not act like a good 100MHz oscilloscope should, I mean it is not performing like any oscilloscope with a 100MHz bandwidth should. On the other hand, unless the oscilloscope is used to measure bandwidth limited edges, the user should never notice this problem. But why bother hacking a 50MHz DS1054Z to 100MHz if the extra bandwidth is not going to be taken advantage of?

just apparently no one really knows .. but still thanks for the answers

in life everything is not easy and everything has its causes and consequences

Yes, we do know, and it’s been explained to you repeatedly.

No, we aren’t going into more detail because the answers to your residual/repeat questions already exist in the forum.

But seriously, stop being a smartass and accept that the DS1054Z has been out for years, and that nearly everyone who has one has hacked it, and that there are no reports of damage (or malfunction) due to the hack.

But seriously, stop being a smartass and accept that the DS1054Z has been out for years, and that nearly everyone who has one has hacked it, and that there are no reports of damage (or malfunction) due to the hack.

Scope is solid. Only reports are of user brain malfunction & damage to neural network due to shocking & unexpected visual phenomenon rendered on screen From other thread:

What is unknown is if the DS1104Z 100MHz model and unhacked DS1054Z 50MHz model display the same behavior.

No it isn't.

That is a claim, but all I have seen so far are assumptions (based on the models using the same hardware). Thus, unless you can provide/link to proofs (measurements, not just assumptions), it is nothing more than educated guess. (Which could be right, though. I'd make the same guess on their behavior, but I would not claim it is "known", per se, without something to back it up.)

At least David Hess has tried get to facts (real measurements) to test the assumption of that earlier case. Due to the small set of results, reliability could be low, but then again, the measurement results to show otherwise had even smaller set

If the hacks are so common as some claim, and reverting the hack also claimed to be easy, and those Rigol scopes as popular as some others claim, it should be trivial to get quite a few more results to prove both cases one way or another. (Well, I didn't look what kind of measurement David Hess was looking for, maybe those are not as trivial.)

Quote

You know the hardware is identical, right?

You know the identical hardware is being used ever so slightly differently in those two models, right? (Edit: And I think that identical hardware does not need more proving. Merely pointing here to that usage difference.)

Sorry if that all sounds a bit like ... it is a bit of that, but also a bit of my desire to see facts and good explanations instead of the typical internet opinions and assumptions. There is too much latter all over the places.

I'm wondering how that matters to me, that Rigol measures screen data, along with there only being 7 bits shown on the screen. I guess I should be able to figure that out.

What, someone doesn't think the zoom window is telling the truth? Or is telling less truth than the unzoomed screen? Other than being compressed vertically?

At the moment, I'm not sure if one screen is zoomed or the other is compressed. I don't understand why you would rather make a measurement on the compressed screen data, which surely will have much fewer datapoints than the zoomed window.

I'm also trying to understand exactly what David is explaining above, so I provided my interpretation of what a good trace would look like, and the region where the Rigol is not good...

You know the identical hardware is being used ever so slightly differently in those two models, right?

Sorry if that all sounds a bit like ... it is a bit of that, but also a bit of my desire to see facts and good explanations instead of the typical internet opinions and assumptions. There is too much latter all over the place.

Aren't you making the same baseless claim, and really adding nothing of what you want to the discussion?

I'm not at all interested in the 1054 vs 1104 debate. Who cares? All that matters is the absolute performance of the instrument, so we don't need to compare the 1104 unicorn, almost nobody has one anyway.

You know the identical hardware is being used ever so slightly differently in those two models, right?

Sorry if that all sounds a bit like ... it is a bit of that, but also a bit of my desire to see facts and good explanations instead of the typical internet opinions and assumptions. There is too much latter all over the place.

Aren't you making the same baseless claim, and really adding nothing of what you want to the discussion?

If referring that first part you quoted above, then with that particular part I was not expecting Fungus to prove his previous sentence, I was pointing out the mistake that he is showing only relying on identical hardware -idea, leaving out the different usage. Thus, some of the assumptions, based only on the identical hardware, may not necessarily be valid. (On my claim of different usage: If the hardware is identical, it must be used differently; this is pure logical deduction, otherwise the models would behave exactly the same way with bandwidth as is, and no bandwidth hacks would be needed. I think Fungus knows all that, but just didn't consider it in this context.) (Lets see if I can modify the earlier message to clarify a bit... Done.)

Also, indeed I am not trying to add any Rigol facts to discussion, I'm merely pointing that if there is an argument going, the parties should try to provide more info (not necessarily instantly), especially if the other side has some measurements or other provable facts (potentially) showing otherwise.

Otherwise things end easily like in my mind: one side refers to earlier measurements showing a potential difference, another side replies with "nonsense, identical hardware", and I get to think "what kind of answer is that, the 'identical hardware' doesn't even consider different usage of the hardware, which could explain something, and even if different usage was considered and somehow ending with idea that the scopes should behave exactly the same, the different measurement results (contradiction of another assumption) should still be explained somehow, even if found out to be just user error."

Quote

I'm not at all interested in the 1054 vs 1104 debate. Who cares? All that matters is the absolute performance of the instrument, so we don't need to compare the 1104 unicorn, almost nobody has one anyway.

You might not be interested on it (and maybe not many others, either), but since it is out there and fungus replied, I tried to point on the weaknesses on Fungus' arguments, in the hopes that something more solid might appear. If nothing happens, no big deal.

Also note that David Hess' question is not a comparison between 1104 and 1054, but comparison between hacked 1054 and both unhacked models. Getting results just from the unhacked 1054 would already be an improvement to the situation. And he has noted the possibility of that (minor) deficiency on that "absolute performance" of the hacked 1054, so that question should then be of interest to you, too, though not necessarily a major interest.

What is unknown is if the DS1104Z 100MHz model and unhacked DS1054Z 50MHz model display the same behavior.

No it isn't.

You know the hardware is identical, right?

We know the design is the same or at least I assume it is. We do not know if Rigol grades or selects them.

I was surprised to discover that in the 1980s, Tektronix was grading 2N3904 transistors for low collector-base time constant (high bandwidth) and using just those transistors in their 100MHz oscilloscopes although not in the vertical signal path. It just seems strange to bother grading such cheap transistors but maybe they found some economic advantage.

I doubt Rigol is grading 2N3904s before assembly although they are using them as part of the vertical preamplifier but instead they could be grading the DSOs as complete units and only selling the best performing ones as 100MHz DS1104Zs. This is something I would consider if I was using 2N3904s which are marginal for 100MHz operation.

Most probably sin(x)/x was on when testing, or some other acquisition settings were different between the two 'scopes.

sin(x)/x is my guess, too. Turn it off if you don't like it.

Borjam's claim that "dots should be samples" is just an unfounded assumption on his part.

There have been complaints before that Rigol's sin(x)/x interpolation does not place the interpolated trace on the sample points. If this is the case, then I suspect truncation in order to speed up the math is the problem. The curve produced by sin(x)/x interpolation should overlap every sample point.

Quote

PS: Who looks at pulse generators in dot mode anyway? You can't calculate rise times from dots.

If the hacks are so common as some claim, and reverting the hack also claimed to be easy, and those Rigol scopes as popular as some others claim, it should be trivial to get quite a few more results to prove both cases one way or another. (Well, I didn't look what kind of measurement David Hess was looking for, maybe those are not as trivial.)

The measurement itself is trivial with a flat top reference pulse generator which most users lack but the interpretation may not be. These types of pulse generators are used for transient response calibration and verification.

An unhacked 50MHz DS1054Z should be checked for overload from the fast edge which is something we have observed in the hacked 100MHz DS1054Z DSOs. There is a good chance it will not show a problem because of its 50MHz maximum bandwidth.

A hacked 100MHz DS1054Z should be compared to a 100MHz DS1104Z. Interpreting this should be much easier since it is a comparison of supposedly identically performing DSOs. If the 100MHz DS1104Z shows signs of overload from the fast edge, then maybe they do perform identically but that indicates nothing good about the DS1104Z.

I'm also trying to understand exactly what David is explaining above, so I provided my interpretation of what a good trace would look like, and the region where the Rigol is not good...

That looks like a different problem if it is one. The change in slope from negative to positive indicates that if there was an overload, the amplifier has recovered by the time you indicate. I kept a copy of the photograph where I first noticed it shown below.

It would be practically impossible for improper transient response calibration to produce that response (it should be wavy instead of straight) and it is way too fast for it to be a thermal tail. It does look like the result of overload due to exceeding the maximum slew rate of a linear amplifier driving a transistor into cutoff or saturation.

I did not think much of it until I saw a second example and a user took measurements of bandwidth versus vertical sensitivity which showed something was going on. The same problem could cause both behaviors.

If referring that first part you quoted above, then with that particular part I was not expecting Fungus to prove his previous sentence, I was pointing out the mistake that he is showing only relying on identical hardware -idea, leaving out the different usage. Thus, some of the assumptions, based only on the identical hardware, may not necessarily be valid. (On my claim of different usage: If the hardware is identical, it must be used differently; this is pure logical deduction, otherwise the models would behave exactly the same way with bandwidth as is, and no bandwidth hacks would be needed. I think Fungus knows all that, but just didn't consider it in this context.) (Lets see if I can modify the earlier message to clarify a bit... Done.)

But I do not agree that the hardware is being used differently at all. Generally, there are simply limits placed in software to stop a parameter setting from going beyond a certain constant value. The hack likely just changes those constants from one value to another. For example, software limit the sweep speed setting. I see no way to deduce that a 1054, a 1054 hacked, and an 1104 ALL set to the identical user settings would be 'being used differently.' That seems nonsensical, but perhaps you could fabricate an example for discussion to provoke some open thought?

Quote

Also, indeed I am not trying to add any Rigol facts to discussion, I'm merely pointing that if there is an argument going, the parties should try to provide more info (not necessarily instantly), especially if the other side has some measurements or other provable facts (potentially) showing otherwise.

Otherwise things end easily like in my mind: one side refers to earlier measurements showing a potential difference, another side replies with "nonsense, identical hardware", and I get to think "what kind of answer is that, the 'identical hardware' doesn't even consider different usage of the hardware, which could explain something, and even if different usage was considered and somehow ending with idea that the scopes should behave exactly the same, the different measurement results (contradiction of another assumption) should still be explained somehow, even if found out to be just user error."

You might clarify what you mean by different useage of hardware. Application of the tool by the user or how the instrument firmware 'uses' the instrument hardware?

The argument I am considering is from David:

"The hacked ones display symptoms of non-linearity on fast edges which varies depending on vertical sensitivity. 5+ nanoseconds of overload recovery after a fast edge is not consistent with the 3.5 nanosecond transition time of a [good] 100MHz oscilloscope. This is likely related to the bandwidth measurements which vary significantly at different vertical sensitivities presumably due to insufficient full power bandwidth. In an operational amplifier, this would be due to slew rate limiting which produces the same problem. In this case I suspect one of the amplifier stages is being driven into saturation or cutoff by the fast edge which is not quite surprising given what we know of the design from Dave."

I posted a response to Alsetalokin with imagery to try and clarify the symptom, for me anyway. I'm sure plenty here don't need that clarification, but I do. And to that point, once the symptom is clear we can take a closer look.

Quote

You might not be interested on it [1054 vs. 1104] (and maybe not many others, either), but since it is out there and fungus replied, I tried to point on the weaknesses on Fungus' arguments, in the hopes that something more solid might appear. If nothing happens, no big deal.

Also note that David Hess' question is not a comparison between 1104 and 1054, but comparison between hacked 1054 and both unhacked models. Getting results just from the unhacked 1054 would already be an improvement to the situation. And he has noted the possibility of that (minor) deficiency on that "absolute performance" of the hacked 1054, so that question should then be of interest to you, too, though not necessarily a major interest.

I'm not getting your point, especially the bold part. My take is David is comparing data he's seen from hacked 1054 to to his perception or experience with "good" scopes. I would like to understand the performance differences more clearely, and their ramifications.

Here's the point why it does not matter to compare hacked 1054 to 1104. If hacked 1054 performs as expected (as a good 100 MHz scope), then there is realistically no reasonable expectation that an 1104 is going to be any better than a good scope, so why bother.

Now, since comparing a hacked 1054 to unhacked 1054 is easy and readily available, what test setup and measurement will best issultrate the deficiencies? I'm sure we cannot just compare rise times, for example, but perhaps there is something in the transient response we could look for. I assume a test like that is conducted with the sweep speed set to the same value when testing the edge, however?

That looks like a different problem if it is one. The change in slope from negative to positive indicates that if there was an overload, the amplifier has recovered by the time you indicate. I kept a copy of the photograph where I first noticed it shown below.

It would be practically impossible for improper transient response calibration to produce that response (it should be wavy instead of straight) and it is way too fast for it to be a thermal tail. It does look like the result of overload due to exceeding the maximum slew rate of a linear amplifier driving a transistor into cutoff or saturation.

I did not think much of it until I saw a second example and a user took measurements of bandwidth versus vertical sensitivity which showed something was going on. The same problem could cause both behaviors.

Thanks for that, David. I think that is from a YT video. I do not recall what he was using to generate the edge. I had posted some images of mercury switch generated edge - will be challenging to find.

A hacked 100MHz DS1054Z should be compared to a 100MHz DS1104Z. Interpreting this should be much easier since it is a comparison of supposedly identically performing DSOs. If the 100MHz DS1104Z shows signs of overload from the fast edge, then maybe they do perform identically but that indicates nothing good about the DS1104Z.

What about testing a 100MHz DS1104Z against another 100MHz DS1104Z ? Shouldn't it be considered also in these "scientific" analyses?

If referring that first part you quoted above, then with that particular part I was not expecting Fungus to prove his previous sentence, I was pointing out the mistake that he is showing only relying on identical hardware -idea, leaving out the different usage. Thus, some of the assumptions, based only on the identical hardware, may not necessarily be valid. (On my claim of different usage: If the hardware is identical, it must be used differently; this is pure logical deduction, otherwise the models would behave exactly the same way with bandwidth as is, and no bandwidth hacks would be needed. I think Fungus knows all that, but just didn't consider it in this context.) (Lets see if I can modify the earlier message to clarify a bit... Done.)

But I do not agree that the hardware is being used differently at all. Generally, there are simply limits placed in software to stop a parameter setting from going beyond a certain constant value. The hack likely just changes those constants from one value to another. For example, software limit the sweep speed setting. I see no way to deduce that a 1054, a 1054 hacked, and an 1104 ALL set to the identical user settings would be 'being used differently.' That seems nonsensical, but perhaps you could fabricate an example for discussion to provoke some open thought?

Hmm.. I had made an assumption there myself, that of the different bandwidth models actually having different (analog) bandwidth and/or rise times (in the front end path). Which, afaik, requires, for example (might have more to it), hardware low pass filter being enabled/disabled/adjusted in the hardware (via software control on the basis of the model), thus my idea of "hardware used differently". (Put in other words: both models having the filters there = "same hardware"; one disabling a piece of it = "used differently".)Perhaps an example test which would counter that idea: Does the unhacked "50MHz" Rigol have the same analog bandwidth and rise time as the "100MHz" model (and/or the hacked version)? That is, e.g. feeding in a slow signal sweep from 25MHz to near Nyquist to each model, if the hardware is the same and used identically, the results should be the same (within unit-to-unit tolerances), if the settings are the same (for setting values that are available in both models).

I guess they could do software side DSP filtering instead, but at least closer to Nyquist (let alone above that) it might be challenging, and leaves the ADC vulnerable to full unattenuated aliasing, and with unnecessarily wide noise bandwidth.

To add more to the confusion, here are some screenshots of my "liberated" 1054Z, fed with a signal from a Leo Bodnar fast edge square generator through a 50R BNC terminator to channel 1 (the other channels perform identical). The scope was configured in dot mode and fine vertical control. The single input divider relay of the DS1000Z switches between 330 and 335mV/div and this makes a big difference: at 335mV selection, the input amplifier "sees" much less signal and the VGA integrated in the A/D converter is adjusted at high gain. I kept that as a reference trace while I changed input sensitivity to 330mV, resulting in the input amp being driven with a much larger signal. The trace shapes and rise times differ by more than 1ns, but both appear to be well within the 100MHz range.

I also took a reading at 250MSa/s. Funny enough, the input divider relay is now actuated between 250 and 245mV/div. The difference of the rise time between the two settings now is neglible but something ugly goes on with the sin(X)/x trace reconstruction. It becomes obvious that even in dot mode (not only vector display), the 'scope uses this correction function (or something else...maybe a high pass filter to compensate for the input amp's high frequency dropoff) to modify the data readings. Unfortunately, the sin(x)/x "optimization" can only be disabled at 250MSa/s so it's difficult to get a better understanding of what kind of mathematical methods are used (see the third and fourth screenshots).

One may say Rigal is "cheating" in the DS1000Z, and strictly speaking that's probably correct. But what difference does it make for the average hobby user working on audio or low-speed microcontroller stuff? I guess the result is still good enough for the job, if something better is really necessary, the options are plentiful.

Are there any differences between the DS1054Z and DS1104Z models hardware-wise? Possible, but I doubt it. The instrument is too inexpensive for the manufacturer to go through the hassle of component or instrument selection.

I also took a reading at 250MSa/s. Funny enough, the input divider relay is now actuated between 250 and 245mV/div. The difference of the rise time between the two settings now is neglible but something ugly goes on with the sin(X)/x trace reconstruction. It becomes obvious that even in dot mode (not only vector display), the 'scope uses this correction function (or something else...

Yep, looks like sin(x)/x is being applied to the dots.

Maybe it's just an artifact of the way the FPGA passes the data to the display - ie. if sin(x)/x is enabled then it applies to all data types.

You could argue that it's incorrect, but I could argue that the displayed signal is more correct due to interpolation.

At a practical level, the only "problem" I can see with this is that it prevents the volt-heads from fully characterizing the front end at 1GSample/sec.