EEVblog #683 - Rigol DS1000Z & DS2000 Oscilloscope Jitter Problems

[orin]

Whether or not you are acting from an independent standpoint in your head is beside the point when your sig says otherwise.

Granted, gave that some thought and exactly why I added a footer.
I don't normally.

FYI any signature I use will instantly apply to ALL my existing posts so I have to live with this signature like a flag on my forehead.

Would you all be happier if my signature was "NZ Test Equipment Supplier"?
Is that sufficent disclosure?

Should all this discourage me from making valid comment/posts, in this thread or any other?
Just try and hold me back. 

Personally, I think suppliers on this forum should take the moral high ground and not criticize their competitors in any way.  There are plenty others here that can and do 'do that'...

Asking for a policy change re. firmware availability was OK IMO.  Criticizing the Beta terms; not OK.  It was at the equipment owner's risk that they might not be able to get any problems fixed until the general availability of the firmware.  Fair enough.  I accepted that.  My scope isn't mission critical so I could afford the risk.  It's now on its way to Chris at Rigol for testing.  I see it as their beta program doing what it is supposed to do - find problems that do not show up in in house testing.  Kudos to Rigol for making the beta available and to those that took the risk installing it.  Respect to those that didn't install it due to not being able to revert to the previous firmware.

[pickle9000]

Whether or not you are acting from an independent standpoint in your head is beside the point when your sig says otherwise.

Granted, gave that some thought and exactly why I added a footer.
I don't normally.

FYI any signature I use will instantly apply to ALL my existing posts so I have to live with this signature like a flag on my forehead.

Would you all be happier if my signature was "NZ Test Equipment Supplier"?
Is that sufficent disclosure?

Should all this discourage me from making valid comment/posts, in this thread or any other?
Just try and hold me back. 

I'd rather hear the argument against or for (Rigol or whoever),  at least then I can check it out for myself. It does not mean he's wrong (or right).

[mamalala]

Hello, I am sorry that you had trouble with the beta. I double checked here, but the firmware doesn't enable downgrading. We have limited that to avoid compatibility issues with the latest hardware and earlier firmware versions. In fact, that is tied to the same reason we ask for serial numbers before we share firmware for upgrading. It allows us to verify compatibility and make sure there will not be issues. As our firmware gets more sophisticated in verifying versions we can hopefully make that more easily available.

I'm sorry, but i'm not really buying that. You had no problem to hand out a link to the beta firmware so that people can test it. Nowhere in that post did it say something like "This firmware is only suitable for units in the serial number / hardware revision range XXX to YYY, please do not apply to units outside thatt range". In the teardown videos there are resistor straps visible that set the revision of the unit. Did Rigol place them there just for fun, or can the firmware read out what they are set to? I would assume the latter, so the firmware should be able to differentiate.

If the firmware really can't make that distinction, then it is rather poorly designed when it comes to such stuff. Heck, even 50€ sat receivers can do it and tell you that some firmware file for another type, using the exact same hardware but having slight diffences in functionality, is not compatible with the unit the user wants to upload it to.

Unless Rigol is hand-soldering every device specifically for the customers, eaach one in turn being different, it is really hard to believe that you need to have that begging-for-firmware procedure in place. If the firmware needs to be specific for a few model revisions and/or serial number ranges, but the units are unable to figure it out on their own, then simply put that information out there together with those files. You know, like "here is firmware version A. This version is only for the series B units, hardware revision C and serial number range XX to YY. Do not apply to other units". Again, you had no problem providing a beta firmware to people without any such restrictions/information attached, which strongly hints at this not really being an issue. Don't treat your customers as stupid folks who can't read, have some confidence in them, please.

Greetings,

Chris

ETA: And as has been suggested already, if the beta firmware does not allow "downgrading" to the previous non-beta version, then simply provide the previous version with a changed version number (or whatever) so that the beta recognizes it as an update and will "update". You want people to help you figure out the issue, the least you can do is to help them revert back after they tried the beta, found issues and reported them.

[orin]

Hello, I am sorry that you had trouble with the beta. I double checked here, but the firmware doesn't enable downgrading. We have limited that to avoid compatibility issues with the latest hardware and earlier firmware versions. In fact, that is tied to the same reason we ask for serial numbers before we share firmware for upgrading. It allows us to verify compatibility and make sure there will not be issues. As our firmware gets more sophisticated in verifying versions we can hopefully make that more easily available.

I'm sorry, but i'm not really buying that. You had no problem to hand out a link to the beta firmware so that people can test it. Nowhere in that post did it say something like "This firmware is only suitable for units in the serial number / hardware revision range XXX to YYY, please do not apply to units outside thatt range". In the teardown videos there are resistor straps visible that set the revision of the unit. Did Rigol place them there just for fun, or can the firmware read out what they are set to? I would assume the latter, so the firmware should be able to differentiate.

If the firmware really can't make that distinction, then it is rather poorly designed when it comes to such stuff. Heck, even 50€ sat receivers can do it and tell you that some firmware file for another type, using the exact same hardware but having slight diffences in functionality, is not compatible with the unit the user wants to upload it to.

Unless Rigol is hand-soldering every device specifically for the customers, eaach one in turn being different, it is really hard to believe that you need to have that begging-for-firmware procedure in place. If the firmware needs to be specific for a few model revisions and/or serial number ranges, but the units are unable to figure it out on their own, then simply put that information out there together with those files. You know, like "here is firmware version A. This version is only for the series B units, hardware revision C and serial number range XX to YY. Do not apply to other units". Again, you had no problem providing a beta firmware to people without any such restrictions/information attached, which strongly hints at this not really being an issue. Don't treat your customers as stupid folks who can't read, have some confidence in them, please.

I think what is going on is that Rigol are not testing downgrading firmware and are only releasing firmware that is tested to work as an upgrade from previous versions.  There is nothing to say that a downgrade wouldn't work, there is simply no incentive for them to spend time testing downgrades from a new firmware to every previous version that is in the wild.  If they haven't tested it, they aren't allowing it.  That would be my guess as to part of their motive.

I have to say that given the experience with the beta, I don't think that a list of "do"s and "don't"s as to which firmware works with which serial numbers/boards would work.  Some of us will go ahead and try it anyway...

I was once asked by a friend what the difference in the new version of a product I'd worked on was.  "Different bugs." was all I could say.  That seems to apply to many product releases these days, whether from Apple, Microsoft, Google or open source projects.

[womai]

tutech wrote:
>>Granted, gave that some thought and exactly why I added a footer.
>>I don't normally.
>>
>>FYI any signature I use will instantly apply to ALL my existing posts so I have to live with this signature like a flag on my forehead.
>>
>>Would you all be happier if my signature was "NZ Test Equipment Supplier"?
>>Is that sufficent disclosure?
>>
>>Should all this discourage me from making valid comment/posts, in this thread or any other?
>>Just try and hold me back. 

I guess it is important to separate two things:

- The fact that you are distributor for a competing brand does not by itself mean your comments are biased; they may indeed be made in best faith and without any ulterior motives.

- The problem is that others can't know that, and some (or many) will assume they ARE biased because there is obvious incentive for them being biased. This probability increases exponentially the moment your statements don't express simple facts but rather opinions or suggestions. E.g. saying "the Siglent scope X has 100 MHz bandwidth, this is superior to Rigol scopy Y which only has 50 MHz" would not get anybody suspect bias (they may still think "you want to push YOUR products"). But saying "I would not buy Rigol products because their support is bad" is not as clear-cut objective and will immediately bring up the suspicion of bias.

[tautech]

I am careful not to make such statements especially in a thread about Rigol and hope that others would show similar courtesy.

And BTW FYI I have imported Rigol product for my customers when there have been no better alternatives.
And some of you might call me biased? 

EDIT
Signature modified.

[Orange]

Surely you can press help immediately right after power up to do a force firmware update if you have the previous version firmware on a USB stick, right?

Or is the DS1000 boot sequence different than the DS2000 series?

It use to work, the help button on a DS1000Z, however, with the latest firmware upgrade, RIGOL also distributed a new bootloader that needed to be installed first. I don't know if this was really needed, I did follow the procedure that RIGOL gave me, and it includes a new boot loader.

So now the HELP button does not longer work with booting.... 

[leppie]

Surely you can press help immediately right after power up to do a force firmware update if you have the previous version firmware on a USB stick, right?

Or is the DS1000 boot sequence different than the DS2000 series?

It use to work, the help button on a DS1000Z, however, with the latest firmware upgrade, RIGOL also distributed a new bootloader that needed to be installed first. I don't know if this was really needed, I did follow the procedure that RIGOL gave me, and it includes a new boot loader.

So now the HELP button does not longer work with booting.... 

So now people have a much greater chance of bricking their scope. 

Which really sucks for me living in South Africa... It will probably cost as much as the scope did to ship it insured back to the US where it was bought from.

(Unless Rigol has an official distributor in South Africa that can deal with RMA's, does it?)

[mamalala]

I think what is going on is that Rigol are not testing downgrading firmware and are only releasing firmware that is tested to work as an upgrade from previous versions.  There is nothing to say that a downgrade wouldn't work, there is simply no incentive for them to spend time testing downgrades from a new firmware to every previous version that is in the wild.  If they haven't tested it, they aren't allowing it.  That would be my guess as to part of their motive.

I doubt that they have such a lousy record-keeping and versioning scheme in place that they are unable to keep track of what the changes in different hardware revisions are, and how those are reflected in the firmware. If they have different firmware revisions for different hardware revisions, then they should mark them as such, having a certain sub-version number tied to a specific hardware revision. People can always check on the scope itself what the actual hardware revision of their machine is, and then use the right firmware file for that. All that is assuming that they really have such a lousy bootloader/firmware upgrade mechanism which by itself is unable to detect what the actual hardware is.

And i strongly disagree about them having no incentive. Quite the opposite, i think they should have a very strong incentive to make sure that users can always revert to at least the previous firmware version easily. Just look at this thread. Allegedly Rigol themselves could not find any of the issues described on the machines they have at hand (which i find very suspicious, to be frank). This just means that what they ship to people is not what they have in-house. Which in turn suggest that the shipped units may have different issues even between each other. Thatt, in turn, means that any alleged "good" firmware upgrade can cause trouble. It would be in their best interrest to provide an easy way for users to go back to the previous firmware in case such a problem occurs.

Instead we now have people sending their scopes to Rigol so that they can figure out what is wrong with those units, since they claim that none of their units suffer from these issues. I would think it is safe to assume that during manufacture the units all get the same firmware pre-installed on them, and that Rigol knows what revision is put on scopes after a given serial number. It should be trivially easy for them to provide those firmwares, together with the info about what hardware revision / serial number range uses what firmware revision originally.

In fact, not doing so is just havoc waiting to happen. Imagine they provide a firmware update that will wreck a lot of the units out in the fild. Again, keep in mind that according to them the units out in the field must be different from the ones they have in-house. If such a thing would happen, the only way to undo it would be for people having to ship their units back to Rigol, who in turn have to fix them and ship them back out again. That would cause them way more work and trouble than simply maintaining a download archive for firmwares with the infos i suggested.

After all, most manufacturers manage to do exactly that. I don't see any good reason why Rigol should be special.

Greetings,

Chris

[marmad]

After all, most manufacturers manage to do exactly that. I don't see any good reason why Rigol should be special.

Yes. If we lived in a world where Rigol was the only company that made/offered FW upgrades to their equipment, we might accept their arguments. But we don't.

In fact, as Chris points out, almost every other manufacturer in the world deals with this in a better fashion then Rigol. This - coupled with the general history of Chinese T&M manufacturers reticence plus the fact that Rigol is still doing chip-grinding and rebadging to try to hide part numbers - has to lead any logical person to believe that the nonsense surrounding FW availability (and the almost total lack of version notes for public perusal) - is due solely to Rigol's attempt to maintain some semblance of "control" over an area that should be completely aboveboard and transparent.

[Orange]

None of this will stop me from buying more Rigol gear unless they become hostile toward their customers over issues.   

Well, did not they produced a nice letter saying they did a test and found no issues. It was all in user's heads, before we pointed out to the PLL problem.
Aren't we having a deja vu now, this time with them having tested the beta which was also successful as they say. It is again all in the heads of those who claims they have their scopes locking up and/or the issue not fixed.

Cant wait for MarkL to hook up his SA to the "final firmware-d" scope. I think I have earned some credibility here to say these guys have no idea what they are doing to the PLL. It was not a proper fix, it was a desperate attempt to patch the hole by any means, whatever seemed to work.

The PLL problem seems easy to fix if you can avoid hardware changes. The good thing about this ADF chip is that Analog Devices backs it up with software that give you a possibility to simulate your design. Rigol could have done this easily.
Even without the simulation software this is not a impossible to do.  PLL loop-filter design is not a hit and miss game.   

[motocoder]

Hello, I am sorry that you had trouble with the beta. I double checked here, but the firmware doesn't enable downgrading. We have limited that to avoid compatibility issues with the latest hardware and earlier firmware versions. In fact, that is tied to the same reason we ask for serial numbers before we share firmware for upgrading. It allows us to verify compatibility and make sure there will not be issues. As our firmware gets more sophisticated in verifying versions we can hopefully make that more easily available.

I'm sorry, but i'm not really buying that. You had no problem to hand out a link to the beta firmware so that people can test it. Nowhere in that post did it say something like "This firmware is only suitable for units in the serial number / hardware revision range XXX to YYY, please do not apply to units outside thatt range". In the teardown videos there are resistor straps visible that set the revision of the unit. Did Rigol place them there just for fun, or can the firmware read out what they are set to? I would assume the latter, so the firmware should be able to differentiate.

If the firmware really can't make that distinction, then it is rather poorly designed when it comes to such stuff. Heck, even 50€ sat receivers can do it and tell you that some firmware file for another type, using the exact same hardware but having slight diffences in functionality, is not compatible with the unit the user wants to upload it to.

Unless Rigol is hand-soldering every device specifically for the customers, eaach one in turn being different, it is really hard to believe that you need to have that begging-for-firmware procedure in place. If the firmware needs to be specific for a few model revisions and/or serial number ranges, but the units are unable to figure it out on their own, then simply put that information out there together with those files. You know, like "here is firmware version A. This version is only for the series B units, hardware revision C and serial number range XX to YY. Do not apply to other units". Again, you had no problem providing a beta firmware to people without any such restrictions/information attached, which strongly hints at this not really being an issue. Don't treat your customers as stupid folks who can't read, have some confidence in them, please.

Greetings,

Chris

ETA: And as has been suggested already, if the beta firmware does not allow "downgrading" to the previous non-beta version, then simply provide the previous version with a changed version number (or whatever) so that the beta recognizes it as an update and will "update". You want people to help you figure out the issue, the least you can do is to help them revert back after they tried the beta, found issues and reported them.

UPDATE: The non-downgrade-able firmware issue does not apply to the DS2072 - at least to the beta firmware they installed on my DS2072. Apologies for my previous comments that may have led some to believe otherwise.

[poida_pie]

It's not hard to hate the DS1054Z now. But let's give Rigol the week or so they said they need to
provide the fixed firmware.

From what I gather from Bud and MarkL, there are a range of performances of the PLL depending on the borderline
stability of the PLL filter. I suspect that most problem DS1054Z DSOs will be fixed "well enough" in the view of Rigol.
I think there is a large variation in the degree of jitter/PLL problems, stemming from variation in values of the filter components.  Should the promised new firmware not fix my 70 ns wide jitter I plan to open the DSO
and try some different capacitors (C2 mentioned in
https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg561375/#msg561375)
And if that does not fix it, then it's either ebay or chopping block with youtube video documentation.
What would I get for a DSO with 70 ns jitter? AUS $200? probably less.
Not worth spending any more time really, I blow $50 a week on beer.

[leppie]

It's not hard to hate the DS1054Z now. But let's give Rigol the week or so they said they need to
provide the fixed firmware.

From what I gather from Bud and MarkL, there are a range of performances of the PLL depending on the borderline
stability of the PLL filter. I suspect that most problem DS1054Z DSOs will be fixed "well enough" in the view of Rigol.
I think there is a large variation in the degree of jitter/PLL problems, stemming from variation in values of the filter components.  Should the promised new firmware not fix my 70 ns wide jitter I plan to open the DSO
and try some different capacitors (C2 mentioned in
https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg561375/#msg561375)
And if that does not fix it, then it's either ebay or chopping block with youtube video documentation.
What would I get for a DSO with 70 ns jitter? AUS $200? probably less.
Not worth spending any more time really, I blow $50 a week on beer.

From what I can see, me and you are the only people that have reported being worse off with the beta FW in terms of the jitter.

I am also in the southern hemisphere and love beer too. Do I smell a conspiracy? 

Did you buy yours from a local supplier or also imported it like me?

[Bud]

Should the promised new firmware not fix my 70 ns wide jitter I plan to open the DSO
and try some different capacitors (C2 mentioned in
https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg561375/#msg561375)

Do not bother if you installed the beta. Trying C2 may only work for the last firmware before the beta. As to the new firmware we first need to see what else changed.

[marmad]

Totally agree. In my case, Chris and team "upgraded" the firmware on my scope while they had it at their facility to use in investigating a network bug. So I had no choice in the matter. My only plan for this scope is to sell it. First that was delayed waiting for Chris and Steve to return it. Now that is delayed waiting for a firmware that doesn't randomly lock up the scope (WORSE than the situation before I sent it in for "repair").

Are you saying you can't simply downgrade the firmware via the bootloader method on the DS2000? Afaik, this would be a first for the DS2000 series.

I don't really know about the bootloader history/availability on the DS1000Z series (there is no reference to it that I can find), but if what you're saying is true, it negates the Rigol published and long-circulated document, "DS2000 DS4000 DS6000 Firmware Upgrade Procedure".

[Bud]

OK , decided to have some fun with the previously posted photo of DS2000 and DS1000 PLL, on which the PLL chip on DS2000 was shaved to remove marking - photo 1 below. It was not hard to copy the needed part of the PLL image from the DS1000 board pic and superimpose on the DS2000 shaved chip in Photoshop. Some casual opacity and brightness adjustment on the inserted clip and here ya go, you can see the markings aligned nicely in picture 2, a rotated close-up picture 3 is provided for your convenience.

 

So here you have a convincing evidence the same 4360-7 chip was used in DS2000, and a small problem with that is the chip is rated for 1.85GHz max, whereas DS2000 is a 2GSa scope. What is that, bean counting trying to save by using the same chip or what. Mind boggling. Having a feeling we are about to open a fresh can of worms on DS2000. Let me throw one in right away - chances are the PLL in DS2000 suffers the exact same issue as on DS1000, i.e the PLL is not in locked state. If someone has access to DS2000 inners please check PLL pin 24 with a scope and post a screenshot.

[sergey]

Bud, i've got DS2072 here which i wouldn't mind opening. The only issue is -- it's the only oscilloscope here atm.  And afraid i can't probe oscilloscope by itself, can i?

Not really familiar with PLL, but if it's expected to be a constant high level guess probing with dmm would work?

[Orange]

Bud, i've got DS2072 here which i wouldn't mind opening. The only issue is -- it's the only oscilloscope here atm.  And afraid i can't probe oscilloscope by itself, can i?

Not really familiar with PLL, but if it's expected to be a constant high level guess probing with dmm would work?

I would not bother opening a sealed DS2072, there is no jitter problem on a DS2000 series scope. You will probably also loose your guarantee.

[poida_pie]

From what I can see, me and you are the only people that have reported being worse off with the beta FW in terms of the jitter.

I am also in the southern hemisphere and love beer too. Do I smell a conspiracy? 

Did you buy yours from a local supplier or also imported it like me?

Only yours and mine are worse after beta? Odds are firming for a DSO destruction on the chopping block.
I bought it from a local Rigol agent.

[leppie]

From what I can see, me and you are the only people that have reported being worse off with the beta FW in terms of the jitter.

I am also in the southern hemisphere and love beer too. Do I smell a conspiracy? 

Did you buy yours from a local supplier or also imported it like me?

Only yours and mine are worse after beta?

From what I can recall. There are probably quite a few that have not applied the beta after hearing about the keyboard issue.

[MarkL]

Bud, i've got DS2072 here which i wouldn't mind opening. The only issue is -- it's the only oscilloscope here atm.  And afraid i can't probe oscilloscope by itself, can i?

Not really familiar with PLL, but if it's expected to be a constant high level guess probing with dmm would work?

In this case, the probe ground is also the scope internal ground and the signal you're probing is not synchronized to the sample clock, so yes, you can probe the scope with itself.  You could also look at the pin with a DMM but you wouldn't see any small blips if it was falling out of lock for short moments.

But more importantly (unless someone has already done it) and assuming this is indeed a 4360-7, we don't know how the MUXOUT pin has been programmed.  It could be a number of things and LOCK is only one of them.  You'd have to decode the SPI bus to know, and it appears they've conveniently provided labeled probe points for it (LE, DATA, CLK).

Although not as definitive, you might also be able to examine a long-point FFT taken with the scope of a known stable source (like a crystal oscillator).  If the sample clock is unstable you should see modulation in the FFT.  I'm not familiar with how many points the various Rigol models use for it's internal FFT calculations, so I would download the long raw waveform capture and process it externally.  Obviously this doesn't involve taking the scope apart, and it might be a good starting point that would show if there's any egregious problem.  However, it's still not proof the PLL is locked.

[sergey]

I would not bother opening a sealed DS2072, there is no jitter problem on a DS2000 series scope. You will probably also loose your guarantee.

Don't think it's on the warranty (i've bought it like 2.5 years ago or so), and sending it back to rigol could cost more than the scope i'm afraid.

It's likely nothing to do with the trigger jitter indeed, it's more like a curiosity of what's going on. Maybe it's something more like "no discovered jitter issue" since the arrangement is the same as in ds1000z

[sergey]

MarkL, i'll check tomorrow if i can get second scope here. If not i'll try to probe itself without blowing it up

As for instability in the clock, my first thought after watching the video was whether using external low-drifting clock (like rubidium standard) would do any difference to the jitter issue on ds1000z series.

[Orange]

I would not bother opening a sealed DS2072, there is no jitter problem on a DS2000 series scope. You will probably also loose your guarantee.

Don't think it's on the warranty (i've bought it like 2.5 years ago or so), and sending it back to rigol could cost more than the scope i'm afraid.

It's likely nothing to do with the trigger jitter indeed, it's more like a curiosity of what's going on. Maybe it's something more like "no discovered jitter issue" since the arrangement is the same as in ds1000z

Well the PLL in a DS2000 runs at 2GHz, the one in the DS1000z on 1 GHz, also we don't know the loop filter component values of the DS2000 and we don't know how the chip is programmed.
But I really doubt there is a similar problem that needs fixing on the DS2000 since is no jitter on these beauties.